KMTS para Representação de Comportamento Parcial em Desenvolvimento de Software

UNIVERSIDADE FEDERAL DA BAHIA
DISSERTAÇÃO DE MESTRADO
Sistemas de Transições Modais de Kripke para Representação de

Comportamento Parcial no Desenvolvimento Incremental e
Iterativo de Software
Efraim Zalmoxis de Almeida Machado
Programa de Pós-Graduação em Ciência da Computação
Salvador
30 de novembro de 2016
EFRAIM ZALMOXIS DE ALMEIDA MACHADO
SISTEMAS DE TRANSIÇÕES MODAIS DE KRIPKE PARA

REPRESENTAÇÃO DE COMPORTAMENTO PARCIAL NO
DESENVOLVIMENTO INCREMENTAL E ITERATIVO DE
SOFTWARE
Esta Dissertação de Mestrado foi

apresentada ao Programa de Pós-
Graduação em Ciência da Com-
putação da Universidade Federal da
Bahia, como requisito parcial para
obtenção do grau de Mestre em
Ciência da Computação.
Orientadora: Aline Maria Santos Andrade
Salvador
30 de novembro de 2016
Sistema de Bibliotecas - UFBA
Machado, Efraim Zalmoxis de Almeida.

Sistemas de Transições Modais de Kripke para Representação de Com-
portamento Parcial no Desenvolvimento Incremental e Iterativo de Software
/ Efraim Zalmoxis de Almeida Machado – Salvador, 2016.
154p.: il.
Orientadora: Prof. Dr. Aline Maria Santos Andrade.

Dissertação (Mestrado) – Universidade Federal da Bahia, Instituto de
Matemática, 2016.
1. KMTS. 2. Informação Parcial. 3. Desenvolvimento de Software. 4.

Conjunção. 5. Composição Paralela. 6. Jogo de Refinamento. 7. Reparo
de Refinamento. I. Andrade, Aline Maria Santos. II. Universidade Federal
da Bahia. Instituto de Matemática. III Tı́tulo.
CDD – XXX.XX
CDU – XXX.XX.XXX
TERMO DE APROVAÇÃO
EFRAIM ZALMOXIS DE ALMEIDA MACHADO
SISTEMAS DE TRANSIÇÕES MODAIS DE

KRIPKE PARA REPRESENTAÇÃO DE
COMPORTAMENTO PARCIAL NO
DESENVOLVIMENTO INCREMENTAL E
ITERATIVO DE SOFTWARE
Esta Dissertação de Mestrado foi julgada

adequada à obtenção do tı́tulo de Mestre em
Ciência da Computação e aprovada em sua
forma final pelo Programa de Pós-Graduação
em Ciência da Computação da Universidade
Federal da Bahia.
Salvador, 30 de Novembro de 2016
Profa. Dra. Aline Maria Santos Andrade

Universidade Federal da Bahia
Prof. Dr. Adolfo Almeida Duran

Universidade Federal da Bahia
Prof. Dr. Alexandre Cabral Mota

Universidade Federal de Pernambuco
Este trabalho é dedicado a todos que, de forma direta ou
indireta, contribuı́ram para que eu o concluı́sse, sem esque-
cer daqueles que sentiram minha ausência neste perı́odo,
mas aceitaram e compreenderam que, muitas vezes, minha
falta era necessária.
AGRADECIMENTOS
Agradeço à minha orientadora, Profª Dra. Aline Andrade, pela paciência em ter me
ouvido, pela dedicação em ter me ensinado e por todo incentivo dado. Esta atenção foi
muito importante para que eu concluı́sse minha dissertação e por isto, serei eternamente
grato.
Agradeço também aos amigos, familiares e todos aqueles que me apoiaram e me
ouviram durante este perı́odo, com especial importância às discussões com meu amigo
Jandson e ao professor Sandro Andrade, que contribuı́ram para esta pesquisa.
vii
Andar sobre as águas e fazer software a partir de uma especificação é
simples se ambas estiverem congeladas.
—EDWARD V BERARD
RESUMO
O projeto de software, na abordagem iterativa e incremental, lida com novos requisitos

ao longo do desenvolvimento, que implicam em constantes mudanças no projeto, e me-
canismos que deem suporte para o desenvolvimento na presença de informação parcial e
incompleta são importantes para reduzir o impacto dessas mudanças. Expressar incerte-
zas a respeito do comportamento pretendido do software (ou dos seus componentes) pode
evitar a tomada de decisões precipitadas, que poderiam acarretar em erros de projeto.
Neste contexto, diversos trabalhos utilizam sistemas de transições modais na modelagem
de sistemas, que permitem expressar incerteza de forma explı́cita através de modalidades
em suas transições.
Um Sistema de Transição Modal de Kripke (KMTS) além de conter modalidades em
suas transições, também expressa indefinições em nı́vel de proposições nos estados. A in-
determinação nos estados é interessante, pois permite que vários estados sejam abstraı́dos
em um mesmo estado, evitando uma definição prévia de todos os estados do sistema nas
fases iniciais do desenvolvimento. Todavia, existem poucos trabalhos que utilizam KMTS
para especificação parcial aplicados no desenvolvimento de software.
O presente trabalho estuda o uso de modelos KMTS para explicitar informações par-
ciais durante o desenvolvimento de software, trazendo contribuições na criação, na análise
e no reparo destes modelos. Em relação à criação de modelos, propomos um algoritmo de
sı́ntese de modelos KMTS a partir de diagramas de sequência, que é uma adaptação de
um algoritmo proposto na literatura para Modal Transition System (MTS). Em relação
à análise de modelos, definimos as operações de conjunção e de composição paralela
bem como a relação de refinamento modal forte para modelos KMTS. O conceito de
refinamento para KMTS é também caracterizado nessa dissertação como um jogo e um
algoritmo para o jogo do refinamento é proposto, discutido e validado. A contribuição no
reparo de modelos se dá através do estudo do problema de reparo do refinamento para
KMTS, isto é, como alterar um modelo KMTS para que ele seja um refinamento de outro
modelo KMTS. Para este problema, algoritmos são também propostos, discutidos e vali-
dados. Entendemos que esta solução poderá trazer contribuições no reparo automático de
modelos e pode ser aplicada, por exemplo, na análise de impacto de mudanças para de-
terminar qual a mudança menos custosa a se fazer em um determinado modelo de forma
a satisfazer determinadas propriedades. A partir das contribuições na construção, análise
e reparo de modelos KMTS, o presente trabalho define uma base para um framework
formal que pode ser utilizado na construção e evolução de modelos comportamentais de
software.
Palavras-chave: KMTS; Informação Parcial; Desenvolvimento de Software; Con-

junção; Composição Paralela; Jogo de Refinamento; Reparo de Refinamento;
xi
ABSTRACT
The software design, in the iterative and incremental approach, deals with new require-
ments throughout development that imply constant changes in the design, and mecha-
nisms that support development in the presence of partial and incomplete information
are important to reduce the impact of these Changes. Expressing uncertainties about the
intended behavior of the software (or its components) can avoid making hasty decisions
that could lead to design errors. In this context, several studies use modal transition
system to modeling systems and to express explicitally uncertainty through modalities in
their transitions.
A Kripke Modal Transition System (KMTS), besides containing modalities in its
transitions, also expresses propositional level indefinits in the states. Indeterminacy in
states is interesting because it allows several states to be abstracted in the same state,
avoiding a prior definition of all states of the system in the early stages of development.
However, there are few papers that use KMTS for partial specification applied in software
development.
The present work studies the use of KMTS models to represent partial information du-
ring software development, introduzing contributions in the creation, analysis and repair
of these models. In relation to the modeling, we propose an algorithm for the synthesis of
KMTS models from sequence diagrams, which is an adaptation of an algorithm proposed
in the literature for Modal Transition System (MTS). In relation to the model analysis,
we define the conjunction and parallel composition operations as well as the strong mo-
dal refinement relation for KMTS models. The concept of refinement for KMTS is also
characterized in this dissertation as a game and an algorithm for the refinement game
is proposed, discussed and validated. The contribution in model repair is through the
study of the refinement repair problem for KMTS, that is, how to change a KMTS model
so that it is a refinement of another KMTS model. For this problem, algorithms are also
proposed, discussed and validated. We believe that this solution can bring contributions
to automatic model repair and can be applied, for example, in the impact analysis of
changes to determine which is the least costly change to be made in a given model in
order to satisfy certain properties
From the contributions in the construction, analysis and repair of KMTS models, the
present work defines a basis for a formal framework that can be used in the construction
and evolution of software behavioral models.
Keywords: KMTS; Partial Information; Software Development; Conjunction; Parallel

Composition; Refinement Game; Refinement Repair;
xiii
SUMÁRIO
Capı́tulo 1—Introdução 1
1.1 Escopo do Trabalho e Contribuições . . . . . . . . . . . . . . . . . . . . . 4
1.2 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 6
Capı́tulo 2—Modelos Comportamentais 7

2.1 Modelos de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Sistemas de Transição e Especificações Modais . . . . . . . . . . . . . . . 8
2.2.1 Simulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.2 Especificações Comportamentais Parciais . . . . . . . . . . . . . . 10
2.2.3 KMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Teoria das Especificações Parciais . . . . . . . . . . . . . . . . . . . . . . 12
2.3.1 Relação de Refinamento . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 Operador de Composição Paralela . . . . . . . . . . . . . . . . . . 17
2.3.3 Operador de Conjunção . . . . . . . . . . . . . . . . . . . . . . . 17
Capı́tulo 3—Trabalhos Relacionados 21

3.1 Modelos Comportamentais Parciais . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Sistema de Transição Modal de Kripke . . . . . . . . . . . . . . . 23
3.2 Construção de Especificações Parciais no Desenvolvimento de Software . 24
3.3 Análise de Especificações Parciais no Desenvolvimento de Software . . . . 26
3.3.1 Jogo de Refinamento . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.4 Reparo de Refinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.5 Posicionamento do Presente Trabalho em Relação aos Demais . . . . . . 28
Capı́tulo 4—Sı́ntese de Modelos KMTS a partir de Cenários 29

4.1 Modelos KMTS com Ações . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Algoritmo para Sı́ntese de KMTS . . . . . . . . . . . . . . . . . . . . . . 30
4.2.1 Entradas e Saı́das . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.3 Etapas do Algoritmo para Sı́ntese de KMTS . . . . . . . . . . . . . . . . 34
4.3.1 Etapa I: Restrições por Componente . . . . . . . . . . . . . . . . 34
4.3.2 Etapa II: Diagrama de Sequência por Componente . . . . . . . . 36
4.3.3 Etapa III: KMTS Inicial por Componente . . . . . . . . . . . . . 38
4.3.4 Etapa IV: Comportamento Obrigatório por Componente . . . . . 42
4.4 Análise do Algoritmo de Sı́ntese . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Validação do Algoritmo de Sı́ntese . . . . . . . . . . . . . . . . . . . . . . 47
xv
xvi SUMÁRIO
Capı́tulo 5—Relações e Operações para Modelos KMTS 49

5.1 Refinamento de KMTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.1.1 Propriedades da Relação de Refinamento . . . . . . . . . . . . . . 52
5.1.2 Relação de Refinamento no Desenvolvimento de Software . . . . . 53
5.2 Composição Paralela para Modelos KMTS . . . . . . . . . . . . . . . . . 57
5.2.1 Propriedades do Operador de Composição Paralela . . . . . . . . 59
5.2.2 Exemplo de Operação de Composição Paralela no Desenvolvimento
de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Conjunção de Modelos KMTS . . . . . . . . . . . . . . . . . . . . . . . . 61
5.3.1 Propriedades do Operador de Conjunção . . . . . . . . . . . . . . 64
5.3.2 Exemplo de Operação de Conjunção no Desenvolvimento de Software 65
Capı́tulo 6—Jogo do Refinamento 69

6.1 Definição Intuitiva do Jogo de Refinamento . . . . . . . . . . . . . . . . . 69
6.2 Jogo do Refinamento Como um Grafo . . . . . . . . . . . . . . . . . . . . 73
6.3 Algoritmo do Jogo de Refinamento . . . . . . . . . . . . . . . . . . . . . 78
6.3.1 Análise do Algoritmo do Jogo de Refinamento . . . . . . . . . . . 80
6.3.2 Validação do Algoritmo do Jogo de Refinamento . . . . . . . . . . 82
Capı́tulo 7—Reparo de Refinamento 91

7.1 O Problema do Reparo de Refinamento . . . . . . . . . . . . . . . . . . . 91
7.1.1 Representando Mudanças em Modelos KMTS . . . . . . . . . . . 92
7.1.2 Análise do Problema do Reparo de Refinamento . . . . . . . . . . 94
7.1.3 Uma Solução Algorı́tmica para o Reparo de Refinamento . . . . . 100
7.2 Reparo de Refinamento Baseado no Jogo do Refinamento . . . . . . . . . 102
7.3 Algoritmo de Reparo de Refinamento Baseado no Jogo de Refinamento . 107
7.3.1 Variações do RRBJ . . . . . . . . . . . . . . . . . . . . . . . . . . 109
7.3.2 Análise do RRBJ . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
7.3.3 Exemplo de Execução do RRBJ e Algumas de Suas Variações . . 113
7.3.4 Validação dos Algoritmos de Reparo . . . . . . . . . . . . . . . . 116
Capı́tulo 8—Conclusões 123

8.1 Sı́ntese de KMTS a partir de Cenários . . . . . . . . . . . . . . . . . . . 123
8.2 Relação de Refinamento e Operações de Composição Paralela e Conjunção 123
8.3 Jogo de Refinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.4 Reparo do Refinamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
8.5 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
8.6 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Apêndice A—Tópicos de Engenharia de Software 135

A.1 Cenários . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
SUMÁRIO xvii
A.2 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

A.3 Object Constraint Language (OCL) . . . . . . . . . . . . . . . . . . . . . 136
A.4 Desenvolvimento Incremental e Iterativo . . . . . . . . . . . . . . . . . . 138
A.4.1 Especificação e Implementação . . . . . . . . . . . . . . . . . . . . 140
Apêndice B—Definições Relacionadas 143

B.1 Bissimulação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
B.2 Sistema de Transição Modal - MTS . . . . . . . . . . . . . . . . . . . . . 144
B.3 Variantes do Refinamento Modal Forte . . . . . . . . . . . . . . . . . . . 144
Apêndice C—Provas do capı́tulo 6 147

LISTA DE FIGURAS
1.1 Visão de alto-nı́vel de um processo de desenvolvimento que utiliza KMTS

suportado por métodos formais . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Dois sistemas de transição onde N simula o comportamento de M (BAIER;

KATOEN; LARSEN, 2008) . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Exemplo do sinal de trânsito . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3 Uma estrutura de Kripke . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Exemplo de refinamento. A casa mais detalhada é um refinamento da
outra casa. Adaptado de Fairbanks (2010) . . . . . . . . . . . . . . . . . 13
2.5 Exemplo de refinamento com semântica fechada (A) e semântica aberta
(B). A casa mais detalhada é um refinamento da outra casa. Adaptado de
Fairbanks (2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 Um modelo parcial M e uma implementação N . . . . . . . . . . . . . . 15
2.7 Dois modelos parciais que não possuem uma relação de refinamento modal 15
2.8 Uma especificação mista que não possui implementações . . . . . . . . . 16
2.9 Duas especificações mistas M e N com I pM q I pN q, mas não vale M ¨ N 16
2.10 Exemplo da incompletude da relação de refinamento modal em relação ao
operador de composição paralela . . . . . . . . . . . . . . . . . . . . . . . 18
2.11 Exemplos de MRC em (A) e de RCM em (B) . . . . . . . . . . . . . . . 19
3.1 Visão geral do algoritmo de sı́ntese de MTS proposto por Krka et al. (2009)
(KRKA et al., 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Diagrama de sequência de solicitação e acesso do componente Recurso pelo

componente Módulo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Diagrama de sequência que representa um cenário onde o componente
módulo solicita acesso, mas não pode acessar um recurso . . . . . . . . . 34
4.3 Diagrama de sequência estendido antes (A) e depois da propagação (B)
para o componente Módulo baseado no diagrama de sequência da Figura 4.1 38
4.4 KMTS inicial do componente Módulo da Figura 4.1 . . . . . . . . . . . . 41
4.5 Operação de Refino para evitar auto-loop obrigatório . . . . . . . . . . . 42
4.6 KMTS inicial do componente Módulo . . . . . . . . . . . . . . . . . . . . 44
5.1 KMTSs representando os possı́veis comportamentos da câmera. Em (A)

uma especificação do comportamento da câmera. Em (B) um possı́vel refi-
namento da especificação mostrada em (A). Em (C) um modelo de compor-
tamento da câmera que não é um refinamento da especificação mostrada
em (A). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
xix
xx LISTA DE FIGURAS
5.2 Regras das transições do operador de composição paralela . . . . . . . . 58

5.3 Modelos KMTS para o software de vistoria remota, onde (A) representa o
e-Formulário e (B) o sincronizador. . . . . . . . . . . . . . . . . . . . . . 61
5.4 Composição paralela dos modelos e-Formulário e Sincronizador. . . . . . 62
5.5 Regras do transições do operador de conjunção . . . . . . . . . . . . . . . 63
5.6 Duas versões do componente e-Formulário para atender a requisitos de
georreferenciamento e fotografia . . . . . . . . . . . . . . . . . . . . . . . 66
5.7 Conjunção entre os modelos exibidos na Figura 5.6 . . . . . . . . . . . . 66
6.1 Dois KMTS M, N, onde vale M ¨ N . . . . . . . . . . . . . . . . . . . . . 71

6.2 Configurações possı́veis de um jogo de refinamento entre os modelos M e
N da Figura 6.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Jogo do refinamento entre os modelos M e N da Figura 6.1 expressos em
um grafo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 Estrutura dos testes realizados por grupo . . . . . . . . . . . . . . . . . . 84
6.5 Gráfico do tempo médio de execução (milissegundos) do algoritmo do jogo
de refinamento de acordo com a quantidade de estados . . . . . . . . . . 85
de refinamento de acordo com a quantidade de transições por estado . . . 86
de refinamento de acordo com a quantidade de proposições por estado . . 86
de refinamento de acordo com o crescimento proporcional do modelo . . . 87
6.9 Gráfico do cruzamento dos dados do Grupo-estado e Grupo-proporcao . . 88
7.1 Gráfico do tempo de execução (em milissegundos) do Algoritmo 10 em

relação número de mudanças primitivas aplicáveis . . . . . . . . . . . . . 101
7.2 Dois Modelos M e N tal que M ª N e duas saı́das do algoritmo RRE . . 101
7.3 Jogo de refinamento entre os modelos M e N da Figura 7.1 . . . . . . . . 102
7.4 Exemplo de execução do algoritmo de reparo de refinamento entre os mo-
delos M e N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.5 Examplo de uma solução não minimal retornada pelo algoritmo de reparo
de refinamento. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
7.6 Modelos M e N tal que M ª N . . . . . . . . . . . . . . . . . . . . . . . 114
7.7 Jogo do refinamento entre os modelos M e N da Figura 7.6(A) e entre os
modelos M e N 9 da Figura 7.10 . . . . . . . . . . . . . . . . . . . . . . . 114
7.8 Modelos resultantes das possı́veis mudanças para remover a causa de falha
cf1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
cf2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
cf3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
7.11 Um modelo resultante do processo de reparo de refinamento pelos algorit-
mos RRBJ, RRBJ-C e RRBJ-U . . . . . . . . . . . . . . . . . . . . . . . 116
LISTA DE FIGURAS xxi
7.12 Estrutura dos testes realizados por grupo . . . . . . . . . . . . . . . . . . 118

7.13 Gráfico do tempo médio de execução, em milissegundos, dos algoritmos de
reparo de refinamento por quantidade de causas de falha do GRUPO-UM 118
reparo de refinamento por quantidade de causas de falha do GRUPO-DOIS 119
reparo de refinamento por quantidade de causas de falha do GRUPO-TRES120
7.16 Gráfico do tempo médio de execução, em milissegundos, do algoritmo
RRBJ por quantidade de causas de falha e por grupo . . . . . . . . . . . 121
7.17 Quantidade de modelos encontrados como solução dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-TRES . . 121
A.1 Elementos do Diagrama de Sequência da UML 2.0. Adaptado de Lund e

Stølen (2006) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
A.2 Exemplo de diagrama de sequência do fluxo de login . . . . . . . . . . . . 137
A.3 Modelo de desenvolvimento incremental . . . . . . . . . . . . . . . . . . . 139
A.4 Modelo de desenvolvimento iterativo . . . . . . . . . . . . . . . . . . . . 140
A.5 Modelo de desenvolvimento iterativo e incremental . . . . . . . . . . . . 141
B.1 Dois sistemas de transição bissimilares representando uma máquina de

vender bebidas e refrigerante (BAIER; KATOEN; LARSEN, 2008) . . . . 144
B.2 Exemplo de dois modelos que não possuem relação de refinamento forte,
mas possuem uma relação de refinamento fraco . . . . . . . . . . . . . . 145
B.3 Exemplo de refinamento fraco que contradiz o senso de refinamento . . . 146
LISTA DE TABELAS
6.1 Variáveis de acordo com o grupo de teste . . . . . . . . . . . . . . . . . . 84

6.2 Tempo médio de execução (milissegundos) do algoritmo do jogo de refina-
mento de acordo com a quantidade de estados . . . . . . . . . . . . . . . 85
mento de acordo com a quantidade de transições por estado . . . . . . . 85
mento de acordo com a quantidade de proposições por estado . . . . . . . 86
mento de acordo com o crescimento proporcional do modelo . . . . . . . 87
7.1 Variáveis de acordo com o grupo de teste . . . . . . . . . . . . . . . . . . 117

7.2 Tempo médio de execução, em milissegundos, dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-UM . . . . . 118
7.3 Tempo médio de execução, em milissegundos, dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-DOIS . . . . 119
7.4 Tempo médio de execução, em milissegundos, do algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-TRES . . . . 120
7.5 Quantidade de modelos encontrados como solução dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-TRES . . 121
xxiii
Capı́tulo
1
INTRODUÇÃO
Nos dias atuais, em um ambiente globalizado, onde mudanças ocorrem a todo instante,
softwares devem ser produzidos rapidamente para que empresas possam obter proveito
das oportunidades e se manterem competitivas (SOMMERVILLE, 2011). Softwares são
construı́dos em meio a uma série de dúvidas decorrentes do conhecimento incompleto
da aplicação tanto do cliente quanto dos seus projetistas. Mudanças rápidas tornam
impossı́vel obter um conjunto estável de requisitos, pois, geralmente, o conhecimento
do usuário sobre suas reais necessidades e, consequentemente, como o sistema deve se
comportar é inicialmente parcial e só vai se complementando no decorrer do ciclo de
desenvolvimento do software. Desta forma, especificar todo o sistema para só depois
implementá-lo pode durar um prazo maior que o acordado e o software não satisfazer as
necessidades da aplicação.
Para contornar este problema, o desenvolvimento iterativo se baseia na ideia de dis-
ponibilizar uma versão inicial do software para o usuário ir refinando-a, através de novos
requisitos, até obter-se o software desejado (SOMMERVILLE, 2011). De maneira geral,
no desenvolvimento iterativo, há uma intercalação cı́clica das quatro etapas de desenvol-
vimento de software: análise de requisitos, projeto, implementação e teste. Esta inter-
calação faz com que o software seja construı́do em partes e, desta forma, durante o ciclo de
desenvolvimento do mesmo, o cliente consegue definir melhor quais as suas necessidades,
à medida que novos requisitos surgem. Outras abordagens complementares ao desenvol-
vimento iterativo focam na construção rápida de um software, como o desenvolvimento
incremental (PRESSMAN, 2005), no qual o software é desenvolvido em incrementos, o
que torna a tarefa de entender os requisitos do sistema e propor uma solução ainda mais
desafiadora.
Neste contexto, uma das etapas mais complexas no processo de desenvolvimento é
a construção do projeto, devido às recorrentes mudanças que implicam em constante
adaptação de uma solução. Em geral, os projetos de software são realizados de modo
que o projetista atue com base no comportamento já definido, que em geral, não reflete
completamente os requisitos. A imaturidade em relação ao conhecimento do problema
e a necessidade de definir uma solução completa podem ter como consequência decisões
1
2 INTRODUÇÃO
precipitadas que acarretam em projetos incorretos. Erros no projeto implicam em refazer

parte do trabalho já realizado e, consequentemente, em um maior custo.
Na fase de projeto, modelos são construı́dos para modelar componentes e o sistema
como um todo. Muitas vezes os modelos propostos no projeto de um software são analisa-
dos manualmente ou testados através de um protótipo. Todavia, softwares são formados
por componentes que interagem entre si ou com outros sistemas e, analisar ou testar o
comportamento e a interação entre os modelos dos componentes é uma tarefa exaustiva,
principalmente no contexto de constantes mudanças do desenvolvimento iterativo e incre-
mental. O uso de técnicas de verificação formal de modelos permite automatizar a análise
da correção de modelos de sistemas e modelos de componentes (CLARKE; GRUMBERG;
PELED, 1999).
Considerar possı́veis comportamentos do software pode auxiliar na elaboração e im-
plementação de projetos mais fiéis aos requisitos levantados e menos propensos a erros
(D’IPPOLITO et al., 2008a). Quanto mais cedo os erros forem descobertos menos eles
irão implicar no custo do software (VLIET; VLIET; VLIET, 1993), (BOEHM, 1984).
Existem diferentes modelos formais capazes de representar explicitamente informação
parcial como em Uchitel, Kramer e Magee (2003a), em que os autores utilizam Modal
Transition System (MTS) para representar comportamento parcial de sistemas. Existem
outros modelos que estendem o MTS, aumentando sua expressividade, mas com a mesma
finalidade, como Disjuntive Modal Transition System (BENEš; ČERNá; KřETı́NSKý,
2011) ou o Parametric Modal Transition System (PMTS) (BENEš et al., 2011).
Um outro modelo proposto na literatura é o Kripke Modal Transition System (KMTS)
(HUTH; JAGADEESAN; SCHMIDT, 2001a), que é um diagrama de transição de estados
que permite expressar comportamentos requeridos e possı́veis através de indefinições nos
seus estados e modalidades nas suas transições. Os KMTS têm dois tipos de transições:
obrigatórias e possı́veis, e seus estados podem ser definidos através de proposições que
podem ser verdade (V), falso (F) ou indefinido (K). Assim, é possı́vel utilizar um KMTS
para modelar, por exemplo, o comportamento de um componente de software, deixando
explı́citas as indefinições presentes em seus estados e em suas interações. É válido ressaltar
que nem o MTS nem suas extensões permitem o uso de indefinições nos estados dos
modelos, como o KMTS. A indeterminação nos estados é interessante, pois permite que
vários estados sejam abstraı́dos em um mesmo estado, evitando uma definição prévia
de todos os estados do sistema nas fases iniciais do desenvolvimento. Todavia, existem
poucos trabalhos que utilizam KMTS como modelos para especificação parcial aplicados
no desenvolvimento de software.
Independente do modelo utilizado, em cada ciclo, no contexto de desenvolvimento
iterativo e incremental, três atividades são fundamentais: a construção dos modelos; a
análise dos modelos; e o reparo dos modelos se for necessário. O presente trabalho traz
contribuições em cada uma destas atividades.
A criação de modelos formais (parciais) requer um conhecimento que não é comum
entre os projetistas de software. Assim, apesar de métodos de análise/verificação for-
mal serem eficazes, eles são menos empregados porque necessitam de expertise para a
construção dos modelos. Projetistas de software, geralmente, representam os softwares
através de linguagens informais ou semiformais como UML. Modelos comportamentais e
INTRODUÇÃO 3
de interação se limitam, muitas vezes, a diagramas de sequência (UCHITEL; KRAMER;

MAGEE, 2003a). Como será mostrado posteriormente, existem algumas pesquisas que
focam nesta atividade de forma a semi-automatizar a construção dos modelos parciais
tanto a partir de artefatos comumente gerados antes da implementação dos requisitos
quanto a partir do código-fonte. O presente trabalho contribui nesta atividade através da
adaptação de um algoritmo de sı́ntese de modelos parciais a partir de cenários (KRKA et
al., 2009) para a construção de modelos KMTS a partir de diagramas de sequência ano-
tados com OCL. Não tratamos neste trabalho o caminho inverso, isto é, gerar diagramas
de sequência a partir de modelos KMTS.
Em relação à análise de modelos, uma teoria de especificação parcial (BAUER, 2012),
(ALFARO; HENZINGER, 2005) define as operações e as relações sobre modelos parci-
ais para que expressem adequadamente o comportamento de um sistema composto por
componentes com informação parcial explı́cita ao longo do processo de desenvolvimento
(BAUER, 2012). Apesar de não existir uma definição exata dos operadores que devem es-
tar presentes em uma teoria da especificação, existem duas operações presentes na maioria
das definições: a operação de composição paralela e a operação de conjunção. A operação
de composição paralela consiste em representar o comportamento de diversos componen-
tes, que executam em paralelo, em um único modelo que representa o modelo do sistema.
A operação de conjunção tem como finalidade realizar a junção de vários modelos que
representam um mesmo componente em um único modelo. Além destas operações, a
relação de refinamento é a base de toda teoria de especificação parcial, pois todos os ope-
radores são definidos com base nesta relação ao longo do processo de desenvolvimento.
O presente trabalho contribui com a definição de uma teoria da especificação parcial
para modelos KMTS a partir da definição da relação de refinamento e das operações de
conjunção e composição paralela. Após a construção, em um ciclo de desenvolvimento
incremental, os modelos gerados devem ser analisados sob duas perspectivas: se eles sa-
tisfazem propriedades pretendidas naquele ciclo e se, para um mesmo componente, os
modelos gerados respeitam as propriedades dos modelos dos ciclos anteriores.
Para a segunda perspectiva, é necessário um meio de verificar se os modelos gerados
nas novas iterações e/ou incrementos respeitam os modelos previamente definidos de um
determinado componente, isto é, se o novo modelo representa um detalhamento maior
do modelo anterior sem perder nenhuma propriedade já definida. Esta relação entre
os modelos é chamada de refinamento. A relação de refinamento introduz a relação de
”menos abstrato que” entre dois modelos. Entre dois modelos de um mesmo componente,
o modelo mais abstrato possui mais indefinições e é chamado de especificação e o menos
abstrato, isto é, com menos indefinições, é o modelo que refina a especificação. Diversos
trabalhos focam no uso de modelos parciais e nos conceitos de refinamento, como em
(UCHITEL; KRAMER; MAGEE, 2003b), para a etapa de análise de modelos.
A maior parte dos trabalhos que utilizam modelos parciais para expressar modelos ao
longo do desenvolvimento de software definem e caracterizam uma relação de refinamento
para suas estruturas modais e utilizam técnicas para analisar se existe uma relação de
refinamento entre a especificação e um modelo. Uma abordagem baseada em um jogo
entre dois jogadores é uma das técnicas utilizadas para verificar se um modelo é um
refinamento de uma especificação. O presente trabalho define um jogo de refinamento
4 INTRODUÇÃO
para modelos KMTS através de regras, modela este jogo como um grafo e apresenta um
algoritmo para computar a existência de uma relação de refinamento modal forte a partir
deste grafo (até onde sabemos nenhum outra pesquisa definiu tal algoritmo). A nossa
solução possui complexidade polinomial, o que garante uma performance comparável aos
principais algoritmos de verificação de refinamento encontrados na literatura.
Quando não há uma relação de refinamento entre a especificação e o modelo, o último
deve ser reparado para garantir que ele preserve as propriedades definidas na especificação.
Todavia, nenhum dos trabalhos encontrados focam na alteração do modelo para garantir
uma relação de refinamento com a especificação. Automatizar esta tarefa não é um
problema trivial pois é necessário detectar os motivos que fazem com que não haja uma
relação de refinamento. Chamamos esta atividade de reparo de modelos. O presente
trabalho contribui com a automatização desta atividade através de um algoritmo de
reparo de refinamento, que utiliza o jogo de refinamento para extrair os motivos que
fazem com que não haja uma relação de refinamento entre o modelo e a sua especificação.
A extração dos motivos a partir do jogo permite que o modelo em questão seja reparado
automaticamente.
1.1 ESCOPO DO TRABALHO E CONTRIBUIÇÕES
No processo de desenvolvimento iterativo de software, surge a necessidade de métodos e

algoritmos que deem suporte contı́nuo para a construção, análise e correção de modelos
comportamentais que expressam conhecimento parcial explı́cito de componentes dentro
de um contexto formal. Neste sentido, idealizamos um esboço de um processo de de-
senvolvimento incremental e iterativo de software, baseado em componentes e amparado
pela teoria das especificações para especificar o escopo do nosso trabalho e como nossas
contribuições se relacionam. Na Figura 1.1 apresentamos uma visão de alto nı́vel de um
ciclo deste processo. As etapas de análise de requisitos, projeto, implementação, testes e
integração de um ciclo de desenvolvimento são representadas pelos blocos de cor amarela
e são repetidas a cada novo ciclo. A etapa de integração é responsável por integrar as
diversas partes desenvolvidas (o que é possı́vel no desenvolvimento incremental) em um
único artefato.
Esta figura também destaca o escopo do nosso trabalho mostrando quais as atividades
são suportadas pelo mesmo (blocos de cor azul) e quais ainda não foram desenvolvidas
para KMTS mas que podem ser adaptadas para estes modelos (blocos de cor verde).
O bloco “verificação de modelos” possui duas cores porque métodos de verificação de
modelos para modelos KMTS já existem, mas o presente trabalho define um operador que
permitem representar o sistema em diversos nı́veis (componentes e sistema), contribuindo
de forma indireta para a verificação de sistemas em diversos nı́veis.
Assim, o presente trabalho propõe o uso de modelos KMTS ao longo do processo de
desenvolvimento de software iterativo e incremental, focando nas três atividades básicas
ao longo do processo: construção de modelos KMTS a partir de diagramas de sequências;
análise de modelos KMTS, suas relações e suas operações no processo de desenvolvimento;
e reparo de refinamento entre modelos KMTS para que os mesmos satisfaçam os requisitos
desejados. Para cada um destes pontos, definimos meios e/ou métodos que podem auxiliar
1.1 ESCOPO DO TRABALHO E CONTRIBUIÇÕES 5
Figura 1.1 Visão de alto-nı́vel de um processo de desenvolvimento que utiliza KMTS suportado
por métodos formais
às atividades de construção, análise e reparo de modelos.

Em relação à construção de modelos, definimos e implementamos um algoritmo de
sı́ntese de modelos KMTS a partir de diagramas de sequência da UML baseado no al-
goritmo de sı́ntese de modelos MTS proposto em (KRKA et al., 2009). É importante
destacar que este algoritmo apenas converte diagramas de sequência em modelos KMTS.
A atividade inversa (KMTS para diagrama de sequência) não é abordado neste trabalho.
Em relação à análise de modelos, definimos relações e operações sobre modelos KMTS,
de forma a caracterizar uma teoria da especificação parcial para modelos KMTS:
Definimos o conceito de refinamento forte e completo para modelos KMTS e suas
relações entre si;
Caracterizamos o conceito de refinamento como um jogo entre dois jogadores e um

algoritmo para verificar o refinamento;
Definimos um operador de composição paralela juntamente com o conceito de com-

posicionalidade para representar diversos KMTSs interagindo em conjunto, como
componentes de um software executando em paralelo;
Definimos um operador de conjunção para KMTS de forma a permitir a união dos

diversos modelos KMTS de um mesmo componente e permitir representar o sistema
em diversos nı́veis de abstração (componente e sistema).
6 INTRODUÇÃO
Em relação ao reparo de modelos:
Definimos e estudamos o problema do reparo de refinamento, sua complexidade e

tipos de soluções;
Definimos algoritmos para o problema do reparo de refinamento de um modelo em

relação a uma especificação, isto é, métodos que realizam modificações de modelos
KMTS com a finalidade de criar uma relação de refinamento entre a especificação
e o modelo; e
Implementamos e validamos os algoritmos propostos para o problema do reparo do

refinamento.
1.2 ORGANIZAÇÃO DA DISSERTAÇÃO

O restante do presente trabalho é estruturado da seguinte forma: o Capı́tulo 2 apresenta
os principais conceitos sobre modelagem comportamental de sistemas e componentes e
sobre o desenvolvimento incremental e iterativo. O Capı́tulo 3 apresenta modelos com-
portamentais parciais, suas relações e o uso de verificação formal sobre eles. O Capı́tulo
4 apresenta os principais trabalhos relacionados à nossa proposta. O Capı́tulo 5 apre-
senta um algoritmo de sı́ntese de modelos KMTS a partir de diagramas de sequência
anotados por regras OCL e resultados de sua implementação. O Capı́tulo 6 mostra o
uso de KMTS para representar comportamento parcial no desenvolvimento de sistemas,
apresentando relações e operadores sobre modelos KMTS. O Capı́tulo 7 caracteriza for-
malmente o jogo de refinamento, apresentando um algoritmo para verificar a relação de
refinamento através do jogo. O Capı́tulo 8 aborda o problema do reparo de refinamento,
sua complexidade, possı́veis soluções e algoritmos para resolver este problema. Por fim,
o Capı́tulo 9 apresenta as contribuições, resultados alcançados e trabalhos futuros.
Capı́tulo
2
MODELOS COMPORTAMENTAIS
Muitos processos de desenvolvimento de software são definidos com base em quatro eta-
pas: análise de requisitos, projeto, desenvolvimento e teste (SOMMERVILLE, 2011). In-
dependente do processo escolhido, é comum haver dúvidas a respeito do comportamento
pretendido pelo sistema principalmente na etapa de análise de requisitos, pois os usuários
do sistema não têm conhecimento completo do mesmo ou não conhecem suficientemente o
domı́nio do sistema para orientar a equipe de desenvolvimento. Estas dúvidas se refletem
nas etapas seguintes, impactando a etapa de projeto, pois algumas decisões a respeito do
comportamento do software só podem ser tomadas quando se conhece o suficiente sobre
a necessidade do cliente. Além disso, diversas abordagens focam na construção rápida
de um software, como o desenvolvimento incremental e iterativo (PRESSMAN, 2005), no
qual o software é desenvolvido por partes e guiado por iterações com o cliente/usuário,
o que torna a tarefa de entender os requisitos do sistema e propor uma solução ainda
mais desafiador (o Apêndice A detalha mellhor esta abordagem). Outras abordagens,
como a engenharia de software baseada em componentes também tem como um dos seus
objetivos a construção rápida de um software através do reuso de partes já testadas e
implementadas de um ou mais sistemas.
Independente da abordagem de desenvolvimento escolhida, os projetistas de software
costumam utilizar modelos para representar o sistema com base nos seus requisitos.
2.1 MODELOS DE SOFTWARE

Uma modelagem de sistema é uma descrição, através de um modelo abstrato, de um
sistema (SOMMERVILLE, 2011). Engenheiros de requisitos utilizam modelos para en-
tender melhor o sistema e extrair novos requisitos. Engenheiros e arquitetos de software
utilizam estes modelos para entender e projetar o sistema.
Um sistema pode possuir diversos modelos, pois um modelo é uma abstração de um
sistema em relação a diferentes visões em relação a requisitos especı́ficos. Desta forma,
é possı́vel construir diversos modelos a partir das diversas perspectivas de um sistema.
É possı́vel, por exemplo, descrever uma perspectiva de interação, onde são modeladas
7
8 MODELOS COMPORTAMENTAIS
as interações entre o ambiente e o sistema ou entre os componentes do sistema, ou uma

perspectiva comportamental, onde o comportamento dinâmico do sistema é modelado,
descrevendo como o sistema reage a eventos.
A modelagem do sistema pode ser representada por modelos formais ou por alguma
notação gráfica, como a Unified Modeling Language (UML). Modelos formais são menos
empregados na indústria porque requerem, geralmente, um expertise pelo profissional
que os elabora, embora tragam vantagens através de métodos que podem garantir uma
maior confiabilidade aos modelos gerados. Já os modelos que utilizam uma notação
gráfica menos formal são mais empregados porque são mais fáceis de se ler e escrever.
Entretanto, muitas vezes, não permitem uma verificação automatizada.
Para a construção de modelos, analistas de requisitos utilizam vários métodos para
extração da informação que servem de base para modelar o sistema. Entrevistas, cenários,
etnografia, dentre outros, são exemplos de técnicas aplicadas. Dentre estas técnicas, o
uso de cenários (Apêndice A.1 e A.2) se destaca pela sua simplicidade de entendimento e
capacidade de detalhar o comportamento do sistema e por isto é amplamente utilizado.
Durante o ciclo de desenvolvimento incremental e iterativo é comum que os projetistas
não conheçam todos os requisitos do software a ser construı́do ou evoluı́do. A incerteza
pode estar presente nas mais diversas perspectivas do software. O presente trabalho foca
na incerteza em relação ao comportamento pretendido e em técnicas formais e por isto,
neste capı́tulo, são apresentados os principais tópicos e conceitos que motivam o presente
trabalho em relação a especificações comportamentais parciais em um contexto formal de
desenvolvimento de software.
Especificações comportamentais ou apenas especificações (no presente trabalho) são
modelos utilizados para descrever o comportamento de sistemas. Como mostrado poste-
riormente, existem diversos modelos para descrição comportamental, sendo o sistema de
transição (TS) (BAIER; KATOEN; LARSEN, 2008), o modelo mais utilizado para esta
finalidade.
2.2 SISTEMAS DE TRANSIÇÃO E ESPECIFICAÇÕES MODAIS

Um sistema de transição é um modelo descrito por um grafo dirigido onde os nós são os
estados e as arestas são as transições que representam a evolução temporal dos estados
do sistema (BAIER; KATOEN; LARSEN, 2008).
Definição 2.2.1 (Sistema de Transição (BAIER; KATOEN; LARSEN, 2008)). Um sis-

tema de transição TS é uma tupla pS, Σ, R, I, AP, Lq onde S é um conjunto de estados,
Σ um conjunto de ações, R P S Σ S é uma relação de transição, I P S é o conjunto
de estados iniciais, AP o conjunto de proposições atômicas e L : S Ñ 2AP é uma função
rotuladora.
Esta definição é genérica e, muitas vezes, alguns elementos da definição não são utili-
zados, como por exemplo o conjunto de proposições ou as ações que rotulam as transições.
A partir deste ponto, omitiremos o conjunto de estados iniciais e assumiremos, para fins
de simplificação, que cada sistema de transição possui um único estado inicial, ao qual
chamaremos de s0 sendo S o conjunto de estados do modelo em questão.
2.2 SISTEMAS DE TRANSIÇÃO E ESPECIFICAÇÕES MODAIS 9
Sistemas de transição são úteis para a análise e verificação formal de propriedades

(BAIER; KATOEN; LARSEN, 2008). Diversas técnicas ou métodos podem ser utilizados
para esta finalidade, como por exemplo a verificação de modelos (CLARKE; LERDA,
2007). Todavia, muitas vezes, quando existe mais de um sistema de transição que descreve
o comportamento de um software (ou componente de software) é necessário compará-
los entre si de forma a entender melhor a relação entre os seus comportamentos. Esta
comparação pode ser utilizada, por exemplo, para descobrir se dois modelos descrevem
o mesmo comportamento ou se um modelo N consegue simular um outro modelo M , de
forma que N é capaz de reproduzir todo o comportamento de M , além de possuir outros
comportamentos.
2.2.1 Simulação
A simulação é uma relação binária entre sistemas de transição que associa sistemas que
se comportam, em parte, da mesma maneira, no sentido que um sistema simule o outro.
De maneira intuitiva, podemos imaginar que um sistema de transição T SN simula um
sistema de transição T SM se todo comportamento que T SM descreve o modelo T SN
também descreve. É importante observar que o modelo T SN pode descrever também
outros comportamentos que não são descritos em T SM .
Definição 2.2.2 (Simulação (BAIER; KATOEN; LARSEN, 2008)). Seja T SM pSM , Σ,
RM , APM , LM q e T SN pSN , Σ, RN , APN , LN q dois sistemas de transição tal que
ps0, t0q P SM SN com s0 e t0 os estados iniciais de T SM e T SN respectivamente. Dizemos
que t0 simula s0 sse existir uma relação < SM SN tal que ps0 , t0 q P < e para todo
ps, tq P < vale:
1. Se ps, a, s1 q P RM então existe t1 tal que pt, a, t1 q P RN com ps1 , t1 q P <;
2. LM psq LN ptq.
O seguinte exemplo esclarece melhor a relação de simulação: suponha dois sistemas
de transição que descrevem o comportamento de uma máquina de vender refrigerantes e
bebidas alcóolicas. Existem três proposições que indicam qual a ação que o usuário deve
fazer no estado em que o sistema se encontra: pagar - indica que o usuário deve pagar;
bebida - indica que o usuário deve escolher uma bebida alcóolica; e soda - indica que
o usuário deve escolher um refrigerante, considerando que após realizar o pagamento, o
usuário deve informar se deseja uma bebida alcóolica ou um refrigerante. Dois sistemas
de transição que descrevem este comportamento são apresentados na Figura 2.1 e, para
simplificar este exemplo, as ações foram ocultadas.
É possı́vel notar que nos modelos mostrados na Figura 2.1, o modelo N simula o
comportamento do modelo M através da seguinte relação:
R tps0 , t0 q, ps1 , t1 q, ps2 , t1 q, ps3 , t2 q, ps4 , t3 qu
Todavia, o modelo N não é simulado por M porque não existe nenhum estado em
M que “imite” o comportamento do estado t1 pois, a partir de t1 é possı́vel alcançar um
estado onde vale bebida e um estado que vale soda.
Figura 2.1 Dois sistemas de transição onde N simula o comportamento de M (BAIER; KA-
TOEN; LARSEN, 2008)
Existem situações em que M simula N e N simula M simultaneamente através de

uma relação R e sua relação inversa, R . Quando este fato ocorre, dizemos que R é uma
relação de bissimulação e que M e N são bissimilares. Uma definição de bissimulação
pode ser encontrada no Apêndice B.1.
2.2.2 Especificações Comportamentais Parciais

Especificações parciais são uma extensão de sistemas de transição que permitem expressar
parcialmente (ou integramente) o comportamento de um software (ou seu componente),
possibilitando explicitar comportamentos em que não estão totalmente definidos (com-
portamentos possı́veis) e comportamentos já definidos (obrigatórios) através de modali-
dades nas suas transições e indefinições nas proposições dos seus estados (ANTONIK et
al., 2008). Existem dois tipos de especificações parciais: especificações mistas e especi-
ficações modais. A diferença básica entre estas definições dizem respeito à definição de
comportamentos obrigatórios e possı́veis.
Definição 2.2.3 (Especificação Mista (ANTONIK et al., 2008)). Seja Σ um conjunto não
vazio de ações e AP um conjunto não vazio de proposições atômicas, uma especificação
mista M é a tupla pS, R , R , L , L q tal que pS, R , L q e pS, R , L q são sistemas de
transição. Em particular, R e R são subconjuntos de S Σ S, e L , L são membros
de S Ñ 2AP .
Assim, uma especificação mista é composta de duas partes separadas: pS, R , L q

que especifica as proposições e comportamento obrigatório e pS, R , L q que especifica
2.2 SISTEMAS DE TRANSIÇÃO E ESPECIFICAÇÕES MODAIS 11
as proposições e comportamento possı́vel. Uma especificação modal é uma especificação

mista com restrições nos seus componentes obrigatórios e possı́veis de forma que todo
comportamento obrigatório é necessariamente possı́vel.
Definição 2.2.4 (Especificação Modal (ANTONIK et al., 2008)). Uma especificação
modal M é uma especificação mista onde R R e L psq L psq para todo s P S.
2.2.3 KMTS
Existem diversos modelos para expressar especificações parciais na literatura que são
apresentados no capı́tulo 3. Para o presente trabalho dois modelos se destacam: o Sis-
tema de Transição Modal (Modal Transition System - MTS) (Seção B.2 e o Sistema de
Transição Modal de Kripke (Kripke Modal Transistion System - KMTS).
Definição 2.2.5 (KMTS (HUTH; JAGADEESAN; SCHMIDT, 2001a)). Seja AP um
conjunto de proposições atômicas e Lit AP Yt p | p P AP u o conjunto de literais sobre
AP . Um Sistema de Transições Modais de Kripke é uma tupla M pAP, S, R , R , Lq,
onde S é um conjunto finito de estados, R S S e R S S são relações de
transição tal que R R , e L : S Ñ 2Lit é uma função rotuladora, tal que para todo
estado s e p P AP , pelo menos um ente p e p occore.
A partir de agora, para facilitar a leitura do texto, definimos que s0 Ñ
Ý s1 representa
ps0, s1q P R e s0 99K s1 representa ps0 , s1 q P R .
Figura 2.2 Exemplo do sinal de trânsito
Na Figura 2.2 é apresentado um KMTS com três estados s0 , s1 e s2 , onde no estado

s0 e s2 valem p e em s1 vale p K. As linhas tracejadas representam as transições may
(R ) enquanto as linhas sólidas representam as transições must (R ).
Quando o KMTS é utilizado como um modelo parcial, suas possı́veis implementações
são expressas como estruturas de Kripke. Uma estrutura de Kripke é um grafo dirigido
onde os vértices, que representam os estados do sistema, são rotulados com um conjunto
de proposições atômicas que representam propriedades básicas que são verdade no estado
correspondente ao vértice. As arestas do grafo são chamadas de transições (CLARKE;
LERDA, 2007).
Definição 2.2.6 (Estrutura de Kripke). Uma estrutura de Kripke é uma tupla K = (AP,
S, S0 , R, L) onde AP é o conjunto de proposições atômicas; S é um conjunto finito de
estados, S0 S são os estados iniciais, R S S e uma relação de transição sobre S, e
L : S Ñ 2AP é uma função de rotulação de valores verdade sobre os estados.
A Figura 2.3 apresenta uma estrutura de Kripke.
Figura 2.3 Uma estrutura de Kripke
Com o crescente uso de especificações parciais para modelagem comportamental de

sistemas, alguns estudos (BAUER, 2012) propõem uma teoria das especificações parciais
que define um conjunto mı́nimo de elementos (classes de modelos, relações e operações
sobre estes modelos) com determinadas propriedades que permitem expressar o compor-
tamento de um sistema, de forma parcial, adequadamente.
2.3 TEORIA DAS ESPECIFICAÇÕES PARCIAIS

Não há um consenso sobre a definição exata do conjunto básico de operações que definem
uma teoria da especificação, isto é, alguns autores definem algumas operações que outros
autores não consideram como sendo operações básicas. A maior parte das pesquisas so-
bre especificações comportamentais parciais estão concentradas nos modelos MTS, suas
operações e suas extensões. Modelos KMTS são uma extensão de modelos MTS com a
possibilidade de expressar indefinições nos estados (HUTH; JAGADEESAN; SCHMIDT,
2001a). Todavia, modelos KMTS são pouco estudados no contexto de desenvolvimento
comportamental parcial. Esta é uma das motivações do presente trabalho: considerando
que modelos KTMS são uma extensão de modelos MTS, analisar quais operações e propri-
edades podem ser adaptados para modelos KMTS e o impacto da indefinição nos estados
nestas adaptações. De qualquer maneira, uma classe de modelos parciais e a relação de
refinamento está presente em todos os trabalhos e os principais operadores definidos pe-
los principais trabalhos sobre teoria das especificações até o presente momento (até onde
sabemos) são os operadores de composição paralela e o operador de conjunção.
Assim, uma teoria da especificação T h é definida por uma tupla
T h pS , ¨, k, ^q
Onde S é o espaço de modelos, ¨ é a relação de refinamento, k é o operador de com-
posição paralela e ^ é o operador de composição. Outros estudos ampliam teorias das
1
Estruturas de Kripke são normalmente definidas com uma relação total de transição, tal requerimento
é desprezado aqui. Assumimos estruturas de Kripke com uma relação de transição parcial sem nenhum
impacto nesta pesquisa.
2.3 TEORIA DAS ESPECIFICAÇÕES PARCIAIS 13
especificações para contratos (BAUER et al., 2012a), acrescentando a descrição compor-

tamental do ambiente e definindo as relações e operações considerando sempre o modelo
do componente e o modelo do ambiente. Todavia, o estudo de contratos não faz parte do
escopo do presente trabalho e, por isto, não será detalhado.
Assim como acontece nos sistemas de transição, muitas vezes é necessário comparar o
comportamento de duas especificações parciais pois, ao longo do processo de desenvolvi-
mento, existirão diversas versões de modelos comportamentais de um mesmo componente
(ou software). As versões podem ser diferentes porque em uma delas há um detalhamento
maior a respeito de algo que ainda não tinha sido definido quando a versão foi criada. To-
davia, os conceitos de simulação e bissimulação não podem ser empregados diretamente
em especificações parciais porque pode haver diferenças nos comportamentos dos modelos
devido a novos requisitos. Neste caso, os modelos podem descrever o mesmo comporta-
mento em diferentes nı́veis de abstração e isto deve ser levado em consideração. Uma
relação que pode ser usada para comparar o comportamento de dois modelos parciais
considerando diferentes nı́veis de abstração é a relação de refinamento.
2.3.1 Relação de Refinamento

Numa abordagem informal, o refinamento é uma relação entre duas representações (uma
mais e a outra menos detalhada) de um mesmo componente. A ideia de refinamento
é utilizada para comparar modelos de uma mesma entidade em diferentes ciclos. Um
exemplo de relação de refinamento pode ser visto na Figura 2.4, onde a casa com portas
e janelas é um refinamento da outra casa.
Figura 2.4 Exemplo de refinamento. A casa mais detalhada é um refinamento da outra casa.
Adaptado de Fairbanks (2010)
A semântica do refinamento especifica qual tipo de detalhes pode ser introduzido.

Duas semânticas são possı́veis, a semântica aberta e a semântica fechada (FAIRBANKS,
2010).
Semântica fechada: na semântica fechada, o refinamento só pode introduzir detalhes
restritos a uma lista de possı́veis detalhamentos.
Semântica aberta: na semântica aberta, o refinamento pode introduzir qualquer
tipo de mudança que for necessária.
A Figura 2.5 exibe um exemplo de refinamento fechado e aberto na casa: janelas
ou portas seriam detalhes que poderiam ser adicionados no refinamento de semântica fe-
chada; adição de uma garagem e chaminés representaria um refinamento com a semântica
aberta.
Figura 2.5 Exemplo de refinamento com semântica fechada (A) e semântica aberta (B). A
casa mais detalhada é um refinamento da outra casa. Adaptado de Fairbanks (2010)
Considerando o uso especificações modais, quando dois modelos parciais descrevem o

mesmo comportamento em diferentes nı́veis de abstração (ou de detalhamento), dizemos
que o modelo mais detalhado é um refinamento do outro modelo (o mais abstrato). Em
relação a modelos parciais, a exclusão de certas possibilidades de comportamento pela
remoção de incertezas (através da remoção de comportamentos possı́veis ou conversão
deles em comportamentos obrigatórios) representa o conceito informal de refinamento.
Este conceito introduz a relação ”menos abstrato que” entre dois modelos. De forma
similar à relação de simulação (ou bissimulação), a relação de refinamento mapeia estados
entre os modelos. Se um estado s do modelo M é mapeado em um estado t do modelo N ,
diz-se que t é refinamento do estado s. Um estado t é um refinamento de um estado s se o
comportamento obrigatório de s é preservado em t e se todo comportamento possı́vel de
t é herdado de s. Observe que t pode ter os mesmos comportamentos possı́veis ou menos
comportamentos possı́veis do que s, mas o inverso nunca é verdade. Esta verificação é
aplicada de forma co-indutiva para os estados sucessores de s e t.
O refinamento é baseado na ideia de simulação/bissimulação sobre sistemas de transição
(PARK, 1981) e pode ser entendido da seguinte forma: o modelo N é um refinamento
de um modelo M se e somente se N simula todo o comportamento obrigatório de M e
M simula todo o comportamento possı́vel de N . Quando isto acontece qualquer com-
portamento possı́vel foi adicionado em N . Este conceito de refinamento é chamado de
refinamento modal e sua definição segue abaixo:
Definição 2.3.1 (Refinamento Modal (ANTONIK et al., 2008)). Seja M pSM , RM , RM ,
LM , L
M q e N pSN , RN , RN , LN , LN q duas especificações mistas e ps0 , t0 q P SM SN
com s0 e t0 os estados iniciais de M e N , respectivamente. Dizemos que t0 refina s0 sse
existir uma relação < SM SN tal que ps0 , t0 q P < e para todo ps, tq P < vale:
1. Para todo ps, a, s1 q P RM existe algum pt, a, t1 q P RN com ps1 , t1 q P <;
existe algum ps, a, s1 q P R com ps1 , t1 q P <;
2. Para todo pt, a, t1 q P RN M
3. LM LN ;
4. L
N LM .
Quando o modelo N é um refinamento do modelo M, escrevemos M ¨ N . Esta relaçã

de refinamento é reflexiva e transitiva, garantindo assim um ordenamento (no sentido de
“mais abstrato que”) entre especificações parciais (ANTONIK et al., 2008).
A Figura 2.6 e a Figura 2.7 exibem dois casos onde há e onde não há uma relação de
refinamento entre os modelos (respectivamente) pois, não há nenhum estado de N que
pode ser mapeado em s0 do modelo M. As setas tracejadas representam as transições
possı́veis enquanto que as setas sólidas representam as transições obrigatórias. Voltando
para a Figura 2.6, podemos observar que existe uma relação de refinamento modal entre
o modelo M e o modelo N . Também é possı́vel observar, que neste exemplo, o modelo
N não expressa nenhum comportamento possı́vel que não seja obrigatório. Quando uma
especificação parcial não expressa nenhum comportamento passı́vel de mudança, dá-se o
nome de implementação a esta especificação.
Definição 2.3.2 (Implementação (ANTONIK et al., 2008)). Uma implementação é uma

especificação parcial onde R R e L L .
Figura 2.6 Um modelo parcial M e uma implementação N
Figura 2.7 Dois modelos parciais que não possuem uma relação de refinamento modal
A relação de refinamento modal pode ser utilizada entre especificações parciais e entre
implementações. Quando usada para comparar apenas implementações, vale notar que a
relação coincide com a definição de bissimulação B.1.
Como um modelo parcial pode ser constituı́do de diversas indeterminações, é possı́vel
que ele possa originar diversas implementações, e por isto, definimos o conjunto de im-
plementações do modelo parcial M como I pM q tI } M ¨ I u.
Existem casos em que um modelo parcial não possui implementações. Dizemos que
uma especificação parcial é consistente se e somente se ela possui pelo menos uma imple-
mentação.
Definição 2.3.3 (Consistência em especificação parcial (ANTONIK et al., 2008)). Uma
especificação parcial M é consistente sse I pM q é não-vazio.
A Figura 2.8 mostra uma especificação mista que não possui implementações possı́veis.
As setas tracejadas representam as transições possı́veis enquanto que as setas sólidas
representam as transições obrigatórias. Antonik et al. (2008) mostram que o problema de
determinar se uma especificação mista é consistente tem seu limite inferior localizado na
classes de problemas PSPACE-hard enquanto que o limite superior está em EXPTIME.
Toda especificação modal é consistente porque toda transição obrigatória é uma transição
possı́vel (sempre existe uma implementação possı́vel, escolhendo o modelo formado por
todo comportamento must) e por isto apenas uma seta sólida é utilizada para representar
as transições obrigatórias, diferentemente das especificações mistas.
Figura 2.8 Uma especificação mista que não possui implementações
Independente do modelo ser consistente ou não, existem casos em que a relação de

refinamento não reproduz a ideia intuitiva de refinamento porque dados dois modelos
parciais M e N , se M ¨ N então I pN q I pM q, todavia, o inverso, se I pN q I pM q
então M ¨ N nem sempre é verdade (ANTONIK et al., 2008). Autores em (BENEš
et al., 2009) mostram que o inverso é verdade quando um dos modelos é determinı́stico.
Este resultado é demonstrado para modelos KMTS no presente trabalho. A Figura 2.9
exibe dois modelos que possuem o mesmo conjunto de implementação, mas um não refina
o outro.
Para evitar estes casos, é possı́vel definir um conceito de refinamento baseado apenas
na inclusão do conjunto de implementações e este conceito é chamado de refinamento
completo.
Definição 2.3.4 (Refinamento Completo (ANTONIK et al., 2008)). O Modelo N é um
refinamento completo do modelo M , M ¨c N , sse I pN q I pM q.
Todavia, calcular o refinamento completo tem um custo computacional elevado, e por
isto o refinamento modal continua sendo utilizado (ANTONIK et al., 2008). Antonik
Figura 2.9 Duas especificações mistas M e N com I pM q I pN q, mas não vale M ¨N
et al. (2008) mostram que o limite inferior para cálculo do refinamento completo para
especificações parciais encontra-se na classe de problemas PSPACE-hard enquanto seu
limite superior na classe EXPTIME.
Existem na literatura, variações do refinamento modal, que podem ser vistas na Seção
B.3. O presente trabalho utiliza o conceito de Refinamento Modal Forte (BAIER; KA-
TOEN; LARSEN, 2008) sobre modelos KMTS por entender que este é o conceito base
para todas as outras variações de refinamento.
2.3.2 Operador de Composição Paralela

Um software pode ser formado por vários componentes que são executados de forma
paralela e interagem entre si. Todavia, existem propriedades que não são satisfeitas por
nenhum componente isoladamente e sim pelo sistema como um todo, ou seja, propriedades
que somente se tornam presentes quando determinados componentes interagem entre si.
Assim, modelos em nı́vel de sistema se fazem necessários para uma análise mais precisa
de um sofware (KRKA et al., 2009).
É possı́vel sintetizar modelos comportamentais do sistema a partir da composição dos
modelos dos seus componentes através do operador de composição paralela. O operador
de composição paralela definido por uma teoria da especificação é comumente estrutural,
isto é, cada estado do sistema é composto da união dos estados dos componentes indivi-
duais, onde ações dos componentes são convertidas em ações na composição. Ações em
comum entre os componentes são representadas como transições na composição que al-
teram os estados de vários componentes simultaneamente e as ações não-compartilhadas
são simuladas por interleaving, representando, na composição, a alteração do estado um
ou mais componentes.
O operador de composição paralela deve ser comutativo e associativo para garantir
que a ordem de execução da composição não influencie no resultado final da composição.
A Figura 2.10 mostra um exemplo de composição paralela, representada por M k
N dos modelos M e N . A figura também mostra um exemplo em que a relação de
refinamento modal não é completa com respeito ao operador de composição paralela, isto
é, a composição paralela dos modelos parciais M e N pode ser vista no modelo M k N
e o modelo I representa uma implementação do modelo M k N que não consegue ser
formado a partir da composição de quaisquer implementações dos modelos M e N .
Figura 2.10 Exemplo da incompletude da relação de refinamento modal em relação ao opera-

dor de composição paralela
2.3.3 Operador de Conjunção

Muitas vezes, um componente (ou um software) é desenvolvido por diversas equipes.
Cada uma pode ser responsável por uma visão do componente o que resultará em dife-
rentes modelos a respeito de um mesmo componente. Unificar os diversos modelos em
apenas um é a função do operador de conjunção. Considerando que todos os modelos
descrevem um mesmo componente, a abordagem mais utilizada para calcular o operador
de conjunção consiste em encontrar um modelo que seja um refinamento em comum dos
modelos desejados.
Definição 2.3.5 (Refinamento Comum). Dados os modelos parciais M e N , um modelo

X é um refinamento comum entre M e N sse M ¨ X e N ¨ X.
Antonik et al. (2008) definem o refinamento comum como um dos principais problemas
de especificações parciais e mostram que seu limite inferior em termos de complexidade
é PSPACE-hard (para especificações mistas e modais) e o limite superior ainda não é
preciso, mas fica localizado na classe de problemas EXPTIME.
Intuitivamente, dois modelos M e N que descrevem parcialmente um mesmo sistema
ou componente devem ser consistentes, isto é, o comportamento obrigatório e possı́vel
dos dois deve ser compatı́vel. Todavia, em alguns casos não existe refinamento comum
entre dois componentes. Quando existe refinamento comum (baseado no conceito de
refinamento modal forte) entre dois componentes dizemos que eles são consistentes.
Definição 2.3.6 (Consistência). Duas especificações modais, M e N são ditos consistentes

se existe um modelo parcial C tal que C é um refinamento comum de M e de N.
A consistência também pode ser definida como uma relação sobre especificações mo-
dais (RACLET et al., 2011).
Definição 2.3.7 (Consistência (RACLET et al., 2011)). Seja M pSM , RM , RM q e

N pSN , RN , RN q duas especificações modais e ps , t q P S S com s e t os estados
0 0 M N 0 0
iniciais de M e N , respectivamente. Dizemos que os modelos M e N são consistentes sse
existir uma relação < SM SN tal que ps0 , t0 q P < e para todo ps, tq P < vale:
com ps1 , t1 q P <q;
1. (@l, s1 qpps, a, s1 q P RM existe algum pt, a, t1 q P RN
com ps1 , t1 q P <q.
2. (@l, t1 qppt, a, t1 q P RN existe algum ps, a, s1 q P RM
Considerando que a relação de refinamento define uma pré-ordem no espaço dos mo-
delos (RACLET et al., 2011), podem existir diversos (ou um ou nenhum) refinamento
comum entre dois modelos. No caso do operador de conjunção, busca-se o refinamento
comum mais próximo dos dois modelos de entrada, isto é, o refinamento comum com
mais indefinições. Esta restrição é justificada porque busca-se o modelo que represente
os outros modelos, mas que perca o mı́nimo possı́vel de indefinições. Caso os modelos se-
jam consistentes, chamamos o conjunto formado por todos os refinamentos comuns mais
próximos dos modelos de entrada de Refinamento Comum Minimal (RCM) (vale lembrar
que como a relação de refinamento é uma pré-ordem, estes elementos do RCM não são
comparáveis entre si). Alguns trabalhos chamam a operação de conjunção de merge.
Caso exista apenas um menor refinamento comum, chamamos este modelo de Menor
Refinamento Comum (MRC). O MRC é o refinamento comum mais abstrato (ou com
mais indefinições) e o RCM é um conjunto formado pelos refinamentos comuns mais
abstratos e não comparáveis entre si pela relação de refinamento(BRUNET; CHECHIK;
UCHITEL, 2006a). A Figura 2.11 mostra a ideia de Menor Refinamento Comum em (A)
e do conjunto de Refinamento Comum Minimal em (B). Cada nó do grafo representa uma
especificação parcial e a seta representa a relação de refinamento.
Definição 2.3.8 (Refinamento Comum Minimal). Dados dois modelos M e N , o modelo

X pertence ao RCM de M e N sse X é um refinamento comum entre M e N e para todo
modelo X 1 tal que M ¨ 1 X e N ¨ X 1 então X ª X 1 e X 1 ª X.
Definição 2.3.9 (Menor Refinamento Comum). Dados dois modelos M e N , o modelo

X é o MRC de M e N sse X é um refinamento comum entre M e N e para todo modelo
X 1 tal que M ¨ X 1 e N ¨ X 1 então X ¨ X 1 .
Segundo (RACLET et al., 2011), o operador de conjunção deve ser associativo e co-
mutativo para garantir que a ordem de execução da conjunção não influencie o resultado
final. Além disto, as seguintes propriedades devem valer para que o operador de con-
junção (representado por ^) retorne de fato a conjunção entre os dois modelos (e não o
refinamento comum):
Figura 2.11 Exemplos de MRC em (A) e de RCM em (B)
1. M ^ N é definido sse existe um modelo parcial X tal que M ¨ X e N ¨ X;

2. Se M ^ N é definido então para todo modelo parcial X tal que M ¨ X e N ¨ X
então X ¨ M ^ N .
Capı́tulo
3
TRABALHOS RELACIONADOS
Existem na literatura diversos trabalhos que objetivam prover suporte à análise de mo-
delos comportamentais com informações parciais no contexto da engenharia de software.
Nesta seção, listamos as principais pesquisas relacionadas ao presente trabalho, desta-
cando as influências e as diferenças entre elas e o presente trabalho.
3.1 MODELOS COMPORTAMENTAIS PARCIAIS

Larsen e Thomsen (1988) propõem Modal Transition System (MTS) que generalizam os
modelos Labelled Transition Systems (LTS) através da inclusão de transições may, que re-
presentam transições possı́veis, isto é, não são obrigatórias nem são proibidas, e transições
must, que são obrigatórias e definem o refinamento sobre estes modelos. Uchitel, Kramer
e Magee (2003a) utilizam o refinamento sobre MTS no contexto de desenvolvimento de
sistemas. Para os autores, modelos comportamentais parciais permitem raciocinar sobre
o comportamento pretendido do sistema na presença de informações incompletas e o refi-
namento é uma maneira de representar o processo de elaboração destes modelos. A ideia
deste refinamento é gerar um modelo ”mais definido que”ou ”com mais informações que”
o modelo a ser refinado, preservando suas propriedades iniciais e com menos indefinições.
Uma série de modelos baseados em MTS são propostos na literatura:
1. Disjuntive Modal Transition System (DMTS): Beneš, Černá e Křetı́nský (2011)
propõem uma extensão do MTS chamada DMTS. Segundo os autores, apesar de
serem úteis para expressar comportamento parcial, modelos MTS não permitem ex-
pressar soluções condicionais, isto é, transições com mais de um estado de destino,
também chamadas de hipertransições. Os DMTS incorpora hipertransições aos mo-
delos MTS. Nesta proposta, uma hipertransição representa várias transições. Na
implementação de um DMTS, pelo menos uma transição de cada hipertransição
deve existir, ou seja, pelo menos uma das transições representada na hipertransição
deve se tornar must, possibilitando expressar que entre um conjunto de compor-
tamentos possı́veis, pelo menos um deve valer, evitando assim que todos sejam
removidos, o que pode ter como consequência um estado não alcançável no modelo;
21
22 TRABALHOS RELACIONADOS
2. One Selecting MTS (1-MTS): uma variante do DMTS chamada One-Selecting MTS
é proposta em (FECHER; SCHMIDT, 2008). Esta extensão interpreta as hiper-
transições como transições exclusivas (XOR), isto é, na implementação de um One-
Selecting MTS cada hipertransição se tornará uma transição, ao contrário do DMTS
onde cada hipertransição pode se tornar mais de uma transição (OR);
3. Parametric Modal Transition System (PMTS): Beneš et al. (2011) propõem uma
extensão do MTS chamada PMTS, juntamente com uma noção geral do seu refina-
mento. Segundo os autores, o PMTS resolvem limitações do MTS, tornando possı́vel
expressar aspectos presentes no refinamento como escolhas exclusivas (XOR), con-
dicionais (OR) e persistentes (AND), de maneira similar ao DMTS (e 1-MTS);
4. Model IO Automata (MIO): Larsen, Nyman e Wasowski (2007) propõem a utilização
do MIO. O MIO é uma junção do MTS e do Input Output Automata (LYNCH;
TUTTLE, 1989) que permite não só especificar conhecimento parcial como também
modalidades nas operações: transições de saı́da, entrada e ações internas. O obje-
tivo do MIO é modelar interfaces de componentes, representando suas entradas e
saı́das;
5. MTS com pesos nas transições: Juhl, Larsen et al. (2012) estendem o MTS, adicio-
nando intervalo de pesos (uma sequência de valores) nas transições, descrevendo as
possibilidades de valores que podem ser usadas nas suas implementações, de forma
que na implementação, cada transição terá apenas um valor/peso associado;
6. Kripke Modal Transition System: Huth, Jagadeesan e Schmidt (2001a) estendem
modelos MTS com a possibilidade de expressar indefinições em nı́vel de propriedade
nos estados.
Ainda existem outros modelos como, por exemplo, o MTS probabilı́stico e MTS tem-
poral. Os trabalhos supracitados também definem para seus modelos a operação de refi-
namento (forte ou fraco), além das operações de composição paralela e conjunção. Alguns
trabalhos ainda definem a operação de disjunção. Um resultado importante em relação
ao refinamento fraco é apresentado em (FISCHBEIN; BRABERMAN; UCHITEL, 2009),
em que autores mostram que o refinamento fraco traz resultados contrários ao senso de
refinamento e propõem uma relação chamada de refinamento de alfabeto ramificado (jun-
tamente com a semântica ramificada). Este refinamento preserva a estrutura ramificada
(como o refinamento modal forte) e permite ações observáveis e não-observáveis. Todavia,
autores mostram que não é possı́vel definir a relação de refinamento de alfabeto ramifi-
cado entre quaisquer duas especificações parciais, mas somente entre uma especificação
parcial e uma implementação e, por isto, o argumento dos autores é utilizar a ideia de
refinamento completo entre especificações parciais e utilizar o conceito de refinamento de
alfabeto ramificado entre especificações e implementações.
Outros trabalhos buscam estudar melhor os modelos parciais já propostos, demons-
trando algumas propriedades, como em (WEI; GURFINKEL; CHECHIK, ) que mostra a
equivalência entre KMTS, Especificações Mistas e o KMTS Generalizado (uma extensão
do KMTS com hipertransições, similar ao DMTS).
3.1 MODELOS COMPORTAMENTAIS PARCIAIS 23
Em (BENEš et al., 2009), os autores mostram que em modelos MTS, o refinamento

completo implica no refinamento modal quando um dos modelos é determinı́sta. Outra
contribuição deste trabalho é a operação deterministicHull, que consiste em dado um
MTS M, retornar o refinamento determinı́sta mais abstrato de M. Esta operação é útil
para transformar um modelo parcial em um modelo determinı́sta. Baseando-se neste
resultado, o presente trabalho caracteriza quando, nos modelos KMTS, o refinamento
forte e completo coincidem.
Considerando que os modelos parciais devem ser utilizados para especificar sistemas e
componentes, Bauer (2012), inspirado na teoria das interfaces (ALFARO; HENZINGER,
2005), propõem uma teoria da especificação parcial, que define os elementos para mode-
lagem top-down de sistemas baseados em componentes, concorrentes e reativos. Bauer
et al. (2012b) propõem uma teoria da especificação baseada em MTS que permite a re-
presentação de dados através de predicados lógicos. Expandindo o conceito de teoria da
especificação, Bauer et al. (2012a) e (BENVENISTE et al., 2012) propõem a criação de
contratos a partir de qualquer teoria da especificação que possuam determinadas propri-
edades. A diferença de um contrato e uma teoria da especificação é que os contratos tem
como requisito a representação do ambiente e todas as relações e operações devem consi-
derar um (ou mais) modelo(s) e um ambiente. Para a eles, a representação do ambiente
é tão importante quanto a representação do software (ou componente).
Entre os modelos propostos, apenas o KMTS expressa indefinições nas proprieda-
des dos estados explicitamente e por isto, a nossa abordagem considera indefinições nos
estados através destes modelos. A maior parte das pesquisas sobre especificações compor-
tamentais parciais estão concentradas nos modelos MTS, suas operações e suas extensões.
Todavia, modelos KMTS são pouco estudados no contexto de desenvolvimento compor-
tamental parcial.
3.1.1 Sistema de Transição Modal de Kripke
Huth, Jagadeesan e Schmidt (2001a) propõem os modelos KMTS a partir de modelos LTS
e define conceitos de simulação e refinamento sobre modelos KMTS. Shoham e Grumberg
(2007) utilizam modelos KMTS para abstrair estruturas de Kripke como uma alternativa
para contornar o problema da explosão de estados na verificação de modelos através o
conceito de abstração de modelos. Os conceitos de abstração e refinamento são conceitos
duais e são utilizados no presente trabalho.
A semântica de 3-valores (verdade, falso, indefinido) sobre modelos KMTS usada no
presente trabalho segue a semântica definida em (SHOHAM; GRUMBERG, 2007).
Apesar de, a princı́pio, a ideia de abstração e de refinamento seguirem em sentidos
opostos, a semântica utilizada na nossa abordagem é a mesma pois, a relação de abstração
e a relação de refinamento (BAIER; KATOEN; LARSEN, 2008) possuem a mesma de-
finição (ambas são baseadas na ideia de abstração (SHOHAM; GRUMBERG, 2007)). A
única diferença entre os conceitos é o sentido da conversão: a abstração torna um modelo
menos abstrato em mais abstrato e o refinamento realiza o processo inverso.
Guerra, Andrade e Wassermann (2013a) utilizam modelos KMTS para representar
informação parcial explicitamente. Na abordagem proposta pelos autores, um KMTS
representa um conjunto de estruturas de Kripke. Cada estrutura, por sua vez, repre-
senta uma possibilidade de comportamento do sistema. Ao utilizar um KMTS para
representar o comportamento de um componente de software, por exemplo, o modelo re-
presenta possı́veis comportamentos deste componente. Os autores utilizam fórmulas em
Computation Tree Logic (CTL) (CLARKE; LERDA, 2007) para expressar propriedades
e um algoritmo que repara o modelo para que propriedades desejadas sejam satisfeitas.
Quando a propriedade é indefinida no KMTS, o reparo consiste na aplicação de um fil-
tro que retorna um ou mais modelos KMTS que se expandem apenas em estruturas de
Kripke presentes no modelo inicial que satisfazem a propriedade desejada. Consideramos
o resultado deste trabalho como uma operação possı́vel ao longo do desenvolvimento de
software. Esta operação de filtrar os modelos coincide, nestes casos, com a operação de
refinamento completo.
É importante ressaltar que as semânticas dadas por Shoham e Grumberg (2007),
chamada aqui de semântica de abstração, e Guerra, Andrade e Wassermann (2013a),
chamada aqui de semântica de conjuntos, podem ser utilizadas numa mesma solução
porque possuem uma certa compatibilidade. É possı́vel observar que os modelos que a
semântica de conjuntos considera como possı́veis refinamentos de um KMTS M também
são considerados como refinamento na semântica de abstração. Todavia, o refinamento da
semântica de conjuntos é restritivo demais, significando que há uma perda considerável de
modelos que poderiam ser refinamento, mas não são considerados. De qualquer maneira, o
presente trabalho propõe a utilização da revisão de modelos em alguns pontos do processo
de desenvolvimento.
3.2 CONSTRUÇÃO DE ESPECIFICAÇÕES PARCIAIS NO DESENVOLVIMENTO

DE SOFTWARE
Há na literatura trabalhos que aplicam os modelos de comportamento parcial supracita-

dos no processo de desenvolvimento de software. Estes trabalhos propõem a utilização
explı́cita de informação incompleta nas etapas do ciclo de desenvolvimento, como por
exemplo na análise de requisitos, como proposto por Salay et al. (2013) no qual autores
propõem uma metodologia para explicitar e rastrear indefinições.
Courbis et al. (2012) propõem uma metodologia para desenvolvimento incremental de
modelos comportamentais no contexto de desenvolvimento ágil. A metodologia consiste
numa composição de refinamentos sobre máquinas de estados até que esta represente
o modelo comportamental desejado. Todavia, esta abordagem não utiliza informação
incompleta explicitamente.
Krka et al. (2010) utilizam modelos MTS para reengenharia de software. Através de
traces de execução do software, a técnica proposta gera automaticamente MTS dos com-
ponentes do software. Estes modelos gerados podem ser utilizados para geração de caso
de testes, verificação de propriedades ou servir de apoio para processos de reconstrução
arquitetural.
Uchitel et al. (2004) apresentam um método de sı́ntese de modelos comportamentais
de componentes no contexto de arquitetura do software a partir de cenários. Segundo os
autores, a necessidade de maior expertise matemática cria uma limitação nas abordagens
3.2 CONSTRUÇÃO DE ESPECIFICAÇÕES PARCIAIS NO DESENVOLVIMENTO DE SOFTWARE25
atuais de suporte ao desenvolvimento de modelos formais comportamentais arquiteturais.

Para eles, essa limitação faz com que seja mais fácil desenvolver modelos comportamentais
apenas em nı́vel de sistema (intercomponent). Todavia, estas abordagens requerem mo-
delos comportamentais em nı́vel de componentes (intra-component). Através de cenários
e de instâncias de arquiteturas, descritas em Architecture Description Language (ADL)
(PERRY; WOLF, 1992), o método proposto gera modelos comportamentais em nı́vel de
tipos de componentes. O método utiliza informações especı́ficas para construir modelos
genéricos que representam as instâncias criadas.
Uchitel, Brunet e Chechik (2009) apresentam um método de sı́ntese de modelos com-
portamentais parciais através de cenários e propriedades expressas em Fluent Linear
Temporal Logic (FLTL). A ideia deste método se baseia na fusão de modelos MTS. Um
modelo é gerado para cada cenário e para cada propriedade expressa. A fusão é realizada
entre os modelos gerados, obtendo o modelo do sistema. Novos requisitos são adicionados
ao sistema pelo mesmo processo: união entre o modelo do sistema e o modelo construı́do
a partir de cenários e/ou propriedades. Para a construção automática de modelos MTS,
autores adaptam algoritmos para sı́ntese automática de LTS a partir de propriedades e
cenários propostos em Letier et al. (2008).
Krka e Medvidovic (2014) propõem uma extensão das linguagens para expressar
cenários através da Component-aware Triggered Scenarios (CaTS). Segundo os mesmos,
linguagens comumente utilizadas, como a UML através do diagrama de sequência, não
permitem expressar detalhadamente os comportamentos reativos dos sistemas. Segundo
os autores, esta linguagem busca resolver dois problemas encontrados no diagrama de
sequência: modalidades universais e existenciais; e escopo no nı́vel de sistema e no nı́vel
de componente. Através desta linguagem, os autores argumentam que conseguem gerar
modelos MTS mais precisos.
Em um contexto mais aplicado, Krka et al. (2009) propõem um algoritmo para sı́ntese
automática de modelos MTS a partir de diagramas de sequência e propriedades OCL.
Este algoritmo é dividido em quatro etapas explicadas a seguir:
Etapa I - Extrai-se das restrições expressas em OCL e em nı́vel de sistema as

restrições em nı́vel de componente;
Etapa II - Um MTS inicial, sem nenhum comportamento obrigatório, é gerado para

cada componente a partir das valorações das restrições extraı́das;
Etapa III - Os diagramas de sequência são analisados para inferir a valoração das
variáveis e detectar inconsistência nas mesmas;
Etapa IV - O diagrama de sequência é utilizado para definir as transições must. As

transições presentes no diagrama se tornam requeridas.
Uma visão geral do algoritmo de sı́ntese encontra-se na Figura 3.1.

Para a etapa de sı́ntese de modelos KMTS, o presente trabalho utiliza uma adaptação
do algoritmo proposto por Krka et al. (2009). Este algoritmo foi escolhido porque ele
utiliza artefatos comumente utilizados no desenvolvimento de software pois, utilizar ADL
Figura 3.1 Visão geral do algoritmo de sı́ntese de MTS proposto por Krka et al. (2009) (KRKA
et al., 2009)
pode reduzir a aplicabilidade do algoritmo, considerando que artefatos expressos em ADL

não são tão empregados quanto diagramas de sequência em UML. Todavia, o fato da
existência de proposições indefinidas nos estados é um fator complicador para o algoritmo
de sı́ntese de modelos KMTS e alguns passos foram adaptados com finalidade de evoluir
o algoritmo proposto por Krka et al. (2009).
3.3 ANÁLISE DE ESPECIFICAÇÕES PARCIAIS NO DESENVOLVIMENTO DE

SOFTWARE
Ghezzi et al. (2013) abordam modelos parciais no desenvolvimento ágil e utilizam com-
posições de máquinas de estados incompletas, fazendo o uso de propriedades em CTL
para verificar e refinar estes modelos.
D’Ippolito et al. (2008b) e Uchitel (2009) utilizam modelos MTS para representar
o comportamento de sistemas na presença de conhecimento incompleto e o refinamento
destes modelos para representar a evolução do comportamento dos sistemas. Nestes tra-
balhos, os autores também propõem a utilização da operação de conjunção (merge) de
modelos MTS para representar a evolução comportamental do sistema com a inclusão de
novos requisitos. Nesta abordagem os modelos gerados incialmente são fundidos com os
modelos extraı́dos dos novos requisitos, gerando novos modelos que preservam as propri-
edades do modelo inicial e os novos requisitos.
É demonstrada por Brunet, Chechik e Uchitel (2006b) a possibilidade de realização da
conjunção de modelos MTS automaticamente através de um algoritmo. Brunet (2006)
mostra que o operador de conjunção utilizado possui falhas quando os dois modelos
permitem comportamentos contraditórios, mostrando que a consistência é uma condição
necessária. Quando o conceito de refinamento modal fraco é utilizado, a consistência não é
uma condição suficiente para que entre dois modelos exista um RCM ou MRC e propõem
um operador chamado cr para contornar esta limitação. Fischbein e Uchitel (2008)
mostram que o operador cr falha em alguns casos (modelos com não-determinismo) e
propõem um algoritmo que usa o operador cr de forma iterativa.
O presente trabalho se baseia no operador cr para definir o operador de conjunção,
apesar de usar apenas modelos determinı́stas. Mais uma vez, no operador de conjunção
3.3 ANÁLISE DE ESPECIFICAÇÕES PARCIAIS NO DESENVOLVIMENTO DE SOFTWARE 27
entre modelos KMTS a valoração das proposições nos estados tem que ser considerada
e, devido a isto, é possı́vel, durante a operação de conjunção, detectar problemas nos
modelos (valorações inconsistentes entre os estados) e inferir a valoração de proposições
indefinidas a partir da valoração de outros modelos. Estes dois aspectos serão detalhados
posteriormente.
Existem também trabalhos que utilizam outros modelos como utilizado por Raclet et
al. (2011), no qual os autores utilizam o MIO para análise e especificação de interfaces
para componentes reativos. Já Krka et al. (2014) e Krka e Medvidovic (2012) utilizam o
MIO para representar componentes de um sistema e suas interfaces.
É válido ressaltar que modelos KMTS são uma extensão de modelos MTS (HUTH;
JAGADEESAN; SCHMIDT, 2001a). Possivelmente, estes trabalhos que propõem ou
utilizam MTS e suas extensões podem ser mapeados para KMTS ou para extensões defi-
nidas de forma similar às definidas para o MTS. Assim, o estudo e utilização de modelos
KMTS no presente trabalho pode permitir sua aplicação nas mais diversas abordagens
que utilizam o MTS, expandindo-as através da possibilidade de expressar indefinições nos
estados.
3.3.1 Jogo de Refinamento
Existem diversos meios para analisar se um modelo é refinamento de outro modelo. De

maneira geral, como feito em (KRETINSK, 2013), consiste em realizar um produto car-
tesiano entre os estados dos modelos e remover do produto cartesiano os pares que não
satisfazem a condição de refinamento. Se o conjunto de pares resultante formar uma
relação de refinamento então um modelo é refinamento do outro. Em (BENEŠ et al.,
2015), autores demonstram um método para reduzir o problema da verificação de refi-
namento em diversas estruturas modais (MTS, DMTS, PMTS e variantes) ao problema
de verificar se uma fórmula que representa os modelos é uma fórmula booleana comple-
tamente quantificada (QBF), mostrando que o problema da verificação do refinamento
modal é um problema que tem sua complexidade na classe P.
Alguns trabalhos, como (BENEš et al., 2009), apresentam um outro meio de verificar
a existência de refinamento entre dois modelos através de um jogo entre dois jogadores: o
atacante e o defensor. O jogo representa todas as possı́veis combinações de mapeamento
entre os estados dos dois modelos e se o defensor ganha o jogo então existe uma relação
de refinamento. Caso contrário, não existe uma relação de refinamento. Em (BENEš
et al., 2009), (BOZZELLI et al., 2014) são propostos jogos de refinamento para diversas
estruturas modais. Todos estes jogos são uma adaptação do jogo para bissimulação
proposto em (STIRLING, 1995) ou em (THOMAS, 1993), que são usados para analisar
se existe uma relação de bissimulação entre dois modelos.
A diferença do jogo apresentado no presente trabalho e nos demais é, mais uma vez, a
adaptação para acomodar a restrição de proposições nos estados. Além disto, o presente
trabalho define o jogo de refinamento como um grafo, baseado no jogo de bissimulação
proposto em (BULYCHEV; KONNOV; ZAKHAROV, 2007). Até onde sabemos, todos os
trabalhos que utilizam jogo de refinamento, o fazem para provar propriedades em relação
aos trabalhos propostos, como por exemplo em (BENEš et al., 2009). O presente trabalho
define e implementa um algoritmo que executa o jogo de refinamento para verificar a

existência de uma relação de refinamento modal forte entre modelos KMTS. Além disto,
até onde temos conhecimento, nenhum outro trabalho define o jogo de refinamento para
modelos KMTS.
3.4 REPARO DE REFINAMENTO

Até onde sabemos, o reparo de refinamento como considerado neste trabalho, sobre mo-
delos KMTS e baseado no jogo de refinamento nunca foi proposto anteriormente. Em
(WANG; CHENG, 2008) os autores definem um algoritmo de reparo para a relação de
bissimulação, mas esta solução não é aplicável para modelos parciais. Esta solução cal-
cula o maior subgrafo do modelo que é bissimilar à especificação em questão. Então,
os elementos do modelo que não pertencem a este subgrafo são removidos do modelo
e os elementos da especificação que não são mapeados no subgrafo são adicionados ao
subgrafo. Nosso trabalho, diferentemente deste, trata de refinamento ao invés de bissi-
mulação e é baseado no jogo de refinamento por considerar o jogo para descobrir quais
mudanças devem ser aplicadas nos modelos para garantir uma relação de refinamento
entre o modelo e a especificação.
3.5 POSICIONAMENTO DO PRESENTE TRABALHO EM RELAÇÃO AOS DE-

MAIS
Devido ao extenso escopo do presente trabalho, resumimos nesta seção as principais de-
cisões tomadas ao longo da nossa proposta e como os trabalhos supracitados influenciaram
de alguma forma nestas decisões.
1. Utilização de modelos KMTS: o uso de KMTS traz a possibilidade de indefinições

nos estados, o que no processo de desenvolvimento pode ser útil para o usuário não
ter que definir a valoração nas proposições de maneira precipitada. Outro fator que
influenciou o uso de modelos KMTS foi o pequeno número de trabalhos que estudam
este modelo e ausência de trabalhos que o contraindiquem para a modelagem de
sistemas com informação parcial;
2. Utilização do refinamento modal forte: este conceito de refinamento é a base para

os outros conceitos. O refinamento modal forte definido é facilmente estendido para
o refinamento modal fraco;
3. Uso de KMTS determinı́stas: a simplificação na verificação da existência da relação

de refinamento mostrada em (BENEš et al., 2009), influenciou a limitação de escopo
para este tipo de modelos KMTS. Como será mostrado posteriormente, esta decisão
impactou na complexidade do jogo do refinamento de forma positiva;
4. Semântica da lógica de 3 valores: a semântica da abstração é compatı́vel com a

ideia de refinamento e por isto é utilizada. Todavia, a semântica de conjuntos
permite a operação de revisão que acreditamos também ser útil no processo de
desenvolvimento;
3.5 POSICIONAMENTO DO PRESENTE TRABALHO EM RELAÇÃO AOS DEMAIS 29
5. Operadores de composição paralela e conjunção: estes dois operadores foram defi-

nidos porque são a base da teoria de especificação para modelos parciais, além do
operador de composição paralela coincidir com a necessidade de expressar o sistema
em diferente nı́veis de abstração (componente e sistema);
6. Sı́ntese de KMTS a partir de diagramas de sequência e OCL: como defendido por

Krka et al. (2009), diagramas de sequências são modelos convencionais utilizados no
dia-a-dia do desenvolvimento. Gerar modelos formais a partir deles pode facilitar
o emprego de técnicas formais no processo de desenvolvimento de software; e
7. Jogo de refinamento: alguns trabalhos definem o refinamento através de um jogo

para provar certas propriedades sobre as relações definidas nestes trabalhos. No
presente trabalho, o jogo de refinamento é utilizado para mostrar que não há uma
relação de refinamento entre dois modelos.
Capı́tulo
4
SÍNTESE DE MODELOS KMTS A PARTIR DE
CENÁRIOS
O uso de modelos formais pode prover um suporte mais preciso para a verificação e
análise de propriedades de sistemas e seus componentes. Entretanto, expressar formal-
mente o comportamento pretendido de um componente ou sistema, muitas vezes, requer
uma expertise que não é encontrada normalmente nas habilidades dos projetistas e de-
senvolvedores de software. Métodos automáticos ou semi-automáticos para a criação de
modelos formais pode incentivar o uso de métodos de verificação formal, trazendo uma
maior confiabilidade aos softwares desenvolvidos.
Neste capı́tulo apresentamos a definição de modelos KMTS com ações, que é utilizada
no presente trabalho e apresentamos uma adaptação do algoritmo de sı́ntese heurı́stica
de modelos MTS a partir de cenários apresentado em (KRKA et al., 2009) para modelos
KMTS. Esta adaptação modifica todas as etapas do algoritmo para funcionar com a
lógica de três valores sobre os valores das proposições e faz algumas modificações no
sentido de corrigir de problemas observados (e explicados posteriormente) e possibilitar
uma maior automatização desta tarefa. O algoritmo apresentado em (KRKA et al., 2009)
foi utilizado como referência porque apresenta uma sı́ntese de modelos parciais baseada
em artefatos comumente utilizados durante o processo de desenvolvimento de software.
A Seção 4.1 apresenta nossa definição de KMTS com ações. Esta definição é usada
ao longo deste trabalho. A Seção 4.2 apresenta o algoritmo de sı́ntese heurı́stica de mo-
delos KMTS, explicando como cada elemento do KMTS é definido através dos cenários
informados, que são representados como diagramas de sequência da UML anotados com
OCL. A Seção 4.3 apresenta uma descrição detalhada das etapas do algoritmo proposto.
A Seção 4.4 apresenta uma análise e validação do algoritmo proposto, demonstrando
sua terminação, correção e complexidade. Por fim, uma série de validações são reali-
zadas sobre uma implementação do algoritmo proposto e seus resultados e análises são
apresentadas.
31
32 SÍNTESE DE MODELOS KMTS A PARTIR DE CENÁRIOS
4.1 MODELOS KMTS COM AÇÕES

Um modelo KMTS é uma estrutura de Kripke com modalidades nas suas transições e
indefinições nas proposições dos seus estados. No contexto de especificações modais, as
modalidades das transições podem ser vistas como comportamento obrigatório (must) e
possı́vel (may) e as indefinições nas proposições são uma forma de representar a incerteza
em relação às variáveis do sistema, representando o comportamento obrigatório com as
proposições com valor definido (verdadeiro ou falso) e o comportamento possı́vel, com as
proposições sem valor definido.
Definição 4.1.1 (KMTS). Seja AP um conjunto de proposições atômicas, Lit AP Y
t p | p P AP u o conjunto de literais sobre AP e Σ um conjunto finito de sı́mbolos
representando ações. Uma estrutura modal de Kripke com ações (KMTS) é uma tupla
M pAP, Σ, S, s0 , R , R , Lq, onde S é um conjunto finito de estados, s0 é o estado
inicial, R S Σ S e R S Σ S são relações de transição tal que R R , e
L : S Ñ 2Lit é uma função rotuladora, tal que para todo estado s e p P AP , no máximo,
um entre p and p ocorre.
As transições pertencentes aos conjuntos R e R são chamados de transições must
e may respectivamente.
A partir deste ponto, para facilitar a leitura, nós definimos que s Ñ Ý s1 representa
a
ps, a, s1q P R e s 99K s1 representa ps, a, s1q P R e para qualquer KMTS M tal que SM
a
é o conjunto de estados de M, sM 0 representa o estado inicial de M. Se não for necessário

diferenciar o KMTS, s0 representa o estado inicial do KMTS em questão. Também
usamos a notação Lps, pq para representar a valoração da proposição p no estado s.
4.2 ALGORITMO PARA SÍNTESE DE KMTS

De forma semelhante ao definido em Krka et al. (2009), o algoritmo de sı́ntese extrai,
das entradas fornecidas, os componentes, seus estados e suas transições, construindo
um modelo KMTS para cada componente. As entradas fornecidas são um conjunto de
diagramas de sequência anotados com regras OCL a respeito de propriedades especificadas
em nı́vel de sistema, ou seja, em relação a uma visão geral e não sobre componentes
individuais.
4.2.1 Entradas e Saı́das

Diagramas de sequência expressam a troca de mensagens entre os componentes do sis-
tema, definindo uma parte do comportamento de cada componente, de forma que os
diagramas são inerentemente parciais. Para se ter a ideia do comportamento do sistema,
é necessário um conjunto de diagramas de sequência. Entende-se aqui como componente
um módulo lógico do sistema, podendo ser um outro software, uma classe, um pacote ou
um usuário, por exemplo.
Para expressar as informações a respeito das variáveis do sistema antes e após a
troca de mensagens entre os componentes, o presente algoritmo utiliza um subconjunto
da OCL que permite a construção de regras de pré e poscondições com um formato
4.2 ALGORITMO PARA SÍNTESE DE KMTS 33
definido a seguir. Uma regra OCL é composta por proposições OCL da forma vi ri
com ri P verdade, f also, indef inido que indicam condições sobre as variáveis do sistema,
onde vi é uma variável e ri sua respectiva valoração.
Definição 4.2.1 (Proposição OCL). Uma proposição OCL p é um par pv, rq com r P
tv, f, iu, onde v representa verdade, f falso e i indefinido, que é utilizada para expressar
uma informação a respeito das variáveis do sistema, onde v é uma variável e r sua
respectiva valoração.
Diferente do método apresentado em (KRKA et al., 2009), no presente trabalho as

variáveis do sistema podem assumir o valor i (indefinido). O uso de variáveis com o
valor indefinido é justificável para representar cenários onde certa condição pode existir.
Podemos imaginar um cenário de determinada funcionalidade do sistema que talvez só
seja acessı́vel para usuários cadastrados. Então uma precondição para executar esta
funcionalidade ainda não está totalmente definida, mas pode ser definida futuramente.
Desta forma, a incerteza fica explı́cita e pode ser acompanhada ao longo do processo de
desenvolvimento. A vantagem de explicitar a incerteza neste contexto é que todos os
comportamentos onde esta condição pode influenciar ficam relacionados a esta incerteza.
Ao resolver esta incerteza, estes comportamentos serão obrigatoriamente analisados, de
forma que o impacto da tomada de decisão é rastreável.
Uma regra OCL é uma conjunção de proposições OCL.
Definição 4.2.2 (Regra OCL). Uma regra OCL r é uma fórmula ϕ p1 ^ p2 ^ ... ^ pn
onde cada pi com i 1, 2, ..., n é uma proposição OCL.
Regras OCL são utilizadas como pré e poscondições das mensagens do diagrama de
sequência. Uma mensagem, no diagrama de sequência, representa a troca de informação
entre dois componentes: (1) o componente de saı́da, que é quem envia a mensagem; e (2)
o componente de entrada, que é o componente que consome a mensagem. A mensagem
é composta pela ação (ou rótulo da mensagem), por duas regras OCL que representam
a precondição e a poscondição sobre variáveis do sistema antes e depois da troca de
mensagem e pelos componentes de saı́da e de entrada.
Definição 4.2.3 (Mensagem). Uma mensagem m é uma quı́ntupla pcs , a, ce , rpre , rpos q
onde ce e cs são os componentes de entrada e saı́da, respectivamente, a é a ação contida
na mensagem e rpre e rpos expressam as condições das variáveis do sistema antes e depois
da execução da ação a.
As mensagens são trocadas ao longo da linha da vida de um componente. Uma

linha da vida é uma dupla formada por um componente e um vetor que representa as
mensagens trocadas por este componente de forma ordenada, isto é, a primeira posição
do vetor representa a primeira mensagem trocada e assim por diante.
Definição 4.2.4 (Linha da vida). Uma linha da vida l é uma dupla pc, v q, onde c é um
componente e v rm0 , m1 , ...mn s é um vetor que representa as mensagens trocadas mi
com i 0, 1, ..., n (enviadas ou recebidas) por um componente.
Definição 4.2.5 (Diagrama de Sequência). Um diagrama de sequência ds é um conjunto

de linhas da vida.
De acordo com um conjunto de diagramas de sequência, é possı́vel definir o conjunto
de variáveis de domı́nio do sistema, como sendo o conjunto de todas as proposições que
aparecem em alguma regra OCL em algum diagrama de sequência.
Definição 4.2.6. Dado um conjunto de diagramas de sequência DS, o conjunto V de
variáveis de domı́nio do sistema é formado por toda variável que aparece em alguma
regra OCL em algum diagrama de sequência, isto é, V tv |v P p tal que p pv, rq e
existe alguma regra OCL ϕ em algum diagrama de sequência ds P DS u.
Assim, o algoritmo de sı́ntese heurı́stica de modelos KMTS recebe um conjunto DS
de diagramas de sequência anotados com OCL e retorna um modelo KMTS para cada
componente presente em algum diagrama de sequência do conjunto de diagramas de
sequência recebido como entrada. As informações necessárias para compor cada KMTS
estão presentes nas entradas recebidas:
Componente do sistema a ser representado: é o componente presente em alguma

linha da vida de algum diagrama de sequência da entrada;
Proposições do KMTS : as proposições são representadas pelas variáveis do sistema
e seus valores são extraı́dos através das precondições e poscondições das mensagens
do diagrama de sequência. É importante observar que é necessário definir quais
variáveis representam proposições de cada componente (variáveis fornecidadas nas
regras OCL representam a visão do sistema). Uma proposição tem seu valor indefi-
nido quando não é possı́vel definir o seu valor ou a regra OCL explicita que o valor
é indefinido (null );
Estados do KMTS : são definidos pelos valores alcançáveis das proposições de cada
componente/KMTS ao longo do conjunto de diagramas de sequência. Muitas vezes,
o valor de uma proposição pode ser deduzido pelo estado anterior e pela póscondição
que levou o KMTS ao estado atual;
Ações e transições do KMTS : as transições são definidas a partir das mensagens
trocadas pelo componente em questão. A modalidade da transição é definida como
must se a transição está presente no diagrama de sequência ou may se as regras
OCL permitem a transição, mas ela não está expressa em nenhum diagrama de
sequência da entrada.
Com uma ideia de entrada e saı́da esperada, podemos apresentar os passos realiza-
dos pelo algoritmo de sı́ntese de forma a extrair cada elemento que compõe o KMTS.
Para exemplificar estes passos, vamos assumir o exemplo do projeto de um dispositivo
eletrônico.
Este dispositivo é composto por diversos módulos, cada módulo é responsável por
um conjunto de funcionalidades e estes módulos accessam diversos sensores deste dispo-
sitivo. Para controlar o acesso aos dispositivos, existe um componente para garantir que
4.2 ALGORITMO PARA SÍNTESE DE KMTS 35
Figura 4.1 Diagrama de sequência de solicitação e acesso do componente Recurso pelo com-
ponente Módulo
um recurso não seja acessado simultaneamente por mais de um módulo. Assim, temos
três componentes: módulo, gerenciador de acesso e recurso (o dispositivo é formado por
diversos componentes do tipo módulo, um componente do tipo gerenciador de acesso e
diversos componentes do tipo recurso). Ainda não está claro para os projetistas se um
módulo pode acessar mais de um recurso simultaneamente. O funcionamento básico entre
estes três componentes é: o módulo requisita acesso ao gerenciador de recurso, que checa
se o recurso está em uso. Caso não esteja o acesso é liberado e o módulo acessa o recurso
diretamente. Caso contrário o gerenciador de recurso informa ao módulo que o recurso
está ocupado. Por fim, como só existe um gerenciador de recurso e ele tem capacidade
de processamento limitada, ele trata uma solicitação de recurso por vez.
A Figura 4.1 exibe um diagrama de sequência (anotado com regras OCL) que descreve
o cenário onde um módulo consegue acessar um determinado recurso. As regras OCL
estão descritas ao lado do diagrama de sequência.
A Figura 4.2 exibe um diagrama de sequência (anotado com regras OCL) que descreve
o caso onde um módulo não consegue acessar um determinado recurso e após o recurso
ser liberado por outro componente o módulo em questão é informado da disponibilidade
do recurso. As regras OCL estão descritas ao lado do diagrama de sequência.
A listagem a seguir contém a explicação de cada variável utilizada. As regras OCL
foram definidas de acordo com os requistos apresentados.
utilRec: variável utilizada para definir se um módulo já está utilizando um recurso
ou não;
solRec: variável utilizada para controlar se algum módulo está solicitando algum
recurso ao gerenciador de recurso;
solDisp: variável utilizada para controlar se o gerenciador de recurso está verificando

a disponibilidade de algum recurso;
Figura 4.2 Diagrama de sequência que representa um cenário onde o componente módulo
solicita acesso, mas não pode acessar um recurso
verDisp:variável utilizada para controlar se existe uma verificação de disponibilidade

de recurso;
recDisp: variável utilizada para controlar se o recurso está disponı́vel ou não; e
aguardaRec:variável utilizada para controlar se existe um módulo aguardando o

recurso ou não.
4.3 ETAPAS DO ALGORITMO PARA SÍNTESE DE KMTS

Similarmente ao algoritmo apresentado em (KRKA et al., 2009), definimos quatro etapas
para o algoritmo: (I) definir quais são as variáveis do sistema que são importantes para
cada componente, especificando regras OCL de pré e poscondições para cada compo-
nente; (II) criar diagramas de sequência na perspectiva de cada componente; (III) criar
um KMTS inicial baseado nas informações dos passos anteriores; e (IV) percorrer os
diagramas de sequência criados, definido quais são os comportamentos obrigatórios no
KMTS criado no passo anterior.
Em relação ao algoritmo proposto em (KRKA et al., 2009), as etapas (II) e (III) são
feitas na ordem inversa, isto é, em (KRKA et al., 2009) o modelo inicial (MTS) é criado e
somente após este passo os diagramas sobre a perspectiva de cada componente é criado.
Como será mostrado a seguir, esta inversão possibilita a definição de forma automática
dos estados iniciais em potencial e a definição da valoração de cada proposição nos estados
de forma mais precisa por causa da propagação dos valores realizada.
4.3.1 Etapa I: Restrições por Componente

O primeiro passo do algoritmo é similar ao apresentado em (KRKA et al., 2009) e consiste
em definir como as restrições sobre as propriedades em nı́vel do sistema interferem em
cada componente. É possı́vel observar que uma restrição em nı́vel do sistema pode não
influenciar o comportamento de um componente ou pode influenciar de forma parcial,
4.3 ETAPAS DO ALGORITMO PARA SÍNTESE DE KMTS 37
isto é, apenas uma parte da restrição é aplicável sobre o componente. Considerando que
não há especificação da interface de cada componente, o algoritmo define, de acordo com
os diagramas de sequência, quais são as mensagens trocadas pelos componentes, e para
cada componente, as mensagens que ele troca são classificadas como mensagens esperadas
ou mensagens recebidas.
Definição 4.3.1 (Mensagens Recebidas). Dado um conjunto de diagramas de sequência

DS e um componente c que possui pelo menos uma linha da vida l pc, v q em algum
ds P DS, uma mensagem recebida é uma mensagem mi P v rm0 , m1 , ...mn s tal que
mi pcs , a, c, rpre , rpos q para alguma ação a, algum componente cs e algum par de regras
OCL rpre e rpos .
Podemos citar como exemplos de mensagens recebidas do componente Módulo da

Figura 4.1 as mensagens InformaDisponibilidadeModulo e RetornaResultado.
Definição 4.3.2 (Mensagens Esperadas). Dado um conjunto de diagramas de sequência

DS e um componente c que possui pelo menos uma linha da vida l pc, v q em algum
ds P DS, uma mensagem esperada é uma mensagem mi P v rm0 , m1 , ...mn s tal que
mi pc, a, ce , rpre , rpos q para alguma ação a, algum componente ce e algum par de regras
OCL rpre e rpos .
Podemos citar como exemplos de mensagens esperadas do componente Módulo da

Figura 4.1 as mensagens SolicitaAcesso e SolicitaOperacao.
Nem toda variável do sistema determina uma restrição sobre todo componente. As-
sim, é preciso analisar para cada variável, quais componentes têm seu comportamento
influenciado por ela. Variáveis que influenciam o comportamento de um componente são
chamadas de variáveis significantes de domı́nio para aquele determinado componente, e
podem ser entendidas como todas as variáveis que aparecem em alguma precondição para
alguma mensagem esperada do componente em questão.
Definição 4.3.3 (Variável Significante de Domı́nio). Seja DS o conjunto de diagramas de

sequência e V o conjunto das variáveis do sistema. O conjunto de variáveis significantes
de domı́nio VSc V para um componente c é definido como VSc tv | para alguma
linha da vida l em algum diagrama de sequência ds P DS do componente c, existe uma
mensagem esperada que tenha na sua precondição a variável v u.
Podemos citar como exemplos de variáveis significantes de domı́nio do componente

Módulo da Figura 4.1 as variáveis utilRec, solRec, verDisp e recDisp.
Além das variáveis significantes de domı́nio, existem variáveis que influenciam quando
uma mensagem pode ser recebida por um componente, isto é, em quais condições o
componente pode processar aquela mensagem. Estas variáveis são chamadas de variáveis
de escopo porque elas existem globalmente dentro do escopo do componente. Assim,
estas variáveis definem quando as ações das mensagens esperadas podem ser invocadas,
numa perspectiva do componente c. Para uma variável ser uma variável de escopo de
um componente, ela só pode ser alterada nas mensagens trocadas em que o componente
participa tanto como componente de entrada ou como componente de saı́da.
Definição 4.3.4 (Variável alterada). Uma variável v é alterada em uma mensagem m

= pcs , a, ce , rpre , rpos q se, e somente se, existe uma proposição p pv, rq P rpre e uma
proposição p1 pv, r1 q P rpos tal que r r1 .
Definição 4.3.5 (Variável de Escopo). Seja DS o conjunto de diagramas de sequência
e V o conjunto das variáveis do sistema, o conjunto de variáveis de escopo VEc V
para um componente c, é definido como VEc tv | v é uma variável alterada apenas em
mensagens m pcs , a, ce , rpre , rpos q tal que c cs ou c ce u.
Podemos citar como exemplos de variáveis de escopo, em relação ao componente
Módulo, a variável solRec.
As variáveis utilRec, recDisp e solRec são variáveis significantes de domı́nio e de escopo
(ambas variáveis dos dois conjuntos) do componente Módulo da Figura 4.1.
Com o conjunto de variáveis significantes de domı́nio e de escopo para cada compo-
nente, é possı́vel reescrever as restrições expressas em nı́vel do sistema para cada compo-
nente (KRKA et al., 2009). O algoritmo que reescreve as restrições para cada componente
é apresentado no Algoritmo 1 e consiste em iterar sobre as mensagens que um compo-
nente c participa (como componente de entrada ou saı́da), analisando quais as variáveis
significantes de domı́nio ou de escopo do componente c compõem cada precondição ou
poscondição existentes nesta mensagens. Assim, cada precondição ou poscondição é rees-
crita apenas com as variáveis daquele componente. De maneira geral, as mensagens são
separadas em mensagens de saı́da e de entrada. Se uma mensagem for de saı́da então
a precondição desta mensagem só conterá proposições que pertencem ao conjunto de
variáveis significantes de domı́nio e a poscondição terá proposições que são ou significan-
tes de domı́nio ou de escopo. De forma inversa, se a mensagem for de saı́da, a mensagem
terá na sua precondição as proposições que são ou significantes de domı́nio ou de escopo
e na sua poscondição apenas variáveis de escopo.
Após esta etapa, algumas regras OCL associadas às mensagens trocadas são diferentes
para cada componente. A regra OCL associada à mensagem InformaDisponibilidadeMo-
dulo, por exemplo, na perspectiva do componente Módulo é:
InformaDisponibilidadeModulo
Pre: solRec = v ^ utilRec = i
Pos: solRec = f ^ recDisp = v
É possı́vel observar que a regra não contém informações sobre a proposição verDisp
porque ela não é uma variável de escopo do componente Módulo.
4.3.2 Etapa II: Diagrama de Sequência por Componente

Nesta etapa, para cada componente c, são criados diagramas de sequência na perspectiva
do componente c, chamados de diagramas de sequência estendidos. Um diagrama de
sequência estendido é um diagrama de sequência onde existe um vetor de proposições
com os valores das variáveis do componente antes e depois de cada mensagem na linha
da vida do componente, de forma a representar o estado do componente antes e depois
de cada mensagem, anotando o diagrama de sequência convencional com o estado do
Algoritmo 1: geraRestricaoOCLPorComponente
Data: Componente c
Result: Conjunto R de mensagens em que c participa com regras OCL para o
componente c
1 begin
2 R ÐÝ H
3 for m pc, a, ce , rpre , rpos q P MEc do
4 m1 ÐÝ m
5 R ÐÝ R Y m1
6 m1 .rpre ÐÝ H
7 m1 .rpos ÐÝ H
8 for p pv, rq P rpre do
9 if v P VSc then
10 m1 .rpre ÐÝ m1 .rpre Y tpu
11 for p pv, rq P rpos do
12 if v P VSc Y VEc then
13 m1 .rpos ÐÝ m1 .rpos Y tpu
14 for m pcs , a, c, rpre , rpos q P MRc do

15 m1 ÐÝ m
16 R ÐÝ R Y m1
17 m1 .rpre ÐÝ H
18 m1 .rpos ÐÝ H
19 for p pv, rq P rpre do
20 if v P VEc then
21 m1 .rpre ÐÝ m1 .rpre Y tpu
22 for p pv, rq P rpos do
23 if v P VSc Y VEc then
24 m1 .rpos ÐÝ m1 .rpos Y tpu
Figura 4.3 Diagrama de sequência estendido antes (A) e depois da propagação (B) para o
componente Módulo baseado no diagrama de sequência da Figura 4.1
componente. A cada diagrama pertencente ao conjunto de entrada em que o componente

c aparece, um novo diagrama de sequência estendido na pespectiva de c é criado. Estes
diagramas de sequência criados são utilizados para definir quais os comportamentos no
KMTS inicial devem ser obrigatórios. Os novos diagramas são criados em duas etapas: (i)
criação do diagrama baseando-se no diagrama original (na linha da vida do componente),
modificando as restrições em nı́vel do sistema para restrições no nı́vel do componente de
acordo com o resultado da etapa I; e (ii) propagação dos valores das variáveis/proposições
entre as pre e poscondições das ações consecutivas nos diagramas criados.
A criação do diagrama consiste em copiar a linha da vida do componente em questão,
preenchendo os vetores de proposições de acordo com o valor das proposições nas restrições
sobre as ações.
A propagação de valoração acontece entre proposições que não possuem o valor defi-
nido nas pre e poscondições das mensagens adjacentes na linha da vida do componente
em questão. Devemos destacar que não possuir o valor definido é diferente de possuir o
valor indefinido (i). O valor destas proposições é inicialmente inicializado com um “*”
na fase de criação do diagrama de sequência anotado e é preenchido pelo algoritmo de
propagação (Algoritmo 2).
O algoritmo proposto em (KRKA et al., 2009) assume que após a propagação de
valores, todas as variáveis terão seus valores definidos. Não existe nenhuma restrição
sobre as regras OCL que garanta tal restrição. O algoritmo apresentado neste trabalho
preenche com o valor indefinido (i) as variáveis que, após a propagação dos valores,
continuam com o valor “*’. Desta forma, os valores indefinidos ficam explı́citos, o que
pode servir de indicativo para a análise de requisitos nas próximas iterações e evita que
algum detalhe passe despercebido ao projetista do software.
A Figura 4.3 mostra um exemplo de diagrama de sequência anotado antes (A) e depois
da propagação de valor (B), baseado no diagrama da Figura 4.1 para o componente
Módulo, considerando que o vetor de variáveis é [solRec, recDisp, utilRec].
Algoritmo 2: propagaValoracaoDiagramaSequenciaAnotado
Data: Linha da vida l do componente c no diagrama de sequência anotado sda
Result: Linha da vida l com as valorações propagadas
1 begin
2 vetorDeM ensagensOrdenadas ÐÝ
ordenaM ensagensP orOrdemCronologicaplq
3 vetorDeV aloracaoCorrente ÐÝ vetorDeM ensagensOrdenadasr0s
4 for i 0; i |vetorDeM ensagensOrdenadas|; i do
5 for j 0; j |conjuntoV ariaveisSignif icantesdeC |; j do
6 if vetorM ensagensOrdenadasris.anotacaorj s ‘1 then
7 vetorM ensagensOrdenadasris.anotacaorj s ÐÝ
vetorDeV aloracaoCorrenterj s
8 else
9 vetorDeV aloracaoCorrenterj s ÐÝ
vetorM ensagensOrdenadasris.anotacaorj s
10 for i |vetorDeM ensagensOrdenadas|; i ¡ 0; i do

12 if vetorM ensagensOrdenadasris.anotacaorj s ‘ then
1
13 vetorM ensagensOrdenadasris.anotacaorj s ÐÝ
vetorDeV aloracaoCorrenterj s
14 else
15 vetorDeV aloracaoCorrenterj s ÐÝ
vetorM ensagensOrdenadasris.anotacaorj s
16 for i |vetorDeM ensagensOrdenadas|; i ¡ 0; i do

18 if vetorM ensagensOrdenadasris.anotacaorj s ‘1 then
19 vetorM ensagensOrdenadasris.anotacaorj s ÐÝ “i2
20 else
4.3.3 Etapa III: KMTS Inicial por Componente

Após criar o conjunto de diagramas na perspectivva de cada componente, o próximo passo
do algoritmo de sı́ntese consiste em criar um KMTS inicial por componente. Este KMTS é
chamado de inicial porque ele será modificado pela última etapa do algoritmo (Algoritmo
4). A ideia deste KMTS é criar um modelo que defina os estados do componente e
adicione as transições entre os estados, respeitando as restrições de pre e poscondições
de cada mensagem/ação. A criação dos estados é feita de forma iterativa, a partir de
um conjunto inicial de estados, da seguinte forma: dado um estado m, seleciona-se quais
ações daquele componente, que o KMTS representa, são satisfeitas pela valoração das
proposições em m, isto é, se o valor da proposição no estado m é igual à valoração de
cada proposição na regra OCL analisada. Para todas as ações a, haverá uma transição
may pm, a, m1 q levando do estado m para um estado m1 . O estado m1 tem a valoração das
suas proposições igual ao estado m, exceto para as variáveis que são alteradas pela ação,
garantindo assim que m1 satisfaça a poscondição da ação. Se o estado m1 não existir,
ele é criado. Assim, estados são adicionados ao KMTS inicial até que todos os estados
tenham sido analisados por cada ação do componente em questão. O Algoritmo 3 mostra
os passos necessários para criar o KMTS inicial a partir de um conjunto inicial de estados.
Algoritmo 3: geraKMTSInicialParaComponente
Data: Componente c, o conjunto Mc, resultado do Algoritmo 1, e o conjunto de
estados S para serem adicionados ao KMTS. Na primeira chamada, S deve
ser o conjunto de estados iniciais em potencial
Result: M, o KMTS Inicial para componente C
1 begin
2 estadosP araAdicionar ÐÝ H
3 SM ÐÝ SM Y S
4 for m P SM do
5 for a P M c do
6 if m satisfaz m.rpre then
7 estadoAlvo ÐÝ clonepmq
8 estadoAlvo ÐÝ
modif icaV aloracaoDasV ariaveisAlteradaspestadoAlvo, aq
9 if estadoAlvo R SM then
10 SM ÐÝ SM Y testadoAlvou
11 estadosP araAdicionar ÐÝ
estadosP araAdicionar Y testadoAlvou
12 RM ÐÝ RM Y tpm, a, estadoAlvoqu
13 if estadosP araAdicionar H then
14 geraKM T SInicialP araComponentepc, M c, estadosP araAdicionarq
A função modificaValoracaoDasVariaveisAlteradas (linha 8) não possui seu algoritmo

apresentado. Esta função recebe dois parâmetros: um estado s e uma ação a. A ideia
desta função é modificar a valoração das proposições no estado s de forma que as pro-
posições do estado s e as proposições da poscondição possuam a mesma valoração. Esta
etapa do algoritmo apresentado difere da mesma etapa do algoritmo proposto em (KRKA
et al., 2009) em dois pontos: (i) o algoritmo de sı́ntese proposto em (KRKA et al., 2009)
não possui esta recursão, e, não faz a análise correta para a adição das transições, pois ele
não checa se pode existir uma transição entre um estado já existente e um estado adicio-
nado. A recursão é utilizada para garantir que todas as combinações entre os estados (já
existentes e novos) seja avaliada para adicionar uma transição; e (ii) a existência de um
conjunto de estados iniciais em potencial calculado de forma automática, que representa
um avanço em relação ao algoritmo proposto em (KRKA et al., 2009), onde o usuário
deve informar o estado inicial.
O conjunto inicial de estados é definido de acordo com o valor das variáveis antes da
primeira mensagem ser trocada em cada linha da vida de um componente em questão
nos seus diagramas estendidos. Estes estados compõem os estados iniciais em potencial.
Diferente do defendido em (KRKA et al., 2009), acreditamos que isto não é um problema
do algoritmo visto que o conjunto de diagramas de sequência descreve os comportamen-
tos mais importantes de um componente e, consequentemente, o comportamento de um
componente ao ser inicializado é, sem dúvida, importante. No algoritmo definido por
(KRKA et al., 2009), o usuário deve definir um estado inicial. Caso o usuário defina
o estado errado, o modelo gerado não irá representar adequadamente os diagramas de
sequência. No algoritmo do presente trabalho, um grupo de estados iniciais em potencial
não significa dizer que, necessariamente, o estado inicial do KMTS está em um daque-
les estados, apenas que o algoritmo detectou que algum deles pode ser o estado inicial.
Ao fim do processamento do algoritmo de sı́ntese, o usuário deve escolher qual o estado
inicial (o algoritmo pode apresentar os estados iniciais em potencial como uma possibili-
dade para o usuário). O algoritmo para detecção do estado inicial de cada diagrama de
sequência é apresentado na etapa IV.
A Figura 4.4 mostra o KMTS inicial do componente Módulo. Para facilitar a visua-
lização, os nomes das ações foram reduzidos e os estados exibem o vetor das proposições.
Ao final deste passo, é possı́vel inferir o valor de algumas proposições que possuem seu
valor indefido porque assumimos que cada combinação de valores das proposições define
um estado, de forma que não existem dois estados com as mesmas valorações. Assim,
após esta etapa é possı́vel remover incertezas e/ou remover estados (caso já exista estados
com as mesmas valorações). Todavia, este passo não foi realizado no presente trabalho,
sendo listado nos trabalhos futuros.
4.3.4 Etapa IV: Comportamento Obrigatório por Componente
Por fim, a etapa IV é responsável por definir o comportamento obrigatório sobre as

transições do KMTS inicial. A ideia desta etapa é utilizar os diagramas de sequência ano-
tados e “caminhar” simultaneamente nos diagramas de sequência anotados e no KMTS
inicial. Para cada diagrama, o estado inicial escolhido no KMTS muda de acordo com a
valoração inicial da linha da vida do componente no diagrama de sequência em questão.
Figura 4.4 KMTS inicial do componente Módulo da Figura 4.1
Toda vez que uma mensagem é enviada no diagrama de sequência, uma transição com
o mesmo rótulo da ação é realizada no KMTS, alterando seu estado corrente. Estas
transições utilizadas para percorrer no KMTS inicial têm sua modalidade alterada para
must à medida que os diagramas de sequência anotados são percorridos.
Todavia, como mostrado em (KRKA et al., 2009), este método pode transformar
transições que saem e entram em um mesmo estado (auto-transições) em um compor-
tamento obrigatório. Todavia, as auto-transições são criadas para que o máximo de
comportamento possı́vel seja adicionado e não estão, necessariamente ,expressas nos dia-
gramas de sequência. Desta forma, transformar uma auto-transição em must pode forçar
a existência de um loop no comportamento do componente que não deveria existir. A
solução proposta por (KRKA et al., 2009), e seguida no presente trabalho, é chamada
de refino e consiste em duplicar o estado s, que possui a auto-transição, gerando um s’ e
criar uma transição must entre s e s’ com a ação a da auto-transição, adicionar a auto-
transição em s’ e, para cada transição t ps, x, s2 q tal que x a, criar uma transição
t1 ps1 , x, s2 q. Desta forma, o loop fica presente no KMTS final, mas de forma opcional
(é possı́vel remover a auto-transição may criada no estado s”). A Figura 4.5 exemplifica
este processo.
O Algoritmo 4 realiza as ações da etapa IV. Observe o tratamento para evitar o

auto-loop obrigatório entre as linhas 16 - 20.
(KRKA et al., 2009) chama este tratamento do auto-loop de refino porque existe uma
relação de refinamento entre os modelos antes e depois da clonagem. Este resultado é
utilizado para provar certas propriedades do algoritmo de sı́ntese.
A Figura 4.6 exibe o KMTS gerado para o componente Módulo como resultado do
algoritmo de sı́ntese.
Figura 4.5 Operação de Refino para evitar auto-loop obrigatório
Figura 4.6 KMTS inicial do componente Módulo

Algoritmo 4: geraKMTSFinal
Data: KMTS inicial Mc e o conjunto DSac de diagramas de sequência na
perspectiva do componente c
Result: KMTS final Mc
1 begin
2 for ds P DSac do
3 vetorDeM ensagensOrdenadas ÐÝ
ordenaM ensagensP orOrdemCronologicapds.linhaDaV idaq
4 primeiroEstadoDoDS ÐÝ vetorDeM ensagensOrdenadasr0s
5 estadosIniciais ÐÝ
estadosComM esmaV aloracaopSM c , primeiroEstadoDoDS q
6 estadosCorrentes ÐÝ estadosIniciais
7 proximosEstados ÐÝ H
8 for i 0; i |vetorDeM ensagensOrdenadas|; i do
9 acao vetorDeM ensagensOrdenadasris
10 for s P estadosCorrentes do
11 for t ps, acao, s1 q P RM do
12 if t R RM then
13 RM c ÐÝ RM c Y ttu
14 proximosEstados ÐÝ proximosEstados Y ts1 u
15 if s == s’ then
16 s2 ÐÝ clonepsq
17 RM c ÐÝ RM c ttu
18 RM ÐÝ R tps, acao, s1 u
19
c Mc
do
for t ps, a, squalquer q P RM
20

RM c ÐÝ RM c Y tps , a, squalquer qu
1
21 estadosCorrentes ÐÝ proximosEstados
4.4 ANÁLISE DO ALGORITMO DE SÍNTESE 47
4.4 ANÁLISE DO ALGORITMO DE SÍNTESE

Para analisar o algoritmo proposto, assumimos, de forma similar ao realizado em (KRKA
et al., 2009), que:
um componente c qualquer executa uma sequência de eventos (ou ações) tr

e1 e2 ...en , onde ei com i 1, 2, ..., n são eventos do componente c que não violam
as restrições definidas sobre o componente c. Chamaremos esta série de eventos de
trace de execução; e
um diagrama de sequência representa um trace de execução que por sua vez re-
presenta a sequência de mensagens trocadas em um diagrama de sequência sob a
perspectiva de um componente especı́fico.
O algoritmo de sı́ntese de modelos KMTS a partir de diagramas de sequência anotados

com OCL sempre termina, produz as saı́das corretas e tem uma complexidade exponencial
em relação ao número de variáveis significantes que um componente pode possuir. Estas
três afirmações são provadas nas Proposições 4.4.1, 4.4.2 e 4.4.3, respectivamente, e são
adaptações das provas apresentadas em (KRKA et al., 2009).
Proposição 4.4.1. O algoritmo de sı́ntese de modelos KMTS sempre termina.
Demonstração. A prova da terminação deste algoritmo segue do fato de que todos os

seus loops (tipo for ) iteram sobre conjuntos finitos de forma que cada elemento só é
selecionado uma vez. A recursão no Algoritmo 3 é responsável por adicionar novos esta-
dos ao KMTS. No algoritmo definido, não existem dois estados com a mesma valoração
para as proposições. Como cada proposição pode assumir três valores (verdade, falso
e indefinido) e um componente tem |VS Y VE | proposições, o número máximo de com-
binações das valorações das variáveis (e consequentemente o número máximo de estados)
do componente c será 3|VS YVE | , que é um número finito. Desta forma, a recursão ter-
mina, o algoritmo sempre termina. No Algoritmo 3, é possı́vel notar este fato pois, após
criar todos os possı́veis estados, a condição da linha 9 deixar de ser verdadeira de forma
que a variável estadosP araAdicionar será vazia, fazendo com que o algoritmo não seja
invocado recursivamente (linha 14) porque a condição da linha 13 será falsa.
Proposição 4.4.2. O algoritmo de sı́ntese de modelos KMTS retorna o resultado correto,

ou seja, (i) o KMTS representa todos os possı́veis traces de execução tr e1 e2 ...en
permitidos pelas restrições dos componentes; (ii) o KMTS não representa nenhum tr
e1 e2 ...en que possua algum evento que viole restrições dos componentes; e (iii) o KMTS
representa todos tr e1 e2 ...en que representam comportamentos obrigatórios.
Demonstração. Seja um componente c e tr e1 e2 ...en um trace qualquer de execução de

c.
(i) por indução sobre o tamanho de tr, mostramos que o KMTS resultante possui um
caminho que representa tr (observando que eventos e ações são sinônimos).
Base: tr e1 . O KMTS Inicial M terá a transição ps0 , e1 , s1 q para algum s1 P SM porque
a condição da linha 6 (Algoritmo 3) garante que são criadas transições (linha 12) para
todos os eventos que têm suas precondições válidas em s0 .
Passo indutivo: tr e1 e2 ...en en 1 . Suponha que M represente um tr1 de tamanho n.
Vamos mostrar que M representa todo tr de tamanho n 1 que não viola as restrições
de c. Seja o estado s P SM alcançado pela sequência de tr de tamanho n e en 1 o evento
de posição n 1 em tr. De acordo com a condição da linha 6 (Algoritmo 3), o algoritmo
irá gerar uma transição para cada evento e que tenha suas precondições satisfeitas em s,
o que inclui o evento en 1 .
(ii) segue um raciocı́nio análogo ao item (i), considerando no passo indutivo que todo
trace de tamanho n 1 que não respeite as restrições do componente c não será simulado
pelo KMTS M . Isto ocorre porque o evento en 1 não tem suas precondições satisfeitas
em s (estado alcançado pelo tr de tamanho n) e, pela condição da linha 6 (Algoritmo 3),
a transição que representa en 1 não será adicionada ao modelo M .
(iii) segue direto do fato de que um comportamento só é obrigatório no KMTS se,
e somente se, ele é especificado em algum diagrama de sequência. Este fato pode ser
observado no Algoritmmo 4 pois, ele itera sobre todas as mensagens (ações) que o com-
ponente troca (for da linha 8) e transforma uma transição may em must se a mensagem
está expressa no diagrama de sequência (linha 13).
Proposição 4.4.3. A complexidade do algoritmo de sı́ntese de modelos KMTS a partir

de diagramas de sequência anotados com OCL é exponencial em função do tamanho de
variáveis significantes que um componente possui.
Demonstração. Seja NC o número de componentes de um sistema, NDS o número de
diagramas de sequência, NE o número de eventos distintos, NV o número de variáveis
de domı́nio do sistema, TDS o tamanho máximo de um diagrama de sequência, NCSV o
número máximo de variáveis significantes de um componente. Cada fase do algoritmo é
chamada separadamente. A complexidade de cada etapa é:
Etapa I: nesta etapa, cada diagrama de sequência é analisado uma vez para extração
dos componentes e dados para outras etapas (existem NDS diagramas de sequência
de tamanho TDS ), representando NDS TDS iterações. Para cada componente
extraı́do (existem NC componentes), existem duas iterações sobre as regras OCL
das mensagens (existem NE eventos) que este componente participa (linhas 3 e 14
do Algoritmo 1). Assim, no pior caso, a complexidade de tempo é OpNDS TDS
2 NC NE q;
Etapa II: para cada diagrama de sequência e para cada componente, um diagrama de
sequência anotado é gerado, ou seja, são gerados NDS NC diagramas de sequências
anotados. Para cada diagrama de sequência anotado, o algoritmo de propagação
(Algoritmo 2) varre a linha da vida (TDS ) três vezes (linhas 4, 10 e 16), assim, no
pior caso, a complexidade de tempo é OpNDS NC 3 TDS q;
Etapa III: no pior caso, o Algoritmo 3 desta etapa adicionará 3NCSV estados pois,
no algoritmo definido, não existem dois estados com a mesma valoração para as
4.5 VALIDAÇÃO DO ALGORITMO DE SÍNTESE 49
proposições. Como cada proposição pode assumir três valores (verdade, falso e
indefinido) e um componente tem |VS Y VE | proposições, o número máximo de
combinações das valorações das variáveis (e consequentemente o número máximo
de estados) do componente c será 3|VS YVE | , o que resulta que o algoritmo desta
etapa será invocado 3NCSV vezes. Para cada estado adicionado, existe uma iteração
sobre os eventos de cada componente (linha 4 e 5). Este passo é repetido para cada
componente (NC ), o que resulta em uma complexidade de tempo Op3NCSV NC
NE q;
Etapa IV: para cada diagrama de sequência anotado (linha 2 do Algoritmo 4), que
representa o número de diagramas de sequência vezes o número de componentes,
NDS NC ) as linhas da vida são percorridas, iterando pelas mensagens (linha 8 do
Algoritmo 4). Para cada mensagem, os estados do componente são analisados e para
cada estado do componente (linha 10 do Algoritmo 4) as ações (NE ) são analisadas
(linha 11 do Algoritmo 4). No pior caso, cada componente tem 3NCSV estados e
assim temos que a complexidade de tempo é OpNDS NC TDS 3NCSV NE q.
Desta forma, a complexidade de tempo do algoritmo de sı́ntese é exponencial já que

algumas de suas etapas têm complexidade exponencial.
Todavia, como argumentado por (KRKA et al., 2009), esta complexidade exponencial
não é um problema na prática porque um componente terá um número pequeno de
variáveis significantes (NCSV ) e a quantidade destas variáveis não aumenta à medida que
o sistema cresce e, assim, em casos reais, espera-se tempos de execução polinomiais em
relação ao tamanho da entrada.
4.5 VALIDAÇÃO DO ALGORITMO DE SÍNTESE

O algoritmo de sı́ntese heurı́stica de modelos KMTS a partir de cenários foi implementado
e está disponı́vel em (MACHADO, 2016). O algoritmo foi testado em um computador
com a seguinte configuração: processador Intel(R) Core (TM) i7-5500U CPU @2.40GHz
2.40 GHz, memória ram 8 GB e sistema operacional Windows 10 64 bits. Os testes sobre
a implementação foram divididos em dois grupos: testes de validação da correção e testes
de validação do performance.
A validação da correção ocorreu através da geração manual de 10 casos de testes.
Cada um dos testes foi executado e a saı́da do algoritmo foi analisada. Caso a saı́da não
fosse a saı́da esperada, o algoritmo era modificado para corrigir o erro. Ao total, 4 reparos
foram realizados. Ao fim de cada reparo, os 10 casos foram executados novamente e as
saı́das foram analisadas. Até o presente momento, nenhum novo erro foi detectado com
outros testes realizados.
Os testes para análise de execução foram criados manualmente e tiveram a intenção
de comparar os resultados obtidos com os resultados mostrados (KRKA et al., 2009). A
quantidade de estados dos modelos resultantes variou muito de acordo com a entrada for-
necida. Similarmente ao valor encontrado em (KRKA et al., 2009), a média para os testes
maiores variou entre 40 e 60 estados. Já a média de tempo encontrada para os maiores
testes ficou entre 20 e 23 segundos, diferente da média de 36 segundos encontrada em

(KRKA et al., 2009). Acreditamos que esta diferença de tempo médio está na diferença
de capacidade de processamento dos computadores utilizados durante os testes. Não foi
possı́vel executar o algoritmo implementado em (KRKA et al., 2009) porque a tecnologia
utilizada para implementar o algoritmo não é mais compatı́vel com as ferramentas atuais
e alterações no código-fonte seriam necessárias.
Capı́tulo
5
RELAÇÕES E OPERAÇÕES PARA MODELOS KMTS
Alguns autores definem um conjunto de operações básicas para respresentar o compor-

tamento de software através de especificações parciais. Estas operações, juntamente com
a relação de refinamento e uma classe de modelos formam uma teoria da especificação.
Neste sentido, este capı́tulo apresenta um estudo das propriedades, relações e operações
sobre modelos KMTS, de forma a definir uma teoria da especificação para modelos KMTS.
A Seção 5.1 apresenta os conceitos de refinamento modal forte e refinamento com-
pleto para modelos KMTS. Estes conceitos são baseados nos conceitos de refinamento
presentes na literatura. Outras definições também são apresentadas como as defnições
de implementação e de KMTS determinı́sticos. A Seção 5.2 apresenta uma definição
do operador de composição paralela para modelos KMTS juntamente com o conceito de
composicionalidade. Em seguida, a Seção 5.3 apresenta uma definição do operador de
conjunção para modelos KMTS juntamente com a definição do conceito de consistência
e da relação de consistência para modelos KMTS.
5.1 REFINAMENTO DE KMTS
A relação de refinamento definida para modelos KMTS apresentada neste trabalho é

uma adaptação da definição proposta em (HUTH; JAGADEESAN; SCHMIDT, 2001b)
considerando os KMTS com ações. O uso de ações se faz necessário porque nosso escopo
contempla a modelagem de softwares e componentes reativos.
A definição de refinamento entre modelos proposta e utilizada neste trabalho se baseia
na definição de refinamento modal forte entre os estados dos modelos (Definição 2.3.1.
Um estado n é refinamento modal forte de um estado m, m ¨ n, se ele preserva o com-
portamento obrigatório de m (as transições must e proposições com valorações verdade
ou falso) e não adiciona nenhum comportamento possı́vel que não esteja previsto em m
(todas as transições may de n devem possuir uma transição correspondente em m e todas
as proposições indefinidas em n estão indefinidas em m). A Definição 5.1.3 formaliza este
conceito.
51
52 RELAÇÕES E OPERAÇÕES PARA MODELOS KMTS
,L q
Definição 5.1.1 (Refinamento de Literal). Dados M pAPM , ΣM , SM , sM 0 , RM , RM M
, L q dois KMTS. Dizemos que um estado n P S é
e N pAPN , ΣN , SN , sN 0 , RN , RN N N
um refinamento de literal de um m P SM , LM pmq ¤ LN pnq, sse para todo p P LM pmq
então p P LN pnq e o valor-verdade de p em m é o mesmo valor-verdade de p em n ou p é
indefinido em m.
O operador ¤ define entre dois estados quaisquer uma relação que chamamos de
refinamento de literal, isto é, se ¤ vale entre dois estados, dizemos que um estado é um
refinamento de literal do outro estado. Usaremos ¦ para dizer que não há refinamento
de proposições entre dois estados.
Definição 5.1.2 (Refinamento Modal Forte Entre Estados). Dados M pAPM , ΣM ,

, L q e N pAP , Σ , S , s , R , R , L q dois KMTS. Dizemos
SM , sM 0 , RM , RM M N N N N0 N
que um estado n P SN refina um estado m P SM sse:
N N
1. LM pmq ¤ LN pnq;
2. Para todo pm, a, m1 q P RM , existe pn, a, n1 q P RN tal que n’ refina m’;

, existe pm, a, m1 q P R tal que n’ refina m’.
3. Para todo pn, a, n1 q P RN M
A partir deste ponto, usaremos apenas refinamento para se referir ao refinamento

modal forte.
Podemos ampliar a definição de refinamento entre estados para refinamento entre
modelos, definindo que um modelo N é um refinamento de um modelo M se existir
um refinamento de estados entre seus estados iniciais. Como a definição de refinamento
de estado se estende aos estados alcançáveis, a definição de refinamento entre modelos
garante que todos os estados alcançáveis a partir do estado inicial de N são refinamento
de algum estado alcançável a partir do estado inicial de M .
Definição 5.1.3 (Refinamento Modal Forte entre Modelos). Dados M pAPM , ΣM ,

, L q e N pAP , Σ , S , s , R , R , L q dois KMTS. N refina M
se e somente se existe uma relação < SM SN tal que pm0 , n0 q P <, e para qualquer
N N
par pm, nq P <:
1. LM pmq ¤ LN pnq;
2. Para todo pm, a, m1 q P RM , existe pn, a, n1 q P RN com pm1 , n1 q P <

, existe pm, a, m1 q P R com pm1 , n1 q P <
3. Para todo pn, a, n1 q P RN M
Nós utilizados M ¨ N para denotar que N é um refinamento de M e M ª N para

denotar que N não é um refinamento de M .
Para ilustrar o refinamento sobre modelos KMTS, adaptamos um exemplo de (SA-
BETZADEH; EASTERBROOK, 2003). Neste exemplo o comportamento de uma câmera
com três funcionalidades principais é considerado: obturador aberto ou fechado, luz do
flash ligada ou desligada e auto-focus sendo aplicado ou não. Quando uma proposição é
5.1 REFINAMENTO DE KMTS 53
Figura 5.1 KMTSs representando os possı́veis comportamentos da câmera. Em (A) uma

especificação do comportamento da câmera. Em (B) um possı́vel refinamento da especificação
mostrada em (A). Em (C) um modelo de comportamento da câmera que não é um refinamento
da especificação mostrada em (A).
indefinida em um estado m ela não aparece no estado m. As seguintes propriedades são

consideradas: s - representa quando o obturador está aberto(s), fechado (¬s) ou indefi-
nido; f o - representa quando o autofocus está sendo aplicado (fo), não aplicado (¬fo) ou
indefinido; e f l - indica quando a luz do flash está ligada (fl), desligada (¬fl) ou indefi-
nida. A câmera tem três ações: a - representa o usuário pressionando o botão para tirar
a foto; b - representa o usuário apertando o botão para ativar o auto-focus; c - representa
o usuário apertando um botão para cancelar o disparo da foto; e t - representa a ação
automática que faz a câmera ficar pronta para tirar outra foto novamente.
Figura 5.1(A) mostra um KMTS que representa o comportamento do obturador e a
possibilidade de um comportamento face-focus, isto é, uma funcionalidade que automa-
ticamente focaliza o rosto das pessoas na foto. Assumindo que esta funcionalidade não
entre na versão final da câmera, a Figura 5.1(B) mostra um KMTS que é um possı́vel re-
finamento da especificação presente na Figura 5.1(A) sem a funcionalidade de face-focus.
Com a relação de refinamento definida, podemos apresentar a definição de imple-
mentação:
Definição 5.1.4 (Implementação). Seja um KMTS I pAP, ΣI , S, sM 0 , R , R Lq, di-
zemos que I é uma implementação do KMTS M pAPM , ΣM , SM , sM 0 , RM , RM , L q,
M
se R R , M ¨ I e para todo s P S, p P Lpsq ou p P Lpsq para qualquer p P AP .

A partir deste ponto, usamos a notação I pM q para representar o conjunto de todas
as implementações do modelo M .
5.1.1 Propriedades da Relação de Refinamento

Como dito anteriormente, para que < seja uma relação de refinamento de acordo com
uma teoria da especificação, < deve ser reflexiva e transitiva.
Proposição 5.1.1 (A relação de refinamento é uma relação reflexiva e transitiva). Seja

M , N e O três modelos KMTS. Temos que M ¨ M e se M ¨ N e N ¨ O então M ¨ O
Demonstração.
1. Reflexividade: a prova segue diretamente da Definição 5.1.3 pois, é fácil verificar

que existe uma relação de refinamento < que mapeará cada estado m P SM para
ele mesmo, de forma que para todo m P M pm, mq P < (incluindo o par pm0 , m0 q).
Assim, M ¨ M e < é uma relação reflexiva; e
2. Transitividade: vamos considerar que <M,N represente os pares da relação M ¨ N

e que <N,O represente os pares da relação N ¨ O. É possı́vel criar um mapeamento
<M,O entre M e O de forma que se existir um par pm, nq P <M,N e um par pn, oq P
<N,O então o par pm, oq P <M,O . É válido observar que o par pm0 , o0 q P <M,O porque
pm0, n0q P <M,N e pn0, o0q<N,O . Ou seja, M ¨ O e ¨ é uma relação transitiva.
É importante observar que como a relação de refinamento é transitiva, se M ¨N

então I pN q I pM q.
Proposição 5.1.2. Sejam M e N dois modelos KTMS. Se M ¨ N então I pN q I pM q.

Demonstração. A prova é uma consequência direta da transitividade da relação de refi-
namento modal, isto é, para todo I P I pN q vale N ¨ I (Definição 5.1.4). Como M ¨ N
e ¨ é transitiva, temos que M ¨ I para todo I P I pN q, ou seja, I pN q I pM q.
A relação de refinamento sobre modelos (e também sobre os estados) induz uma

relação de equivalência (representada aqui pelo sı́mbolo ) sobre os modelos (e também
sobre os estados).
Definição 5.1.5 (Equivalência entre Modelos KMTS). Sejam dois KMTS M e N , M é

equivalente a N , M N , se, e somente se M ¨ N e N ¨ M .
Como em outras relações de refinamento, M ¨ N implica em I pN q I pM q, mas o

inverso, isto é, I pN q I pM q não implica em M ¨ N . O inverso só vale para casos onde
o modelo M é determinı́stico (assim como mostrado para modelos MTS em (BENEš et
al., 2009)).

Definição 5.1.6 (KMTS Determinı́stico). Um KMTS M pAPM , ΣM , SM , sM 0 , RM , RM
, LM q é determinı́stico sse para cada s P SM e a P ΣM existe no máximo um s tal que
1
s1 P S e s 99K s1 .
a
Proposição 5.1.3. Sejam M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,

M N N
, L q dois modelos KMTS tal que M é determinı́stico. Se I pN q I pM q
SN , sN 0 , RN , RN N
então M ¨ N .
Demonstração. Sejam M e N dois KMTS tal que M é determinı́stico e I pN q I pM q.

Para mostrar que M ¨ N vamos mostrar que as condições entre os modelos M e N
garantem a existência de uma relação de refinamento < entre eles.
O par pm0 , n0 q P < pelos seguintes fatos:
1. O conjunto I pN q contém um KMTS para cada possı́vel valoração do estado inicial

de N pois, se existir alguma indefinição nas proposições em n0 , existe pelo menos
uma implementação para cada possı́vel valoração distinta sobre a indefinição de
n0 . Como LN pn0 q ¤ I pi0 q e LM pm0 q ¤ I pi0 q para todo I P I pN q, as proposições
definidas em m0 e em n0 têm a mesma valoração e, como existe um i0 para cada
possı́vel valoração das proposições indefinidas em n0 , temos que toda proposição
indefinida em n0 é indefinida em m0 , logo LM pm0 q ¤ LN pn0 q;
2. Suponha uma transição pm0 , a, m1 q P RM . Então, todas as implementações I de

M devem possuir uma transição pi0 , a, i1 q. Como I pN q I pM q então todas as
implementações de N possuem uma transição pi0 , a, i1 q, e assim, pn0 , a, n1 q P RN , ou
.
seja, para toda transição pm0 , a, m1 q P RM existe uma transição pn0 , a, n1 q P RN
3. Suponha uma transição pn0 , a, n1 q P RN . Então deve existir uma implementação

I P I pN q que possui a transição pi0 , a, i1 q. Como I pN q I pM q então M ¨ I e
então, como M é determinı́stico deve existir uma transição pm0 , a, m1 q P RM , ou

seja, para toda transição pn0 , a, n q P RN existe uma transição pm0 , a, m q P RM
1 1 .
De maneira similar, é possı́vel mostrar que vale para qualquer estado m P SM , alcançável
a partir de m0 . Logo, R é uma relação de refinamento e M ¨ N .
5.1.2 Relação de Refinamento no Desenvolvimento de Software

A ideia de refinamento no desenvolvimento de software se assemelha com o conceito de
refinamento definido, considerando que nos dois conceitos há a ideia de um novo modelo,
construı́do com base no modelo anterior. Este novo modelo é criado a partir da análise
de novos requisitos que podem definir comportamentos ou propriedades que o sistema
ou componente deve possuir. Comumente, os novos requisitos podem ser expressos como
novos diagramas de sequência (KRKA et al., 2009) ou como propriedades (invariantes
sobre o sistema) (UCHITEL; BRUNET; CHECHIK, 2009).
Quando a propriedade se referir ao sistema (e não a um componente especı́fico) é
possı́vel utilizar a operação de composição paralela para criar o modelo do sistema a
partir dos modelos dos componentes. Entretanto, é necessário definir, de forma similar
ao definido em (KRKA; MEDVIDOVIC, 2013), um método de propagar alterações no
modelo do sistema para os modelos dos componentes. Este método é listado nos trabalhos
futuros.
Quando novos requisitos são expressos como propriedades, a análise dos modelos
KMTS pode ser realizada considerando um KMTS como uma abstração de uma estrutura
de Kripke ou como um conjunto destas estruturas.
Em (SHOHAM; GRUMBERG, 2007) uma estrutura de Kripke é abstraı́da em um
KMTS, reduzindo o tamanho do modelo para contornar o problema de explosão de es-
tados. Neste caso, técnicas de verificação de modelo parciais podem ser utilizadas para
analisar se os modelos existentes satisfazem as propriedades requeridas. Caso a veri-
ficação retorne que a propriedade é satisfeita no modelo parcial, então em qualquer imple-
mentação possı́vel daquele modelo a propriedade valerá (como mostrado anteriormente,
implementações possuem relação de refinamento com suas especificações e a relação de
refinamento preserva propriedades CTL (BAIER; KATOEN; LARSEN, 2008)). Nos ca-
sos em que a propriedade é falsa, nenhuma implementação satisfaz esta propriedade e o
modelo deve ser corrigido. Nos casos onde a propriedade é indefinida, significa dizer que o
modelo não possui informações suficientes, e ele deve ser refinado para que a propriedade
possa ser verificada. Em todos os casos, é possı́vel utilizar os contraexemplos fornecidos
pelos algoritmos para fazer a correção manual dos modelos, se necessário. É importante
destacar que nos referimos a CTL, mas utilizamos modelos baseados em ações. Todavia,
existem lógicas temporais baseadas em ações, como a ACTLW (MEOLIC; KAPUS; BRE-
ZOVCNIK, 2008) ou a α-CTL (MENEZES; BARROS; PEREIRA, 2010) que utilizam
um adaptação da CTL para a se referir às ações nas fórmulas. É importante ressaltar
que as propriedades também são preservadas para lógicas baseadas em ações (BAIER;
KATOEN; LARSEN, 2008). No nosso trabalho, o projetista possui modelos abstratos e
deseja obter modelos concretos. Apesar da diferença de objetivos, a verificação proposta
em (SHOHAM; GRUMBERG, 2007) pode ser utilizada.
Em (GUERRA; ANDRADE; WASSERMANN, 2013b) um KMTS é interpretado
como um conjunto de estruturas de Kripke. Caso a verificação de uma propriedade,
com esta semântica, retorne falso ou indefinido, é possı́vel utilizar técnicas de revisão de
modelos para refinar o modelo em questão, gerando um modelo KMTS em que a proprie-
dade seja verdadeira. Todavia, ao utilizar esta abordagem, o projetista deve ter em mente
que o modelo KMTS gerado pode não será um refinamento do modelo anterior porque
a propriedade que era falsa passa a valer e então o modelo gerado não preserva as pro-
priedades do modelo anterior. Além disto, como mostrado em (GUERRA; ANDRADE;
WASSERMANN, 2013b), pode ser feita de forma semiautomática.
Nos dois casos é necessário refletir as alterações nos modelos nos diagramas de sequência
e/ou no código-fonte. Este mapeamento entre o modelo e o diagrama de sequência (ou
código-fonte) é um ponto do processo que precisa ser estudado e é listado como trabalho
futuro.
Quando novos requisitos são expressos como diagramas de sequências, duas abor-
dagens podem ser consideradas para a atualização dos modelos: (I) utilizar todos os
diagramas de sequência existentes, gerando apenas um modelo por componente, se não
houver alguma inconsistência entre os diagramas de sequência; ou (II) utilizar apenas os
novos diagramas de sequência. Nos dois casos, existirá o modelo criado anteriormente
e o modelo criado com os novos requisitos. Estes modelos podem ser unificados através
da operação de conjunção se forem consistentes entre si (uma discussão a respeito deste
método é realizada na Seção 5.3).

Independentemente do modo utilizado para agregar os novos requisitos, os modelos
gerados precisam preservar o comportamento já definido. É possı́vel comparar os dois
modelos utilizando a relação de refinamento de forma a analisá-los. Para discutir a
utilização da relação de refinamento no processo de desenvolvimento, vamos considerar
um processo de desenvolvimento incremental e iterativo que esteja no enésimo (N) ciclo
de desenvolvimento. Ao final deste ciclo, teremos modelos KMTS para representar as
especificações dos componentes (modelos gerados a partir dos diagramas de sequência
ou manualmente gerados) e os modelos KMTS gerados a partir da implementação (dos
traces de execução do sistema). Para um componente c qualquer, chamaremos EN e IN
os modelos KMTS que representam a especificação e o modelo gerado a partir dos traces
para o componente c no ciclo N , respectivamente. Seja N+1 o ciclo de desenvolvimento
que foi iniciado e finalizado após o ciclo N. Para o mesmo componente c, chamaremos
EN 1 e IN 1 os modelos KTMS que representam a especificação e o modelo gerado para
o componente c no ciclo N+1.
Existem quatro possı́veis comparações entre os modelos supracitados: (1) comparação
entre a especificação e o modelo extraı́do de um mesmo ciclo; (2) comparação entre as
especificações de ciclos diferentes; (3) comparação entre os modelos extraı́dos de ciclos
diferentes; e (4) comparação entre a especificação de um ciclo e o modelo extraı́do do
outro.
Em relação à comparação de uma especificação E e o modelo extraı́do I dentro de
um mesmo ciclo, podemos ter os seguintes resultados:
1. E I: quando os modelos E e I de um mesmo ciclo são equivalentes, a imple-

mentação segue exatamente a especificação e, se a especificação satisfaz os requisitos
do cliente então a implementação também satisfará;
2. E ¨ I e I ª E: significa que I respeita o comportamento definido em E, mas

que algum comportamento indefinido em E foi definido em I, ou seja, os traces
de execução são mais ricos em detalhes que os diagramas de sequência utilizados.
Neste caso, indefinições da especificação foram removidas da mesma, isto é, ou os
requisitos (modelos) estão desatualizados (algumas indefinições foram definidas e
não estão refletidas na especificação) ou a remoção das indefinições não foi fruto do
processo de extração de requisitos, e isto pode representar que foi necessário um de-
talhamento maior para realizar a implementação e isto foi refletido nos traces. Para
identificar qual dos casos é verdade, é necessário verificar se as indefinições presen-
tes na especificação EN permanecem na especificação EN 1 (o que será detalhado
posteriormente); e
3. E ª I e I ª E: significa que as propriedades da especificação não são preservadas

na implementação.
É necessário levar em consideração que estamos utilizando o conceito de refinamento

modal forte. Acreditamos que não existe um conceito de refinamento perfeito e, a análise
de cada conceito deve ser levada em consideração pelo projetista e analisada sobre a neces-
sidade desejada. Por exemplo, suponha que não existe uma relação de refinamento modal
forte entre E e I, mas que exista uma relação de refinamento modal fraco. Isto significa
que não há preservação da estrutura ramificada entre os modelos, mas há preservação das
propriedades. Em alguns casos, isto pode ser o suficiente. Boas ferramentas de análise
de modelos devem trazer ao projetista os resultados para cada relação de refinamento
desejada.
Em relação à comparação de uma especificação EN e a especificação EN 1 entre
diferentes ciclos, podemos ter os seguintes resultados:
1. EN EN 1 : significa que não houve avanços em determinar o comportamento

do componente em questão entre os ciclos. Isto pode ser normal no processo de
desenvolvimento iterativo e incremental, se o componente em questão não foi foco
de novos requisitos no ciclo N+1;
2. EN ¨ EN 1 e EN 1 ª EN : significa que houve a determinação de indefinições

entre os ciclos N e N+1 e que os novos comportamentos definidos preservam as
propriedades e comportamentos anteriormente definidos;
3. EN 1 ¨ EN e EN ª EN 1 : significa que houve a indefinição de comportamen-

tos já definidos anteriormente. Se analisarmos este caso de acordo com a ideia de
desenvolvimento incremental e iterativo, existe um erro no processo de desenvolvi-
mento, pois a teoria define que a cada ciclo o comportamento deve ser mais definido.
Entretanto, estes casos são comuns no processo de desenvolvimento iterativo e in-
cremental na prática, e representam, possivelmente, que o cliente não aprovou o
resultado de alguma definição e, por isto, esta definição foi desconsiderada. É nor-
mal em um processo iterativo que não se tome as melhores decisões numa iteração
e que este problema seja detectado nas próximas iterações;
4. EN ª EN 1 e EN 1 ª EN : significa que não há preservação das propriedades entre

os modelos dos ciclos. Neste caso, há duas possı́veis análises: o modelo do ciclo EN
está correto e houve um erro ao criar o modelo do ciclo EN 1 ou, que houve um
erro no modelo EN e que este erro foi corrigido no modelo EN 1 .
Observe que o resultado da análise entre especificações de ciclos diferentes pode ser
aplicado à análise de modelos extraı́dos de ciclos diferentes, restando comparar a especi-
ficação de um ciclo e o modelo extraı́do do outro:
1. EN IN 1 : significa que a implementação de um ciclo N 1 é equivalente à especi-

ficação do ciclo N. O resultado desta análise depende do resultado da análise entre
EN e IN . Se EN ¨ IN isto pode representar que o ciclo N 1 houve um retrocesso
na definição do comportamento (já explicado anteriormente). Se EN ª IN isto pode
significar que no ciclo N+1 foi utilizado para corrigir a implementação. Ainda é
necessário analisar o resultado entre EN 1 e IN 1 e EN e EN 1 para poder analisar
o que houve. Observe que estas análises já foram apresentadas anteriormente;
5.2 COMPOSIÇÃO PARALELA PARA MODELOS KMTS 59
2. IN EN 1 : pode significar que não houveram avanços na definição de comporta-

mento entre os ciclos. Todavia, para chegar a este resultado é necessário observar
a relação entre EN e IN . Se EN IN podemos afirmar que não houve avanço.
Entretanto, se EN ¨ IN , significa que a definição de comportamento foi necessária
para a implementação do ciclo N e que esta informação foi adicionada no ciclo N+1;
3. EN ¨ IN 1 e IN 1 ª EN : significa que houve um avanço na definição do compor-

tamento definido entre os dois ciclos;
4. IN ¨ EN 1 e EN 1 ª IN : significa que houve um avanço na definição do compor-

5. EN 1 ¨ IN e IN ª EN 1 : como discutido acima, este fato pode representar que no

ciclo N 1 houve um retrocesso na definição do comportamento porque o compor-
tamento definido anteriormente (até o ciclo N ) estava incorreto;
6. IN 1 ¨ EN e EN ª IN 1 : significa que houve um avanço na definição do compor-

7. EN ª IN 1 e IN 1 ª EN : significa que houve um avanço na definição do compor-

8. IN ª EN 1 e EN 1 ª IN : como discutido acima, este fato pode representar que no

ciclo N 1 houve um retrocesso na definição do comportamento porque o compor-
tamento definido anteriormente (até o ciclo N ) estava incorreto;
É importante observar que a análise da relação de refinamento entre modelos de ciclos
diferentes depende do resultado da análise dos modelos dentro de um mesmo ciclo. Assim,
ferramentas para o apoio a tal análise devem oferecer suporte de forma facilitada a este
tipo de comparação.
Como explicado anteriormente, existem casos onde novos requisitos expressam pro-
priedades especı́ficas de um sistema (ou conjunto de componentes). Neste sentido, é
necessário analisar estas propriedades em relação à composição de componentes. Assim,
apesar da relação de refinamento proposta ser adequada para teorias de especificação,
ainda é necessário mostrar que é possı́vel compor o comportamento de um conjunto de
componentes executando em paralelo de forma a representar o comportamento do soft-
ware (ou componente). Esta capacidade é dada pelo operador de composição paralela
sobre modelos KMTS que será apresentado a seguir.
5.2 COMPOSIÇÃO PARALELA PARA MODELOS KMTS

Semelhante a outros trabalhos, definimos a composição (e consequentemente o operador
de composição paralela) como uma série de regras que devem ser seguidas para formar
a composição a partir de dois modelos. A ideia desta definição é criar a combinação de
todos os estados entre dois modelos (cada combinação sendo um estado da composição),
e criar as transições entre os estados da composição de forma a representar a execução
em paralelo dos dois modelos, sincronizando suas transições nas ações compartilhadas,
isto é, nas ações que eles têm em comum. Para as outras ações, o comportamento é de
interleaving.
Considerando M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ , S , s , R ,
M N N N N0

RN , LN q, a composição paralela M ||N é um KMTS definido pela tupla M ||N pAPM ||N ,
N
,L
ΣM ||N , SM ||N , sM ||N 0 , RM ||N , RM ||N M ||N q.
Como a composição paralela representa o sistema e este é composto pela união de
componentes, o conjunto de sı́mbolos proposicionais e o conjunto de ações do sistema é,
trivialmente, a união dos sı́mbolos proposicionais e as ações de cada componente. Assim,
temos que:
APM ||N APM Y APN

ΣM ||N ΣM Y ΣN
O conjunto de estados do sistema reflete o estado de cada componente, assim o con-

junto de estados da composição é o produto cartesiano dos estados dos componentes:
SM ||N SM SN
Considerando que o estado inicial do sistema é o estado inicial dos componentes, e
que sM 0 e sN 0 são os estados iniciais de M e N respectivamente, temos que:
sM ||N 0 psM 0, sN 0q
O conjunto de transições must e may devem representar o interleaving e as ações com-
partilhadas, levando em consideração a modalidade da transição. Seguindo o que foi dito
em (ANTONIK et al., 2008), um operador de composição paralela sobre especificações
parciais pode ser criado através das regras de composição paralela para modelos LTS,
considerando as modalidades nas transações. De maneira geral, estas regras definem se
uma ação é compartilhada ou não e qual a origem e o destino de cada transição. Na
adaptação do presente trabalho, as regras definem se existe uma transição e qual a moda-
lidade da transição na composição de acordo com a existência, inexistência e modalidade
da transição em M e N . Estas regras estão definidas na Figura 5.2.
Ñ
Ým
Ý pm ,n q pa R ΣN q pa R ΣN q
a a
mi mi 99Kmj
pm ,n qÑ
j
(1) (2)
i k
a
j k pmi ,nk q99K
a
pmj ,nk q
nÑÝn
Ý pm ,n q pa R ΣM q pa R ΣM q
a a
ni 99Knj
pm ,n qÑ
i j
(3) (4)
k i
a
k j pmk ,ni q99Kpmk ,nj q
a
m 99Km ^n ÑÝn Ñ
Ý m ^n 99Kn
a a a a
i j k o mi j k o
(5) (6)
pmi ,nk q99Kpmj ,no q a
pmi ,nk q99Kpmj ,no q
a
a
mi 99Kmj nk 99Kno ^ a
miÑ
Ý m ^n Ñ
a
Ýn a
pm ,n qÑ
Ý pm ,n q
j k o
(7) (8)
pmi ,nk q99K
a
pmj ,no q i k
a
j o
Figura 5.2 Regras das transições do operador de composição paralela

Como no KMTS os estados são rotulados com as proposições, os estados da com-

posição também devem ser rotulados com proposições. Considerando que as proposições
com o mesmo rótulo são informações sobre o software compartilhada pelos componentes,
a função rotuladora deve definir a valoração da proposição de acordo com o que vale
em cada modelo em separado. Nos casos onde a proposição tem uma mesma valoração,
esta será a valoração na composição. Quando as valorações são diferentes, temos dois
casos: quando uma das valorações é indefinida, neste caso o valor na composição será
a valoração definida (verdadeiro ou falso); e quando os dois modelos têm valorações de-
finidas e diferentes, isto é, uma valoração verdadeira e outra falsa, neste caso dizemos
que aquele estado tem uma valoração inconsistente (representada pelo sı́mbolo ). No
último caso, a composição terá estado(s) inconsistente(s) pois, cada componente tem uma
valoração diferente e contraditória a respeito de uma proposição do sistema. Os estados
inconsistentes na composição podem apontar erros no projeto de um ou mais estados de
um dos componentes e pode ser preciso que sejam alterados para que o software funcione
apropriadamente.
Desta maneira, podemos definir uma função rotuladora para um estado definido pelo
produto cartesiano de dois outros estados da seguinte maneira:
Definição 5.2.1 (Função Rotuladora de Composição Paralela). A função rotuladora L,
para um sı́mbolo proposicional, é definida como: L : SM ||N APM ||N Ñ tv, f, K, u sobre
um estado, tal que para todo estado ps, tq P SM ||N e p P APM ||N , no máximo um dos
resultados entre p e p ocorre, ou seja:
$v
'' se LM ps, pq e LN pt, pq são verdade ou pelo menos
'& um é verdade e o outro é indefinido
se LM ps, pq e LN pt, pq são falsos ou pelo menos
Lpps, tq, pq
f
'' um é falso e o outro é indefinido
'% K se LM ps, pq e LN pt, pq são indefinidas
, caso contrário
Nem sempre o resultado da composição entre dois modelos resulta em um modelo
consistente. Quando existem estados inconsistentes que podem ser alcançados, dizemos
que estes modelos não são composicionáveis. Caso contrário eles são composicionáveis.
Definição 5.2.2. dois modelos M e N são composicionáveis entre si quando a composição
entre eles não possui estados inconsistentes alcançáveis a partir do seu estado inicial.
Dizemos que dois modelos são composicionáveis quando a composição entre eles não
possui estados inconsistentes alcançáveis a partir do seu estado inicial. Desta maneira,
nem todos os modelos são composicionáveis e por este motivo o operador de composição
definido aqui é parcial.
Finalmente, com todos os elementos definidos, podemos definir o operador de com-
posição paralela.
,L q
Definição 5.2.3 (Composição Paralela). Sejam M pAPM , ΣM , SM , sM 0 , RM , RM M

e N pAPN , ΣN , SN , sN 0 , RN , RN , LN q dois KMTS. A Composição Paralela (||) é um
operador parcial que produz um KMTS M ||N pAPM YAPN , ΣM YΣN , SM SN , psM 0 , sN 0 q,
R , R , Lq, R eR são as menores relações que satisfazem as regras da Figura 5.2, sa-
bendo que mi , mj P SM , nk , no P SN , e a P ΣM , a P ΣN e L é uma função rotuladora de
composição paralela (Definição 5.2.1).
5.2.1 Propriedades do Operador de Composição Paralela

Como dito anteriormente, numa teoria da especificação, o operador de composição pa-
ralela deve ser associativo e comutativo. As propriedades de comutatividade e associati-
vidade do operador de composição paralela definido no presente trabalho são mostradas
pelas Proposições 5.2.1 e 5.2.2 respectivamente.
Proposição 5.2.1 (O operador de composição paralela é comutativo). Sejam M

pAPM , ΣM , SM , sM 0, RM , RM , LM q e N pAPN , ΣN , SN , sN 0, RN , RN , LN q dois KMTS
composicionáveis, então M ||N = N ||M .
Demonstração. Apresentada no Apêndice A.
Proposição 5.2.2 (O operador de composição paralela é associativo). Sejam M

pAPM , ΣM , SM , sM 0, RM , RM , LM q, N pAPN , ΣN , SN , sN 0, RN , RN , LN q e P pAPP , ΣP ,
SP , sM 0 , RP , RP , LP q três KMTS composicionáveis entre si, então pM ||N q||P M ||pN ||P q.
5.2.2 Exemplo de Operação de Composição Paralela no Desenvolvimento de Soft-

ware
Vamos ilustrar a utilização do operador de composição paralela, através de um exemplo:
é normal, nas grandes cidades do Brasil, que o perı́odo de chuva cause deslizamentos de
encostas, trazendo prejuı́zos a uma parcela da população carente. Algumas prefeituras
auxiliam as famı́lias que têm seus imóveis atingidos por estas calamidades através de uma
ajuda financeira. Todavia, antes de receber o auxı́lio, técnicos da prefeitura precisam se
deslocar até o local para verificar que, de fato, a casa foi atingida e a famı́lia precisa de
ajuda. Na maioria das cidades, esta vistoria acontece através do preenchimento manual
de formulários na residência atingida e só após a volta do fiscal à sede da prefeitura, os
formulários são redigitados e o caso é cadastrado em um sistema de ajuda. Com o caso
registrado, o recurso é liberado e a famı́lia pode receber a ajuda dada. Todo este processo
pode demorar alguns dias, o que é claramente um fator negativo.
Para agilizar o registro dos casos, uma determinada prefeitura decide utilizar dispo-
sitivos móveis (tablets) para que o fiscal preencha um formulário eletrônico na hora da
vistoria e já cadastre automaticamente o caso no sistema de ajuda. Neste cenário de
calamidade pública, dois requisitos são fundamentais para dar agilidade ao processo de
cadastro: (1) o fiscal deve receber no seu dispositivo a lista de vistorias a serem feitas de
forma que ele não precise voltar até a sede da prefeitura para receber novas atividades; e
(2) em perı́odos de chuvas e devido ao relevo das regiões com deslizamento, é normal que
não haja sinal de internet móvel no dispositivo do técnico, de forma que possivelmente o
Figura 5.3 Modelos KMTS para o software de vistoria remota, onde (A) representa o e-
Formulário e (B) o sincronizador.
software deva ser capaz de funcionar desconectado da internet (offline) e sincronizar os

casos já preenchidos quando a internet for reestabelecida (online).
Após levantamento preliminar dos requisitos do software, foi constatado que dois
componentes devem ser desenvolvidos: o e-formulario, que representa o software onde o
fiscal receberá a lista de tarefas e cadastrará vistorias e o sincronizador, que é responsável
por enviar as vistorias já cadastradas ao sistema de ajuda quando o dispositivo móvel
possuir conectividade com a internet. Modelos KMTS para cada componente foram
gerados e podem ser vistos na Figura 5.3.
Nos modelos apresentados na Figura 5.3, são especificadas as proposições pv - o fiscal
está preenchendo uma vistoria; o - há conectividade com a internet e ed - o software está
enviando dados ao sistema de ajuda. Assim como nos exemplos anteriores, a ausência de
uma proposição em um estado significa que seu valor está indefinido. Figura 5.3(A) repre-
senta o e-formulário, onde é possı́vel notar que o fiscal realizará um login pm0 , login, m1 q.
Neste momento, o software detectará a presença da conectividade com a internet e irá para
o estado m2 , se houver conectividade, ou o estado m3 , caso contrário. Havendo conectivi-
dade, a lista de tarefas é atualizada, pm2 , atualizaLista, m2 q e o fiscal já pode começar a
realizar vistorias pm3 , iniciaV istoria, m4 q. Ao finalizar a vistoria, a depender da conecti-
vidade, a lista de tarefas é atualizada pm4 , estaOnline, m2 q ou não pm4 , estaOf f line, m3 q.
A Figura 5.3(B) representa o sincronizador, onde é possı́vel notar que após o login (que
é disparado automaticamente quando o fiscal realiza o login no e-formulário), o compo-
nente chegará a um estado para detectar conectividade pn0 , login, n1 q. Se o dispositivo
tiver conectividade com a internet (pn1 , estaOnline, n2 q), o sincronizador começa a enviar
as vistorias já cadastradas. Caso contrário, pn1 , estaOf f line, n3 q, ele fica aguardando a
conexão estar disponı́vel.
O uso do operador de composição paralela sobre os modelos gera o modelo e-Formulário
|| Sincronizador, apresentado na Figura 5.4.
É possı́vel notar no exemplo da Figura 5.4, a existência de estados inconsistentes,
marcados de vermelho, e como as proposições indefinidas tiveram seus valores inferidos
ao analisar a composição paralela. Um exemplo de proposição com valor inferido é a
proposição o do estado m4 do modelo e-Formulário. Na composição paralela, o valor
desta proposição o, no estado pm4 , n2 q, tem seu valor definido e este valor pode ser usado
para inferir qual o valor que a proposição deve possuir no modelo e-Formulário.
Figura 5.4 Composição paralela dos modelos e-Formulário e Sincronizador.
5.3 CONJUNÇÃO DE MODELOS KMTS

Semelhante a outros trabalhos, definimos a conjunção (e consequentemente o operador de
conjunção) como uma série de regras que devem ser seguidas para formar a conjunção a
partir de dois modelos. Como mostrado em (FISCHBEIN; UCHITEL, 2008), o conceito
de consistência entre eles é utilizado para identificar quando há refinamento comum. A
Definição 5.3.1 apresenta a definição de consistência entre modelos KMTS.
Definição 5.3.1 (Consistência entre KMTS). Dois KMTS M e N são consistentes entre
si se existe um KMTS X tal que X é um refinamento comum de M entre N .
De maneira geral, haverá uma relação de consistência entre dois KMTS se um simula
o comportamento obrigatório do outro e vice-versa. Este comportamento obrigatório fará
parte de qualquer modelo que seja um refinamento em comum dos modelos analisados.
O comportamento possı́vel que representado nos dois modelos simultaneamente também
está presente no refinamento comum.
Definição 5.3.2 (Relação de Consistência entre KMTS). Dados M pAPM , ΣM , SM , sM 0 ,

RM , RM , L q e N pAP , Σ , S , s , R , R , L q dois KMTS. A relação de con-
M N N N N0 N
sistência é uma relação binária CM N SM SN tal que pm0 , n0 q P CM N , e para qualquer
N N
par pm, nq P <:
1. p@p P LM pmqqpLM pm, pq LN pn, pq ou LN pn, pq Kq;

5.3 CONJUNÇÃO DE MODELOS KMTS 65
2. p@p P LN pnqqpLN pn, pq LM pm, pq ou LM pm, pq Kq;

3. p@a, m1qpsepm, a, m1q P RM , então existe pn, a, n1q P RN com pm1, n1q P C q;
4. p@a, n1qpsepn, a, n1q P RN , então existe pm, a, m1q P RM com pm1, n1q P C q.
A relação apresentada na Definição 5.3.2 garante que o comportamento obrigatório
de um modelo seja simulado pelo outro e vice-versa.
Proposição 5.3.1. Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,

M N N

SN , sN 0 , RN , RN , LN q dois KMTS. M e N são consistentes entre si sse existir uma relação
de consistência CM N entre M e N .
Considerando M pAPM , ΣM , SM , sM 0, R , L q e N pAP , Σ , S , s , R ,

, RM M N N N N0
, L q, a conjunção de M e N é o KMTS M
RN
M
^ N pAPM ^N , ΣM ^N , SM ^N , spM ^N q0,
N
N
,L
RM ^N , RM ^N M ^N q.
Como a conjunção representa o refinamento entre os dois KMTS, o conjunto de
sı́mbolos proposicionais e o conjunto de ações do sistema é, trivialmente, a interseção
dos sı́mbolos proposicionais e as ações de cada componente. Assim, temos que:
APM ^N APM X APN

ΣM ^N ΣM X ΣN
O conjunto de estados da conjunção deve representar a interseção dos estados dos

modelos. Como um estado de um modelo pode estar relacionado com mais de um estado
do outro modelo, sabemos que:
S M ^N SM SN
Considerando que o estado inicial do sistema é o estado inicial dos componentes, e
que sM 0 e sN 0 são os estados iniciais de M e N , respectivamente, temos que:
spM ^N q0 pm0, n0q

Para ligar os estados, o conjunto de transições must e may devem representar in-
terseção dos comportamentos obrigatórios e a interseção dos comportamentos possı́veis.
Estas regras estão na Figura 5.5.
Observamos que as regras (4) e (5) mostradas na Figura 5.5 definem estados que
são adicionados em um conjunto . Este conjunto define o que chamamos de estados
inconsistentes e representam estados que não podem ser alcançados na conjunção porque
um dos modelos não possui uma transição especı́fica.
Estados do produto cartesiano também podem ser incluı́dos no conjunto de estados
inconsistentes se eles possuı́rem valorações contraditórias para proposições em comum.
A valoração dos estados do produto cartesiano é definida pela função rotuladora. A
função rotuladora deve refletir, nos estados, uma valoração que represente a interseção
da valoração das proposições nos estados dos modelos.
a
^ a
mi 99Kmj nk 99Kno Ñ
Ý m ^n 99Kn
mi
a a
pm ,n qÑ
Ý pm ,n q
j k o
(1) (2)
pmi ,nk q99Kpmj ,no q
a
i k
a
j o
^ Ñ
Ýn mÑÝ m ^pn ,a,n qRR
a a a
mi 99Kmj nk
pmi ,nk qÑ
Ýa pmj ,noq
o i j k o
(3) (4) pmj ,nk qP
N
pmi ,a,mj qRRM ^nk Ñ

Ýa no
(5) pmi ,no qP
Figura 5.5 Regras do transições do operador de conjunção
Definição 5.3.3 (Função Rotuladora de Conjunção). Dados M pAPM , ΣM , SM , sM 0 , RM ,

RM , L q e N pAP , Σ , S , s , R , R , L q dois KMTS, a função rotuladora L, para
M N N N N0 N
um sı́mbolo proposicional, é definida da seguinte forma: L : SM ^N APM ^N Ñ 2Lit é
N N
uma função rotuladora, se para todo estado ps, tq e p P APM ^N , no máximo, um dos
resultados entre p e p ocorre, ou seja:
$ L psq,
& M se LN ptq ¤ LM psq
Lpps, tqq :
% L p,tq, N se LM psq ¤ LN ptq
caso contrário
Diferentemente da composição paralela, estados inconsistentes na conjunção repre-
sentam partes dos modelos que não são refinamento comum e devem ser removidos para
garantir que SM ^N SM SN . Para tal remoção, definimos a função poda P , que remove
estados inconsistentes. Se um estado t P SM SN , t é inconsistente se Lptq ou se
tP .
,L q e N
Definição 5.3.4 (Função Poda). Sejam M pAPM , ΣM , SM , sM 0 , RM , RM M

pAPN , ΣN , SN , sN 0, RN , RN , LN q dois KMTS e SM SN o produto cartesiano entre seus
estados e a função rotuladora L de conjunção em função de LM e LN (Definição 5.3.3).
A função poda P : SM SN Ñ SM SN , tal que P pSM SN q SM SN {X onde
X ts—s P SM SN e s P ou Lpsq u
Assim, o conjunto de estados pode ser definido como:
P pSM SN q
SM ^N
Definição 5.3.5 (Conjunção). Sejam M pAPM , ΣM , SM , sM 0 , RM , RM ,L q e N
M
pAPN , ΣN , SN , sN 0, RN , RN , LN q dois KMTS. A conjunção (^) é um operador parcial
que produz um KMTS M ^ N pAPM X APN , ΣM X ΣN , P pSM SN q, R , R , Lq onde
R e R são as menores relações que satisfazem as regras na Figura 5.5, sabendo que
mi , mj P SM , nk , no P SN e a P ΣM e a P ΣN e que L é uma função rotuladora de
conjunção (Definição 5.3.3).
Como dito anteriormente, o operador de conjunção pode ser aplicado entre dois KMTS
que não são consistentes entre si e o resultado da conjunção não será o refinamento comum
dos KMTS. Quando aplicada sobre dois KMTS consistentes, dizemos que a conjunção é
definida. De qualquer maneira, é possı́vel analisar o resultado da conjunção para deter-
minar se dois KMTS M e N são consistentes entre si através da relação de refinamento.
As propriedades que garantem esta afirmação são exploradas a seguir.
5.3.1 Propriedades do Operador de Conjunção

Assim como o operador de composição paralela, o operador de conjunção definido também
é associativo e comutativo.
Proposição 5.3.2 (O operador de conjunção é associativo). Sejam M pAPM , ΣM ,
, L q e N pAP , Σ , S , s , R , R , L q dois KMTS consistentes
entre si, então M ^ N N ^ M .
N N

Proposição 5.3.3 (O operador de conjunção é comutativo). Sejam M pAPM , ΣM ,
, L q, N pAP , Σ , S , s , R , R , L q e P pAP , Σ , S , s , R ,
SM , sM 0 , RM , RM M N N N N0 N P P P P0
RP , LP q tres KMTS consistentes entre si, então pM ^ N q ^ P M ^ pN ^ P q.
N N P

Quando aplicado entre dois KMTS consistentes, as seguintes propriedades sobre o
KMTS resultante são verdadeiras:
1. M ^ N é definido se e somente se existe um KMTS X tal que M ¨ X e N ¨ X;

2. Se M ^ N é definido então para todo KMTS X tal que M ¨ X e N ¨ X então
X ¨ M ^ N.
Proposição 5.3.4. Sejam M pAPM , ΣM , SM , sM 0 , RM , RM , L q, e N pAP , Σ ,

M N N

SN , sN 0 , RN , RN , LN q. M ^ N é definido se e somente se existe um KMTS X tal que
M ¨ X e N ¨ X.
5.3.2 Exemplo de Operação de Conjunção no Desenvolvimento de Software

Quando um mesmo componente é expresso por vários modelos sob diferentes pontos de
vista, é possı́vel unir estes modelos em um único modelo através da operação de conjunção
definida na seção anterior. Para exemplificar este uso, voltamos ao exemplo apresentado
na Seção 5.2.2. Considere que agora, além de um caráter operacional de liberação de
recursos, as vistorias precisam de dois tipos de dados: posicionamento GPS do imóvel,
para georreferenciar as ocorrências e utilizar esta informação na predição de áreas de risco
e de fotos dos imóveis, para que técnicos na sede da prefeitura possam analisar os riscos
de desabamento dos imóveis. Suponha que a equipe de desenvolvimento do software
foi dividida em duas equipes, cada uma responsável por elaborar a solução para cada
um destes requisitos, de forma que as equipes trabalharam isoladamente a partir de um
modelo inicial do e-Formulário.
As equipes perceberam que recursos de GPS, para o georreferenciamento, e câmera
fotográfica, para as fotos, do dispositivo móvel, podem ser utilizados para atender aos
requisitos. Cada equipe desenvolveu um modelo, considerando que estes dois recursos
necessitavam de acesso exclusivo do software e por isto, podem ou não estar disponı́veis
Figura 5.6 Duas versões do componente e-Formulário para atender a requisitos de georrefe-
renciamento e fotografia
no momento de uso do aplicativo e que a precisão do GPS é melhorada com o acesso à

internet. A equipe de desenvolvimento do georreferenciamento decidiu então que o acesso
à internet é necessário no aplicativo, e que problemas de sinal devem ser contornados com
outras medidas.
A Figura 5.6 mostra os modelos gerados pelas duas equipes, sendo que o modelo (A)
representa a equipe do georreferenciamento e o modelo (B) a equipe da fotografia.
Para representar estas duas perspectivas do componente em um único componente, a
operação de conjunção definida é aplicada sobre os modelos da Figura 5.6 e o resultado
é exibido na Figura 5.7.
No modelo apresentado na Figura 5.7, os estados cinza-claro representam os estados
que foram removidos pela função poda. É possı́vel observar que os modelos são consis-
tentes entre si, todavia, na prática, existem casos onde os modelos expressam o mesmo
componente, mas não possuem comportamento em comum porque, durante um ciclo de
desenvolvimento, algumas caracterı́sticas de alguns componentes são pensadas de forma
totalmente isolada por uma questão de separação de interesse (SOMMERVILLE, 2010)
Figura 5.7 Conjunção entre os modelos exibidos na Figura 5.6
ou por se tratarem de equipes (muitas vezes geograficamente distantes) que projetam

diferentes aspectos de um mesmo componente. Esta falta de similaridade entre os mo-
delos pode impedir o uso da operação de conjunção pois, como dito anteriormente, a
conjunção se baseia em buscar a maior interseção do comportamento obrigatório (e do
comportamento possı́vel) entre os dois componentes. Se não há interseção, não haverá
conjunção.
Diante deste fato, uma operação de disjunção entre os modelos pode ser útil. Esta
operação deve unir o comportamento dos dois modelos em um único modelo, realizando a
interseção do que há em comum e adicionando as caracterı́sticas únicas que cada modelo
traz. Na semântica dada aos modelos parciais, o que não é especificado como obrigatório
nem como possı́vel é comportamento proibido. A disjunção dos modelos deve flexibilizar
este entendimento e assumir que apenas o que não é especificado simultaneamente nos dois
modelos é proibido. Uma outra possı́vel (e complementar) solução é criar a modalidade
proibido de transição. Entendemos que especificar o que é proibido além de ser exaustivo
torna o modelo difı́cil de ser analisado manualmente devido à quantidade de detalhes
(o modelo será visualmente poluı́do). Acreditamos que boas ferramentas de auxı́lio na
elaboração e análise de modelos podem contornar este problema de visualização. Todavia,
uma análise da flexibilização da semântica e desta modalidade de transição são pontos
listados para trabalhos futuros.
Capı́tulo
6
JOGO DO REFINAMENTO
Existem diferentes formas de verificar se existe uma relação de refinamento entre dois
modelos quaisquer, entre elas o jogo de refinamento é caracterizado entre dois jogadores
e verifica a existência de uma relação de refinamento entre dois modelos de acordo com
o jogador que ganha o jogo.
Neste capı́tulo analisamos o jogo de refinamento entre modelos KMTS, considerando
o refinamento modal forte. A Seção 6.1 apresenta o jogo de refinamento para modelos
KMTS de forma intuitiva e prova sua equivalência com a relação de refinamento. A
Seção 6.2 apresenta o jogo de refinamento como um grafo e até onde sabemos, esta
representação não foi realizada em nenhum outro trabalho sobre jogos de refinamentos.
A Seção 6.3 apresenta um algoritmo que verifica a relação de refinamento através do jogo
de refinamento como um grafo. Provamos a correção, terminação e complexidade deste
algoritmo. Por fim, são apresentados os resultados e as análises de uma série de validações
realizadas sobre uma implementação deste algoritmo.
6.1 DEFINIÇÃO INTUITIVA DO JOGO DE REFINAMENTO

O jogo de refinamento é um jogo baseado em turnos entre dois jogadores, que tem como
objetivo descobrir se existe uma relação de refinamento entre uma especificação M e um
modelo N . Os jogadores são o spoiler e o duplicator. O objetivo do spoiler é tentar
executar um movimento que o duplicator não pode imitar. O objetivo do duplicator é
tentar imitar todos os movimentos executados pelo spoiler.
O jogo de refinamento para os modelos M e N representa todas as possı́veis partidas
entre os dois jogadores sobre M e N, onde uma partida é uma sequência de estados do jogo.
Um estado do jogo é um par ps, tq onde s e t são os estados de M e N , respectivamente. O
estado corrente de uma partida é representado pelo estado pm, nq do jogo, o que significa
que m é o estado corrente de M e n é o estado corrente de N . Uma partida é composta
por vários turnos até que um jogador perca a partida. Em cada turno, os jogadores
modificam o estado corrente da partida, através de um movimento por uma transição
em M ou em N, que os levam para um outro estado corrente do jogo. Uma partida é
caracterizada pelas regras da Definição 6.1.1:
71
72 JOGO DO REFINAMENTO
, L q e N pAP , Σ S , s ,
Definição 6.1.1. Sejam M pAPM , ΣM , SM , sM 0 , RM , RM M N N N N0
, L q dois KMTS, uma partida do jogo de refinamento sobre M e N é definida
RN , RN N
pelas seguintes regras:
1. O estado inicial de uma partida é o par pm0 , n0 q onde m0 e n0 são os estados iniciais
de M e de N , respectivamente;
2. Se LM pm0 q ¤ LN pn0 q não for verdade então o spoiler ganha a partida;
3. Uma partida é composta por rodadas, que por sua vez é composta por dois turnos:
o turno do spoiler e o turno do duplicator, nesta ordem;
4. No seu turno, o spoiler deve escolher um dos modelos e executar um movimento,

isto é, escolher uma transição do estado corrente do modelo escolhido e modificar o
estado corrente do modelo de acordo com o estado de destino da transição escolhida.
Se o spoiler escolher o modelo M então ele deve executar o movimento representado
pela transição t pm, a, m1 q P RM . Se ele escolher o modelo N então ele deve
;
executar o movimento representado pela transição t1 pn, a, n1 q P RN
5. Depois do turno do spoiler, o estado corrente da partida é o par pm1 , nq se ele se

moveu em M ou pm, n1 q se ele se moveu em N ;
6. No seu turno, o duplicator deve executar um movimento no modelo que não foi
escolhido pelo spoiler no seu último movimento. Se ele for executar o movimento
em M então o movimento deve representar a transição t pm, a, m1 q P RM tal
que LM pm1 q ¤ LN pn1 q seja válido. Se ele executar o movimento em N então o
movimento deve representar a transição t1 pn, a, n1 q P RN tal que LM pm1 q ¤
LN pn1 q seja válido;
7. Depois do turno do duplicator, o novo estado corrente da partida é pm1 , n1 q, e a

partida continua em uma nova rodada;
8. Uma partida termina em duas situações: quando ela for infinita, isto é todos os
possı́veis movimentos no estado corrente do jogo leva o mesmo para um estado
anterior do jogo e, neste caso, o duplicator ganha o jogo; ou quando um dos jogadores
não pode se mover e, neste caso, o jogador que não consegue se mover perde o jogo,
exceto se a configuração atual for o estado inicial da partida e LM pm0 q ¦ LN pn0 q;
Para exemplificar o conceito de jogo, vamos observar o exemplo exibido na Figura 6.1.
O estado inicial do jogo é pm0 , n0 q e o spoiler começa o jogo, podendo escolher en-
tre jogar em M ou em N. Se ele escolhe jogar em M, sua única opção de movimento
é seguir pela transição com a ação “b”, pois é a única transição must. Se ele escolhe
jogar no modelo N, ele pode escolher jogar em qualquer das transições possı́veis, pois,
por definição, todas as transições são may (transições com as ações “a”, “b” e “c”). Su-
pomos que nesta partida ele jogou no modelo M, realizando o movimento representado
pela transição pm0 , b, m2 q. O estado corrente do jogo será pm2 , n0 q. No turno do dupli-
cator, ele deve executar um movimento no modelo N tal que a transição seja rotulada
6.1 DEFINIÇÃO INTUITIVA DO JOGO DE REFINAMENTO 73
Figura 6.1 Dois KMTS M, N, onde vale M ¨ N.
pela mesma ação do spoiler (ação “b”) e que a transição vá para um estado n tal que
LM pm2 q ¤ LN pnq. Deste modo, o movimento que o duplicator fará será mover-se pela
transição pn0 , b, n2 q. Observemos que LM pm2 q ¤ LN pn2 q vale, caso contrário o duplicator
não poderia jogar e perderia a partida. A nova configuração do jogo é pm2 , n2 q, uma
nova rodada se inicia e é a vez do spoiler jogar. Como não existem transições disponı́veis
(nem o estado m2 nem o estado n2 possuem transições de saı́da) o spoiler não pode jo-
gar e perde a partida. Consideremos agora a partida onde na primeira jogada, o spoiler
joga no modelo N. Supomos que o spoiler moveu-se pela transição pn0 , b, n1 q, obrigando
o duplicator a se mover por pm0 , b, m2 q, tornando o estado corrente do jogo pm2 , n1 q.
Mais uma vez, o spoiler não pode se mover e perde a partida. Consideramos agora mais
uma partida possı́vel, onde o spoiler move-se pela transição pn0 , a, n3 q. A única opção do
duplicator é se mover pela transição pm0 , a, m1 q, levando o jogo ao estado pm1 , n3 q. Na
vez do spoiler ele pode escolher entre mover-se pela transição pm1 , a, m1 q levando o jogo
para a configuração pm1 , n3 q ou mover-se pela transição pn3 , a, n2 q levando o jogo para
a configuração pm1 , a, n2 q. Para qualquer uma das duas alternativas, o duplicator terá
um movimento válido. É fácil observar que qualquer destas partidas será infinita e final-
mente podemos afirmar que o duplicator ganha em todas as partidas. Como mostraremos
posteriormente, isto implica que M ¨ N , ou seja N é um refinamento de M .
Cada escolha do spoiler pode representar uma partida diferente. Como reduzimos
nosso escopo a modelos determinı́sticos, o duplicator nunca pode escolher em qual transição
jogar, se ele puder jogar, sempre existirá uma única transição com a ação desejada. Se o
duplicator ganha em todas as possı́veis partidas do jogo de refinamento sobre os modelos
M e N, então existe uma relação de refinamento entre M e N . Caso contrário, isto é, se
o duplicator perde em pelo menos uma partida, não existe relação de refinamento entre
M e N.
É possı́vel perceber que as restrições da definição de refinamento (Definição 5.1.3) são
refletidos nas regras do jogo de refinamento (Definição 6.1.1). O Teorema 6.1.1 estabelece
uma relação entre o jogo de refinamento e a existência de uma relação de refinamento
entre dois modelos M e N, ou seja, as regras do jogo determinam as restrições para
a existência da relação de refinamento. Os movimentos, tanto do spoiler quanto do
duplicator, representam as transições nos modelos. A ideia do duplicator ter que repetir
todos os movimentos do spoiler representa as restrições sobre as transições da definição

de refinamento. Quando o spoiler joga por uma transição no modelo M, ele deve escolher
uma transição must e o duplicator deve mostrar que existe uma transição semelhante (no
sentido de refinamento) no modelo N. Em uma partida, a cada jogada, o spoiler escolherá
apenas uma transição. Todavia, o jogo representa todas as possı́veis partidas e então,
para todas as possı́veis transições que o spoiler pode escolher no estado m, o duplicator
deve achar uma transição correspondente no estado n. Esta regra representa a restrição
“Para todo pm, a, m1 q P RM , existe pn, a, n1 q P RN com pm1 , n1 q P <” da definição de
refinamento. Um raciocı́nio análogo pode ser aplicado para explicar a relação entre o
jogo e a restrição “ Para todo pn, a, n1 q P RN , existe pm, a, m1 q P R com pm1 , n1 q P <”.
Por fim, a restrição “LM pmq ¤ LN pnq” da relação de refinamento deve valer no inı́cio do
M
jogo e sempre após que o duplicator jogar. Observamos que a cada rodada, as restrições
são garantidas. Se o duplicator perde, então naquela rodada as restrições não foram
garantidas e por isto não há relação de refinamento. De forma inversa, se o spoiler perde,
é porque não há movimentos possı́veis. Como até a última rodada as restrições são
satisfeitas então para todas as transições (e estados) o duplicator imita os movimentos
do spoiler, o que representa que as restrições são satisfeitas em qualquer caso. Partidas
infinitas significam que o spoiler voltou a uma configuração onde as restrições já foram
garantidas anteriormente e que não há uma jogada diferente para ser feita.
Teorema 6.1.1 (Relação entre Refinamento e um Jogo de Refinamento). Seja M
pAPM , ΣM , SM , sM 0, RM , RM , LM q e N pAPN , ΣN SN , sN 0, RN , RN , LN q, N é um refi-
namento de M , M ¨ N , se e somente se o duplicator ganha em todas as partidas do jogo
de refinamento RGM,N pVS , VD , E q.
Demonstração.
(Ñ) Suponha, por contradição, que existe pelo menos uma partida em que o duplicator
perca. Então, dois casos podem acontecer:
(a) LM pm0 q ¤ LN pn0 q não é válido: Este caso contradiz a hipótese porque M ¨ N
(o que implica em LM pm0 q ¤ LN pn0 q); ou
(b) O duplicator não pode imitar o movimento do spoiler : seja pm, nq o estado
corrente no turno do spoiler. Neste caso, o spoiler pode se mover a partir de:
(a) uma transição t pm, a, m1 q P RM ; ou (b) uma transição t pn, a, n1 q P
RN . Em ambos os casos se chega a uma contradição. Vamos mostrar o caso
(a) (caso (b) é similar):
O spoiler move-se em pm, a, m1 q P RM e não existe transição em RN tal que o
duplicator possa imitar o movimento do spoiler. Como M ¨ N , então existe
uma relação de refinamento R entre M e N e pm, xq P R para algum x P SN
((m, x) existe porque m é alcançavel a partir de m0 no modelo M, caso contrário
(m, n) não poderia ser uma configuração do jogo (hipótese)). Pela definição
de refinamento, se pm, xq P R então para todas as transições pm, a, k q P RM
existe uma transição px, a, x1 q P RN tal que LM pk q ¤ LN pxq onde o duplicator
pode se mover, isto é, semrpe existe uma transição onde o duplicator pode
imitar o movimento do spoiler, ou seja, chegamos a uma contradição
6.2 JOGO DO REFINAMENTO COMO UM GRAFO 75
(Ð) Suponha que o duplicator ganhe em todas as partidas do jogo de refinamento

RGM,N . Seja < = tpa, bq|pa, bq é uma configuração do spoiler u. Vamos provar
que < é uma relação de refinamento entre M e N. Suponha, por contradição, que
< não é uma relação de refinamento então (a) pm0 , n0 q R <; ou (b) para algum par
pm, nq P < um (ou mais de um) dos seguintes itens valem: (i) LM pmq ¦ LN pnq; ou
(ii) existe pm, a, m1 q P RM e não existe transição pn, a, n1 q P RN com pm1 , n1 q P <; ou
e não existe transição pm, a, m1 q P R com pm1 , n1 q P <.
(iii) existe pn, a, n1 q P RN M
(a): Pela definição do jogo, pm0 , n0 q é a configuração inicial do spoiler, então

pm0, n0q P <, o que contradiz (a);
(b)(i): Pela definição do jogo, se (m, n) é uma configuração do spoiler então
LM pmq ¤ LN pnq, o que contradiz (b)(i);
(b)(ii): quando o spoiler joga a partir da configuração pm, nq, existem duas possı́veis
configurações para o duplicator : pm1 , nq ou pm, n1 q. Como o duplicator ganha em
todas as partidas, em ambos os casos o duplicator consegue imitar o movimento do
spoiler, isto é, se o spoiler muda a configuração corrente da partida para pm1 , nq
a partir de alguma transição pm, a, m1 q P RM então o duplicator irá modificar a
configuração corrente do jogo para pm1 , n1 q a partir de uma transição qualquer
pn, a, n1q P RN com LM pm1q ¤ LN pn1q (de acordo com a definição das regras do
jogo). Assim, para todas as transições t P RM que representam a modificação do
estado corrente de uma partida de pm, nq para pm1 , nq no turno do spoiler, existe
uma transição t1 P RN que representa a mudança da configuração corrente da
partida de pm1 , nq para pm1 , n1 q no turno do duplicator com LM pm1 q ¤ LN pn1 q e
pm1, n1q P < (pm1, n1q é a nova configuração do spoiler após a jogada do duplicator ),
o que contradiz o item (b)(ii).
(b)(iii): segue raciocı́nio similar a (b)(ii), tomando a configuração pm, n1 q como a
configuração após o movimento do spoiler.
Voltando para o exemplo da Figura 6.1, percebemos que o mais importante no jogo
de refinamento são as configurações do jogo e quais configurações são acessı́veis através
de outras configurações. A Figura 6.2 exibe todas as configurações do jogo do exemplo
da Figura 6.1 e como elas são alcançadas. A letra do lado da configuração indica se é a
vez do spoiler (s) ou duplicator (d) jogar e a direção das setas indica a acessibilidade de
uma configuração através de outra.
Como podemos perceber através da Figura 6.2, é possı́vel representar todas as possı́veis
configurações de um jogo através de um grafo.
6.2 JOGO DO REFINAMENTO COMO UM GRAFO
O jogo de refinamento entre dois KMTS M e N pode ser representado através de um

grafo. Os vértices do grafo representam as configurações do jogo enquanto que as arestas
representam as transições entre as configurações. A definição 6.2.1 formaliza esta ideia.
Figura 6.2 Configurações possı́veis de um jogo de refinamento entre os modelos M e N da

Figura 6.1
Definição 6.2.1 (Jogo do Refinamento). Um jogo de refinamento entre os modelos M

pAPM , ΣM , SM , sM 0, RM , RM , LM q e N pAPN , ΣN , SN , sN 0, RN , RN ,LN q é um grafo
RGM,N pVD , VS , E q onde VD é um conjunto de vértices onde o duplicator joga, VS é um
conjunto de vértices onde o spoiler joga e E pVD Y VS q pVD Y VS q é um conjunto de
arestas tal que:
VS tpm, nq | m P SM ^ n P Sn ^ LM pmq ¤ LN pnqu Y tpm0, n0qu
VD VD1 Y VD2 onde:
VD1 tpm, a, m1 , nq | m P SM ^ m1 P SM ^ n P SN ^ LM pmq ¤ LN pnq ^ m Ñ
Ýa
m1 ^ a P ΣM u
VD2 tpm, a, n1 , nq | m P SM ^ n1 P SN ^ n P SN ^ LM pmq ¤ LN pnq ^ n 99K

a
n1 ^ a P ΣN u
E E1 Y E11 Y E2 Y E21 onde:
E1 trpm, nqS , pm, a, m1 , nqD s | m Ñ Ýa m1 ^ a P ΣM u
E2 trpm, nqS , pm, a, n1 , nqD s | n 99K n1 ^ a P ΣN u
a
E11 trpm, a, m1 , nqD , pm1 , n1 qS s | m ÑÝa m1 ^ a P ΣM ^ n Ñ

Ýa n1 ^ a P ΣN ^ LM pm1q ¤
LN pn1 qu
E21 trpm, a, n1 , nqD , pm1 , n1 qS s | m 99K m1 ^ a P ΣM ^ n 99K n1 ^ a P ΣN ^

a a
LM pm1 q ¤ LN pn1 qu
Onde pi, j qS representa os vértices do spoiler e pw, a, x, k qD representa os vértices do
duplicator com i, j, w, x, k P SM Y SN e a P ΣM Y ΣN .
Figura 6.3 Jogo do refinamento entre os modelos M e N da Figura 6.1 expressos em um grafo
Considerando o jogo de refinamento RGM,N pVS , VD , E q, os movimentos do spoiler

são representados pela união dos subconjuntos E1 Y E2 tal que E1 E representa os
movimentos do spoiler no modelo M e E2 E representa os movimentos do spoiler
no modelo N. De maneira similar, os movimentos do duplicator são representados pela
união dos subconjuntos E11 Y E21 tal que E11 E representa os movimentos do duplicator
no modelo N e E21 E representa os movimentos do duplicator no modelo M. Como
E E1 Y E11 Y E2 Y E21 (Definição 6.2.1) pode-se representar o jogo RGM,N pVS , VD , E q
como RGM,N pVS , VD , E1 , E11 , E2 , E21 q.
Um caminho finito ou infinito no grafo do jogo de refinamento representa uma partida e
este caminho satisfaz as regras de partidas definidas anteriormente. Por exemplo, suponha
o jogo de refinamento mostrado na Figura 6.3, o caminho S0 D0 S1 é uma partida
finita enquanto o caminho S0 D3 S3 D4 S3 ... é uma partida infinita.
Definição 6.2.2 (Partida). Uma partida φ de um jogo de refinamento RGM,N pVS , VD , E q
é uma sequência finita ou infinita v0 v1 ...vn ... de vértices tal que pvi , vi 1 q P E e v0
pm0, n0q onde m0 e n0 são os estados iniciais de M e N , respectivamente.
A Proposição 6.2.1 mostra que todas as possı́veis partidas de um jogo de refinamento
definido na Definição 6.1.1 estão representas no grafo do jogo.
Proposição 6.2.1. Sejam M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,
M N N
,L q e RG
M,N pVS , VD , E1 , E1 , E2 , E2 q o grafo do jogo de refinamento
1 1
entre M e N. O grafo RGM,N representa todas as possı́veis partidas pi do jogo de refina-
mento da Definição 6.1.1, através de um caminho finito ou infinito φi .
Demonstração. Suponha, por contradição, que exista uma partida pi que não esteja re-
presentada no grafo, isto é, nenhum caminho φi de RGM,N representa a partida pi . Como
uma partida é uma sequência de configurações do jogo, então se pi não está representada
em nenhum caminho do grafo RGM,N existem duas possibilidades: (i) existe alguma con-
figuração que não está representada no grafo e consequentemente não está em φi ; ou (ii)
todas as configurações da partida estão representadas no jogo, mas não existe pelo menos
uma aresta que ligue duas configurações consecutivas de forma a representar a partida
pi . Consideremos então a partida pi pm0 , n0 qpmx , my q...pm, nq... finita ou infinita.
(i): Suponha que uma configuração px, y q qualquer não esteja no grafo. Se px, y q
pm0, n0q chegamos a uma contradição pois, pela Definição 6.2.1, pm0, n0q P VS .
Suponha agora que px, y q pm0 , n0 q e que px, y q seja a primeira configuração de pi
que não esteja em φi , de forma que pm0 , n0 qpmx , my q...pm, nq esteja em φi e que px, y q
é alcançável diretamente pela configuração pm, nq. Considerando que px, y q é alcançável
diretamente de pm, nq, px, y q pode ter uma das seguintes formas (a) pm1 , nq ou (b) pm, n1 q.
(a) Se px, y q pm1 , nq. Como pm1 , nq é alcançável diretamente de pm, nq então existe uma
transição t pm, a, m1 q tal que t P RM para algum a P ΣM e LM pmq ¤ LN pnq se foi
o spoiler o jogador que causou a mudança de estado ou t pm, a, m1 q tal que t P RN
para algum a P ΣN e LM pm1 q ¤ LM pnq se a mudança foi causa pelo duplicator. Se a
mudança foi causada pelo spoiler, as condições t pm, a, m1 q P RM para algum a P ΣM e
LM pmq ¤ LN pnq garantem a existência de um vértice v pm, a, m1 , nq tal que v P VD1 ,
o que representa a configuração pm1 , nq no grafo, o que nos leva a contradição. (b) Se
px, yq pm, n1q, as condições garantiriam a existência de um vértice v pm, a, n1, nq tal
que v P VD2 . Da mesma forma, se a nova configuração fosse resultado do movimento do
duplicator, a condição LM pmq ¤ LN pnq valeria, o que garantiria um vértice v P VS , e
assim chegamos a uma contradição;
(ii): Suponha ci e ci 1 , duas configurações sucessivas da partida pi representadas no grafo
pelos vértices vi e vi 1 , respectivamente, tal que não exista uma aresta entre vi e vi 1 .
Suponha que vi pm, nq então vi 1 pm1 , nq ou vi 1 pm, n1 q. Se a transição ausente
no grafo representa uma jogada do spoiler e vi 1 pm1 , nq, temos que m Ñ Ýa m1 e a P ΣM ,
o que garante a existência de uma transição pvi , vi 1 q P E1 . Se vi 1 pm, n1 q temos que
n 99K n1 e a P ΣN , o que também garante a existência de uma transição pvi , vi 1 q P E2 .
a
Assim, para estes casos chegamos a uma contradição. Um raciocı́nio análogo pode ser
feito assumindo que a mudança de configuração foi causada pelo duplicator.
A Proposição 6.2.1 mostra que todas as partidas da Definição 6.1.1 estão representadas
no grafo, mas o inverso não é verdade. O grafo representa mais configurações do que a
Definição 6.1.1 permite. Isto acontece porque a regra de formação do conjunto de vértices
(ou de arestas) do grafo não define que os elementos deste conjunto devem ser alcançados
a partir do estado inicial, ou seja, pela Definição 6.2.1 podem existir vários subgrafos
desconexos, entretanto, é possı́vel observar que apenas um subgrafo contém o estado
inicial. Desta forma, ao utilizar o grafo para representar todas as partidas de um jogo de
refinamento, é importante utilizar o subgrafo que contém o estado inicial. A partir deste
ponto, sempre que nos referirmos ao grafo do jogo de refinamento, estamos nos referindo
ao subgrafo que contém o estado inicial (a menos que seja explı́cito o contrário). Também,
a partir de agora, usaremos o termo “jogo de refinamento” de forma intercambiável com
o termo “grafo do jogo de refinamento”.
Um conjunto de propriedades relacionadas a uma partida e os tipos de arestas que co-

nectam os vértices de um jogo de refinamento podem ser deduzidas. É possı́vel identificar
o tipo de aresta que representa o movimento do duplicator em uma rodada, analisando o
tipo de aresta que representa o movimento do spoiler na mesma rodada.
Proposição 6.2.2. Seja φ v0 v1 ...vn ... uma partida do jogo RGM,N pVS , VD , E1, E11 ,
E2 , E21 q onde vi P S. Os seguintes itens são verdade:
se pvi , vi q P E1 então pvi 1, vi 2q P E11 ;
1
se pvi , vi 1 q P E2 então pvi 1 , vi 2 q P E21 .

Demonstração. Seja pvi , vi 1 q P E1 , pela Definição 6.2.1, E1 representa os movimentos
executados pelo spoiler. Quando o spoiler move-se pela aresta E1 , isto representa que
o spoiler jogou no modelo M . Também, pela mesma definição, E11 e E21 representam os
movimentos executados pelo duplicator. Quando o duplicator move-se pela aresta E11 ,
isto significa que o duplicator jogou no modelo N e quando ele se move pela aresta E21
isto significa que ele jogou no modelo M. Assim, pela Definição 6.2.1 se pvi , vi 1 q P E1
então pvi 1 , vi 2 q P E11 . A prova do Item (2) segue o mesmo raciocı́nio.
Por fim, o Teorema 6.2.1 mostra que o duplicator ganha em todas as partidas de um
jogo de refinamento se e somente se não existe nenhum vértice do duplicator sem uma
aresta de saı́da.
Teorema 6.2.1. Sejam os modelos M pAPM , ΣM , SM , sM 0 , RM , RM ,L q e N
M

pAPN , ΣN , SN , sN 0, RN , RN ,LN q e um jogo de refinamento entre M e N, RGM,N
pVS , VD , E1, E11 , E2, E21 q, M ª N se, e somente se, existe um vértice vd P VD tal que
não existe uma aresta e P E11 Y E21 e e pvd , vs q, vs P VS .
Demonstração.
Ñ Pelo Teorema 6.1.1, M ª N se o duplicator perde em alguma partida. Seja φ
a partida em que o duplicator perde. Se o duplicator perde então existe uma
configuração c em φ que o duplicator não pode se mover, isto é, a partida é finita
e termina na vez do duplicator. A partida φ e a configuração c estão representadas
no grafo (Proposição 6.2.1) e seja v o vértice que representa c no grafo. Como a
partida termina em c (v) então não existe uma aresta e P E11 Y E21 e e pv, vs q,
vs P VS .
Ð Basta observar que se existe uma configuração do duplicator que não possui ares-
tas de saı́da, isto significa que naquela configuração o duplicator não pode fazer
nenhum movimento. Como o jogo começa pelo spoiler, existe algum movimento
executado pelo spoiler que levou o jogo até esta configuração. Assim, o duplicator
não pode mover-se e não consegue imitar o movimento do spoiler perdendo a par-
tida. Pelo Teorema 6.1.1, se o duplicator perde uma partida então não há relação
de refinamento entre os modelos M e N.
Até onde sabemos, não existe nenhum algoritmo que gere o jogo de refinamento para
qualquer especificação parcial (MTS e suas variantes). A referência a este tipo de jogo na
literatura resume-se a uma lista de regras menos detalhadas que as regras apresentadas
na Definição 6.1.1 e esta caracterização em forma de jogo é utilizada apenas para provar
algumas propriedades do refinamento, como em (BENEš et al., 2009). Propomos um
algoritmo que utiliza o jogo de refinamento para analisar a existência de uma relação de
refinamento modal forte entre dois KMTS.
6.3 ALGORITMO DO JOGO DE REFINAMENTO
Verificar a não existência de refinamento entre dois KMTS através do jogo de refinamento
consiste em gerar o jogo e verificar se existe alguma partida que o duplicator perde. A
geração e verificação podem ser resumidos nos seguintes passos: (i) gerar o conjunto de
vértices do spoiler ; (ii) gerar o conjunto de vértices do duplicator ; (iii) adicionar as arestas
entre os vértices do spoiler e duplicator (e vice-versa); (iv) percorrer, a partir do estado
inicial, o grafo criado verificando se existe algum vértice do duplicator que não possui
transição de saı́da (de acordo com o Teorema 6.2.1).
O Algoritmo 5 cria o conjunto de vértices do spoiler seguindo a Definição de jogo de
refinamento 6.2.1. De forma geral, o algoritmo analisa para todos os possı́veis pares de
estados formados por um estado da especificação M e um estado do modelo N (for’s das
linhas 3 e 4) que cumprem a restrição do conjunto VS da Definição 6.2.1 (linha 5).
Algoritmo 5: geraVerticesDoSpoiler
Data: KMTS M e N
Result: VS tal que VS é o conjunto de vértices do spoiler do jogo RGM,N
1 begin
2 VS ÐÝ H
3 for m P SM do
4 for n P SN do
5 if LM pmq ¤ LN pnq then
6 VS ÐÝ VS Y tpm, nqu
O Algoritmo 6 cria o conjunto de vértices do duplicator de acordo com a Definição de

VD1 e VD2 da Definição 6.2.1. De forma geral, o algoritmo analisa para todos os possı́veis
pares de estados formados por um estado m P M e um estado n P N (for’s das linhas 3
e 4) se eles satisfazem a condição LM pmq ¤ LN pnq (linha 5). Se sim, para cada transição
must t pm, a, m1 q a P ΣM e m1 P SM um vértice do duplicator é criado pm, a, m1 , nq
(linhas 6 e 7) e para cada transição may t pn, a, n1 q a P ΣN e m1 P SN um vértice
pm, a, m1, nq do duplicator é criado (linhas 8 e 9).
O Algoritmo 7 verifica para cada par de vértice formado por um vértice do spoiler e
um vértice do duplicator (for’s das linhas 3 e 4) se é possı́vel adicionar algum tipo de
aresta entre eles (if ’s das linhas 5, 7, 9 e 11), seguindo a Definição 6.2.1.
6.3 ALGORITMO DO JOGO DE REFINAMENTO 81
Algoritmo 6: geraVerticesDoDuplicator
Data: KMTS M e N
Result: VD tal que VD é o conjunto de vértices do duplicator do jogo RGM,N
1 begin
2 VD ÐÝ H
3 for m P SM do
4 for n P SN do
5 if LM pmq ¤ LN pnq then
6 for t P RM tal que t pm, a, m1 q do
7 VD ÐÝ VD Y tpm, a, m1 , nqu
8
tal que t pn, a, n1 q do
for t P RN
9 VD ÐÝ VD Y tpm, a, n1 , nqu
Algoritmo 7: geraArestas
Data: VS e VD do jogo de refinamento RGM,N
Result: Conjunto E do jogo de refinamento RGM,N
1 begin
2 E ÐÝ H
3 for vs pms , ns q P VS do
4 for vd pmd , a, x, nd q P VD do
5 if pms , a, xq P RM then
6 E ÐÝ E Y tpvs , vd qu
7
then
if pnd , a, xq P RN
8 E ÐÝ E Y tpvs , vd qu
9 if pmd , a, xq P RM ^ x ms ^ pnd, a, nsq P RM ^ LM pxq ¤ LN pnsq
then
10 E ÐÝ E Y tpvd , vs qu
11
^xn
if pmd , a, ms q P RM ^ pnd, a, nsq P RM ^ LM pmsq ¤ LN pxq
s
then
12 E ÐÝ E Y tpvd , vs qu
Algoritmo 8: checaRefinamento
Data: KMTS M e N
Result: “SIM” se M ¨ N e “NAO” caso contrário
1 begin
2 RG ÐÝ H
3 VS ÐÝ geraV erticesDoSpoilerpM, N q
4 VD ÐÝ geraV erticesDoDuplicatorpM, N q
5 E ÐÝ geraArestaspVS , VD q
6 RG ÐÝ pVS , VD , E q
7 vi nicial ÐÝ encontraV erticeInicialpVS q
8 removeV erticesN aoAlcancaveisP artindoDepvi nicialq
9 Vwf ÐÝ encontraV erticesSemArestaDeSaidapVD q
10 if Vwf H then
11 retorne“SIM 2
12 retorne“N AO2
E por fim, o Algoritmo 8 verifica a existência da relação de refinamento entre os mo-

delos. Primeiro, o algoritmo gera os vértices do spoiler, duplicator e as arestas entres
eles (respectivamente, nas linhas 3, 4 e 5), definindo o jogo (linha 6) e seu estado ini-
cial a partir do vértice do spoiler que contém os vértices iniciais dos modelos (linha 7).
Como dito anteriormente, podem existir subgrafos desconexos. A função removeVerti-
cesNaoAlcancaveisPartindoDe (linha 8) percorre o grafo de forma similar a uma busca
em largura, anotando os vértices alcançados a partir do estado inicial. Em seguida, os
vértices não alcançados são removidos da lista de vértices do jogo. A função encontra-
VerticesSemArestaDeSaida (linha 9) itera sobre a lista de vértices, buscando vértices do
spoiler que não possuem transições de saı́da, e as retorna em um conjunto que é o con-
junto de testemunhas de falha. Se o conjunto de testemunhas de falha está vazio então
há uma relação de refinamento entre os modelos (linha 10 e 11) e, caso contrário, não há
relação de refinamento entre os modelos (linha 12).
6.3.1 Análise do Algoritmo do Jogo de Refinamento

O Algoritmo 8 sempre termina (mostrado na Proposição 6.3.1), ele sempre retorna o
resultado correto, isto é, retorna “SIM” se existe uma relação de refinamento entre os
modelos e “NAO” se esta relação não existir (mostrado na Proposição 6.3.2) e possui
uma complexidade polinomial em relação ao tamanho dos modelos, isto é, em relação à
quantidade de estados, transições e proposições (mostrado na Proposição 6.3.3).
Proposição 6.3.1. O Algoritmo 8 sempre termina.
Demonstração. Todos os laços de repetição do algoritmo iteram sobre elementos de con-

juntos finitos (conjunto de estados, de transições, de vértices e de arestas) e a condição
de terminação de cada laço consiste em iterar sobre todos os elementos de cada destes
conjuntos. Como nenhum laço é reiniciado e todos os conjuntos são finitos, podemos
concluir que o algoritmo sempre termina.
Proposição 6.3.2. O Algoritmo 8 sempre retorna “SIM” se M ¨ N e “NAO” se M ª N .

Demonstração. O algoritmo retorna “SIM” se o jogo de refinamento gerado não possuir
nenhum vértice do duplicator sem arestas de saı́da e “NAO” se o jogo possuir algum
vértice com esta caracterı́stica (linhas 10-12) do Algoritmo. De acordo com o Teorema
6.2.1 esta condição é suficiente para garantir a existência ou não da relação de refinamento
entre os modelos.
Proposição 6.3.3. O Algoritmo 8 possui complexidade polinomial.
Demonstração. Para mostrar que o Algoritmo 8 possui complexidade polinomial, mos-

tramos que cada trecho do algoritmo é polinomial em relação ao tamanho dos mode-
los de entrada. Para tal, vamos assumir como entrada os modelos M pAPM , ΣM ,
, L q e N pAP , Σ , S , s , R , R ,L q.
SM , sM 0 , RM , RM M N N N N0 N N N
1. Calcular LM pmq ¤ LN pnq é polinomial: a função para calcular se LM pmq ¤ LN pnq

consiste em iterar sobre cada literal de n, comparando com a valoração dos literais
de m. Consideremos que no pior caso, os estados n e m possuem todos os literais
definidos. Desta forma, o algoritmo para computar esta função deve iterar, para
cada literal de n, sobre os literais de m para verificar se n é refinamento de literal
de m. Desta forma, têm-se duas iterações aninhadas que percorrem, no pior caso,
sobre dois conjuntos de tamanho |APM | e |APN |, o que nos permite concluir que
esta função será Op|APM | |APN |q;
2. Calcular se um estado é acessı́vel a partir de outro estado por uma ação é polino-
mial: no algoritmo, existem condições em que verifica-se um estado qualquer x1 é
alcançado por uma transição com ação a a partir de um estado x (o que equivale a
verificar se a transição t px, a, x1 q pertence a algum conjunto R (ou R ). Para
fazer tal verificação, deve-se verificar se existe uma transição de saı́da rotulada com
a ação a no estado x e se o estado de chegada é igual a x1 . Considerando que as
transições dos modelos são armazenadas numa lista, verificar se px, a, x1 q P R (ou
R ) consiste em iterar sobre esta lista, comparando os estados de origem, a ação e
o estado de destino. Assim, a complexidade desta função é Op|R | |R |q;
3. O Algoritmo 5 é polinomial: este algoritmo resume-se em iterar em todos os estados

n P SN para cada estado m P SM , verificando se LM pmq ¤ LN pnq, ou seja, esta
função é Op|SM | |SN | |APM | |APN |q;
4. O Algoritmo 6 é polinomial: este algoritmo resume-se em iterar em todos os estados

n P SN para cada estado m P SM , verificando se LM pmq ¤ LN pnq. Se a condição
for verdade, o algoritmo itera sobre todas as transições must de saı́da do estado
m e todas as transições may do estado n, ou seja, esta função é Op|SM | |SN |
|APN | p|RM | |RN |qq;
5. O Algoritmo 7 é polinomial: este algoritmo itera em todos os vértices do dupli-

cator para cada vértice do spoiler, verificando quatro condições (quatro ifs). As
condições são compostas por comparações diretas (Op1q), verificação de acessibi-
lidade p|APM | |APN |q e verificação da função LM pmq ¤ LN pnq (|R | |R |).
Assim, podemos concluir que esta função é Op|VS | |VD | p4 p|APM | |APN |
|R | |R|qqq; e
6. Percorrer todos os estados de um grafo dirigido é polinomial: percorrer todos os
estados de um grafo dirigido utilizando busca em largura possui complexidade po-
linomial Op|V | |E |q, sendo |V | a quantidade de vértices e |E | a quantidade de
arestas. A função encontraVerticeInicial utiliza este método para encontrar o es-
tado inicial do jogo e portanto encontraVerticeInicial tem complexidade polinomial
Op|VS | |VD | |E |q. Já a função removeVerticesNaoAlcancaveisPartindoDe utiliza
a busca em largura para marcar os estados alcancáveis a partir do estado inicial e
depois percorre a lista de vértices, removendo os vértices que não foram marcados,
possuindo então complexidade Op|VS | |VD | |E | |VS | |VD |q. Por fim, a função
encontraVerticesSemArestaDeSaida itera em todos os vértices VD , verificando quais
vértices não possuem aresta de saı́da e retornando-os como um conjunto, de forma
que sua complexidade é Op|VD |q.
As complexidades acima são dadas em função do conjunto de vértices e arestas do jogo e

estas variáveis podem ser escritas em função das estruturas dos modelos, observando que
no pior caso |VS |, |VD | e |E | terão o maior tamanho possı́vel, isto é, |VS | |SM | |SN |
(todas as combinações de estados são vértices do spoiler, e |VD | p|SM |q2 |SN | |SM |
p|SN |q2 (todas as combinações de estados podem ser vértice do duplicator e |E | será
máximo quando |E | 2 |SM ||SN |pp|SM |q2 |SN | |SM |p|SN |q2 q (existem arestas
entre todos os estados).
Como todas as partes do Algoritmo 8 são polinomiais e não existe iteração entre elas,
podemos concluir que a complexidade do Algoritmo 8 é polinomial.
Uma consequência direta da Proposição 6.3.3 é que analisar o problema do refinamento

modal forte para modelos KMTS através do jogo de refinamento pertence à classe de
problemas P.
6.3.2 Validação do Algoritmo do Jogo de Refinamento

Para validar o algoritmo do jogo de refinamento, ele foi implementado e está disponı́vel em
(MACHADO, 2016). O algoritmo foi testado em um computador com a seguinte confi-
guração: processador Intel(R) Core (TM) i7-5500U CPU @2.40GHz 2.40 GHz, memória
ram 8 GB e sistema operacional Windows 10 64 bits. A validação da implementação
deste algoritmo foi dividida em duas etapas: (i) validação da correção do algoritmo; e (ii)
validação da performance em relação ao tempo de execução.
A validação da correção do algoritmo foi realizada em duas partes: (a) 20 testes
especı́ficos com exemplos encontrados na literatura (e modificados para suas versões em
KMTS e analisados manualmente); (b) 10000 (dez mil) testes gerados automaticamente.
Cada teste consiste em dois modelos: a especificação M e o modelo N. Em metade dos

testes especı́ficos, os modelos foram modificados para serem refinamentos e na outra
metade os modelos foram modificados para não serem refinamentos. O mesmo raciocı́nio
foi realizado nos testes gerados automaticamente: um algoritmo gera uma especificação
aleatória M, cria N a partir de uma cópia de M e modifica N através da remoção ou
conversão de transições may em must e da alteração das proposições indefinidas em
verdadeiro ou falso. Realizando apenas estas modificações, N sempre será refinamento de
M. De forma inversa, alterando o comportamento obrigatório para gerar N, temos que
N nunca será um refinamento de M. As saı́das, tanto dos testes especı́ficos quanto a dos
testes automáticos foram analisadas. Em caso de uma saı́da diferente do esperado, o teste
e/ou o algoritmo era inspecionado e corrigido (se necessário).
Para a validação da performance, foram gerados quatro grupos de teste considerando
as seguintes variáveis: quantidade de estados; quantidade de transições de saı́da por
estado (grau); quantidade de proposições; e proporção, que incrementa todas variáveis de
forma proporcional. Os grupos criados foram: Grupo-estado, Grupo-transicao, Grupo-
proposicao e Grupo-proporcao. Cada grupo é composto por blocos. Cada bloco de um
grupo é criado com o mesmo valor para todas as variáveis, com exceção da variável a ser
analisada, que tem seu valor incrementado em cada bloco. Claramente, o grupo Grupo-
proporcao não segue este padrão e tem todas as suas variáveis incrementadas em cada
bloco de forma proporcional.
Cada bloco é composto por 10 testes e cada teste é composto por dois KMTS M e
N. Em 5 testes não há relação de refinamento entre M e N e em 5 testes há relação de
refinamento entre M e N. O resultado de um bloco é o tempo médio (em milissegundos)
para executar o algoritmo sobre cada um dos 10 testes do bloco.
Para criar estes casos, os KMTS foram gerados aleatoriamente de forma a garantir
a relação de refinamento (através da remoção ou da transformação das transições may
em must e alteração das variáveis indefinidas em variáveis definidas). Para gerar os
casos onde não há relação de refinamento, as alterações ocorreram no sentido inverso
(do comportamento definido para o comportamento indefinido). Estas alterações foram
feitas baseadas em duas variáveis: quantidade de mudanças nas proposições e quantidade
de mudanças nas transições. Uma mudança em uma proposição representa alteração de
seu valor de forma aleatória (respeitando o objetivo do teste) e uma mudança em uma
transição representa uma alteração aleatória que pode remover, alterar a modalidade ou
alterar a ação na transição (respeitando o objetivo do teste).
A Figura 6.4 representa a divisão de um grupo qualquer em blocos e em seus testes.
Casos positivos representam a existência da relação de refinamento no teste e casos ne-
gativos representam o contrário. O incremento em cada bloco é justificado no resultado
de cada teste.
As variáveis foram definidas para cada grupo são exibidas na Tabela 6.1. Quando
uma célula desta tabela contém mais de um valor, significa que cada bloco do teste tem
um valor contido na célula. As variáveis do Grupo-proporcao são incrementadas em
conjunto seguindo a ordem definida na tabela. As variáveis que são fixas em um grupo
foram escolhidas buscando-se um valor médio extraı́do dos exemplos encontrados nos
diversos trabalhos pesquisados. Por fim, variáveis que indicam mudanças em transições
Figura 6.4 Estrutura dos testes realizados por grupo
Grupo
Variável
crescimento
estado transições proposições
proporcional
25, 50, 75, 100, 25, 50, 75, 100,
Nº de estados 100 100
125, 150, 175, 200 125, 150, 175, 200
5, 10, 15, 20, 5, 10, 15, 20,
Nº de transições 10 10
25, 30, 35, 40 25, 30, 35, 40
5, 10, 15, 20, 5, 10, 15, 20,
Nº de proposições 10 10
25, 30, 35, 40 25, 30, 35, 40
Nº modificações 4*, 7, 10, 14, 4*, 7, 10, 14,
3 3
em transições 17, 20, 24, 27 17, 20, 24, 27
Nº modificações 4*, 7, 10, 14, 4*, 7, 10, 14,
3 3
em proposições 17, 20, 24, 27 17, 20, 24, 27
Tabela 6.1 Variáveis de acordo com o grupo de teste
ou proposições foram incrementadas sempre seguindo o valor de 2/3 (arredondado para

cima) da sua variável referente. Para os grupos Grupo-transicao e Grupo-proposicao os
mesmos testes foram realizados com o número de mudanças fixas (representado pelo * na
tabela). O objetivo destes testes duplicados é analisar se o número de mudanças implica
de alguma forma na performance do algoritmo. A quantidade de estados e transições
nos testes foram definidos de forma semelhante aos testes realizados pelas ferramentas
MoTrAs (KRETINSK, 2013) e a MTSA (D’IPPOLITO et al., 2008b)
O resultado da execução dos testes dos Grupo-estado, Grupo-transicao, Grupo-proposicao
e Grupo-proporcao são exibidos nas Tabela 7.2 e no gráfico da Figura 6.5, na Tabela 6.3
e no gráfico da Figura 6.6, na Tabela 6.4 e no gráfico da Figura 6.7 e na Tabela 6.5 e no
gráfico da Figura 6.8, respectivamente.
Por fim, o Gráfico 6.9 apresenta um cruzamento dos dados do Grupo-estado e Grupo-
proporcao. Este cruzamento foi realizado porque ambos os grupos demonstraram que
Quantidade de estados
25 50 75 100 125 150 175 200
Tempo médio 10 11,7 11,3 24 43,3 59,5 77,8 121,3
Desvio Padrão 8,59 4,57 1,95 8,42 10,65 15,23 12,64 32,27
Tabela 6.2 Tempo médio de execução (milissegundos) do algoritmo do jogo de refinamento de
acordo com a quantidade de estados
Figura 6.5 Gráfico do tempo médio de execução (milissegundos) do algoritmo do jogo de

refinamento de acordo com a quantidade de estados
Quantidade de transições por estado

5 10 15 20 25 30 35 40
Tempo médio
25,54 21,27 30,91 39 69 78,18 107 90,09
(Nº fixo de mudanças)
Desvio Padrão
31,1 6,55 6,62 8,94 26,89 25,4 30,65 24,27
Tempo médio
31,4 20,6 27,2 37 64,8 62,7 81,5 89,5
(Nº variável de mudanças)
Desvio Padrão
28,95 2,15 3,64 3,65 27,29 10,9 8,72 9,96
acordo com a quantidade de transições por estado

refinamento de acordo com a quantidade de transições por estado
Quantidade de proposições por estado

5 10 15 20 25 30 35 40
Tempo médio
385,54 17,91 13,73 14,18 16,1 16,91 26,73 20,91
Desvio Padrão
175,56 2,87 0,82 2,2 3,19 4,56 11,46 8,41
Tempo médio
399,8 18,9 12,2 13 12,1 11,9 12,2 14,1
Desvio Padrão
108,611 3,44 0,44 3,7 0,71 0,6 0,71 1,79
acordo com a quantidade de proposições por estado

refinamento de acordo com a quantidade de proposições por estado
Quantidade de estados (crescimento proporcional)

25 50 75 100 125 150 175 200
Tempo médio
10,5 11,6 17,2 29,8 64,5 114,6 168,2 282
Desvio Padrão
) 9,72 2,72 7,88 1,81 12,57 10,39 5,39 24,23
Tempo médio
12,3 14,2 11,6 24,3 54 92,2 148,1 230,5
Desvio Padrão
16,6 16,08 0,52 1,57 5,68 10,87 11,78 25,7
acordo com o crescimento proporcional do modelo

refinamento de acordo com o crescimento proporcional do modelo
Figura 6.9 Gráfico do cruzamento dos dados do Grupo-estado e Grupo-proporcao
possuem um peso maior na influência do tempo médio de execução.

A análise das tabelas, dos grupos e os fatos observados durante os testes nos permitem
concluir:
1. A quantidade de estados tem um peso maior no tempo médio de execução do

algoritmo. Este resultado já era esperado porque a quantidade de estados tem um
peso maior na expressão que define a complexidade aproximada do algoritmo (os
expoentes das variáveis que representam a quantidade de estados são maiores que
os demais). Outro fato que impacta neste resultado é que ao se adicionar mais
estados, consequentemente adiciona-se mais transições e proposições aos modelos;
2. A quantidade de transições tem forte influência no tempo médio de execução do

algoritmo, sendo apenas menos impactante que a quantidade de estados;
3. A quantidade de proposições tem uma fraca influência no tempo médio de execução

do algoritmo;
4. Testes com uma quantidade de mudança fixa têm um tempo médio de execução
maior que os testes com uma quantidade de mudança variável. Isto acontece porque
ao fixar a quantidade de mudanças, a especificação e o modelo são mais similares (é
válido lembrar que o modelo é uma cópia da especificação com algumas mudanças).
Quando os modelos são mais similares, a probabilidade de um par de estados sa-
tisfazerem as condições para virarem um vértice do jogo é maior e por isto, testes
com número de mudanças fixas têm jogos com mais estados que testes com número
de mudanças variáveis;
5. Os testes dos blocos iniciais tiveram desvios-padrão mais elevados que os testes
dos outros blocos. Isto ocorre porque nos blocos iniciais, os valores de tempo de
execução de cada teste são muito baixos (próximos a 0). Qualquer teste que tenha
um valor mais elevado entre os 10 testes distorce o valor da média e do desvio-
padrão. Isto significa que mesmo uniformizando as variáveis, existem casos, dentro
de um mesmo bloco, que exigem um maior tempo de execução. Acreditamos que
este fato seja decorrente da estrutura ramificada das entradas. Estes valores pode-
riam ter sido removidos da amostra de testes para desfazer estas distorções, todavia,
decidimos mantê-los por uma questão de transparência.
Por fim, gostarı́amos de ter realizado um comparativo com as principais ferramentas

que implementaram algoritmos de verificação de refinamento modal forte para modelos
parciais, a MoTrAs e a MTSA. Todavia, não encontramos as entradas testadas necessárias
nos benchmarking destas ferramentas. De acordo com os resultados exibidos em (BENES
et al., 2011), e a descrição dos testes realizados nas duas ferramentas, o algoritmo do
jogo de refinamento possui um desempenho similar ou superior aos algoritmos utilizados
nestas ferramentas. Este resultado é interessante porque a ferramenta MoTrAs utiliza
um verificador baseado na redução dos modelos para uma fórmula QBF, e hoje, até onde
sabemos, é a maneira mais eficaz de verificar se existe uma relação de refinamento entre
os modelos. Entretanto, precisamos de mais dados referentes aos testes executados para
realizar um comparativo e poder afirmar que o algoritmo apresentado aqui apresenta
uma performance igual ou superior à performance das ferramentas supracitadas no que
diz respeito à análise de refinamento modal forte.
De qualquer maneira, mesmo que o desempenho do algoritmo do jogo de refinamento
seja pior que o desempenho dos outros algoritmos, sua utilização é justificada porque o
jogo de refinamento nos fornece uma série de informações a respeito da relação de refina-
mento existente (ou de sua não existência). Como mostrado no próximo capı́tulo, estas
informações serão utilizadas para ajudar a resolver o problema do reparo de refinamento.
Capı́tulo
7
REPARO DE REFINAMENTO
No desenvolvimento incremental e iterativo, novos requisitos podem produzir modelos

que devem preservar as propriedades definidas em relação aos modelos já existentes. O
conceito de refinamento pode ser utilizado para garantir a preservação de propriedades já
definidas entre os modelos parciais, como feito, por exemplo em (UCHITEL; KRAMER;
MAGEE, 2003b). A maior parte dos estudos define e caracteriza o refinamento entre
estruturas modais e utiliza técnicas, já apresentadas anteriormente, para analisar quando
existe uma relação de refinamento entre dois modelos. Todavia, estes trabalhos não
analisam o que deve ser feito nos modelos quando não há uma relação de refinamento.
Nestes casos, os novos modelos devem ser alterados para garantir a preservação das
propriedades já definidas. Chamamos esta atividade de reparo de refinamento.
Neste capı́tulo analisamos o problema de reparo de refinamento entre modelos KMTS,
considerando o refinamento modal forte. A Seção 7.1 realizamos uma análise do problema
de refinamento, define as condições mı́nimas para que um modelo N sejam reparado para
ser refinamento de uma especificação M. Esta seção também apresenta um algoritmo que
resolve o problema do reparo de refinamento. A Seção 7.2 apresenta como encontrar
as causas da não existência da relação de refinamento utilizando o jogo de refinamento
e como é possı́vel corrigir estas causas. Em seguida, apresentamos um algoritmo que
resolve o problema do reparo de refinamento utilizando o jogo de refinamento e realiza
uma análise da correção, terminação, complexidade e validação deste algoritmo.
7.1 O PROBLEMA DO REPARO DE REFINAMENTO
Quando um modelo N é utilizado para representar uma especificação M em um nı́vel

maior de detalhes, o modelo N deve ser um refinamento da especificação M, isto é, o
modelo N deve satisfazer todas as propriedades satisfeitas por M. Quando N não é um
refinamento de M, isto significa que N não satisfaz algumas das (ou todas as) propriedades
que M satisfaz e, então, N deve ser alterado para que ele satisfaça todas as propriedades
que o modelo M satisfaz, isto é, N deve ser alterado gerando um modelo N’ tal que N’
93
94 REPARO DE REFINAMENTO
seja um refinamento de M. Encontrar as alterações que devem ser realizadas no modelo

N é o objetivo do problema do reparo de refinamento.
Para estudar este problema de forma sistemática, é preciso definir o que é uma al-
teração em um KMTS. As alterações no modelo se dão de forma estrutural, de forma
similar ao realizado em (GUERRA; ANDRADE; WASSERMANN, 2013a).
7.1.1 Representando Mudanças em Modelos KMTS

Mudanças estruturais sobre KMTS podem ser produzidas por uma série de mudanças pri-
mitivas como remover uma transição, adicionar um estado ou modificar o valor associado
a um literal em um estado.
Definição 7.1.1 (Mudança Primitiva). Uma mudança primitiva x é uma operação es-
trutural sobre um KMTS M pAP, Σ, S, s0 , R , R , Lq definida como:
RT (s, a, s1 ): remove (s, a, s1 ) de R e de R (se ps, a, s1 q P R );
RT (s, a, s1 ): remove (s, a, s1 ) de R ;
AT ps, a, s1 q: adiciona a transição ps, a, s1 q em R ;
AT ps, a, s1 q: adiciona a transição ps, a, s1 q de R em R ;
ALps, lq: associa um literal l para o estado s de um modelo se l R Lpsq;
RLps, lq: remove um literal l em um estado s de um modelo se l P Lpsq;
CLps, l, v q: muda a valoração de um literal l para v em um estado s, onde v P tV, F u;
CTps, a{b, s1 q: transforma a transição ps, a, s1 q em ps, b, s1 q;
ASpsq: adiciona o estado s em S.
A aplicação de uma mudança primitiva x sobre um modelo M é representada por
xpM q e a aplicação de um conjunto de mudanças primitivas X sobre um modelo M é
representada por X pM q. Em ambos os casos, um KMTS M 1 , que representa o modelo
M modificado, é o resultado desta aplicação. Por exemplo, considere a adição de uma
transição must ps, a, s1 q em um KMTS M . Esta adição é representada pelo conjunto
X que é composto de duas mudanças primitivas: uma do tipo AT para adicionar a
transição em M ; e outra do tipo AT para transformar a transição may em uma transição
must. É importante executar AT antes de AT , todavia a notação X pM q abstrai a
ordem de execução das mudanças primitivas (numa implementação deve-se pensar em
uma sequência ordenada de mudanças e não em um conjunto).
Dadas duas mudanças primitivas p0 e p1 dizemos que p0 e p1 são consistentes entre
si se uma não desfaz de alguma forma a modificação realizada pela outra. Por exemplo
p0 RT ps, a, s1 q e p1 RT ps, a, s1 q não são consistentes entre si porque p1 remove
a transição ps, a, s1 q adicionada por p0 . Como será mostrado posteriormente, o conceito
de consistência entre mudanças primitivas é importante para evitar que o algoritmo de
reparo entre em loop infinito.
7.1 O PROBLEMA DO REPARO DE REFINAMENTO 95
Definição 7.1.2 (Consistência entre mudanças primitivas). Seja o KMTS M pAPM , ΣM ,

, L q e duas mudanças primitivas p e p1 . Dizemos que p e p1 são consis-
SM , sM 0 , RM , RM M
tentes se, e somente se elas não assumirem simultaneamente os seguintes valores:
1. p = RT (s, a, s1 ) e p’ = AT ps, a, s1 q;
2. p = RT (s, a, s1 ) e p’ = AT ps, a, s1 q;
3. p = AT ps, a, s1 q e p’ = RT (s, a, s1 ) ou p’ = CTps, a{b, s1 q;
4. p = AT ps, a, s1 q e p’ = RT (s, a, s1 ) ou p’ = CTps, a{b, s1 q;
5. p = ALps, lq e p’ = RLps, lq;
6. p = RLps, lq e p’ = ALps, lq;
7. p = CLps, l, v q e p’ = CLps, l, v 1 q tal que v v1;

8. p = CTps, a{b, s1 q e p’ = RT (s, b, s1 ) ou p’ = RT (s, b, s1 ).
Ao analisar as mudanças consistentes sobre um modelo KMTS qualquer, verifica-

mos que existe um número finito de mudanças consistentes que podem ser aplicadas
sobre um modelo (como mostrado na Proposição 7.1.3). As Proposições 7.1.1 e 7.1.2
mostram, respectivamente, que a quantidade de mudanças primitivas consistentes que
podem ser aplicadas em um estado qualquer em relação aos literais do modelo e em
relação às transições é finita. Como resultado destes fatos, concluı́mos que a quantidade
de mudanças primitivas consistentes que podem ser aplicadas sobre um KMTS qualquer
é finita se considerarmos que um número finito de estados pode ser adicionado ao modelo.
, L q e n P S . O
Proposição 7.1.1. Seja um KMTS N pAPN , ΣN , SN , sN 0 , RN , RN N N
número de mudanças primitivas consistentes entre si que podem ser aplicadas em n em
relação aos literais de N é finito.
Demonstração. Seja um literal l P APN . Se l P LN pnq então apenas uma mudança pode
ser realizada sobre l: mudar sua valoração (CLpn, l, v q) ou removê-lo pRLpn, lqq. Caso
contrário, duas mudanças podem ser realizadas: adicionar l (ALpn, lq) e atribuir um valor
para l (CLpn, l, v q). Pela Definição 7.1.2, qualquer outra mudança que envolva l e n, em
qualquer um dos casos, será inconsistente. Assim, o número máximo de mudanças que
podem ser realizadas em um estado n em relação aos literais é 2 |APN |, caso em que
nenhum literal está definido em n.
, L q e n P S . O
Proposição 7.1.2. Seja um KMTS N pAPN , ΣN , SN , sN 0 , RN , RN N N
número de mudanças primitivas consistentes entre si que podem ser aplicadas em n em
relação às suas transições de saı́da é finito.
Demonstração. Seja um estado n P SN . Como N é determinı́stico, n só pode ter, no

máximo, |ΣN | transições de saı́da. Se uma transição t com a ação a já existe nas transições
de saı́da de n, no máximo duas mudanças podem ser aplicadas sobre t: mudar sua ação
(CLpn, a{b, n1 q) e mudar sua modalidade). Existem outras combinações de mudanças

que podem ser aplicadas, mas todas também têm tamanho 2 (dois). O pior caso ocorre
quando n não possua nenhuma transição de saı́da e para cada a P ΣN duas ações podem
ser realizadas: adicionar a transição AT pn, a, n1 q e AT pn, a, n1 q para transformar a
transição em must. Neste caso, o número máximo de mudanças consistentes sobre as
transições de saı́da de um estado qualquer é dado por 2 |ΣN |.
, L q. O número
Proposição 7.1.3. Seja um modelo N pAPN , ΣN , SN , sN 0 , RN , RN N
de mudanças primitivas consistentes entre si que podem ser aplicadas sobre N é finito se
um número limitado T de estados for adicionado.
Demonstração. O número máximo de mudanças primitivas que podem ser aplicadas em

N é o somatório do número máximo de mudanças primitivas que podem ser aplicadas
sobre os literais e sobre as transições de cada estado. Considerando que T estados foram
adicionados a SN (SApsq), temos que o modelo N tem SN T estados e a expressão que
representa esta soma é (obtida pela soma das expressões das Proposições 7.1.1 e 7.1.2):
2 p|SN | T q p|APN | |ΣN |q T
Pela Proposição 7.1.2 a quantidade de mudanças primitivas consistentes que podem

ser aplicadas sobre N para que ele seja um refinamento de M é finita.
7.1.2 Análise do Problema do Reparo de Refinamento

Podemos definir o problema do reparo de refinamento em relação às mudanças primitivas
como: dados dois modelos KMTS M e N tal que M ª N , identificar os conjuntos de
mudanças primitivas X tal que M ¨ X pN q.
Como o problema do reparo visa modificar um modelo N para obter uma relação de
refinamento entre N e uma especificação M, vamos analisar o uso de mudanças primitivas
para satisfazer as condições necessárias da relação de refinamento entre os dois modelos
(ver itens da Definição 5.1.3).
As Proposições 7.1.4 e 7.1.5 mostram condições que sempre podem ser satisfeitas
através de mudanças primitivas.
Dados dois modelos M e N, a Proposição 7.1.4 mostra que quaisquer que sejam dois
estados n P SN e m P SM , é possı́vel modificar n com um conjunto de mudanças X tal
que LM pmq ¤ LN pX pnqq.
Proposição 7.1.4. Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP ,Σ ,

M N N
, L q, m P S , n P S tal que L pmq ¦ L pnq. Existe um conjunto de
SN , sN 0 , RN , RN N M N M N
mudanças primitivas X aplicável sobre n tal que LM pmq ¤ LN pX pnqq.
Demonstração. Pela Definição 6.2.1, LM pmq ¤ LN pnq é verdade se e somente se para

todo p P LM pmq e p P LN pnq as valorações de p em m e em n têm o mesmo valor. É
possı́vel aplicar a mudança primitiva do tipo AL para adicionar todos os literais p tal
que p P LM pmq e p R LN pnq. Depois de aplicar estas mudanças, o estado n terá todos os
literais que o estado m possui (e talvez mais literais). Após este passo, é possı́vel aplicar
mudanças primitivas do tipo CL para fazer a valoração de todos os literais de n iguais à
valoração dos literais de m.
Definimos a função XRL pm, nq como a função que retorna o conjunto mı́nimo de
mudanças primitivas X para que LM pmq ¤ LN pX pnqq (esta função existe como resultado
da Proposição 7.1.4).
A Proposição 7.1.5 mostra que sempre é possı́vel adicionar uma transição entre dois
estados quaisquer de um modelo, preservando o determinismo do modelo.
Proposição 7.1.5. Dados M pAP, Σ, S, s0 , R , R , Lq, m e m1 P S tal que pm, a, m1 q R

R (ou R R ). Existe um conjunto de mudanças primitivas X tal que X pM q M 1
pAP, Σ1, S, s0, R1 , R1, Lq e pm, a, m1q P R1 (ou pm, a, m1q P R1 ) e M 1 é determinı́stico.
Demonstração. A aplicação de mudanças primitivas do tipo AT e AT adicionam pm, a, m1 q
em R (ou R ). Se existir em M uma transição pm, a, m2 q P R1 e m1 m2 , é necessário
remover esta transição ou alterar seu rótulo para que M’ seja determinı́stico, e isto pode
ser realizado com a aplicação de mudanças primitivas do tipo RT ou CT , respectiva-
mente.
As Proposições 7.1.4 e 7.1.5 mostram que sempre é possı́vel alterar um estado do

modelo N para que este seja um refinamento de um outro estado de um modelo M. O
objetivo do reparo de refinamento é alcançado quando é possı́vel estender este resultado
para a relação de refinamento entre modelos, entretanto isto nem sempre é possı́vel. Para
que isto seja possı́vel, o modelo N deve possuir um número mı́nimo de estados para que
seja possı́vel mapear todos os estados de M nos estados de N. Este número é definido
através da quantidade de estados distintos de M.
Definição 7.1.3 (Equivalência entre Estados). Seja M pAP, Σ, S, s0 , R ,R , Lq um

KMTS. Os estados m e n de S são equivalentes se pm, nq P E S S tal que:
1. Lpmq Lpnq;
2. se m Ñ
Ý m1, existe n Ñ
Ý n1 com pm1, n1q P E;
a a
3. se n 99K n1 , existe m 99K m1 com pm1 , n1 q P E;

a a
4. se n Ñ
Ý n1, existe m Ñ
Ý m1 com pn1, m1q P E; e
a a
5. se m 99K m1 , existe n 99K n1 com pn1 , m1 q P E.

a a
Proposição 7.1.6. Seja M pAP, Σ, S, s0 , R , R , Lq um KMTS e E uma relação de

equivalência entre os estados (Definição 7.1.3). Então E é uma relação de equivalência.
Demonstração. A prova segue direto da Definição 7.1.3.

Dizemos que dois estados são distintos se eles não estão relacionados pela relação de
equivalência entre estados. O conceito de estados distintos é usado para analisar quantos
estados, no mı́nimo, um modelo N deve possuir para que ele seja um refinamento de uma
especificação M.
Assim, dados M e N dois KMTS tal que M ª N , existe um conjunto de mudanças
primitivas que pode transformar N em um refinamento de M se o número de classes de
equivalência sobre os estados de M é menor ou igual ao número de estados de N .
A Proposição 7.1.7 mostra que se existem estados equivalentes em um modelo M , eles
são mapeados em um mesmo estado do modelo N por uma relação de refinamento tal
que M ¨ N .
M N N
, L q dois KMTS, R uma relação de refinamento entre M e N e E uma
relação de equivalência entre os estados de M . Se pm, nq P R e pm, m1 q P E então
pm1, nq P R.
Demonstração. A prova é uma consequência direta da Definição 5.1.3 e Definição 7.1.3.
O Teorema 7.1.1 mostra que em determinadas condições, é possı́vel reparar um modelo
N para alcançar a relação de refinamento entre o modelo N e o modelo M.
Teorema 7.1.1. Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q, N pAP , Σ , S , s ,
M N N N N0

RN , RN , LN q e EM uma relação de equivalência entre os estados de M . Seja SM {EM o con-
junto de classes de equivalência definido por EM sobre SM e | SM {EM | o número de classes
de equivalência do conjunto quociente SM {EM . Suponha que M ª N e | SM {EM |¤| SN |
então existe um conjunto de mudanças primitivas X tal que M ¨ X pN q.
Demonstração. Vamos criar uma relação RM que mapeia os estados de M nos estados
de N (1) e modificar N por um conjunto X de mudanças primitivas, gerando um modelo
N 1 (2) tal que RM é uma relação de refinamento entre M e N 1 (3).
1. Seja RM tpsM , sN q | sM P SM e sN P SN tal que pm0 , n0 q P RM e para

todo m1 P SM , m2 P SM com m1 m2 , existe n P SN tal que pm1 , nq P RM e
pm2, nq P RM sse m1 e m2 pertencem a uma mesma classe de equivalência definida
sobre SM com a relação EM u. Como | SM {RM |¤| SN | então cada elemento de
SM {EM é mapeado em um estado diferente de N por RM .
2. Seja pm, nq P RM , pela Proposição 7.1.4 é possı́vel aplicar um conjunto de mu-
danças XRL em n tal que Lpmq ¤ LpXLR pm, nqpnqq. Pela Proposição 7.1.5 é
possı́vel adicionar todas as transições de RM em RN de forma a copiar (clonar)
as transições de RM tal que se pm, a, m1 q P RM de forma que a transição clo-

nada em n é uma transição pn, a, n q P RN e pm1 , n1 q P RM . Quando existir
1
mais de um estado de M mapeado por RM em um mesmo estado n P Sn , qual-
quer estado de M tomado para modificar n resultará no mesmo resultado porque
apenas estados equivalentes de M são mapeados em um mesmo estado de N. Fi-
nalmente, é possı́vel aplicar mudanças primitivas para remover as transições exis-
tentes em N que não foram criadas pela operação de clonagem. Seja X o conjunto
de todas as mudanças primitivas usadas para modificar N, descritas acima, então

1 , R1 , L1 q.
X pN q N 1 pAPN1 , Σ1N , SN , sN 0 , RN N N
3. RM é uma relação de refinamento (Definição 5.1.3:
(a) psM 0, sN 0q P RM ;
(b) Seja pm, nq P RM (garantido pela aplicação do conjunto XLR pm, nq em n no
1 com pm1 , n1 q P RM
passo (2)); para todo pm, a, m1 q P RM , existe pn, a, n1 q P RN
(garantido pela clonagem de transições do passo (2)); e para todo pn, a, n1 q P
RN1 , existe pm, a, m1 q P R com pm1 , n1 q P RM (garantido pela remoção das
M
transições que existem em N e não existem em M no passo (2)).
É possı́vel utilizar a restrição sobre a quantidade de classes de equivalência do modelo

M e o número de estados do modelo N para determinar quantos estados, no mı́nimo,
devem ser adicionados ao modelo N para que seja possı́vel modificar N de forma a um
refinamento de M. Esta quantidade mı́nima é dada por ||SM {RM | |SN ||. Considerando
que deseja-se adicionar o mı́nimo de estados para que N seja um refinamento de M, o
número de estados de N deve ser o maior entre |SM {RM | e |SN |. Dados M pAPM , ΣM ,
, L q, N pAP , Σ , S , s , R , R , L q e E uma relação de
SM , sM 0 , RM , RM M N N N N0 N N N M
equivalência entre os estados de M , utilizando o resultado da Proposição 7.1.3 temos que
o número máximo de mudanças primitivas consistentes entre si que podem ser aplicadas
no modelo N para que ele seja um refinamento do modelo M é dado pela expressão (sendo
maxpSN , SM {EM q a função que retorna o maior conjunto entre SN e SM {EM ):
2 p|maxpSN , SM {EM |qq p|APN | |ΣN |q |p|SM {RM | |SN |q|

É preciso encontrar um método que seja capaz de determinar quais são as alterações
que devem ser aplicadas ao modelo N, respondendo a segunda pergunta do problema
de reparo de refinamento. Alguns trabalhos, como (BENES et al., 2011), provam que o
problema de verificar se existe uma relação de refinamento entre dois modelos pertence à
classe P convertendo este problema para o problema de verificar se uma fórmula booleana
é uma QBF. Assim, de forma geral, a ideia consiste em utilizar os dois modelos para gerar
uma fórmula QBF e a relação de refinamento existe entre eles se, e somente se, existe uma
valoração que torna a fórmula verdadeira. Portanto, reparar o refinamento corresponde a
alterar a fórmula para que ela seja satisfazı́vel e converter esta alteração para o modelo em
questão. Até onde sabemos, não existe nenhum trabalho que faça este tipo de alterações
em fórmulas QBF, mas o estudo de fórmulas QBF não faz parte do escopo do presente
trabalho e como é mostrado posteriormente utilizamos outra abordagem para resolver
este problema.
A Proposição 7.1.9 mostra que encontrar o conjunto de mudanças primitivas para
resolver o problema do reparo de refinamento é um problema que pertence à classe NP. A
prova deste fato utiliza o Algoritmo 9 para gerar todas as possı́veis mudanças primitivas
que podem ser aplicadas sobre um KMTS qualquer.
Algoritmo 9: geraMudancasPrimitivas
,L q
Data: KMTS M pAPM , ΣM , SM , sM 0 , RM , RM M
Result: X tx | x é uma mudança primitiva aplicada sobre M u
1 begin
2 X ÐÝ H
3 for m P SM do
4 for p P APM do
5 if LM pm, pq then X ÐÝ X Y tCLpm, l, f alsoq, RLpm, lqu
6
7 else if LM pm, pq then
8 X ÐÝ X Y tCLpm, l, verdadeq, RLpm, lqu
9 else
10 X ÐÝ X Y tALpm, pq, CLpm, l, verdadeq, CLpm, l, f alsoqu
11 for m1 P SM do
12
para algum a P Σ then
if D t pm, a, m1 q P RM M
13 X ÐÝ X Y tRT pm, a, m1 qu
14 if t P RM then
15 X ÐÝ X Y tRT pm, a, m1 qu
16 else
17 X ÐÝ X Y tAT pm, a, m1qu
18 for q P ΣM do
19 X ÐÝ X Y tCT pm, a{q, m1 qu
20 else
21 for q P ΣM do
22 X ÐÝ X Y tAT pm, q, m1 qu
23 X ÐÝ X Y tAT pm, q, m1 qu
O Algoritmo 9 itera sobre os estados do modelo de entrada (linha 3), analisando para
cada estado quais às mudanças primitivas que alteram a valoração das proposições (linhas
4-10), de forma que se, por exemplo, se uma proposição tenha a valoração verdade então
o algoritmo adiciona as mudanças primitivas para alterar a valoração da proposição para
falso e para indefinido. Após esta etapa, o algoritmo adiciona cada par de estados (for da
linha 3 com o for da linha 11) as mudanças primitivas para remover as transições existen-
tes (linhas 12-15), alterar a modalidade das transições existentes (linhas 14-17), alterar as
ações das transições existentes (linhas 18-19) e adicionar as transições inexistentes (linhas
20-23).
A Proposição 7.1.8 mostra a complexidade do Algoritmo 9.
Proposição 7.1.8. O Algoritmo 9 possui complexidade polinomial.

Demonstração. Seja o KMTS M pAPM , ΣM , SM , sM 0 , RM , RM , L q. O algoritmo
M
itera sobre todas as proposições de cada estado (for’s das linhas 3 e 4), executando
estas linhas p|SM | |APM |q vezes. Enquanto o algoritmo itera sobre os estados (for
da linha 3) ele itera novamente sobre todos os estados (for da linha 11) e para cada
par de estados, o algoritmo itera sobre o conjunto de ações (for da linha 18 ou for da
linha 21), executando estas linhas |SM | |SM | |ΣM |) vezes. Assim, algoritmo tem
complexidade Op|SM | |APM | |SM |2 |ΣM |q devido ao aninhamento de suas iterações,
logo, o Algoritmo 9 possui complexidade polinomial em função do tamanho do modelo.
A prova da terminação e da correção do Algoritmo 9 é trivial e por isto não será

apresentada aqui.
Proposição 7.1.9. Dados M e N dois modelos KMTS tal que M ª N , encontrar o

conjunto de mudanças primitivas X tal que M ¨ X pN q é um problema da classe NP.
Demonstração. Mostraremos que existe uma máquina de Turing não-determinista que
resolve este problema. Para tal, vamos (i) gerar todas as possı́veis mudanças primitivas
que podem ser aplicadas sobre N de forma polinomial; (ii) criar uma máquina de Turing
de tempo polinomial que, de forma não-determinista, escolhe quais mudanças fazem parte
do conjunto X e (iii) analisar se M ¨ X pN q de forma polinomial.
O item (i) é consequência direta do Algoritmo 9 e o item (iii) vem do fato do problema
de verificar o refinamento modal forte entre dois modelos ser polinomial. Seja o vetor
VM P N de mudanças primitivas aplicáveis sobre N obtido pelo passo (i), resta criar uma
máquina de Turing não-determinista que gere o conjunto de mudanças X a partir de
VM P N :
M TD : M, N, VM P N ¡
Escolha de forma não-determinista um conjunto X tx|x P VM P N u
Se M ¨ X pN q, retorne X
A máquina M TD acima recebe como entrada os modelos M e N e o conjunto VM P N
de mudanças aplicáveis sobre o modelo N e escolhe um conjunto de mudanças primitivas
X formado por elementos de VM P N tal que se X for aplicado sobre o modelo N, o modelo
resultante X(N) será um refinamento do modelo M, isto é, M ¨ X pN q.
7.1.3 Uma Solução Algorı́tmica para o Reparo de Refinamento

O Algoritmo 10 realiza, de forma determinı́stica, o algoritmo mostrado na Proposição
7.1.9 com os seguintes passos: (i) gerar um conjunto X de todas as possı́veis mudanças
primitivas que podem ser aplicadas sobre o modelo N em questão (linha 3); (ii) gerar o
conjunto das partes de X, PpX q (linha 4); e (iii) para cada elemento Xi de PpX q, verificar
se M ¨ Xi pN q (linhas 5-7). Não há “inteligência” neste algoritmo porque ele tenta todas
as possı́veis combinações de mudanças primitivas válidas. O termo válida se refere à
mudanças que podem ser aplicadas em conjunto (por exemplo, não é possı́vel remover
uma transição e posteriormente alterar sua ação). Por isto, chamamos este algoritmo de
reparo de refinamento exaustivo (RRE).
Algoritmo 10: RRE

Data: KMTS M e N tal que M ª N
Result: R tN 1 —M ¨ N 1 e X pN q N 1 }
1 begin
2 R ÐÝ H
3 mudancasP rimitivasP ossiveis ÐÝ geraM udancasP rimitivaspN q
4 combinacoesM udancasP ossiveis ÐÝ PpmudancasP rimitivasP ossiveisq
5 for X P combinacoesM udancasP ossiveis do
6 if M ¨ X pN q then
7 R ÐÝ R Y tX pN qu
Para testar a aplicabilidade desta solução, o Algoritmo 10 (RRE) foi implementado.

Durante os testes, dois problemas foram detectados. O primeiro problema é relativo a
performance do algoritmo. As etapas de geração das possı́veis mudanças primitivas e de
verificar se dois modelos são refinamento um do outro possuem complexidade polinomial,
todavia gerar o conjunto de partes de um conjunto é um problema de complexidade
exponencial em relação ao tamanho do conjunto de entrada (SUCIU; PAREDAENS,
1994).
Como pode ser visto na Figura 7.1, considerando dois modelos M e N tal que M ª N ,
o tempo de execução do algoritmo cresce exponencialmente em relação à quantidade de
mudanças primitivas que podem ser aplicadas em N (em relação ao tamanho do conjunto
mudancasPrimitivasPossiveis). Este comportamento é explicado porque o conjunto de
combinações é exponencial (2|mudancasP rimitivasP ossiveis| ). A quantidade de mudanças pri-
mitivas que podem ser aplicadas em um modelo qualquer segue a expressão definida na
Proposição 7.1.3 e é possı́vel observar que ela cresce rapidamente em relação ao tamanho
do modelo. Tomando como exemplo os modelos M e N da Figura 7.2, existem 212 4096
combinações de mudanças primitivas que podem ser aplicadas em N tomando M como
Figura 7.1 Gráfico do tempo de execução (em milissegundos) do Algoritmo 10 em relação

número de mudanças primitivas aplicáveis
Figura 7.2 Dois Modelos M e N tal que M ª N e duas saı́das do algoritmo RRE
especificação, o que é um número elevado para um modelo relativamente simples e sem

proposições.
Este desempenho (por mais que possa ser melhorado por estruturas de dados es-
pecı́ficas) torna a aplicação deste método custosa em relação ao tempo de execução, o
que pode ser inviável em termos práticos.
O outro problema encontrado neste algoritmo é o tipo de soluções que ele gera. Supo-
nha que o modelo a ser reparado seja N e a especificação seja M, este algoritmo retorna
como solução um conjunto R de modelos que são criados a partir de modificações de N.
Todavia, o conjunto solução pode possuir modelos que são refinamentos entre si, o que
aumenta consideravelmente o tamanho do conjunto solução e indicar ao usuário o melhor
reparo pode se tornar um problema diante de tantos modelos.
Além disto, critérios puramente estruturais, como os utilizados no algoritmo, podem
resultar na escolha de modelos que são refinamentos da especificação, todavia modificam
radicalmente o modelo N. Um exemplo de caso de mudança radical é mostrado na Figura
7.2.
Neste exemplo, o modelo N não é refinamento do modelo M porque a ação que liga
os estados m1 e m2 e a ação que liga os estados n1 e n2 são diferentes. Uma mudança
primitiva que altera a ação seria suficiente para tornar o modelo N um refinamento do
Figura 7.3 Jogo de refinamento entre os modelos M e N da Figura 7.1
modelo M. Todavia, além desta solução (representada na figura por N 1 ), o algoritmo

também gera como possı́vel solução a remoção da aresta que liga os estados n0 e n1
(representada na figura por N 2 ). Apesar da solução ser um refinamento de M (pela
definição de refinamento), podemos observar que o modelo N 2 deixa de refinar uma parte
de M (estados m1 e m2 ). Apesar de formalmente corretas em relação ao refinamento,
soluções deste tipo podem não ser desejáveis no contexto de desenvolvimento de software
porque representam a perda de uma parte do comportamento obrigatório. Na presente
proposta chamamos estas soluções de soluções não-locais.
Este tipo de solução pode ser útil para algumas aplicações, todavia, nos concentramos
aqui em propor soluções locais, isto é, soluções direcionadas à causa da não existência de
refinamento entre os modelos. Para definir objetivamente o critério de uma solução local
e não-local, utilizamos o jogo de refinamento para definir quais são as causas locais da
não existência da relação de refinamento entre os modelos.
A Figura 7.3 mostra o jogo de refinamento entre os modelos M e N da Figura 7.1.
Neste jogo o spoiler ganha porque o duplicator não pode se mover a partir dos estados
D1 e D2. O estado (ou vértice ou configuração) onde o duplicator não pode se mover é
chamado de testemunha de falha. Por exemplo, o estado D1 do jogo é uma testemunha
de falha. As testemunhas de falhas contêm as informações necessárias para detectar o
motivo de não existir uma relação de refinamento entre os modelos. É possı́vel definir um
algoritmo que se baseia no jogo de refinamento para encontrar as causas da não existência
da relação de refinamento entre dois modelos e reparar estas causas.
Desta forma, definimos que uma solução local para o problema do refinamento é
baseada na informação obtida a partir dos vértices que são testemunhas de falha. A
seção seguinte analisa informações obtidas das testemunhas de falhas e define meios de
reparar o modelo baseando-se nestas informações.
7.2 REPARO DE REFINAMENTO BASEADO NO JOGO DO REFINAMENTO 105
7.2 REPARO DE REFINAMENTO BASEADO NO JOGO DO REFINAMENTO
O reparo de refinamento baseado no jogo de refinamento consiste em modificar o modelo

para que o duplicator continue a jogar. As mudanças a serem aplicadas no modelo são
determinadas pela informação obtida das testemunhas de falha do jogo.
Definição 7.2.1 (Testemunha de Falha). Seja M pAPM , ΣM , SM , sM 0 , RM , RM ,L q e

M
, L q dois KMTS tal que M ª N e o jogo de refinamento
N pAPN , ΣN , SN , sN 0 , RN , RN N
RGM,N pVS , VD , E q e φ v0 v1 ...vwf uma partida em que o duplicator perde. O vértice
dwf é uma testemunha de falha.
É possı́vel ver que todas testemunhas de falhas não possuem arestas de saı́da pois,
nestes vértices o duplicator não consegue jogar. A Proposição 7.2.1 afirma que se não
existe uma relação de refinamento entre dois modelos então existe um movimento do
spoiler tal que, no próximo turno, o duplicator não pode se mover, portanto existirá, pelo
menos, uma testemunha de falha.
Proposição 7.2.1. Seja M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,

M N N
SN , sN 0 , RN , RN , LN q dois KMTS tal que M ª N e o jogo de refinamento RGM,N

pVS , VD , E q. Então existe, pelo menos, uma testemunha de falha Dwf P VD , s P VS tal
que ps, Dwf q P E , mas não existe s1 P VS tal que pDwf , s1 q P E.
Demonstração. Pelo Teorema 6.1.1 se M ª N então existe, pelo menos, um partida finita
onde o duplicator não pode se mover. Se o duplicator não pode se mover então existe
Dwf P VD tal que não existe uma aresta a partir Dwf para algum vértice s P VS .
Existe um padrão nos tipos de arestas do jogo. O tipo de aresta que representa os
movimentos do duplicator depende do tipo de transição do último movimento do spoiler.
Dados dois modelos M e N e um jogo de refinamento RGM,N pVS , VD , E1 , E11 , E2 , E21 q.
Se o spoiler move-se através de uma aresta E1 então o duplicator se movimentará através
de uma aresta E11 . Se o spoiler move-se através de uma aresta E2 então o duplicator se
movimentará por uma aresta E21 . Baseado neste fato, é possı́vel obter, de acordo com as
definições de jogo, o tipo de aresta que deveria existir para conectar uma testemunha de
falha com outro vértice, permitindo que o duplicator continue jogando, evitando assim
que ele perca.
Proposição 7.2.2. Dados M e N tal que M ª N , o jogo de refinamento RGM,N

pVS , VD , E1, E11 , E2, E21 q e ps, pq P E E1 Y E2 onde p é uma testemunha de falha e
s1 P VS . É verdade que:
Seps, pq P E1 então não existe pp, s1 q P E11 ;
Seps, pq P E2 então não existe pp, s1 q P E21 .
Demonstração. A prova é uma consequênia direta das Proposições 6.2.2 e 7.2.1.

Definição 7.2.2 (Causa de Falha). Dados dois modelos M pAPM , ΣM , SM , sM 0 , RM , RM ,

LM q e N pAPN , ΣN , SN , sN 0 , RN , RN , L q tal que M ª N , o jogo de refinamento
N
RGM,N pVS , VD , E1 , E1 , E2 , E2 q, uma aresta ps, pq P E E1 Y E2 e uma testemunha
1 1
de falha p = psM , sN q. A causa de falha é definida por condições existentes nos modelos
que são expressas por:
1. psN , a, s1N q R RN _ LpsM q ¦ Lps1N q se ps, pq P E1; ou

2. ps1N , a, sN q P RN se ps, pq P E2.
Onde s1N é algum estado de SN .
A condição ps, pq P E1 no Item (1) expressa que o spoiler jogou no modelo M movendo-
se para o estado sM . Então, o duplicator deve jogar no modelo N a partir do estado sN
para algum estado s1N tal que LpsM q ¤ Lps1N q. Todavia, não existe esta aresta porque
(sM , sN ) é testemunha de falha. A condição ps, pq P E2 no Item (2) expressa que o spoiler
jogou no modelo N, movendo-se do estado s1N para um estado sN . Então o duplicator
deve jogar no modelo M, mas não existe um movimento possı́vel em M porque (sM , sN )
é uma testemunha de falha. Então em ambos os casos, a transição onde o spoiler joga é
a causa da falha.
Proposição 7.2.3. Dados M e N dois KMTS. Se M ª N então existe, pelo menos, uma
causa de falha no jogo de refinamentoRGM,N .
Demonstração. De acordo com a Proposição 7.2.1 se M ª N então existe, pelo menos

uma testemunha de falha no jogo de refinamento entre M e N e consequentemente, pela
Definição 7.2.2 existe pelo menos uma causa de falha.
A negação da causa de uma falha cf indica o que deve ser verdade para prevenir que
o duplicator perca o jogo na configuração que originou cf e esta expressão pode ser usada
para definir um conjunto de mudanças primitivas que podem ser aplicadas no modelo
para remover cf .
Denotamos o conjunto de causas de falha de um jogo de refinamento RGM,N por
CF pM, N q tcf | cf é uma causa de falha do jogo de refinamento RGM,N u.
Para qualquer causa de falha, é possı́vel mudar o modelo através de mudanças primi-
tivas para removê-la, como especificado na Proposição 7.2.4.

M N N
,L q e uma causa de falha cf P CF pM, N q tal que cf é originada da
aresta ps, pq onde p pm, x, nq, com x P SM Y SN . Existe um conjunto de mudanças
primitivas X tal que X pN q N 1 e cf R CF pM, N 1 q.
Demonstração. Considere uma cf P CF pM, N q. É suficiente aplicar mudanças primitivas

em N tal que os itens 1 ou 2 da Definição 7.2.2 sejam satisfeitos:
1. pn, a, n1 q R RN _ Lpm1 q ¦ Lpn1 q se ps, pq P E1 : esta causa de falha é removida

através da adição de uma transição must para algum estado n1 que satisfaça a
7.2 REPARO DE REFINAMENTO BASEADO NO JOGO DO REFINAMENTO 107
condição Lpm1 q ¦ Lpn1 q. Caso a restrição sobre o número de classes de equivalência

dos estados do modelo M e o número de estados do modelo N não seja satisfeita,
é possı́vel adicionar novos estados em SN , gerando SN 1 . Para todo estado k P S 1 é
possı́vel modificar k através do conjunto XRL pm, k q tal que LM pmq ¤ XRL pm, k qpk q
N
seja verdade (Proposição 7.1.4) e criar uma transição pn, a, k q P RN (Proposição

7.1.5);
se ps, pq P E : é possı́vel usar a mudança primitiva do tipo RT pn, a, n1 q
2. pn, a, n1 q P RN 2
para remover a transição de RN ou modificar a transição com CT pn, a{b, n1 q para
algum b P ΣN e a b tal que pn, a, n1 q R RN é satisfeita.
Assim, para qualquer cf P CF pM, N q, existe, pelo menos, um conjunto de mudanças

primitivas que quando aplicadas em N fazem cf não ser satisfeita, isto é, remove cf do
jogo de refinamento RGM,N .
Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ , S , s , R , R ,L q,

M N N N N0 N N N
o Algoritmo 11 mostra como construir todas as possibilidades de mudança primitiva para
causas de falhas definidas pela condição psN , a, s1N q R RN _ LpsM q ¦ Lps1N q se ps, pq P E1
da Definição 7.2.2.
A ideia geral do algoritmo é baseada na Proposição 7.2.4 e consiste em gerar todas as
mudanças que removam a causa de falha, isto é, gerar todas as mudanças possı́veis que
tornam a expressão psN , a, s1N q P RN ^ LpsM q ¤ Lps1N q verdadeira para algum s1N P SN .
Assim, a ideia do algoritmo é criar vários conjuntos de mudanças, onde cada conjunto
modifica N de forma que para um estado qualquer n P SN vale psN , a, nq P RN ^ LpsM q ¤
Lpnq. Existem três casos que são considerados nesta ordem:
caso 1 (linhas 4-8): a transição já existe mas, o estado de destino não é um re-
finamento de literal e neste caso os conjuntos de mudanças gerados contêm tanto
as mudanças para fazer o estado de destino ser um refinamento de literal através
da função XRL (linha 5) quanto o conjunto de possı́veis mudanças que removem
(linha 6) ou alteram a ação da transição já existente (linha 7). Esta alteração ou
remoção é realizada para que a transição com a ação deseja possa ser criada para
outro estado;
caso 2 (linhas 9-15): a restrição sobre a quantidade de classes de equivalência e a

quantidade de estados no modelo a ser modificado não é satisfeita e então um novo
estado pode ser adicionado. Caso a transição com a ação a já exista, as mudanças
primitivas para alterar ou remover a transição são combinadas com as mudanças
para fazer LM psM q ¤ LN pnq (linha 21); e
caso 3 (linhas 16-21): para cada estado n P SN são geradas combinações para
adicionar a transição e alterar n para que ele seja um refinamento de literal do estado
sM . Caso a transição com a ação a já exista, as mudanças primitivas para alterar ou
remover a transição são combinadas com as mudanças para fazer LM psM q ¤ LN psq
(linha 21).
Algoritmo 11: PossiveisMudancasParaResolverCausaDeFalhaI

Data: Dois KMTS M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,
M N N
,L q e a causa de falha cf do tipo
psN , a, s1N q R RN _ LM psM q ¦ LN ps1N q
Result: Um conjunto X de conjuntos de mudanças primitivas X tX |
X pN q N 1 e cf R CF pM, N 1 qu
1 begin
2 X ÐÝ H
3 mudancasP araAlterarOuRemoverT ransicao ÐÝ H
4 if psN , a, s1N q P RN then
5 X ÐÝ X Y tXRL psM , s1N qu
6 mudancasP araAlterarOuRemoverT ransicao ÐÝ tRT psN , a, s1N qu
7 for q P ΣM e q a do
8 mudancasP araAlterarOuRemoverT ransicao ÐÝ tCT psN , a{q, s1N qu
9 if | SM {EM | ¡ | SN | then
10 n ÐÝ criaN ovoEstadopq
11 if psN , a, s1N q R RN then
12 X ÐÝ X Y tAS pnq, AT psN , a, nq, XRL psM , nqu
13 else
14 for x P mudancasP araAlterarOuRemoverT ransicao do
15 X ÐÝ X Y tx, AS psq, AT psN , a, nq, XRL psN , a, squ
16 for s P SN do
17 if psN , a, s1N q R RN then
18 X ÐÝ X Y tAT psN , a, sq, XRL psM , a, squ
19 else
20 for x P mudancasP araAlterarOuRemoverT ransicao do
21 X ÐÝ X Y tx, AT psN , a, sq, XRL psM , a, squ
7.3 ALGORITMO DE REPARO DE REFINAMENTO BASEADO NO JOGO DE REFINAMENTO109
Já o Algoritmo 12 mostra como construir todas as possibilidades de mudanças para

. De maneira
causas de falha definidas na condição (2) da Definição 7.2.2 ps1N , a, sN q P RN
geral existem dois grupos de possibilidades: remover a transição ps1N , a, sN q (linha 5) ou
alterar a ação da transição para outra ação qualquer de ΣM Y ΣN (linhas 3-4).
Algoritmo 12: PossiveisMudancasParaResolverCausaDeFalhaII

Data: Dois KMTS M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,
M N N
,L q e causa de falha cf do tipo ps1 , a, s q P R
SN , sN 0 , RN , RN N N
Result: Um conjunto X de conjuntos de mudanças primitivas X tX |
N N
X pN q N 1 e cf R CF pM, N 1 qu
1 begin
2 X ÐÝ H
3 for e P ΣM e e a do
4 X ÐÝ X Y tCT ps1N , a{e, sN qu
5 X ÐÝ X Y tRTps1N , a, sN qu
A prova da terminação e da correção dos Algoritmos 11 e 12 seguem direto do ar-

gumento utilizado para a construção do algoritmo e por isto não serão apresentadas.
Considerando que já possuı́mos os algoritmos para gerar o jogo de refinamento, extrair as
causas de falha e remover cada tipo de causa de falha, podemos apresentar o algoritmo
do reparo de refinamento baseado em jogo de refinamento, chamado aqui de RRBJ.
7.3 ALGORITMO DE REPARO DE REFINAMENTO BASEADO NO JOGO DE

REFINAMENTO
Dados dois modelos M e N, onde M ª N , o algoritmo proposto neste trabalho usa o
jogo de refinamento para descobrir todas as possı́veis causas de falha e, explora cada
possı́vel mudança para remover cada causa de falha do modelo N. O algoritmo retorna
um conjunto de possı́veis KMTS gerados a partir do modelo N que são refinamentos do
modelo M.
A Figura 7.4 exibe uma estrutura que representa a execução do algoritmo de reparo de
refinamento entre uma especificação M e um modelo N. Cada causa de falha encontrada
(CF1 , CF2 ,...,CFn ) (através do jogo de refinamento) pode ser removida aplicando diferen-
tes conjuntos de mudanças primitivas (X1 , X2 ,...,Xk ) (geradas a partir dos Algoritmos 11
e 12). Cada conjunto de mudança primitiva é uma mudança possı́vel. A aplicação de cada
conjunto Xi sobre N gera modelos (X1 pN q, X2 pN q,...,Xw pN q) que pode ser refinamento
do modelo M . Para cada modelo modificado, o algoritmo verifica se ele é um refinamento
de M através do jogo de refinamento. Se o modelo modificado não é um refinamento, as
causas de falha encontradas são utilizadas para repetir o processo. É importante notar
que cada folha da árvore de execução pode retornar um modelo que é um refinamento
de M ou um modelo que não é um refinamento de M e não pode ser alterado, quando o
número máximo de mudanças primitivas consistentes que podem ser aplicadas sobre N é
atingido.
Figura 7.4 Exemplo de execução do algoritmo de reparo de refinamento entre os modelos M

eN
O Algoritmo 13 mostra o reparo de refinamento baseado em jogo (RRBJ). Os tipos

abstratos de dados Set<X>, Pair<X,Y> and Vector<X> representam respectivamente:
um conjunto de elemento do tipo X; um par de elementos, onde o primeiro elemento é do
tipo X e o segundo elemento é do tipo Y; e um vetor de elementos do tipo X. Os tipos
CF e PC representam causa de falhas e mudanças primitivas, respectivamente.
O RRBJ é inicialmente chamado recebendo como entrada a especificação M e o modelo
N e um conjunto vazio de mudanças primitivas. Nas chamadas recursivas, este conjunto
contém as mudanças primitivas já aplicadas. O primeiro passo é descobrir as causas de
falhas entre M e N chamando a função encontraCausasDeFalha(M, N) (linha 3). Esta
função retorna todas as causas de falhas do jogo de refinamento RGM,N .
O próximo passo do algoritmo é descobrir as possı́veis mudanças para cada causa
de falha (linha 8). Uma parte importante deste passo é que o algoritmo deve saber
quais mudanças já foram aplicadas no modelo para evitar realizar mudanças que não são
consistentes entre si (evitando assim, desfazer mudanças já realizadas). Caso contrário,
o algoritmo poderia entrar em loop infinito. Outro aspecto importante deste passo é usar
as mudanças primitivas do tipo SA para adicionar novos estados. O algoritmo apenas
adiciona novos estados enquanto a restrição do Teorema 7.1.1 é falsa, isto é, o modelo N
tem menos estados que o número de classes de equivalência de M.
Diferentes mudanças podem remover uma única causa de falha. Desde que não seja
possı́vel descobrir de antemão qual a melhor mudança a ser aplicada, o algoritmo processa
cada possibilidade de mudança separadamente, guardando o modelo resultante assim
como as mudanças aplicadas neste modelo em um par (modelo resultante, mudanças
aplicadas) (linha 10). Por exemplo, se é necessário adicionar uma transição, e o modelo
N tem |SN | número de estados, então o algoritmo cria, no máximo, |SN | 1 possibilidades,
uma para cada estado (|SN | e mais uma para um novo estado adicionado (caso um novo
estado tenha sido adicionado).
Finalmente, o RRBJ é chamado recursivamente (linha 12), para cada par (modelo
resultante, mudanças aplicadas) recebendo como entrada a especificação M, o modelo
Algoritmo 13: RRBJ

Data: KMTS M e N tal que M ª N e o conjunto XA de mudanças já aplicadas
sobre N
Result: R = {N’ | M ¨ N 1 e X pN q N 1 para algum conjunto de mudanças
primitivas X}
1 begin
2 R ÐÝ H
3 causasDeF alha ÐÝ encontraCausasDeF alhapM, N q
4 if causasDeFalha H then
5 Set V ector P C ¡¡ mudancasP rimitivas ÐÝ H
6 Set P air KM T S, Set P C ¡¡¡ modelosESuasM udancas ÐÝ H
7 for cf P causasDeFalha do
8 mudancasP rimitivas ÐÝ encontraP ossiveisM udancaspN, cf, XA q
9 if mudancasPrimitivas H then
10 modelosESuasM udancas ÐÝ
aplicarM udancaspN, mudancasP rimitivasq
11 for par pN 1 , XN 1 q P modelosESuasM udancas do
12 R ÐÝ R Y tRRBJ pM, N 1 , XN 1 qu
13 else
14 R ÐÝ R Y tN u
modificado N’ e todas as mudanças já aplicadas sobre este modelo, XN 1 . Se o modelo

modificado é um refinamento de M, esta chamada recursiva retorna apenas o modelo
modificado (a expressão da linha 04 é falsa e o algoritmo vai para linha 14). Caso
contrário, o algoritmo repete o processo.
7.3.1 Variações do RRBJ
Quando existem várias causas de falha em um jogo de refinamento, o RRBJ tenta resol-
ver cada uma isoladamente e refaz o jogo para cada conjunto de mudanças aplicado para
remover uma causa de falha. Neste novo jogo, as causas de falhas já detectadas anteri-
ormente em outro ramo de execução podem aparecer e serão reparadas novamente, ou
seja, o RRBJ, muitas vezes, repara (ou tenta reparar caso não exista um conjunto de mu-
danças primitivas consistentes que podem ser aplicadas) a mesma causa de falha porque
ela aparece em diferentes ramos de execução do algoritmo. Este fato implica diretamente
na performance do algoritmo, principalmente nos casos onde não é possı́vel reparar uma
causa de falha e ela aparece em diversos ramos. Para cada ramo o algoritmo tentará, sem
sucesso, reparar a causa de falha. Isto acontece porque o RRBJ não compartilha entre
seus ramos de execução informações sobre as causas de falha.
Para contornar esta limitação, duas outras versões do RRBJ foram analisadas: RRBJ-
C com checagem da existência de solução para cada causa de falha; e RRBJ-U que busca
as possibilidades de reparo que resolvam todas as causas de falhas encontradas de uma
única vez.
O RRBJ-C verifica antes da sua chamada recursiva se cada causa de falha encontrada
possui um conjunto de mudanças primitivas que pode repará-la. Se alguma causa de falha
não possui solução então o RRBJ-C evita buscar soluções para as outras causas de falha e
retorna que aquele ramo de execução não possui soluções, continuando o processamento de
outros ramos (se existir) de forma isolada, similarmente ao RRBJ. Já o RRBJ-U verifica
se cada causa de falha possui soluções e combina todas as possı́veis soluções para cada
causa de falha (removendo as mudanças primitivas repetidas), verificando a consistência
entre todas as mudanças primitivas de cada combinação de reparo. Cada possibilidade
de reparo em conjunto é aplicada isoladamente e o algoritmo segue de maneira recursiva.
Ainda podemos imaginar outras variações do RRBJ que tentam reduzir o número de
ramos de execuções existentes, como o RRBJ-M, que escolhe, entre os possı́veis conjuntos
de mudanças primitivas para remover uma causa de falha, o menor conjunto. Ou o RRBJ-
H, que escolhe, heuristicamente, entre os possı́veis conjuntos de mudanças primitivas para
remover uma causa de falha, analisando os dois modelos em questão para que as mudanças
realizadas causem a menor quantidade de efeitos colaterais possı́veis. É possı́vel perceber
que nos casos em que a causa de falha tenha a forma (I) da Definição 7.2.2, existem
quatro possibilidades: a transição com a ação a já existir; a transição com a ação a não
existir; existir um estado que é um refinamento de literais de m; e não existir um estado
que seja refinamento de literais de m. A combinação destas possibilidades nos leva às
seguintes condições possı́veis: existir uma transição must que leva a um estado que não
é um refinamento de literal de m; existir uma transição may que leva a um estado que
não é um refinamento de literal de m; existir um estado que é refinamento de literal de
m, mas não existir nenhuma transição para ele; existir um estado que é refinamento de
literal de m, e existe uma transição may para ele. Nos casos onde apenas a transição
não é must, a melhor mudança é alterar a modalidade da transição. Nos outros casos, é
necessário analisar, no jogo de refinamento, qual a mudança que pode ser realizada que
não altere as relações de refinamento entre estados já existentes.
Uma série de outras variantes do RRBJ são possı́veis, inclusive combinações das vari-
antes descritas acima são possı́veis. Todavia, o presente trabalho foca no RRBJ, RRBJ-C
e RRBJ-U. O estado e análise das outras variantes faz parte do conjunto de trabalhos
futuros.
7.3.2 Análise do RRBJ

Existem diversos fatos que comprovam a terminação do RRJB, como mostrado na Pro-
posição 7.3.1.
Proposição 7.3.1. O algoritmo de reparo de refinamento sempre termina.
Demonstração. Em cada chamada ao método RefinementRepair existem duas possibili-
dades: o modelo N (ou o modelo N já modificado) é um refinamento de M e o algoritmo
retorna este modelo (linha 14); ou o modelo não é um refinamento de M e então o algo-
ritmo tenta repará-lo. Todavia, o algoritmo não tenta reparar o modelo indefinidamente
porque as mudanças que já foram feitas não podem ser desfeitas. Então, como o conjunto
de mudanças que podem ser aplicadas sobre um modelo sem desfazer alguma mudança já
realizada é finita (Proposição 7.1.3), existe um momento em que nenhuma nova mudança
pode ser realizada e o algoritmo para sem reparar o modelo (quando a expressão da linha
09 é falsa).
Além disto, os modelos retornados pelo algoritmo sempre são um refinamento da
especificação porque ele sempre retorna modelos quando não existem testemunhas de
falhas no jogo de refinamento.
Proposição 7.3.2. O algoritmo de reparo de refinamento só retorna modelos que são
refinamentos da especificação.
Demonstração. Na linha 04 do algoritmo, quando a expressão condicional é falsa é porque
não existem testemunhas de falha então o algoritmo vai para a linha 14 e retorna o
modelo em questão. Em nenhuma outra condição modelos são retornados. Assim, de
acordo com o Teorema 6.1.1 o algoritmo apenas retorna modelos que são refinamento da
especificação.
É possı́vel observar que os fatos que fazem com que o RRBJ sempre pare e retorne
apenas modelos que são refinamentos da especificação também se aplicam ao RRBJ-C
e RRBJ-U e por isto o RRBJ-C e RRBJ-U também sempre param e retornam apenas
modelos que são refinamentos da especificação. Todavia existem casos em que o RRBJ
encontra mais soluções do que suas variações e existem casos em que o RRBJ-C encontra
mais soluções que o RRBJ-U. É possı́vel confirmar, após a análise dos testes executados,
que estes fatos ocorrem porque, apesar do RRBJ (e suas variações) buscarem reparos
Figura 7.5 Examplo de uma solução não minimal retornada pelo algoritmo de reparo de
refinamento.
locais, outros estados, transições ou proposições são alterados pelas mudanças primitivas
para remover as causas de falhas. Estas modificações no modelo podem indiretamente
remover outras causas de falhas que não possuı́am um reparo possı́vel. Como o RRBJ
realiza o reparo de cada causa de falha isoladamente, após cada reparo, um novo modelo
gerado e causas de falhas que não possuı́am solução agora podem passar a ter. Um
raciocı́nio análogo explica porque o RRBJ-C pode encontrar mais soluções que o RRBJ-
U.
Um problema do algoritmo de reparo de refinamento apresentado no presente trabalho
é que ele retorna como soluções modelos que não são minimais em relação ao conjunto
de mudanças aplicadas, isto é, considerando que ele retorne como solução os modelos N 1
e N 2 , o conjunto de mudanças primitivas usados para gerar N 1 pode estar contido no
conjunto de mudanças primitivas que geram N 2 .
Este fato pode ser comprovado no exemplo ilustrado na Figura 7.5. Neste exemplo,
M ª N e dentre as soluções retornadas na execução de RRBJ pM, N q estão os modelos
N 1 e N 2 . Considerando que X 1 pN q N 1 e X 2 pN q N 2 , podemos observar que X 1
tALppn1, pq, CLpn1, p, f alsoqu e que X 2 tALppn1, pq, CLpn1, p, f alsoq, RT pn0, a, n1q,
AT pn0 , a, n2 q, AT pn0 , a, n2 qu. Desta forma, temos que X 1 X 2 . O algoritmo não
deveria retornar como solução um modelo gerado por um conjunto de mudanças primitivas
não minimais porque: (1) os modelos retornados perdem ou ganham comportamentos
(leia-se transições e valorações das proposições) que não eram necessários; e (2) isto não é
interessante no ponto de vista de desenvolvimento de software pois, suponha que N fosse
um modelo retirado do código-fonte de um software que deve ser modificado para manter
a relação de refinamento com o modelo M (especificação para este código fonte). Caso os
projetistas escolham tomar como base o modelo N 2 mais alterações seriam necessárias e,
possivelmente, isto implicaria em um maior custo.
Esta limitação pode ser contornada, verificando, dentre as soluções encontradas, quais
são formadas por conjuntos minimais, o que acarretaria em um maior custo computacional
ao algoritmo. Todavia, esta parte não foi desenvolvida neste trabalho e foi listada nos
trabalhos futuros.
Por fim, podemos argumentar que a complexidade do RRBJ é exponencial em relação
aos tamanhos dos modelos de entrada. A Proposição 7.3.3 demonstra este fato.
Proposição 7.3.3. Dados os modelos M pAPM , ΣM , SM , sM 0 , RM , RM ,L q e N

M

pAPN , ΣN , SN , sN 0, RN , RN ,LN q, a complexidade de tempo do algoritmo RRBJ é expo-
nencial em relação aos tamanhos de M e N.
Demonstração. A complexidade do RRBJ é exponencial em relação à quantidade de

causas de falha encontradas, pois, para cada causa de falha encontrada, novos jogos
são criados exponencialmente (um para cada possibilidade de reparo), de forma que a
árvore de execução do RRBJ cresce de forma exponencial. Suponhamos o pior cenário
de execução, onde todo jogo realizado retorne o número máximo de causas de falhas, e
todo ramo de execução de cada jogo atinja seu tamanho máximo, isto é, o modelo N é
modificado até que não haja mudanças consistentes a serem aplicadas. Suponhamos ainda
que cada causa de falha encontrada seja removida com apenas uma mudança primitiva,
de forma que a árvore de execução tenha seu tamanho máximo.
, L q e N pAP , Σ , S , s , R , R ,L q
Sejam M pAPM , ΣM , SM , sM 0 , RM , RM M N N N N0 N N N
e o jogo RGM,N . Apenas os vértices do duplicator podem ser testemunhas de falhas (que
por sua vez refletem as causas de falha). O número máximo de vértices do duplicator que
pode existir no jogo RGM,N é M N pM |ΣM | N |ΣN |q pois:
M N pSM |ΣM | SN |ΣN |q Slooooooooomooooooooon

M SN |ΣM |
2
S M SN |ΣN |,
looooooooomooooooooon
2
I II
onde (I) e (II) representam o número máximo de vértices alcançados pelos conjuntos
VD1 e VD2 , respectivamente.
Considere que o número máximo de vértices do duplicator seja Vmax SM SN pSM

|ΣM | SN |ΣN |q. No pior caso, a quantidade máxima de testemunhas de falhas em
um jogo é Vmax , o que representa que todos os vértices do duplicator são testemunhas
de falha. Como cada testemunha de falha representa uma causa de falha, este é o valor
máximo de causas de falha do jogo.
Para cada causa de falha, existem um número finito de possı́veis reparos. Suponhamos
que o número de possı́veis reparos para cada causa de falha seja X. Na árvore de execução
do RRBJ, cada nó representa um jogo entre M e um modelo N’, que é o modelo N
modificado (ou o próprio N no caso da raiz da árvore). Cada nó possuirá k X Vmax
filhos, isto é, para cada causa de falha um modificação é feita sobre o modelo e um novo
jogo (um novo filho) é realizado entre M e o modelo gerado.
O modelo que está na folha da aprove é o modelo N que já foi modificado h vezes, sendo
h o número máximo de mudanças consistentes que um modelo N pode sofrer em função
de M. No pior cenário possı́vel, em todas as folhas o número máximo de modificações foi
alcançado, isto é, a árvore de execução terá altura h e todos os nós possuirão k filhos,
isto é, a árvore de execução é árvore k-ária perfeita (CHA, ). A quantidade de nós desta
árvore representa a quantidade de vezes em que um novo jogo é construı́do pelo RRBJ.
Assim, temos que a quantidade de nós G da árvore k-ária que representa o pior cenário
para a execução do RRBJ é:
G kpkk1q1 , com h sendo a altura e k o número de filhos (CHA, )

h
Temos que K X Vmax e h é o número máximo de mudanças consistentes no modelo

N. Estas duas variáveis variam de acordo com a quantidade de estados, transições e pro-
Figura 7.6 Modelos M e N tal que M ªN
Figura 7.7 Jogo do refinamento entre os modelos M e N da Figura 7.6(A) e entre os modelos
M e N 9 da Figura 7.10
posições no modelo. Assim, a quantidade de vezes que o RRBJ é chamado recursivamente

varia exponencialmente em relação ao tamanho dos modelos M e N.
A Figura 7.4 apresenta uma árvore de execução, destacando alguns parâmetros da
prova da Proposição 7.3.3.
As modificações realizadas no RRBJ para criar RRBJ-C e RRBJ-U não modificam a
natureza exponencial dos algoritmos. Assim, um raciocı́nio similar pode ser usado para
provar que tanto o RRBJ-C e RRBJ-U têm uma complexidade de tempo exponencial.
Entretanto, acreditamos que a checagem do RRBJ-C pode melhorar a complexidade em
alguns casos, mas continuando a ser exponencial e a forma de resolução em conjunto
do RRBJ-U deve melhorar a complexidade em todos os casos, mas mantendo também a
complexidade exponencial.
7.3.3 Exemplo de Execução do RRBJ e Algumas de Suas Variações

Mostramos agora um exemplo de execução para as variantes RRBJ, RRBJ-C, RRBJ-U,
sobre uma mesma entrada. Sejam os modelos M e N tais como vistos na Figura 7.6.
Como primeiro passo, de qualquer um dos algoritmos analisados, o jogo de refinamento
é construı́do, gerando o jogo mostrado na Figura 7.7(A).
É possı́vel observar que o jogo de refinamento possui como testemunhas de falhas os
vértices D1, D2 e D3. A partir destes vértices, as causas de falhas extraı́das são cf1
pn0, b, n1q R RN _ Lpm3q ¦ Lpn1q para algum n1 P SN , pn1, a, n1q R RN _ Lpm2q ¦ Lpn1q
Figura 7.8 Modelos resultantes das possı́veis mudanças para remover a causa de falha cf1
para algum n1 P SN , e pn1 , b, n2 q P RN , respectivamente. Seguindo o Algoritmo 11, as

mudanças utilizadas para remover cf1 consistem em, para cada estado n P SN fazer que
pn0, b, nq R RN ^ Lpm3q ¦ Lpnq. Fazendo n = n0 temos o seguinte conjunto de mudança
X10 = tAT pn0 , b, n0 q}. Fazendo n = n1 temos o seguinte conjunto de mudança X11
= tAT pn0 , b, n1 q, ALpn1 , pq}. Fazendo n = n2 temos o seguinte conjunto de mudança
X12 = tAT pn0 , b, n2 q, CLpn2 , p, verdadeq}. O conjunto de modelos obtidos com cada
um destes conjuntos de mudanças é exibido na Figura 7.8, de forma que X10 pN q N 1,
X11 pN q N 2 e X12 pN q N 3.
De modo similar, temos para a causa de falha cf2 os conjuntos X20 = tAT pn1 , a, n0 q},
X21 = tAT pn1 , a, n1 q, ALpn1 , pq} e X22 = tAT pn1 , a, n2 q, CLpn2 , p, verdadeq}. O con-
junto de modelos obtidos com cada um destes conjuntos de mudança é exibido na Figura
7.9, de forma que X20 pN q N 4, X21 pN q N 5 e X22 pN q N 6.
Seguindo o Algoritmo 12, as mudanças utilizadas para remover cf3 consistem nos
conjuntos X30 = tRT pn1 , b, n2 q} , e X31 =tCT pn1 , b{a, n2 q, CLpn2 , p, verdadeq}. O con-
junto de modelos obtidos com cada um destes conjuntos de mudança é exibido na Figura
7.10, de forma que X30 pN q N 7 e X31 pN q N 8.
A partir deste ponto, cada variante funciona de uma forma diferente:
1. RRBJ: o RRBJ aplicará o primeiro conjunto de mudanças X10 , gerando o modelo

N1. Em seguida, o RRBJ criará o jogo de refinamento RGM,N 1 , exibido na Figura
7.7(A), retornando como testemunhas de falha os vértices D2 e D3;
2. RRBJ-C: o RRBJ-C analisará se cada causa de falha possui pelo menos um conjunto
de mudanças que pode remove-la. Neste exemplo, as causas de falha cf1 , cf2 e cf3
possuem mudanças que a removem, e por isto, o RRBJ-C aplica as mudanças para
resolver cf1 , obtendo o modelo N1 e executa o jogo de refinamento entre M e N1,
obtendo as testemunhas de falha D2 e D3; e
3. RRBJ-U: O RRBJ-U descobrirá o conjunto de mudanças possı́veis para remover

cada causa de falha encontrada. Estes conjuntos são combinados, gerando um
conjunto X tX | CF pM, X pN qq R cf1 e, CF pM, X pN qq R cf2 e CF pM, X pN qq R
cf3 }. A aplicação do primeiro conjunto de mudanças válidas (consistentes e que
retornam KMTS determinı́stas) é (X10 Y X20 Y X31 ) que retorna o modelo N9
mostrado na Figura 7.10. Em seguida, o RRBJ-U cria o jogo de refinamento RGM,N 9
exibido na Figura 7.7(B).
Este processo é repetido por cada variante. Ao final do processamento, um dos mo-
delos obtidos como solução é apresentado na Figura 7.11.
7.3.4 Validação dos Algoritmos de Reparo

Os algoritmos foram implementados e estão disponı́veis em (MACHADO, 2016), junta-
mente com os testes realizados.
Como, até onde sabemos, não existem algoritmos para o reparo de refinamento como
definido neste trabalho, comparamos apenas os resultados com as três variações do algo-
ritmo de reparo de refinamento (RRBJ, RRBJ-C, RRBJ-U). O algoritmo RRE mostrou-se
Figura 7.11 Um modelo resultante do processo de reparo de refinamento pelos algoritmos

RRBJ, RRBJ-C e RRBJ-U
inviável na prática (modelos com 2 estados levavam mais de 5 minutos para serem re-
solvidos e geravam exceções de falta de memória) e, por isto, foi removido das análises.
Geramos casos de testes de forma similar aos realizados em (BENEš et al., 2011), variando
a quantidade de estados, número de transições entre os estados e o número de proposições
nos estados. Para validar a correção do algoritmo, dois grupos de testes foram criados,
cada um com 500 testes e cada teste consistia em uma especificação M e um modelo
N. No primeiro grupo de teste, o GRUPO-A, o modelo N era gerado a partir de um
número aleatório de modificações nas proposições dos estados, nas transições (podendo
ser alteração de ação, remoção de transição ou alteração de modalidade). Desta forma,
sempre foi possı́vel modificar N para alcançar como solução pelo menos um modelo que
fosse refinamento de M. O segundo grupo de teste, o GRUPO-B, foi feito da maneira a
não possuir soluções, isto é, M foi gerado aleatoriamente para ter todos os seus estados
distintos e um N era gerado aleatoriamente também com menos estados que M. A possi-
bilidade de adição de estados foi desabilitada e assim, não era possı́vel reparar o modelo
N para que ele fosse refinamento de M.
Cada algoritmo foi testado com os 1000 casos de teste. Nesta etapa, os algoritmos
deveriam responder SIM caso existisse ao menos uma solução e NÃO caso contrário.
Caso algum algoritmo respondesse NÃO para o GRUPO-A ou SIM para o GRUPO-
B, a entrada era inspecionada e corrigida e/ou em caso necessário o(s) algoritmos eram
reparados (ou seja, a implementação possuı́a erros). Nos casos de alteração na entrada ou
no algoritmo, todo o processo era repetido para todos os algoritmos. No fim desta etapa,
23 correções foram necessárias e todos os algoritmos apresentavam os mesmos resultados.
A quantidade de soluções encontradas não foi levada em consideração, apenas o fato de
encontrar pelo menos uma solução ou não.
Após a etapa de validação, foram gerados testes para analisar o tempo de execução dos
algoritmos. Como podemos analisar pela expressão da complexidade, o fator primário que
influencia no tempo de execução é a quantidade de causas de falhas encontradas. Todavia,
algumas variáveis influenciam de forma secundária o tempo de execução: quantidade de
estados, quantidade de transições e quantidade de proposições por estado. Assim, quatro
grupos de testes baseados em quatro combinações dos valores das variáveis secundárias
foram criados. Os grupos e os valores das variáveis podem ser vistos na Tabela 7.1.
Cada grupo é composto por 07 blocos, de forma que cada bloco contém 10 testes e
cada teste é composto pela especificação M e o modelo N. Os blocos foram divididos
de forma que dentro de um bloco, o jogo de refinamento entre M e N retornasse uma
Grupo
Variável
GRUPO-UM GRUPO-DOIS GRUPO-TRES
Nº de estados 2 5 8
Nº de transições 2 3 4
Nº de proposições 3 3 4
Nº modificações
2 2 2
em transições
Nº modificações
2 2 2
em proposições
Tabela 7.1 Variáveis de acordo com o grupo de teste
Figura 7.12 Estrutura dos testes realizados por grupo
quantidade de causas de falha, o bloco 01 possui 0 causas de falha e o último bloco, o

bloco 07, possui 6 causas de falha. Desta forma, foi possı́vel analisar como as causas de
falhas e as variáveis secundárias impactaram na performance do algoritmo.
A Figura 7.12 representa a divisão de um grupo qualquer em blocos e em seus testes.
Casos positivos representam que é possı́vel reparar o modelo e casos negativos representam
o contrário. O incremento em cada bloco é justificado no resultado de cada teste.
O resultado da execução do GRUPO-UM é exibido na Tabela 7.2 e no gráfico da
Figura 7.13.
O resultado da execução do GRUPO-DOIS é exibido na Tabela 7.3 e no gráfico da
Figura 7.14.
O resultado da execução do GRUPO-TRES é exibido na Tabela 7.4 e no gráfico da
Figura 7.15.
Para analisar o impacto do crescimento no modelo, os resultados para o algoritmo
RRBJ de cada grupo foi cruzado e é apresentado na Figura 7.16.
Por fim, para analisar a diferença dos resultados encontrados em cada algoritmo, a
quantidade de modelos encontrados em cada execução do GRUPO-TRES é apresentada
na Tabela 7.5 e o gráfico desta tabela é exibido na Figura 7.17.
Quantidade de causas de falha

Algortimo
0 1 2 3 4 5 6
RRBJ 8,2 1,1 0,5 61,4 173,1 166,5 603,1
Desvio-padrão 2034,62 1,66 0,972 193,46 386,65 19,17 1638,72
RRBJ-C 5,4 1,7 0,8 21,4 31,8 33,7 41,3
Desvio-padrão 6,17 1,64 0,79 1,50 1,13 8,66 0,95
RRBJ-U 4,3 1,3 1 0,7 1,5 0,9 0,8
Desvio-padrão 5,8 1,06 0,67 (0,48 1,27 0,74 0,42
Tabela 7.2 Tempo médio de execução, em milissegundos, dos algoritmos de reparo de refina-
mento por quantidade de causas de falha do GRUPO-UM
Figura 7.13 Gráfico do tempo médio de execução, em milissegundos, dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-UM

Algortimo
0 1 2 3 4 5 6
RRBJ 8,2 27,3 36,7 70,2 162,2 188,1 777,2
Desvio padrão 75,91 5,42 7,88 12,8 56,44 33,12 125,33
RRBJ-C 9,2 5,5 2,2 10,9 12,8 18,8 48.3
Desvio padrão 2,11 2,22 0,5 2,77 1 4,11 1,33
RRBJ-U 6,2 3,1 3 1,3 1,6 1,2 0,5
Desvio padrão 3,97 2,44 1 0,88 1,5 0,53 0,99
Tabela 7.3 Tempo médio de execução, em milissegundos, dos algoritmos de reparo de refina-
mento por quantidade de causas de falha do GRUPO-DOIS
de refinamento por quantidade de causas de falha do GRUPO-DOIS

Variável
0 1 2 3 4 5 6
RRBJ 432,18 8512,65 11345,11 12987,65 15672,89 22463,11 35234,17
Desvio padrão 774,17 1111,76 3000,22 600,12 5512,22 1233,55 4425
RRBJ-C 221,77 7345,12 8737 8983,11 14235,99 13887 24023,55
Desvio padrão 2001,99 2721,2 500,89 1467,86 8765 1395,88 999,11
RRBJ-U 211,67 5437,49 4782,11 4566,47 3588,67 2567,87 3001,22
Desvio padrão 551,58 2234,11 2000 456,12 655,88 400 200,22
Tabela 7.4 Tempo médio de execução, em milissegundos, do algoritmos de reparo de refina-
mento por quantidade de causas de falha do GRUPO-TRES
de refinamento por quantidade de causas de falha do GRUPO-TRES
Figura 7.16 Gráfico do tempo médio de execução, em milissegundos, do algoritmo RRBJ por
quantidade de causas de falha e por grupo
Quantidade de Algoritmo
causas de falha RRBJ RRBJ-C RRBJ-U
1 63 10 8
2 20 10 10
3 16 10 9
4 24 10 8
5 538 14 10
6 28 9 8
Tabela 7.5 Quantidade de modelos encontrados como solução dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-TRES
Figura 7.17 Quantidade de modelos encontrados como solução dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-TRES
A análise das tabelas e dos gráficos permite-nos confirmar de forma experimental o

resultado obtido na análise da complexidade do algoritmo. A quantidade de estados,
transições e proposições influencia no tempo médio de execução do algoritmo porque in-
fluencia no tamanho dos jogos de refinamentos gerados. Este resultado já era esperado.
Podemos concluir que, apesar de sua complexidade exponencial, a depender do tamanho
dos modelos, estes algoritmos podem ser utilizados, considerando que o uso de métodos
de reparo de refinamento não é uma atividade diária ao longo do processo de desenvol-
vimento. Ela deve ocorrer na etapa de elaboração e de verificação de modelos em cada
iteração, assim, mesmo que o processamento tome alguns minutos (ou horas) o impacto
no tempo final de desenvolvimento pode ser compensado pela garantia da relação de re-
finamento entre os modelos, garantindo a preservação das propriedades e que podem ser
utilizados para guiar alterações precisas em outros artefatos (diagramas de sequência ou
código-fonte).
Todavia, apesar de funcionar adequadamente, existem alguns pontos dos algoritmos
que podem ser melhorados:
1. É possı́vel usar técnicas de programação dinâmica para reusar as soluções já pro-
duzidas para as causas de falhas já analisadas;
2. Acreditamos ser possı́vel trabalhar diretamente sobre um jogo de refinamento, re-

fletindo diretamente as alterações no jogo e analisando seu impacto sem ter que
refazer o jogo a cada reparo realizado;
3. É possı́vel definir algumas heurı́sticas para evitar analisar todos os casos das possı́veis
mudanças. Estas heurı́sticas podem utilizar informações do jogo de refinamento
para fazer modificações sem gerar (ou gerando o mı́nimo possı́vel) novas causas de
falhas.
Capı́tulo
8
“Nós só podemos ver um pouco do futuro, mas o suficiente para perceber que há muito a fazer”, Alan
Turing
CONCLUSÕES
Neste trabalho, apresentamos como sistemas de transições modais de kripke podem ser
utilizados no processo de desenvolvimento de software com informações parciais a res-
peito do comportamento pretendido do software e seus componentes de forma a prover
suporte ao desenvolvimento incremental e iterativo. Tratamos este problema sobre várias
perspectivas: sı́ntese de modelos; relações e operações sobre os modelos; verificação de
refinamento; e reparo de refinamento.
8.1 SÍNTESE DE KMTS A PARTIR DE CENÁRIOS

A utilização de modelos KMTS no desenvolvimento de software requer expertise para a
construção e análise dos modelos envolvidos. No desenvolvimento convencional, utilizam-
se linguagens informais ou semiformais, como a UML, e a modelagem do comportamento
e da interação é usualmente limitado ao uso de diagramas de estado e de sequência. Para
mitigar este problema, o uso de métodos automáticos ou semiautomáticos para criar mo-
delos KMTS a partir de diagramas de sequências foram propostos no presente trabalho
através de um algoritmo de sı́ntese de modelos KMTS a partir de cenários. Adaptamos
o algoritmo de sı́ntese proposto por Krka et al. (2009) para lidar com proposições inde-
finidas, permitindo mais indefinições nas entradas, ou seja, o usuário não precisa definir
propriedades sobre todas as variáveis do sistema.
8.2 RELAÇÃO DE REFINAMENTO E OPERAÇÕES DE COMPOSIÇÃO PARA-

LELA E CONJUNÇÃO
Neste trabalho, baseados no conceito de refinamento modal forte para modelos parciais
presentes na literatura, propomos uma definição de refinamento modal forte para modelos
KMTS com ações, além de definir as operações de composição paralela e conjunção para
modelos KMTS. Esta relação e estas operações são fundamentais para possibilitar uma
análise sobre modelos na presença de informação parcial.
125
126 CONCLUSÕES
A relação de refinamento modal forte definida pode ser utilizada para analisar se as
propriedades de um modelo são preservadas em outro modelo e difere de outras relações
de refinamento previamente definidas na literatura por levar em consideração as ações
nos modelos e as indefinições nos estados. Baseado na relação de refinamento modal
forte, uma definição de refinamento completo foi proposta e a relação entre modelos
determinı́sticos e estas duas definições de refinamento foi estudada.
O operador de composição paralela proposto gera um único modelo KMTS que repre-
senta a execução em paralelo de diversos modelos KMTS através de interleaving e troca
de mensagens sı́ncronas nas ações compartilhadas entre os modelos, de forma similar
ao definido na literatura para outros modelos comportamentais parciais. O conceito de
composicionalidade entre dois modelos também foi definido e reflete quando dois modelos
podem ser executados em paralelo sem que a composição atinja algum estado inconsis-
tente no que diz respeito às proposições dos estados. A análise das proposições no estado
da composição também pode ser usada para inferir valores de proposições definidas pelo
usuário como indefinidas, auxiliando assim o trabalho de análise de requisitos.
O operador de conjunção proposto unifica dois modelos em um único modelo tal
que represente a interseção do comportamento dos dois modelos. O comportamento
obrigatório de ambos os modelos é preservado e o comportamento possı́vel dos modelos
é preservado quando o comportamento possı́vel é definido nos dois modelos. Todavia,
nem sempre é possı́vel unir dois modelos, e para detectar quando a união é possı́vel,
definimos o conceito de consistência entre modelos KMTS, de forma similar aos trabalhos
relacionados.
8.3 JOGO DE REFINAMENTO
Propomos um jogo para analisar o refinamento entre dois modelos KMTS. Até onde
sabemos, nenhum outro trabalho propõe um jogo de refinamento entre modelos parciais
e nenhum trabalho define um jogo de refinamento entre modelos KMTS. Os trabalhos
encontrados resumem-se a definir uma série de regras do jogo sobre modelos MTS. O
presente trabalho, além de caracterizar o jogo com uma série de regras, o caracteriza como
um grafo, mostrando a relação do grafo com as regras e com a relação de refinamento.
Por fim, um algoritmo para geração do jogo de refinamento entre modelos KMTS é
apresentado, estudado e validado, mostrando a natureza polinomial deste problema.
8.4 REPARO DO REFINAMENTO
Estudamos o problema de reparo do refinamento, que consiste em modificar um modelo

para garantir uma relação de refinamento entre este modelo e a especificação. Baseado
no jogo de refinamento, propomos um algoritmo que usa o conceito de testemunha de
falha, das quais são extraı́das as causas de falhas, que são fórmulas proposicionais que
formalizam a causa da não existência do refinamento. A partir destas fórmulas, o mo-
delo é modificado de forma local, evitando assim modificações radicais no modelo. Este
algoritmo é analisado em termos de sua correção, terminação e complexidade. Outras
variantes deste algoritmo são também propostas e, de acordo com as validações realiza-
8.5 CONTRIBUIÇÕES 127
das, estes algoritmos também podem ser utilizados para ajudar a reparar modelos que
não possuem uma relação de refinamento com sua especificação.
8.5 CONTRIBUIÇÕES
Este trabalho traz contribuições tanto no estudo dos modelos parciais quanto na sua
aplicação no desenvolvimento de software.
Citamos como contribuição no estudo de modelos parciais as definições, operações e
algoritmos para modelos KMTS. Neste sentido, podemos destacar o jogo do refinamento
e o algoritmo de reparo de refinamento. O algoritmo que verifica a existência da relação
de refinamento através do jogo de refinamento proposto possui uma performance que
pode ser utilizada na prática, e por isto este resultado é interessante. Sobre o algoritmo
de reparo de refinamento, ate onde sabemos, este é o primeiro algoritmo proposto para
reparar um modelo comportamental parcial de forma a garantir uma relação de refina-
mento. Também acreditamos que este algoritmo pode ser usado para prover suporte na
área de análise de impacto no contexto de desenvolvimento de software incremental e
iterativo. O impacto de uma mudança pode ser mensurado associando pesos para cada
tipo de mudança primitiva e calculando o custo de mudança para cada modelo produzido
pelo algoritmo de reparo de refinamento.
Do lado do desenvolvimento de software em meio à presença de conhecimento parcial,
o presente trabalho traz como uma das contribuições a análise das caracterı́sticas, propri-
edades e operações sobre KMTS neste contexto. Além disto, a presente abordagem utiliza
diagramas consolidados em projetos de desenvolvimento de software para gerar modelos
comportamentais na presença de conhecimento parcial. Utilizar os modelos KMTS pos-
sibilita o uso de técnicas de verificação formal para análise e evolução dos componentes
de um software. O uso destas técnicas adicionará mais uma camada de análise nos mo-
delos comportamentais, trazendo maior confiabilidade ao modelo proposto e ocultando
do usuário a complexidade do processo de verificação formal. Isto pode tornar a presente
proposta aplicável na prática durante um processo real de desenvolvimento de software.
A partir das contribuições na construção, análise e reparo de modelos KMTS, o pre-
sente trabalho define a base para um framework formal que pode ser utilizado na cons-
trução e evolução de software com informação incompleta.
8.6 TRABALHOS FUTUROS
Podemos listar alguns trabalhos futuros que identificamos ao longo da pesquisa:
1. Sı́ntese de modelos KMTS a partir de artefatos de software:
Evoluir o algoritmo de modelos KMTS a partir de diagramas de sequência para

considerar estruturas dos diagramas, como a negação e a estrutura condicional;
Propor algoritmos para sı́ntese de KMTS a partir do código-fonte.
2. Relação de refinamento e operações sobre modelos KMTS:

128 CONCLUSÕES
Definir outras relações de refinamento como refinamento modal fraco e o de

alfabeto ramificado para modelos KMTS;
Definir outras operações sobre modelos KMTS, como a operação quociente
(uma operação dual a operação de conjunção, que pode ser utilizada para
extrair uma visão em nı́vel de componente a partir do modelo do sistema);
Definir um modo de representar as alterações na composição paralela nos mo-
delos que a compõem, de forma a refletir modificações da composição nos seus
modelos;
Implementar algoritmos para calcular conjunção e quociente entre dois modelos
KMTS.
3. Reparo de refinamento
É possı́vel usar técnicas de programação dinâmica para reusar as soluções já

produzidas para as causas de falhas já analisadas;
Acreditamos ser possı́vel trabalhar diretamente sobre um jogo de refinamento,
refletindo diretamente as alterações no jogo e analisando seu impacto sem ter
que refazer o jogo a cada reparo realizado;
É possı́vel definir algumas heurı́sticas para evitar analisar todos os casos das
possı́veis mudanças. Estas heurı́sticas podem utilizar informações do jogo de
refinamento para fazer modificações sem gerar (ou gerando o mı́nimo possı́vel)
novas causas de falhas;
Definir o algoritmo de reparo de refinamento para outros tipos de refinamento.
REFERÊNCIAS BIBLIOGRÁFICAS
ALFARO, L. D.; HENZINGER, T. A. Interface-based design. In: Engineering theories

of software intensive systems. [S.l.]: Springer, 2005. p. 83–104.
ANTONIK, A. et al. 20 years of modal and mixed specifications. Bulletin of the European
Association for Theoretical Computer Science, n. 95, 2008.
BAIER, C.; KATOEN, J.-P.; LARSEN, K. G. Principles of model checking. [S.l.]: MIT
press, 2008.
BAUER, S. Modal specification theories for component-based design. Tese (Doutorado)

— lmu, 2012.
BAUER, S. S. et al. Moving from specifications to contracts in component-based design.

In: . Fundamental Approaches to Software Engineering: 15th International Confe-
rence, FASE 2012, Held as Part of the European Joint Conferences on Theory and Prac-
tice of Software, ETAPS 2012, Tallinn, Estonia, March 24 - April 1, 2012. Proceedings.
Berlin, Heidelberg: Springer Berlin Heidelberg, 2012. p. 43–58. ISBN 978-3-642-28872-2.
Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-28872-2z 3y.
BAUER, S. S. et al. A modal specification theory for components with data. In: .
Formal Aspects of Component Software: 8th International Symposium, FACS 2011, Oslo,
Norway, September 14-16, 2011, Revised Selected Papers. Berlin, Heidelberg: Springer
Berlin Heidelberg, 2012. p. 61–78. ISBN 978-3-642-35743-5. Disponı́vel em: xhttp://dx.
doi.org/10.1007/978-3-642-35743-5z 5y.
BECK, K. Embracing change with extreme programming. Computer, IEEE Computer

Society Press, Los Alamitos, CA, USA, v. 32, n. 10, p. 70–77, out. 1999. ISSN 0018-9162.
Disponı́vel em: xhttp://dx.doi.org/10.1109/2.796139y.
BENEš, N.; ČERNá, I.; KřETı́NSKý, J. Modal transition systems: Composition and
ltl model checking. In: BULTAN, T.; HSIUNG, P.-A. (Ed.). Automated Technology for
Verification and Analysis. Springer Berlin Heidelberg, 2011, (Lecture Notes in Computer
Science, v. 6996). p. 228–242. ISBN 978-3-642-24371-4. Disponı́vel em: xhttp://dx.doi.
org/10.1007/978-3-642-24372-1z 17y.
BENEš, N. et al. On determinism in modal transition systems. Theoretical Computer

Science, v. 410, n. 41, p. 4026 – 4043, 2009. ISSN 0304-3975. Festschrift for Mogens
Nielsen’s 60th birthday. Disponı́vel em: xhttp://www.sciencedirect.com/science/article/
pii/S0304397509004010y.
129
130 REFERÊNCIAS BIBLIOGRÁFICAS
BENEš, N. et al. Parametric modal transition systems. In: BULTAN, T.; HSIUNG, P.-A.
(Ed.). Automated Technology for Verification and Analysis. Springer Berlin Heidelberg,
2011, (Lecture Notes in Computer Science, v. 6996). p. 275–289. ISBN 978-3-642-24371-4.
Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-24372-1z 20y.
BENES, N. et al. Parametric modal transition systems. In: BULTAN, T.; HSIUNG, P.
(Ed.). Automated Technology for Verification and Analysis, 9th International Symposium,
ATVA 2011. Proceedings. Springer, 2011. (LNCS, v. 6996), p. 275–289. ISBN 978-3-642-
24371-4. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-24372-1z 20y.
BENEŠ, N. et al. Refinement checking on parametric modal transition systems. Acta

Informatica, v. 52, n. 2, p. 269–297, 2015. ISSN 1432-0525. Disponı́vel em: xhttp://dx.
doi.org/10.1007/s00236-015-0215-4y.
BENVENISTE, A. et al. Contracts for System Design. [S.l.], 2012. 65 p. Disponı́vel em:
xhttps://hal.inria.fr/hal-00757488y.
BOEHM, B. Software engineering economics. Software Engineering, IEEE Transactions
on, SE-10, n. 1, p. 4–21, Jan 1984. ISSN 0098-5589.
BOZZELLI, L. et al. Refinement modal logic. Information and Computation, Elsevier,

v. 239, p. 303–339, 2014.
BROWN, A. W.; WALLNAN, K. C. Engineering of component-based systems. In: IEEE.

Engineering of Complex Computer Systems, 1996. Proceedings., Second IEEE Internati-
onal Conference on. [S.l.], 1996. p. 414–422.
BRUNET, G. A Characterization of Merging Partial Behavioural Models. Tese (Douto-

rado) — University of Toronto, 2006.
BRUNET, G.; CHECHIK, M.; UCHITEL, S. Properties of behavioural model merging.

In: MISRA, J.; NIPKOW, T.; SEKERINSKI, E. (Ed.). FM 2006: Formal Methods.
Proceedings. Springer, 2006. (LNCS, v. 4085), p. 98–114. ISBN 3-540-37215-6. Disponı́vel
em: xhttp://dx.doi.org/10.1007/11813040z 8y.
BRUNET, G.; CHECHIK, M.; UCHITEL, S. Properties of behavioural model merging.

In: In Proceedings of Formal Methods (FM’06. [S.l.: s.n.], 2006.
BULYCHEV, P.; KONNOV, I.; ZAKHAROV, V. Computing (bi) simulation relations

preserving ctl* x. for ordinary and fair kripke structures. –, –, v. 12, 2007.
CHA, S.-H. On complete and size balanced k-ary tree integer sequences. Citeseer.
CHATZIELEFTHERIOU, G. et al. Nasa formal methods: 4th international symposium,

nfm 2012, norfolk, va, usa, april 3-5, 2012. proceedings. In: . Berlin, Heidelberg:
Springer Berlin Heidelberg, 2012. cap. Abstract Model Repair, p. 341–355. ISBN 978-3-
642-28891-3. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-28891-3z 32y.
REFERÊNCIAS BIBLIOGRÁFICAS 131
CLARKE, E. M.; GRUMBERG, O.; PELED, D. Model checking. [S.l.]: MIT press, 1999.
CLARKE, E. M.; LERDA, F. Model checking: Software and beyond. J. UCS, p. 639–649,
2007.
COCKBURN, A. Agile Software Development. Boston, MA, USA: Addison-Wesley Long-

man Publishing Co., Inc., 2002. ISBN 0-201-69969-9.
COHN, M. Succeeding with Agile: Software Development Using Scrum. 1st. ed. [S.l.]:
Addison-Wesley Professional, 2009. ISBN 0321579364, 9780321579362.
COURBIS, A.-L. et al. A formal support for incremental behavior specification in agile
development. In: Software Engineering and Knowledge Engineering (SEKE). [S.l.: s.n.],
2012. p. 6–p.
D’IPPOLITO, N. et al. MTSA: the modal transition system analyser. In: 23rd
IEEE/ACM International Conference on Automated Software Engineering (ASE 2008).
IEEE, 2008. p. 475–476. Disponı́vel em: xhttp://dx.doi.org/10.1109/ASE.2008.78y.
D’IPPOLITO, N. et al. Mtsa: The modal transition system analyser. In: Automated
Software Engineering, 2008. ASE 2008. 23rd IEEE/ACM International Conference on.
[S.l.: s.n.], 2008. p. 475–476. ISSN 1938-4300.
FAIRBANKS, G. Just enough software architecture: a risk-driven approach. [S.l.]:

Marshall & Brainerd, 2010.
FECHER, H.; SCHMIDT, H. Comparing disjunctive modal transition systems with an

one-selecting variant. The Journal of Logic and Algebraic Programming, Elsevier, v. 77,
n. 1, p. 20–39, 2008.
FISCHBEIN, D.; BRABERMAN, V.; UCHITEL, S. A sound observational semantics for

modal transition systems. In: . Theoretical Aspects of Computing - ICTAC 2009:
6th International Colloquium, Kuala Lumpur, Malaysia, August 16-20, 2009. Proceedings.
Berlin, Heidelberg: Springer Berlin Heidelberg, 2009. p. 215–230. ISBN 978-3-642-03466-
4. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-03466-4z 14y.
FISCHBEIN, D.; UCHITEL, S. On consistency and merge of modal transition systems.

In: CITESEER. Proc. of FSE. [S.l.], 2008.
GHEZZI, C. et al. On requirements verification for model refinements. In: Requirements

Engineering Conference (RE), 2013 21st IEEE International. [S.l.: s.n.], 2013. p. 62–71.
GO, K.; CARROLL, J. M. Scenario-based task analysis. The handbook of task analysis
for human-computer interaction, Lawrence Erlbaum Mahwah, NJ, p. 117–133, 2004.
GUERRA, P.; ANDRADE, A.; WASSERMANN, R. Toward the revision of ctl models
through kripke modal transition systems. In: IYODA, J.; MOURA, L. de (Ed.). Formal
Methods: Foundations and Applications. Springer Berlin Heidelberg, 2013, (Lecture No-
tes in Computer Science, v. 8195). p. 115–130. ISBN 978-3-642-41070-3. Disponı́vel em:
xhttp://dx.doi.org/10.1007/978-3-642-41071-0z 9y.
GUERRA, P. T.; ANDRADE, A.; WASSERMANN, R. Toward the revision of CTL
models through kripke modal transition systems. In: IYODA, J.; MOURA, L. M. de
(Ed.). SBMF 2013. Proceedings. Springer, 2013. (LNCS, v. 8195), p. 115–130. ISBN 978-
3-642-41070-3. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-642-41071-0z 9y.
HUTH, M.; JAGADEESAN, R.; SCHMIDT, D. Modal transition systems: A founda-

tion for three-valued program analysis. In: SANDS, D. (Ed.). Programming Languages
and Systems. Springer Berlin Heidelberg, 2001, (Lecture Notes in Computer Science,
v. 2028). p. 155–169. ISBN 978-3-540-41862-7. Disponı́vel em: xhttp://dx.doi.org/10.
1007/3-540-45309-1z 11y.
HUTH, M.; JAGADEESAN, R.; SCHMIDT, D. A. Modal transition systems: A foun-

dation for three-valued program analysis. In: SANDS, D. (Ed.). ESOP 2001 - ETAPS
2001, Proceedings. Springer, 2001. (LNCS, v. 2028), p. 155–169. ISBN 3-540-41862-8.
Disponı́vel em: xhttp://dx.doi.org/10.1007/3-540-45309-1z 11y.
JUHL, L.; LARSEN, K. G. et al. Modal transition systems with weight intervals. The
Journal of Logic and Algebraic Programming, Elsevier, v. 81, n. 4, p. 408–421, 2012.
KRETINSK. MoTrAs. 2013. Último acesso em 17 de Setembro de 2016. Disponı́vel em:

view-source:https://www7.in.tum.de/ kretinsk/motras.html.
KRKA, I. et al. Synthesizing partial component-level behavior models from system spe-
cifications. In: Proceedings of the the 7th Joint Meeting of the European Software Engi-
neering Conference and the ACM SIGSOFT Symposium on The Foundations of Software
Engineering. New York, NY, USA: ACM, 2009. (ESEC/FSE ’09), p. 305–314. ISBN 978-
1-60558-001-2. Disponı́vel em: xhttp://doi.acm.org/10.1145/1595696.1595756y.
KRKA, I. et al. Using dynamic execution traces and program invariants to enhance beha-
vioral model inference. In: Software Engineering, 2010 ACM/IEEE 32nd International
Conference on. [S.l.: s.n.], 2010. v. 2, p. 179–182. ISSN 0270-5257.
KRKA, I. et al. Revisiting compatibility of input-output modal transition systems. In:

JONES, C.; PIHLAJASAARI, P.; SUN, J. (Ed.). FM 2014: Formal Methods. Springer
International Publishing, 2014, (Lecture Notes in Computer Science, v. 8442). p. 367–381.
ISBN 978-3-319-06409-3. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-319-06410-9z
26y.
KRKA, I. et al. From system specifications to component behavioral models. In: Soft-
ware Engineering - Companion Volume, 2009. ICSE-Companion 2009. 31st International
Conference on. [S.l.: s.n.], 2009. p. 315–318.
KRKA, I.; MEDVIDOVIC, N. Revisiting modal interface automata. In: Software En-
gineering: Rigorous and Agile Approaches (FormSERA), 2012 Formal Methods in. [S.l.:
s.n.], 2012. p. 30–36.
KRKA, I.; MEDVIDOVIC, N. Distributing refinements of a system-level partial behavior

model. In: Requirements Engineering Conference (RE), 2013 21st IEEE International.
[S.l.: s.n.], 2013. p. 72–81.
KRKA, I.; MEDVIDOVIC, N. Component-aware triggered scenarios. 2014 IEEE/IFIP

Conference on Software Architecture, IEEE Computer Society, Los Alamitos, CA, USA,
v. 0, p. 129–138, 2014.
LARSEN, K.; THOMSEN, B. A modal process logic. In: Logic in Computer Science,
1988. LICS ’88., Proceedings of the Third Annual Symposium on. [S.l.: s.n.], 1988. p.
203–210.
LARSEN, K. G.; NYMAN, U.; WASOWSKI, A. Modal i/o automata for interface and
product line theories. In: Proceedings of the 16th European Conference on Programming.
Berlin, Heidelberg: Springer-Verlag, 2007. (ESOP’07), p. 64–79. ISBN 978-3-540-71314-2.
Disponı́vel em: xhttp://dl.acm.org/citation.cfm?id=1762174.1762183y.
LETIER, E. et al. Deriving event-based transition systems from goal-oriented requi-

rements models. Automated Software Engg., Kluwer Academic Publishers, Hingham,
MA, USA, v. 15, n. 2, p. 175–206, jun. 2008. ISSN 0928-8910. Disponı́vel em: xhttp:
//dx.doi.org/10.1007/s10515-008-0027-7y.
LUND, M.; STøLEN, K. A fully general operational semantics for uml 2.0 sequence
diagrams with potential and mandatory choice. In: MISRA, J.; NIPKOW, T.; SEKE-
RINSKI, E. (Ed.). FM 2006: Formal Methods. Springer Berlin Heidelberg, 2006, (Lecture
Notes in Computer Science, v. 4085). p. 380–395. ISBN 978-3-540-37215-8. Disponı́vel em:
xhttp://dx.doi.org/10.1007/11813040z 26y.
LYNCH, N. A.; TUTTLE, M. R. An introduction to input/output automata. CWI Quar-
terly, v. 2, p. 219–246, 1989.
MACHADO, E. Z. d. A. KMTS Framework. 2016. Último acesso em 27 de Outubro de

2016. Disponı́vel em: view-source:https://sourceforge.net/projects/kmtsframework/.
MENEZES, M. V. de; BARROS, L. N. de; PEREIRA, S. d. L. Model updating in action.

KEPS 2010, p. 29, 2010.
MEOLIC, R.; KAPUS, T.; BREZOVCNIK, Z. Actlw - an action-based computation tree

logic with unless operator. Inf. Sci., Elsevier Science Inc., New York, NY, USA, v. 178,
n. 6, p. 1542–1557, mar. 2008. ISSN 0020-0255. Disponı́vel em: xhttp://dx.doi.org/10.
1016/j.ins.2007.10.023y.
OMG. UML 2.4.1. 2011. Último acesso em 30 de Janeiro de 2015. Disponı́vel em: view-
source:http://www.omg.org/spec/UML/2.4.1/.
OMG. OCL 2.4. 2014. Último acesso em 30 de Janeiro de 2015. Disponı́vel em: view-
source:http://www.omg.org/spec/OCL/2.4/.
PARK, D. Concurrency and automata on infinite sequences. In: Theoretical computer

science. [S.l.]: Springer, 1981. p. 167–183.
PERRY, D. E.; WOLF, A. L. Foundations for the study of software architecture. SIG-
SOFT Softw. Eng. Notes, ACM, New York, NY, USA, v. 17, n. 4, p. 40–52, out. 1992.
ISSN 0163-5948. Disponı́vel em: xhttp://doi.acm.org/10.1145/141874.141884y.
PRESSMAN, R. S. Software engineering: a practitioner’s approach. [S.l.]: Palgrave Mac-

millan, 2005.
RACLET, J.-B. et al. A modal interface theory for component-based design. Fundam.
Inf., IOS Press, Amsterdam, The Netherlands, The Netherlands, v. 108, n. 1-2, p.
119–149, jan. 2011. ISSN 0169-2968. Disponı́vel em: xhttp://dl.acm.org/citation.cfm?
id=2362088.2362095y.
RUNDE, R.; REFSDAL, A.; STøLEN, K. Relating computer systems to sequence dia-
grams: the impact of underspecification and inherent nondeterminism. Formal Aspects
of Computing, Springer-Verlag, v. 25, n. 2, p. 159–187, 2013. ISSN 0934-5043. Disponı́vel
em: xhttp://dx.doi.org/10.1007/s00165-011-0192-5y.
SABETZADEH, M.; EASTERBROOK, S. Analysis of inconsistency in graph-based vi-

ewpoints: a category-theoretical approach. In: IEEE. Automated Software Engineering,
2003. Proceedings. 18th IEEE International Conference on. [S.l.], 2003. p. 12–21.
SALAY, R. et al. Managing requirements uncertainty with partial models. Requirements

Engineering, Springer-Verlag, v. 18, n. 2, p. 107–128, 2013. ISSN 0947-3602. Disponı́vel
em: xhttp://dx.doi.org/10.1007/s00766-013-0170-yy.
SHOHAM, S.; GRUMBERG, O. A game-based framework for ctl counterexamples and

3-valued abstraction-refinement. ACM Trans. Comput. Logic, ACM, New York, NY,
USA, v. 9, n. 1, dez. 2007. ISSN 1529-3785. Disponı́vel em: xhttp://doi.acm.org/10.
1145/1297658.1297659y.
SOMMERVILLE, I. Software Engineering. 9th. ed. USA: Addison-Wesley Publishing

Company, 2010. ISBN 0137035152, 9780137035151.
SOMMERVILLE, I. Engenharia de Software. 9th. ed. São Paulo, SP, BR: Pearson Pren-
tice Hall, 2011. ISBN 9788579361081.
STIRLING, C. Concur ’95: Concurrency theory: 6th international conference phila-

delphia, pa, usa, august 21–24, 1995 proceedings. In: . Berlin, Heidelberg: Springer
Berlin Heidelberg, 1995. cap. Local model checking games (extended abstract), p. 1–11.
ISBN 978-3-540-44738-2. Disponı́vel em: xhttp://dx.doi.org/10.1007/3-540-60218-6z 1y.
SUCIU, D.; PAREDAENS, J. Any algorithm in the complex object algebra with powerset
needs exponential space to compute transitive closure. In: ACM. Proceedings of the thir-
teenth ACM SIGACT-SIGMOD-SIGART symposium on Principles of database systems.
[S.l.], 1994. p. 201–209.
SUTCLIFFE, A. G.; RYAN, M. Experience with scram, a scenario requirements analy-

sis method. In: Requirements Engineering, 1998. Proceedings. 1998 Third International
Conference on. [S.l.: s.n.], 1998. p. 164–171.
THOMAS, W. Tapsoft’93: Theory and practice of software development: 4th internati-

onal joint conference caap/fase orsay, france, april 13–17, 1993 proceedings. In: .
Berlin, Heidelberg: Springer Berlin Heidelberg, 1993. cap. On the Ehrenfeucht-Fraı̈ssé
game in theoretical computer science, p. 559–568. ISBN 978-3-540-47598-9. Disponı́vel
em: xhttp://dx.doi.org/10.1007/3-540-56610-4z 89y.
UCHITEL, S. Partial behaviour modelling: Foundations for incremental and iterative

model-based software engineering. In: Formal Methods: Foundations and Applications.
[S.l.]: Springer, 2009. p. 17–22.
UCHITEL, S.; BRUNET, G.; CHECHIK, M. Synthesis of partial behavior models from
properties and scenarios. Software Engineering, IEEE Transactions on, v. 35, n. 3, p.
384–406, May 2009. ISSN 0098-5589.
UCHITEL, S. et al. System architecture: the context for scenario-based model synthesis.
In: ACM. ACM SIGSOFT Software Engineering Notes. [S.l.], 2004. v. 29, n. 6, p. 33–42.
UCHITEL, S.; KRAMER, J.; MAGEE, J. Synthesis of behavioral models from scenarios.
IEEE Trans. Softw. Eng., IEEE Press, Piscataway, NJ, USA, v. 29, n. 2, p. 99–115, fev.
2003. ISSN 0098-5589. Disponı́vel em: xhttp://dx.doi.org/10.1109/TSE.2003.1178048y.
UCHITEL, S.; KRAMER, J.; MAGEE, J. Synthesis of behavioral models from scenarios.
IEEE Trans. Software Eng., v. 29, n. 2, p. 99–115, 2003. Disponı́vel em: xhttp://doi.
ieeecomputersociety.org/10.1109/TSE.2003.1178048y.
VLIET, H. V.; VLIET, H. V.; VLIET, J. V. Software engineering: principles and practice.
[S.l.]: Wiley, 1993.
WANG, F.; CHENG, C.-H. Formal techniques for networked and distributed systems –
forte 2008: 28th ifip wg 6.1 international conference tokyo, japan, june 10-13, 2008 pro-
ceedings. In: . Berlin, Heidelberg: Springer Berlin Heidelberg, 2008. cap. Program
Repair Suggestions from Graphical State-Transition Specifications, p. 185–200. ISBN
978-3-540-68855-6. Disponı́vel em: xhttp://dx.doi.org/10.1007/978-3-540-68855-6z 12y.
WEI, O.; GURFINKEL, A.; CHECHIK, M. Analysis of of partial modeling formalisms

in abstract model checking.
Apêndice
A
TÓPICOS DE ENGENHARIA DE SOFTWARE
Neste apêndice são abordados os principais tópicos da engenharia de software relacionados

ao tema desta dissertação.
A.1 CENÁRIOS
Cenários são descrições de exemplos de sessões de interação de usuários com um sistema

(SOMMERVILLE, 2011). Cenários são mais fáceis de serem entendidos, tanto pelos cli-
entes, quanto pelos engenheiros e arquitetos do sistema (UCHITEL; KRAMER; MAGEE,
2003a). Todavia, por representar apenas algumas possibilidades de interação com o sis-
tema, cenários são inerentemente parciais e, por isto, vários cenários devem ser utilizados
para representar todo o comportamento de um sistema. É possı́vel utilizar cenários para
detalhar uma descrição geral dos requisitos. Devido a esta facilidade, diversas metodo-
logias utilizam cenários para elicitação e validação de requisitos como em (SUTCLIFFE;
RYAN, 1998) ou em (GO; CARROLL, 2004). Os cenários podem ser expressos de diver-
sas maneiras: forma textual, utilização de figuras, estruturas condicionais simples (if-else,
go to) e através de diagramas, como é o caso do diagrama de sequência da UML.
A.2 DIAGRAMA DE SEQUÊNCIA
Diagramas de sequência, definidos pela UML, permitem modelar interações entre atores
e objetos do sistema ou entre os objetos, definindo uma ordem de execução (OMG, 2011).
Um diagrama de sequência descreve as interações que ocorrem num caso de uso ou em
uma instância do mesmo, expressando apenas parcialmente o comportamento pretendido,
possı́vel ou proibido do sistema (RUNDE; REFSDAL; STøLEN, 2013).
Na Figura A.1, são identificados os principais elementos que compõem um diagrama
de sequência:
Frame - delimitam o diagrama de sequência, representando o escopo do mesmo;
137
138 TÓPICOS DE ENGENHARIA DE SOFTWARE
Linha da vida - representam a sequência de eventos, ordenados cronologicamente,

que ocorrem em um participante durante uma interação;
Mensagem - são utilizadas para comunicação entre atores, componentes e outros

sistemas. A direção da seta indica quem iniciou a comunicação;
Fragmento combinado - expressam ramificações, laços e condicionais dentro de um

diagrama de sequência; e
Operando - permitem separar o fragmento combinado, definindo as sequências al-

ternativas dentro de um fragmento combinado.
Figura A.1 Elementos do Diagrama de Sequência da UML 2.0. Adaptado de Lund e Stølen
(2006)
A Figura A.2 exibe um exemplo de um diagrama de sequência que define o fluxo de

um site web onde o usuário realiza um login bem sucedido. Podemos identificar várias
entidades/componentes e suas respectivas linhas da vida: Usuário, TelaHome, TelaLogin
e GerenciadorLogin. O usuário começa navegando na tela representada pela entidade
TelaHome e clica no link para exibir a tela de login (ClicaLogin()). As outras mensagens
definem o fluxo de dados entre os componentes e a função de cada componente numa
perspectiva comportamental. Por fim, o usuário recebe o retorno e é redirecionado para
a tela correta.
Todavia, diagramas de sequência não conseguem expressar formalmente algumas res-
trições a respeito das entidades manipuladas como, por exemplo, especificar restrições,
pré e pós-condições para operações e métodos ou definir o alvo de mensagens e ações.
Voltando ao exemplo da Figura A.2, podemos supor que por questões de segurança, o
usuário só tem um login ativo e que o sistema deve verificar se o usuário não está logado
através de outro acesso ao site, isto é, a pré-condição de LoginOK() é que o usuário
não esteja logado e a pós-condição é que o usuário estará logado. Para especificar estas
restrições, é possı́vel utilizar a Object Constraint Language (OCL) (OMG, 2014).
A.3 OBJECT CONSTRAINT LANGUAGE (OCL) 139
Figura A.2 Exemplo de diagrama de sequência do fluxo de login
A.3 OBJECT CONSTRAINT LANGUAGE (OCL)

A OCL é uma linguagem formal utilizada para complementar descrições em modelos
UML. A OCL permite expressar condições invariantes que o sistema deve cumprir ou ser
utilizada como linguagem de consulta sobre objetos descritos em um modelo. A OCL
foi desenvolvida pois a UML não possui anotações para descrever formalmente todos os
aspectos de uma especificação e o uso da linguagem natural pode causar ambiguidades
nos modelos descritos. A OCL se aplica nas seguintes situações (OMG, 2014):
1. Especificar invariantes sobre estereótipos;
2. Descrever pré e pós condições em operações e métodos;
3. Descrever guardas, que representam condições que devem ser satisfeitas para dis-
parar determinados eventos/ações;
4. Especificar o alvo de mensagens e ações;
5. Especificar restrições em operações; e
6. Especificar regras de derivação para atributos de qualquer expressão sobre um mo-

delo UML.
Na presente proposta, utilizaremos sua capacidade de descrever pré e pós-condições

em operações e métodos. Pré-condições especificam o que deve ser verdade antes da
execução da operação e método. Já as pós-condições especificam o que é verdadeiro após

a execução da operação ou método (SOMMERVILLE, 2011).
É possı́vel adicionar a pré-condição e pós-condição, supracitada, no exemplo da Figura
A.2 da seguinte maneira:
context GerenciadorLogin::LoginOK():void
pre: self.usuarioLogado = false
pos: self.usuarioLogado = true
Este par de regras definem que a precondição para a execução da ação LoginOK é que
a variável usuarioLogado seja falsa e após a execução desta ação esta variável será ver-
dadeira. Não apresentaremos no presente trabalho a sintaxe da OCL por entender que
o conhecimento da sintaxe não alterará o entendimento das soluções presentes neste tra-
balho. É suficiente para o leitor entender que é possı́vel indicar a entidade, o método
e especificar as pré e poscondições como expressões booleanas. Como dito acima, vale
destacar que a OCL vai além desta simples utilização.
Tanto o diagrama de sequência, com suas entidades e mensagens, a OCL, e suas re-
gras, são abstrações que descrevem os requisitos do software. Neste contexto, é possı́vel
interpretar o software como a composição de partes menores, isto é, de componentes. Esta
abordagem é voltada para o reuso da definição, implementação e composição de compo-
nentes independentes e fracamente acoplados em sistemas (SOMMERVILLE, 2011). Um
componente é parte do sistema, quase independente porém substituı́vel, com uma função
clara no contexto de uma modelagem de software bem definida (BROWN; WALLNAN,
1996). É possı́vel compor um componente ou criar um sistema a partir da composição
de outros componentes sem ter o conhecimento sobre suas implementações, apenas co-
nhecendo suas interfaces. A utilização de componentes está relacionada com o reuso de
partes de um ou mais sistemas já testadas e implementadas, mais rapidamente, seguindo
a ideia do desenvolvimento incremental (SOMMERVILLE, 2011).
Estas abstrações de software representam requisitos, mas não descrevem qual a ordem
em que os mesmos devem ser desenvolvidos. Existem diversas abordagens de desenvolvi-
mento como, por exemplo, uma abordagem linear, onde o software é desenvolvido como
uma sequência de atividades (análise, projeto, desenvolvimento, teste e suporte). As
soluções presentes neste trabalho não se limitam a determinadas abordagens de desenvol-
vimento, todavia, o foco são abordagens onde o conhecimento do domı́nio não é completo
durante o desenvolvimento do software, como abordagens de desenvolvimento iterativas
e incrementais (PRESSMAN, 2005) quando o software é entendido como a composição
de componentes.
A.4 DESENVOLVIMENTO INCREMENTAL E ITERATIVO

Nos dias atuais, onde mudanças ocorrem a todo instante, softwares devem ser rapida-
mente produzidos para que empresas possam obter proveito das oportunidades e se man-
terem competitivas (SOMMERVILLE, 2011). Todavia, estas mudanças rápidas tornam
impossı́vel obter um conjunto estável de requisitos pois, geralmente, o conhecimento
do usuário sobre suas reais necessidades e, consequentemente, como o sistema deve se
A.4 DESENVOLVIMENTO INCREMENTAL E ITERATIVO 141
comportar é inicialmente parcial e só vai se complementando no decorrer do ciclo de

desenvolvimento do software. Desta forma, especificar todo o sistema para só depois
implementá-lo pode durar um prazo maior que o acordado e o software não satisfazer as
necessidades do usuário.
Para contornar este problema alguns modelos foram propostos, como o modelo in-
cremental e o modelo iterativo. O desenvolvimento incremental é uma estratégia de
planejamento baseada em estágios em que várias partes do sistema são desenvolvidas em
paralelo e integradas quando completas. O modelo incremental pressupõe que todo o
levantamento de requisitos para o software já foi realizado e somente a etapa de desen-
volvimento é incremental.
Figura A.3 Modelo de desenvolvimento incremental
A Figura A.3 exibe o fluxo das atividades no processo de desenvolvimento incremental.

O software é desenvolvido em incrementos e cada incremento tem etapas de análise de
requisitos, projeto, implementação e testes. Após este ciclo de atividades o incremento é
entregue. Vale ressaltar que os incrementos podem ser desenvolvidos em paralelo, se for
possı́vel.
De forma diferente, o desenvolvimento iterativo é uma estratégia de retrabalho (SOM-
MERVILLE, 2011), isto é, há uma preocupação em o que deve-se fazer quando algo
precisar ser alterado. Pressupõe-se neste modelo, que existe uma visão geral, e pouco de-
talhada, do que deve ser feito e esta visão é detalhada aos poucos, isto é, o levantamento
de requisitos acontece ao longo do projeto. A Figura A.4 exibe o fluxo das atividades
no processo de desenvolvimento iterativo. É possı́vel observar que em cada ciclo do pro-
cesso iterativo há etapas de levantamento de requisitos, análise dos requisitos, projeto,
implementação, testes e uma outra etapa de implementação para corrigir eventuais erros
detectados no teste.
Como as duas abordagens de desenvolvimento são complementares (uma é uma es-
tratégia de planejamento e outra de retrabalho) é possı́vel aplicar as duas estratégias ao
mesmo tempo para desenvolver e evoluir várias partes de um sistema em paralelo. Um
exemplo desta integração pode ser vista na Figura A.5. É possı́vel observar que o desen-
volvimento é dividido em iterações e, cada iteração é dividida em incrementos. Existe
uma nova etapa, a etapa de integração que se resume em integrar e testar os diversos
incrementos em uma entrega.
Figura A.4 Modelo de desenvolvimento iterativo
Assim, o desenvolvimento incremental e iterativo se baseia na ideia de disponibilizar

uma versão inicial do software para o usuário e ir refinando-a, através dos novos requi-
sitos, até obter-se o software adequado (SOMMERVILLE, 2011). De maneira geral, no
desenvolvimento incremental e iterativo, há uma intercalação cı́clica nas quatro etapas
de desenvolvimento do software. Este ciclo faz com que o software seja construı́do em
partes e, desta forma, durante o desenvolvimento do mesmo, o cliente consegue definir
melhor quais as suas necessidades, à medida que novos requisitos surgem.
Para dar suporte ao processo de desenvolvimento incremental, algumas metodologias
foram propostas, como é o caso do desenvolvimento ágil, que objetiva a entrega rápida
de um software adequado ao cliente. O desenvolvimento ágil propõe que o software seja
desenvolvido incrementalmente, adicionando novas funcionalidades a cada incremento.
Alguns métodos de desenvolvimento ágil de software, como o Scrum (COHN, 2009),
Extreme Programming (BECK, 1999), Crystal (COCKBURN, 2002), compartilham os
mesmos princı́pios baseados no Manifesto Ágil (SOMMERVILLE, 2011).
Numa abordagem incremental e iterativa, o software é feito em ciclos ou iterações (que
podem conter vários ou apenas um incremento). É possı́vel entender cada ciclo como o
desenvolvimento de um novo software. Novos requisitos refinam ou definem novas funci-
onalidades, modelos são criados ou atualizados para representar estes requisitos e estes
modelos são implementados. Assim, em cada ciclo de desenvolvimento temos as especi-
ficações dos novos requisitos (etapa de projeto) e a implementação dos novos requisitos
(etapa de implementação).
A.4 DESENVOLVIMENTO INCREMENTAL E ITERATIVO 143
Figura A.5 Modelo de desenvolvimento iterativo e incremental
A.4.1 Especificação e Implementação

Uma especificação é uma definição abstrata a respeito de algum aspecto do sistema.
Durante os diversos ciclos de desenvolvimento, um componente pode ter diversas especi-
ficações. Cada especificação pode introduzir mais informações a respeito do componente
de forma que a especificação de um ciclo mais recente respeite a especificação do ciclo
anterior e aumente a quantidade de detalhes (diminua a quantidade de indefinições) a
respeito do comportamento pretendido.
A concretização de uma especificação é uma implementação. Implementações não
possuem indefinições pois, atualmente, os recursos computacionais não permitem in-
definições (uma funcionalidade está ou não está implementada). Uma implementação
sempre é baseada em uma especificação e da mesma forma que uma especificação nova
deve satisfazer as propriedades descritas na especificação antiga, a implementação deve
satisfazer as propriedades da especificação que lhe baseia. Quando isto ocorre, dizemos
que a especificação nova ou implementação está correta em relação à sua especificação.
Este relacionamento entre especificações ou entre especificação e sua implementação é
chamado de refinamento e é um requisito da abordagem iterativa.
Apêndice
B
DEFINIÇÕES RELACIONADAS
Neste apêndice são apresentadas conceitos e definições referentes à utilização de modelos

comportamentais parciais que possuem relação com o tema desta dissertação.
B.1 BISSIMULAÇÃO
A bissimulação é uma relação binária entre sistemas de transição que associa sistemas
que possuem um comportamento idêntico, não sendo diferenciadas por um observador,
isto é, eles alcançam a mesma valoração (ou estados equivalentes) quando são submetidos
as mesmas ações.
Definição B.1.1 (Bissimulação). Seja T SM pSM , Σ, RM , APM , LM q e T SN pSN , Σ, RN ,

APN , LN q dois sistemas de transição, ps0 , t0 q P SM SN com s0 e t0 os estados inici-
ais de T SM e T SN , respectivamente. Dizemos que t0 refina s0 sse existir uma relação
< SM SN tal que ps0 , t0 q P < e para todo ps, tq P < vale:
1. Se ps, a, s1 q P RM então existe t1 tal que pt, a, t1 q P RN com ps1 , t1 q P <;
2. Se ps, a, s1 q P RN então existe t1 tal que pt, a, t1 q P RM com ps1 , t1 q P <;
3. LM psq LN ptq.
Voltando ao exemplo da máquina de vender bebidas e refrigerante, a Figura B.1 exibe

novamente dois sistemas de transição que expressam a mesma máquina. Novamente, para
simplificar o exemplo, as ações estão ocultas. É possı́vel notar que os modelos mostrados
na Figura B.1 são bissimilares através da seguite relação:
R tps0 , t0 q, ps1 , t1 q, ps2 , t2 q, ps2 , t3 q, ps3 , t4 qu
É possı́vel observar que tanto a simulação quanto a bissimulação realizam um ma-

peamento entre os estados dos modelos tal que estados com a mesma valoração sejam
145
146 DEFINIÇÕES RELACIONADAS
Figura B.1 Dois sistemas de transição bissimilares representando uma máquina de vender
bebidas e refrigerante (BAIER; KATOEN; LARSEN, 2008)
mapeados entre si de forma que os estados relacionados alcancem também estados com
as mesmas valorações (que por sua vez estão relacionados também).
Todavia, apesar de bastante úteis na descrição comportamental, os sistemas de transições
não permitem especificar explicitamente conhecimento parcial pois, não é possı́vel expres-
sar modalidade diretamente sobre eles (BAIER; KATOEN; LARSEN, 2008).
B.2 SISTEMA DE TRANSIÇÃO MODAL - MTS

Definição B.2.1 (Sistema de Transição Modal (ANTONIK et al., 2008)). Um MTS é
uma tupla M pΣ, S, R , R q, onde Σ é um conjunto finito de ações, S é um conjunto
finito de estados, R S Σ S e R S Σ S são relações de transições tal que
R R .
B.3 VARIANTES DO REFINAMENTO MODAL FORTE

A principal variante do refinamento modal forte é o Refinamento Modal Fraco.
O refinamento modal fraco surge da ideia de que durante o desenvolvimento de um
software, os diferentes modelos parciais de um componente (ou software) podem pos-
suir um conjunto de ações diferentes. A diferença entre o refinamento modal fraco e o
refinamento modal é que o primeiro considera a divisão das ações do modelo em ações
observáveis e não-observáveis, representadas por τ . Ações não-observáveis são ações que
apenas o modelo conhece e que não são observáveis de fora do mesmo, e por isso são
chamadas de ações internas, representando ações que são geradas e consumidas interna-
mente no modelo, alterando seu estado de forma que outro modelo não tenha ciência
B.3 VARIANTES DO REFINAMENTO MODAL FORTE 147
da ocorrência das ações. As ações externas são as ações observáveis tanto pelo modelo
quanto por outros modelos.
A diferença entre os dois refinamentos está em considerar a ideia de estado alcançável
diretamente. Para o refinamento modal forte, um estado m1 só é alcançável diretamente
por um estado m se houver uma transição que os conecte. Para o refinamento modal fraco,
m1 é alcançável diretamente por m se houver um caminho formado obrigatoriamente por
uma transição com uma ação observável e, opcionalmente, por outras transições com
ações não-observáveis, não necessariamente nesta ordem.
Definição B.3.1 (Refinamento Fraco (ANTONIK et al., 2008)). Seja M pSM , RM , RM q

e N pSN , RN , RN q duas especificações mistas, onde τ representa as ações não-observáveis
e ps0 , t0 q P SM SN com s0 e t0 os estados iniciais de M e N respectivamente . Dizemos
que t0 refina fracamente s0 sse existir uma relação < SM SN tal que ps0 , t0 q P < e
para todo ps, tq P < vale:
1. Para todo ps, a, s1 q P RM existe algum t’ e existe uma sequência de transições

tpÑ
Ýτ q Ñ
Ýa pÑ
Ýτ qt1 com ps1, t1q P <;
existe algum s’ e existe uma sequência de transições sp99K
2. Para todo pt, a, t1 q P RN
τ
q 99K
a
p99K
τ
qs1 com ps1, t1q P <.
Ao considerar as ações internas, o refinamento modal fraco reconhece como refina-
mento de um modelo M , certos modelos que não seriam um refinamento forte de M, por
permitir uma maior flexibilidade na comparação da estrutura dos dois modelos. De certa
forma, podemos comparar o refinamento forte e fraco com o refinamento de semântica
fechada e aberta, respectivamente. A Figura B.2 mostra um exemplo de dois modelos que
não possuem uma relação de refinamento forte, mas possuem uma relação de refinamento
fraco.
Figura B.2 Exemplo de dois modelos que não possuem relação de refinamento forte, mas
possuem uma relação de refinamento fraco
148 DEFINIÇÕES RELACIONADAS
O refinamento modal fraco permite uma maior flexibilização do conceito de refina-

mento. Todavia, esta flexibilização pode levar a certas inconsistências, como por exemplo
a Figura B.3, onde os modelos não deveriam estar relacionados por uma relação de re-
finamento porque no modelo M , o sistema (ou componente) modelado pode processar
diversas ações p antes de uma ação b (observe o ciclo formado pelos estados destacados de
vermelho começando de s0 ). No modelo N isto não é possı́vel, mas N é um refinamento
fraco de M . Este fato ocorre porque o refinamento modal fraco não busca a preservação da
estrutura ramificada entre os modelos. Este fato contradiz o senso esperado nas relações
de refinamento.
Figura B.3 Exemplo de refinamento fraco que contradiz o senso de refinamento
Existem variações do refinamento modal fraco, como o refinamento de alfabeto rami-

ficado que considera a existência de ações internas mas preserva a estrutura ramificada
entre os modelos (FISCHBEIN; BRABERMAN; UCHITEL, 2009).
Apêndice
C
PROVAS DO CAPÍTULO 6
Neste apêndice são apresentadas as provas mostradas no Capı́tulo 6.

Proposição 5.2.1 (O operador de composição paralela é comutativo) Se-
, L q e N pAP , Σ , S , s , R , R , L q dois
jam M pAPM , ΣM , SM , sM 0 , RM , RM M N N N N0 N
KMTS composicionáveis, então M ||N = N ||M .
N N
Demonstração. Sejam M ||N A pAPA , ΣA , SA , sA0 , RA , RA , L q e N ||M B

A
pAPB , ΣB , SB , sB0, RB , RB , LB q. Para provar que A B, precisamos provar que A ¨ B

e que B ¨ A:
A ¨ B: Seja a relação < tpa, bq | a pm, nq e b pn, mq com m P SM e n P SN u. < é

uma relação de refinamento pois, psA0 , sB0 q P < (sA0 pm0 , n0 q e sB0 pn0 , m0 q) e
para todo pa, bq P < vale:
(a) LA paq ¤ LB pbq: pela Definição 5.2.1, para todo p P m, LA ppm, nq, pq
LB ppn, mq, pq, o que implica em LA paq ¤ LB pbq.
(b) se pa, t, a1 q P RA então existe b1 tal que pb, t, b1 q P RB e pa1 , b1 q P < com t P ΣA
e t P ΣB : pelas regras de composição paralela, o estado a1 pode ter uma das
seguintes formas pm1 , nq, pm, n1 q ou pm1 , n1 q (a depender de t P ΣM ou t P ΣN ),
sendo m1 P SM e n1 P SN estados quaisquer. É possı́vel deduzir pelas regras
da transições da Figura 5.2:
Se a1 pm1 , nq então pn, t, n1 q R RN e pm, t, m1 q P RM e pela regra (1),
existe pb, t, b1 q P RB tal que b1 pn, m1 q e pa1 , b1 q P <;
Se a1 pm, n1 q então pm, t, m1 q R RM e pn, t, n1 q P RN e pela regra (3),
existe pb, t, b1 q P RB tal que b1 pn1 , mq e pa1 , b1 q P <; e
Se a1 pm1 , n1 q então t P SN , t P ΣM , pm, t, m1 q P RM e pn, t, n1 q P RN e
pela regra (8) , existe pb, t, b1 q P SB tal que b1 pn1 , m1 q e pa1 , b1 q P <.
Assim, para qualquer forma assumida por a1 na transição pa, t, a1 q P RA , existe
uma transição correspondente pb, t, b1 q P RB e pela definição de <, pa1 , b1 q P <.
149
150 PROVAS DO CAPÍTULO 6
então existe a1 tal que pa, t, a1 q P R e pa1 , b1 q P < com t P Σ

(c) se pb, t, b1 q P RB A
e t P ΣB : análogo ao item (b), considerando RB e RA .
A
B ¨ A: degue de maneira análoga à prova acima.
Assim, como A ¨ B e B ¨ A temos que A B, isto é M ||N N ||M .

Proposição 5.2.2 (O operador de composição paralela é associativo) Sejam
M pAPM , ΣM , SM , sM 0 , RM , RM , L q, N pAP , Σ , S , s , R , R , L q e P
M N N N N0 N

pAPP , ΣP , SP , sM 0, RP , RP , LP q três KMTS composicionáveis entre si, então pM ||N q||P
N N
M ||pN ||P q.
Demonstração. Devemos mostrar que pM ||N q||P ¨ M ||pN ||P q e M ||pN ||P q ¨ pM ||N q||P .
Vamos chamar pM ||N q||P A ppAPA , ΣA , SA , RA , RA , L q e M ||pN ||P q B
A
pAPB , ΣB , SB , RB , RB , LB q.
A ¨ B: Seja a relação < tpa, bq | a ppm, nq, pq e b pm, pn, pqq tal que m P SM ,
n P SN e p P SP u. Como A, B e C são composicionáveis então sA0 ppm0 , n0 q, p0 q
e sB0 pm0 , pn0 , p0 qq, ou seja, psA0 , sB0 q P <. Vamos mostrar que < é uma relação
de refinamento pois, para todo pa, bq P < vale:
(a) LA paq ¤ LB pbq: pela Definição 5.2.1, para todo p P m, LA ppm, nq, pq
LB ppn, mq, pq, o que implica em LA paq ¤ LB pbq.
(b) se pa, t, a1 q P RA então existe b1 tal que pb, t, b1 q P RB e pa1 , b1 q P < com t P ΣA
e t P ΣB : pelas regras de composição paralela, o estado a1 pode ter uma das
seguintes formas ppm, n1 q, pq, ppm, n1 q, p1 q, ppm1 , nq, pq, ppm1 , nq, p1 q, ppm1 , n1 q, pq
ou ppm1 , n1 q, p1 q (a depender da existência de t P ΣM , em ΣN ou t P ΣP ) sendo
m1 P SM , n1 P SN e p1 P SP estados quaisquer. É possı́vel deduzir pelas regras
de transições da Figura 5.2:
Se a1 ppm, n1 q, pq então ppm, nq, t, pm, n1 q P RM ||N , pn, t, n1 q P RN ,
pm, t, m1q R RM e pp, t, p1q R RP . Assim, pela regra (1) aplicada para
gerar N ||P , existe ppn, pq, t, pn1 , pqq P RN ||P e então, pela regra (3) sobre
M ||pN ||P qq existe pb, t, b1 q P RB tal que b’ = (m, (n’, p)) e pa1 , b1 q P <;
Se a1 ppm1 , nq, pq então ppm, nq, t, pm1 , nq P RM ||N , pm, t, m1 q P RM ,
pn, t, n1q R RM e pp, t, p1q R RP . Então, pela regra (1) aplicada para gerar
M ||pN ||P qq, existe pb, t, b1 q P RB tal que b1 pm1 , pn, pqq e pa1 , b1 q P <;
Se a1 ppm1 , n1 q, pq então ppm1 , n1 q, t, pm1 , n1 q P RM ||N , pn, t, n1 q P RN ,
pm, t, m1q P RM e pp, t, p1q R RP . Assim, pela regra (1) aplicada para gerar
N ||P , existe ppn, pq, t, pn1 , pqq P RN ||P e então, pela regra (8) utilizada
para gerar M ||pN ||P qq, existe pb, t, b1 q P RB tal que b1 pm1 , pn1 , pqq e
pa1, b1q P <;
Se a1 ppm, n1 q, p1 q então ppm, n1 q, t, pm, n1 q P RM ||N , pn, t, n1 q P RN ,
pm, t, m1q R RM e pp, t, p1q P RP . Assim, pela regra (8) aplicada para
PROVAS DO CAPÍTULO 6 151
gerar N ||P , existe ppn1 , p1 q, t, pn1 , p1 qq P RN ||P e então, pela regra (3) utili-
zada para gerar M ||pN ||P qq, existe pb, t, b1 q P RB tal que b1 pm, pn1 , p1 qq
e pa1 , b1 q P <;
Se a1 ppm1 , nq, p1 q então ppm1 , nq, t, pm1 , nq P RM ||N , pn, t, n1 q R RN ,
pm, t, m1q P RM e pp, t, p1q P RP . Assim, pela regra (3) aplicada para
gerar N ||P , existe ppn, p1 q, t, pn, p1 qq P RN ||P e então, pela regra (8) utili-
zada para gerar M ||pN ||P qq, existe pb, t, b1 q P RB tal que b’ = (m’, (n, p’))
e pa1 , b1 q P <; e
Se a1 ppm1 , n1 q, p1 q então ppm1 , n1 q, t, pm1 , n1 q P RM ||N , pn, t, n1 q P RN ,
pm, t, m1q P RM e pp, t, p1q P RP . Assim, pela regra (8) aplicada para
gerar N ||P , ppn1 , p1 q, t, pn1 , p1 qq P RN ||P e então, pela regra (8) utilizada
para gerar M ||pN ||P qq, existe pb, t, b1 q P SB tal que b’ = (m’, (n’s, p’)) e
pa1, b1q P <.
Assim, para qualquer forma assumida por a1 na transição pa, t, a1 q, existe uma
transição correspondente pb, t, b1 q em RB e pela definição de <, pa1 , b1 q P <.
e t P ΣB : pelas regras da composição paralela, o estado b’ pode ter uma das
A
seguintes formas (m, (n’, p)), (m, (n’, p’)), (m’, (n, p)), (m’, (n, p’)), (m’, (n’,
p)) ou (m’, (n’, p’)) (a depender da existência de t P ΣM , t P ΣN ou t P ΣP
e da modalidade da transição em M e N) sendo m1 P SM , n1 P SN e p1 P SP
estados quaisquer. É possı́vel deduzir pelas regras de transições que:
, pn, t, n1 q P R , pm, t, m1 q R
Se b1 pm, pn1 , pqq então ppn, pq, t, pn1 , pqq P RN ||P N
RM e pp, t, p1 q R R . Assim, pela regra (2) utilizada para gerar M ||N , existe
ppm, nq, t, pm, n1qq P RM ||N e pela regra (2) utilizada para gerar pM ||N q||P
P
tal que a’ = ((m, n’), p) e pa1 , b1 q P <;

existe pa, t, a1 q P RA
, pn, t, n1 q R R , e pp, t, p1 q R R .
Se b1 pm1 , pn, pqq: então pm, t, m1 q P RM
Assim, pela regra (2) utilizada para gerar M ||N , existe ppm, nq, t, pm1 , nqq P
N P
e pela regra (2) utilizada para gerar pM ||N q||P existe pa, t, a1 q P R
RM ||N A
tal que a’ = ((m’, n), p) e pa1 , b1 q P <;
Se b1 pm, pn1 , p1 qq: então ppn, pq, t, pn1 , p1 qq P RN , pn, t, n1 q P R ,
||P N
pm, t, m1q R RM e pp, t, p1q P RP. Assim, pela regra (4) utilizada para
gerar M ||N , existe ppm, nq, t, pm, n1 qq P RM e então, pela regra (7) uti-
||N
lizada para gerar pM ||N q||P , existe pa, t, a1 q P RA tal que a’ = ((m, n’),
p’) e pa1 , b1 q P <;
Se b1 pm1 , pn, p1 qq: então ppn, pq, t, pn, p1 qq P RN , pn, t, n1 q R R ,
||P N
pm, t, m1q P RM e pp, t, p1q P RP. Assim, pela regra (2) utilizada para
gerar M ||N , existe ppm, nq, t, pm1 , nqq P RM
||N e pela regra (7) utilizada

para gerar pM ||N q||P , existe pa, t, a q P RA tal que a’ = ((m’, n), p’) e
1
pa1, b1q P <;
Se b1 pm1 , pn1 , pqq: então ppn, pq, t, pn1 , pqq P RN , pn, t, n1 q P R ,
||P N

pm, t, m q P RM e pp, t, p q R RP . Assim, pela regra (7) utilizada para
1 1
gerar M ||N , existe ppm, nq, t, pm1 , n1 qq P RM e pela regra (2) utilizada
||N

para gerar pM ||N q||P , existe pa, t, a q P RA tal que a’ = ((m’, n’), p) e
1
pa1, b1q P <;
, pn, t, n1 q P R ,
Se b1 pm1 , pn1 , p1 qq: então ppn, pq, t, pn1 , p1 qq P RN ||P N

pm, t, m q P RM e pp, t, p q P RP . Assim, pela regra (7) utilizada para
1 1
gerar M ||N , existe ppm, nq, t, pm1 , n1 qq P RM e pela regra (7) utilizada
||N
para gerar pM ||N q||P , existe pa, t, a1 q P RA tal que a’ = ((m’, n’), p’) e
pa1, b1q P <; e
Se b1 pm, pn, p1 qq: então ppn, pq, t, pn, p1 qq P RN , pn, t, n1 q R R ,
||P N
pm, t, m1q R RM e pp, t, p1q P RP. E pela regra (4) utilizada para gerar
pM ||N q||P , existe pa, t, a1q P RA tal que a’ = ((m, n), p’) epa1, b1q P <.
Assim, para qualquer forma assumida por b1 na transição pb, t, b1 q, existirá uma
e pela definição de <, pa1 , b1 q P <.
transição equivalente pa, t, a1 qem RA
B ¨ A: Segue de maneira análoga à prova acima.
Assim, como A ¨ B e B ¨ A temos que A B, isto é, pM ||N q||P M ||pN ||P q.
Proposição 5.3.1 Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,
M N N

SN , sN 0 , RN , RN , LN q dois KMTS. M e N são consistentes entre si sse existir uma relação
de consistência CM N entre M e N .
Demonstração. Suponha uma implementação CI pAP, Σ, CM N , pm0 , n0 q, RI , RI , Lq,

tal que RI RI R a menor relação que satisfaz as regras da Definição 5.3.2.
(Ð) Pela Definição 5.3.2 é suficiente mostrar que existe um modelo que é refinamento
de M e de N. Vamos mostrar que este modelo é CI pela relação de refinamento
< tpm, pm, nqq | pm, nq P CM N u, temos que M ¨ CI
LM pmq ¤ Lppm, nqq: por hipótese M e N estão relacionados por uma relação
de consistência, ou seja, p@p P LpmqqpLpm, pq Lpn, pq ou Lpn, pq Kq, logo
LM pmq ¤ Lppm, nqq;
Para todo pm, a, m1 q P RM existe ppm, nq, a, pm1 , n1 qq P R tal que pm1 , pm1 , n1 qq P
CM N : para toda pm, a, m1 q P RM existe pn, a, n1 q P RN (pela relação de con-
sistência CM N ). Assim, pelas regras da Definição 5.3.2 (hipótese), para todo
pm, a, m1q P RM existe ppm, nq, a, pm1, n1qq P < e como pm1, n1q P CM N então
pm1, pm1, n1qq P CM N ; e
tal que pm1 , pm1 , n1 qq P
Para todo ppm, nq, a, pm1 , n1 qq P R existe pm, a, m1 q P RM
CM N : pelas regras da Definição 5.3.2 (hipótese), para todo ppm, nq, a, pm1 , n1 qq P
(ou R ).
< existe pm, a, m1 q P RM M
De forma análoga, é possı́vel provar que N ¨ CI e, portanto, M e N são consistentes

entre si.
(Ñ) Como M e N são consistentes então existe um modelo X tal que M ¨ X e N ¨ X.

Seja X CI. Pela definição de refinamento, existem relações de refinamento <M
e <N que mapeiam os modelos M e N em CI, respectivamente. Suponha uma
relação CM N tpm, nq | i P SI ^ pm, iq P <M ^ pn, iq P <N u. CM N é uma relação
de consistência:
p@p P LM pmqqpLM pm, pq LN pn, pq ou LN pn, pq Kq: como M ¨ CI

então p@p P LM pmqqpLM pm, pq ¤ Lpi, pqq, ou seja, se LM pm, pq K então
LM pm, pq Lpi, pq. Da mesma maneira, como N ¨ CI então p@p P LN pnqq
pLN pn, pq ¤ Lpi, pqq, ou seja, se LN pn, pq K então LN pn, pq Lpi, pq. Logo,
se LM pm, pq K então LM pm, pq Lpi, pq LN pn, pq ou LN pn, pq K;
p@p P LN pnqqpLN pn, pq LM pm, pq ou LM pm, pq Kq: como N ¨ CI então
p@p P LN pnqqpLN pn, pq ¤ Lpi, pqq, ou seja, se LN pn, pq K então LN pn, pq
Lpi, pq. Da mesma maneira, como M ¨ CI então p@p P LM pmqqpLM pm, pq ¤
Lpi, pqq, ou seja, se LM pm, pq K então LM pm, pq Lpi, pq. Logo, se
LN pn, pq K então LN pn, pq Lpi, pq LM pm, pq ou LM pm, pq K;
p@l, m1qppm, a, m1q P RM , então existe pn, a, n1q P RN com pm1, n1q P CM N q:
como M ¨ CI, Para toda ppm, a, m1 q P RM existe pi, a, i1 q P R com pm1 , i1 q P
<M e, como N ¨ CI, para toda pi, a, i1 q P R existe pn, a, n1 q P RN com
pn1, i1q P RM N , ou seja, para toda pm, a, m1q P RM existe pn, a, n1q P RN e pela
definição de <M , <N , pm1 , n1 q P CM N ; e
p@l, n1qppn, a, n1q P RN , então existe pm, a, m1q P RM com pm1, n1q P CM N q:
como N ¨ CI, Para toda ppn, a, n1 q P RN existe pi, a, i1 q P R com pn1 , i1 q P <N
e, como M ¨ CI, para toda pi, a, i1 q P R existe pm, a, m1 q P RM com pm1 , i1 q P
e pela definição
<M , ou seja, para toda pn, a, n1 q P RN existe pm, a, m1 q P RM
de <M , <N , pm1 , n1 q P CM N .
Logo M e N são consistentes entre si se, e somente se, existir uma relação de consistência
CM N entre M e N .
Proposição 5.3.2 (O operador de conjunção é associativo) Sejam M pAPM , ΣM ,

, L q e N pAP , Σ , S , s , R , R , L q dois KMTS consistentes
entre si, então M ^ N N ^ M .
N N
Demonstração. Sejam M ^ N A pAPA , ΣA , SA , sA0 , RA , RA , L q e N ^ M B

A
pAPB , ΣB , SB , sB0, RB , RB , LB q. Para provar que A B, é preciso provar que A ¨ B e
que B ¨ A:
A ¨ B : Seja a relação < tpa, bq | a pm, nq e b pn, mq com m P SM e n P SN u. Como

A e B são consistentes então sA0 pm0 , n0 q e sB0 pn0 , m0 q, ou seja, psA0 , sB0 q P <.
Vamos mostrar que < é uma relação de refinamento pois, para todo pa, bq P < vale:
(a) LA paq ¤ LB pbq: pela definição de função rotuladora da conjunção (Definição

5.3.3) LA pm, nq LB pn, mq, o que implica em LA paq ¤ LB pbq.
(b) se pa, t, a1 q P RA então existe b1 tal que pb, t, b1 q P RB com pa1 , b1 q P < com t P ΣA
e t P ΣB : pelas regras das transições do operador de conjunção, o estado a1 só
pode ter a seguinte forma (m’, n’), isto é, pm, t, m1 q P RM e pn, t, n1 q P R ou
pm, t, m1q P RM e pn, t, n1q P RN . Para quaisquer uma das combinações, existe
N
uma transição pb, t, b1 q P RB tal que b1 pn1 , m1 q. Assim, para toda transição
pa, t, a1q P RA sempre existirá uma transição pb, t, b1q equivalente em RB e, pela
definição de <, pa1 , b1 q P <;
e t P ΣB : pelas regras das transições no operador de conjunção, o estado
A
e pn, t, n1 q P R . Assim, pela regra (1)

b1 pn1 , m1 q, isto é, pm, t, m1 q P RM
usada para gerar o modelo A, pa, t, a1 q P RA tal que a’N = (m’, n’). Assim, para
toda transição pb, t, b1 q P RB sempre existirá uma transição pa, t, a1 q P R e,
pela definição de <, pa1 , b1 q P <.
A
B ¨A : A prova deste item segue de maneira análoga a prova acima e por isto não será
apresentada.
Assim, como A ¨ B e B ¨ A temos que A B, isto é, M ^ N N ^ M .

Proposição 5.3.3 (O operador de conjunção é comutativo) Sejam M pAPM , ΣM ,
, L q, N pAP , Σ , S , s , R , R , L q e P pAP , Σ , S , s , R ,
SM , sM 0 , RM , RM M N N N N0 N P P P P0
RP , LP q tres KMTS consistentes entre si, então pM ^ N q ^ P M ^ pN ^ P q.
N N P
Demonstração. Sejam M , N e P três KMTS consistentes entre si, para mostrar que
pM ^ N q ^ P = M ^ pN ^ P q devemos mostrar que pM ^ N q ^ P ¨ M ^ pN ^ P q
e M ^ pN ^ P q ¨ pM ^ N q ^ P . Vamos chamar pM ^ N q ^ P A ppAPA , ΣA ,
, L q e M ^ pN ^ P q B pAP , Σ , S , R , R , L q.
SA , RA , RA A B B B B B B
A ¨ B: Seja a relação < tpa, bq | a ppm, nq, pq e b pm, pn, pqq e m P SM , n P SN

e p P SP u. Como A e B são consistentes entre si então sA0 ppm0 , n0 q, p0 q e
sB0 pm0 , pn0 , p0 qq, ou seja, psA0 , sB0 q P <. Vamos mostrar que < é uma relação
de refinamento pois, para todo pa, bq P < vale:
(a) LA paq ¤ LB pbq: pela definição de função rotuladora (Definição 5.3.3) LA pppm, nq,
pq, q q LB ppm, pn, pqq, q q, o que implica em LA paq ¤ LB pbq.
(b) se pa, t, a1 q P RA então existe b1 tal que pb, t, b1 q P RB e pa1 , b1 q P < com
t P ΣA e t P ΣB : pelas regras de transições do operador de conjunção, o
estado a1 ppm1 , n1 q, p1 q então ppm, nq, t, pm1 , n1 qq P RM ^N e pp, t, p1 q P RP
ou ppm, nq, t, pm1 , n1 qq P RM
^N e pp, t, p q P RP . Para quaisquer uma destas
1
combinações, pelas regras de transições do operador de conjunção, sempre
existirá pb, t, b1 q P SB tal que b’ = (m’, (n’, p’)). Assim sempre existirá uma
transição equivalente em RB e, pela definição de <, pa1 , b1 q P <.
com
e t P ΣB : pela regra (1), o estado b1 pm1 , pn1 , p1 qq, isto é, px, t, x1 q P RX
A
X = tM, N, P u. Assim, pela regra (1), pa, t, a1 q P RA tal que a’ = (m, (n’,
p’)). Assim, para toda transição pb, t, b1 q P RB , sempre existirá uma transição
pa, t, a1q P RA e, pela definição de <, pa1, b1q P <.
B ¨ A: A prova deste item segue de maneira análoga à prova acima e por isto não será
apresentada.
Assim, como A ¨ B e B ¨ A temos que A B, isto é, pM ^ N q^ P M ^pN ^ P q.

Proposição 5.3.4 Sejam M pAPM , ΣM , SM , sM 0 , RM , RM , L q, e N pAP , Σ ,
M N N
, L q. M ^ N é definido se e somente se existe um KMTS X tal que
M ¨X eN ¨X
Demonstração.
(Ñ) Seja M ^ N pAPM ^N , ΣM ^N , SM ^N , sM 0^N 0 , RM ^N , RM ,L

^N M ^N q definido, de-
vemos provar que M ¨ M ^ N e N ¨ M ^ N . Vamos mostrar que M ¨ M ^ N
e o caso N ¨ M ^ N segue de modo análogo. Seja a relação < tpm, pm, nqq |
m P SM e n P SN u, tal que M ¨ M ^ N . < é uma relação de refinamento, pois por
definição o par pm0 , pm0 , n0 qq P < e, para todo por pm, nq P < vale:
(a) LM pmq ¤ LM ^N ppm, nqq: pela definição de função rotuladora (Definição 5.3.3)
LM pm, pq LM ^N ppm, nq, pq, o que implica em LM pmq ¤ LM ^N ppm, nqq;
(b) para toda t pm, a, m1 q P RM existe ppm, nq, a, pm1 , n1 qq P RM ^N com pm1 ,
pm1, n1qq P <: como M e N são consistentes, para toda uma transição t
pm, a, m1q P RM existe pn, a, n1q P RN . Assim, pelas regras de transições do
operador de conjunção, para toda transição t existe t1 ppm, nq, a, pm1 , n1 qq P
RM ^N ;

(c) para toda t ppm, nq, a, pm1 , n1 qq P RM
^N existe pm,a, m q P RM com pm ,
1 1
pm , n qq P <: pela regra (1) se ppm, nq, a, pm , n qq P RM ^N então pm, a, m q P
1 1 1 1 1
.
RM
Como o mesmo vale para N, isto é, N ¨ M ^ N , existe X M ^ N tal que M ¨ X

e N ¨ X. Observe que para qualquer modelo Y tal que M ^ N ¨ Y temos que
M ¨ Y e N ¨ Y (transitividade da relação de refinamento).
, L q, <
(Ð) Seja X pAPX , ΣX , SX , sX0 , RX , RX X M,X a relação de refinamento entre
M e X e <N,X a relação de refinamento entre N e X. É possı́vel criar uma relação
CM,N tpm, nq | pm, xq P <M,X e pn, xq P <N,X u. Vamos provar que CM,N é uma
relação de consistência:
(a) p@p P LM pmqqpLM pm, pq LN pn, pq ou LN pn, pq Kq: sejam (m, x) e (n, x)
pares de <M,X e <N,X , respectivamente. LM pmq ¤ LX pxq e LN pnq ¤ LX pxq,
isto é, para todo p P LX pxq, LM pm, pq LN pn, pq LX pxq ou LN pn, pq K
ou LM pm, pq K. Assim, para todol p P LM pmq, LM pm, pq LN pn, pq
LX px, pq ou LN pn, pq K;
(b) p@p P LpnqqpLN pn, pq LM pm, pqouLM pm, pq Kq: a prova deste item segue
análoga a prova do item acima;
(c) p@l, m1qppm, a, m1q P RM , então existe pn, a, n1q P RN com pm1, n1q P C q: como
M ¨ X então para todo t pm, a, m1 q P RM existe um t1 px, ax1 q P RX , e
como N ¨ X então para todo t px, a, x1 q P RX existe um t1 pn, an1 q P R ,
isto é, para todo t pm, a, m1 q P RM existe um t1 pn, an1 q P RN ; N
(d) p@l, n1qppn, a, n1q P RN , então existe pm, a, m1q P RM com pm1, n1q P C q: a prova
deste item segue análoga a prova do item acima.
Como CM,N é uma relação de consistência, pela Proposição 5.3.2, M e N são consis-
tentes entre si e por isto M ^ N é definido.

KMTS para Representação de Comportamento Parcial em Desenvolvimento de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

KMTS para Representação de Comportamento Parcial em Desenvolvimento de Software

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDADE FEDERAL DA BAHIA

Sistemas de Transições Modais de Kripke para Representação de

Efraim Zalmoxis de Almeida Machado

Programa de Pós-Graduação em Ciência da Computação

SISTEMAS DE TRANSIÇÕES MODAIS DE KRIPKE PARA

Esta Dissertação de Mestrado foi

Orientadora: Aline Maria Santos Andrade

Machado, Efraim Zalmoxis de Almeida.

Orientadora: Prof. Dr. Aline Maria Santos Andrade.

1. KMTS. 2. Informação Parcial. 3. Desenvolvimento de Software. 4.

EFRAIM ZALMOXIS DE ALMEIDA MACHADO

SISTEMAS DE TRANSIÇÕES MODAIS DE

Esta Dissertação de Mestrado foi julgada

Salvador, 30 de Novembro de 2016

Profa. Dra. Aline Maria Santos Andrade

Prof. Dr. Adolfo Almeida Duran

Prof. Dr. Alexandre Cabral Mota

O projeto de software, na abordagem iterativa e incremental, lida com novos requisitos

Palavras-chave: KMTS; Informação Parcial; Desenvolvimento de Software; Con-

Keywords: KMTS; Partial Information; Software Development; Conjunction; Parallel

Capı́tulo 2—Modelos Comportamentais 7

Capı́tulo 3—Trabalhos Relacionados 21

Capı́tulo 4—Sı́ntese de Modelos KMTS a partir de Cenários 29

Capı́tulo 5—Relações e Operações para Modelos KMTS 49

Capı́tulo 6—Jogo do Refinamento 69

Capı́tulo 7—Reparo de Refinamento 91

Capı́tulo 8—Conclusões 123

Apêndice A—Tópicos de Engenharia de Software 135

A.2 Diagrama de Sequência . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

Apêndice B—Definições Relacionadas 143

Apêndice C—Provas do capı́tulo 6 147

1.1 Visão de alto-nı́vel de um processo de desenvolvimento que utiliza KMTS

2.1 Dois sistemas de transição onde N simula o comportamento de M (BAIER;

4.1 Diagrama de sequência de solicitação e acesso do componente Recurso pelo

5.1 KMTSs representando os possı́veis comportamentos da câmera. Em (A)

5.2 Regras das transições do operador de composição paralela . . . . . . . . 58

6.1 Dois KMTS M, N, onde vale M ¨ N . . . . . . . . . . . . . . . . . . . . . 71

7.1 Gráfico do tempo de execução (em milissegundos) do Algoritmo 10 em

7.12 Estrutura dos testes realizados por grupo . . . . . . . . . . . . . . . . . . 118

A.1 Elementos do Diagrama de Sequência da UML 2.0. Adaptado de Lund e

B.1 Dois sistemas de transição bissimilares representando uma máquina de

6.1 Variáveis de acordo com o grupo de teste . . . . . . . . . . . . . . . . . . 84

7.1 Variáveis de acordo com o grupo de teste . . . . . . . . . . . . . . . . . . 117

precipitadas que acarretam em projetos incorretos. Erros no projeto implicam em refazer

de interação se limitam, muitas vezes, a diagramas de sequência (UCHITEL; KRAMER;

1.1 ESCOPO DO TRABALHO E CONTRIBUIÇÕES

No processo de desenvolvimento iterativo de software, surge a necessidade de métodos e

às atividades de construção, análise e reparo de modelos.

 Caracterizamos o conceito de refinamento como um jogo entre dois jogadores e um

 Definimos um operador de composição paralela juntamente com o conceito de com-

 Definimos um operador de conjunção para KMTS de forma a permitir a união dos

Em relação ao reparo de modelos:

 Definimos e estudamos o problema do reparo de refinamento, sua complexidade e

 Definimos algoritmos para o problema do reparo de refinamento de um modelo em

 Implementamos e validamos os algoritmos propostos para o problema do reparo do

1.2 ORGANIZAÇÃO DA DISSERTAÇÃO

2.1 MODELOS DE SOFTWARE

as interações entre o ambiente e o sistema ou entre os componentes do sistema, ou uma

2.2 SISTEMAS DE TRANSIÇÃO E ESPECIFICAÇÕES MODAIS

Definição 2.2.1 (Sistema de Transição (BAIER; KATOEN; LARSEN, 2008)). Um sis-

Sistemas de transição são úteis para a análise e verificação formal de propriedades

R  tps0 , t0 q, ps1 , t1 q, ps2 , t1 q, ps3 , t2 q, ps4 , t3 qu

Existem situações em que M simula N e N simula M simultaneamente através de

Caracterizamos o conceito de refinamento como um jogo entre dois jogadores e um

Definimos um operador de composição paralela juntamente com o conceito de com-

Definimos um operador de conjunção para KMTS de forma a permitir a união dos

Definimos e estudamos o problema do reparo de refinamento, sua complexidade e

Definimos algoritmos para o problema do reparo de refinamento de um modelo em

Implementamos e validamos os algoritmos propostos para o problema do reparo do

R tps0 , t0 q, ps1 , t1 q, ps2 , t1 q, ps3 , t2 q, ps4 , t3 qu

Figura 2.9 Duas especificações mistas M e N com I pM q I pN q, mas não vale M ¨N

Definição 2.3.7 (Consistência (RACLET et al., 2011)). Seja M pSM , RM , RM q e

Etapa I - Extrai-se das restrições expressas em OCL e em nı́vel de sistema as

Etapa II - Um MTS inicial, sem nenhum comportamento obrigatório, é gerado para

Etapa IV - O diagrama de sequência é utilizado para definir as transições must. As

Componente do sistema a ser representado: é o componente presente em alguma

solDisp: variável utilizada para controlar se o gerenciador de recurso está verificando

verDisp:variável utilizada para controlar se existe uma verificação de disponibilidade

recDisp: variável utilizada para controlar se o recurso está disponı́vel ou não; e

aguardaRec:variável utilizada para controlar se existe um módulo aguardando o