Escolar Documentos
Profissional Documentos
Cultura Documentos
DISSERTAÇÃO DE MESTRADO
Salvador
30 de novembro de 2016
EFRAIM ZALMOXIS DE ALMEIDA MACHADO
Salvador
30 de novembro de 2016
Sistema de Bibliotecas - UFBA
CDD – XXX.XX
CDU – XXX.XX.XXX
TERMO DE APROVAÇÃO
Agradeço à minha orientadora, Profª Dra. Aline Andrade, pela paciência em ter me
ouvido, pela dedicação em ter me ensinado e por todo incentivo dado. Esta atenção foi
muito importante para que eu concluı́sse minha dissertação e por isto, serei eternamente
grato.
Agradeço também aos amigos, familiares e todos aqueles que me apoiaram e me
ouviram durante este perı́odo, com especial importância às discussões com meu amigo
Jandson e ao professor Sandro Andrade, que contribuı́ram para esta pesquisa.
vii
Andar sobre as águas e fazer software a partir de uma especificação é
simples se ambas estiverem congeladas.
—EDWARD V BERARD
RESUMO
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.
xiii
SUMÁRIO
Capı́tulo 1—Introdução 1
1.1 Escopo do Trabalho e Contribuições . . . . . . . . . . . . . . . . . . . . . 4
1.2 Organização da Dissertação . . . . . . . . . . . . . . . . . . . . . . . . . 6
xv
xvi SUMÁRIO
3.1 Visão geral do algoritmo de sı́ntese de MTS proposto por Krka et al. (2009)
(KRKA et al., 2009) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
xix
xx LISTA DE FIGURAS
xxiii
Capı́tulo
1
INTRODUÇÃO
Nos dias atuais, em um ambiente globalizado, onde mudanç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 são
construı́dos em meio a uma série de dúvidas decorrentes do conhecimento incompleto
da aplicação tanto do cliente quanto dos seus projetistas. Mudanças rápidas tornam
impossı́vel obter um conjunto estável de requisitos, pois, geralmente, o conhecimento
do usuário sobre suas reais necessidades e, consequentemente, como o sistema deve se
comportar é inicialmente parcial e só vai se complementando no decorrer do ciclo de
desenvolvimento do software. Desta forma, especificar todo o sistema para só depois
implementá-lo pode durar um prazo maior que o acordado e o software não satisfazer as
necessidades da aplicação.
Para contornar este problema, o desenvolvimento iterativo se baseia na ideia de dis-
ponibilizar uma versão inicial do software para o usuário ir refinando-a, através de novos
requisitos, até obter-se o software desejado (SOMMERVILLE, 2011). De maneira geral,
no desenvolvimento iterativo, há uma intercalação cı́clica das quatro etapas de desenvol-
vimento de software: análise de requisitos, projeto, implementação e teste. Esta inter-
calaçã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,
à medida que novos requisitos surgem. Outras abordagens complementares ao desenvol-
vimento iterativo focam na construção rápida de um software, como o desenvolvimento
incremental (PRESSMAN, 2005), no qual o software é desenvolvido em incrementos, o
que torna a tarefa de entender os requisitos do sistema e propor uma solução ainda mais
desafiadora.
Neste contexto, uma das etapas mais complexas no processo de desenvolvimento é
a construção do projeto, devido às recorrentes mudanças que implicam em constante
adaptação de uma solução. Em geral, os projetos de software são realizados de modo
que o projetista atue com base no comportamento já definido, que em geral, não reflete
completamente os requisitos. A imaturidade em relação ao conhecimento do problema
e a necessidade de definir uma solução completa podem ter como consequência decisões
1
2 INTRODUÇÃO
para modelos KMTS através de regras, modela este jogo como um grafo e apresenta um
algoritmo para computar a existência de uma relação de refinamento modal forte a partir
deste grafo (até onde sabemos nenhum outra pesquisa definiu tal algoritmo). A nossa
solução possui complexidade polinomial, o que garante uma performance comparável aos
principais algoritmos de verificação de refinamento encontrados na literatura.
Quando não há uma relação de refinamento entre a especificação e o modelo, o último
deve ser reparado para garantir que ele preserve as propriedades definidas na especificação.
Todavia, nenhum dos trabalhos encontrados focam na alteração do modelo para garantir
uma relação de refinamento com a especificação. Automatizar esta tarefa não é um
problema trivial pois é necessário detectar os motivos que fazem com que não haja uma
relação de refinamento. Chamamos esta atividade de reparo de modelos. O presente
trabalho contribui com a automatização desta atividade através de um algoritmo de
reparo de refinamento, que utiliza o jogo de refinamento para extrair os motivos que
fazem com que não haja uma relação de refinamento entre o modelo e a sua especificação.
A extração dos motivos a partir do jogo permite que o modelo em questão seja reparado
automaticamente.
Figura 1.1 Visão de alto-nı́vel de um processo de desenvolvimento que utiliza KMTS suportado
por métodos formais
2
MODELOS COMPORTAMENTAIS
Muitos processos de desenvolvimento de software são definidos com base em quatro eta-
pas: análise de requisitos, projeto, desenvolvimento e teste (SOMMERVILLE, 2011). In-
dependente do processo escolhido, é comum haver dúvidas a respeito do comportamento
pretendido pelo sistema principalmente na etapa de análise de requisitos, pois os usuários
do sistema não têm conhecimento completo do mesmo ou não conhecem suficientemente o
domı́nio do sistema para orientar a equipe de desenvolvimento. Estas dúvidas se refletem
nas etapas seguintes, impactando a etapa de projeto, pois algumas decisões a respeito do
comportamento do software só podem ser tomadas quando se conhece o suficiente sobre
a necessidade do cliente. Além disso, diversas abordagens focam na construção rápida
de um software, como o desenvolvimento incremental e iterativo (PRESSMAN, 2005), no
qual o software é desenvolvido por partes e guiado por iterações com o cliente/usuário,
o que torna a tarefa de entender os requisitos do sistema e propor uma solução ainda
mais desafiador (o Apêndice A detalha mellhor esta abordagem). Outras abordagens,
como a engenharia de software baseada em componentes também tem como um dos seus
objetivos a construção rápida de um software através do reuso de partes já 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.
7
8 MODELOS COMPORTAMENTAIS
Esta definição é genérica e, muitas vezes, alguns elementos da definição não são utili-
zados, como por exemplo o conjunto de proposições ou as ações que rotulam as transições.
A partir deste ponto, omitiremos o conjunto de estados iniciais e assumiremos, para fins
de simplificação, que cada sistema de transição possui um único estado inicial, ao qual
chamaremos de s0 sendo S o conjunto de estados do modelo em questão.
2.2 SISTEMAS DE TRANSIÇÃO E ESPECIFICAÇÕES MODAIS 9
2.2.1 Simulação
A simulação é uma relação binária entre sistemas de transiçã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 transição T SN simula um
sistema de transição T SM se todo comportamento que T SM descreve o modelo T SN
também descreve. É importante observar que o modelo T SN pode descrever também
outros comportamentos que não são descritos em T SM .
Definição 2.2.2 (Simulação (BAIER; KATOEN; LARSEN, 2008)). Seja T SM pSM , Σ,
RM , APM , LM q e T SN pSN , Σ, RN , APN , LN q dois sistemas de transiçã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 relação < SM SN tal que ps0 , t0 q P < e para todo
ps, tq P < vale:
1. Se ps, a, s1 q P RM entã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 relação de simulação: suponha dois sistemas
de transição que descrevem o comportamento de uma máquina de vender refrigerantes e
bebidas alcóolicas. Existem três proposições que indicam qual a ação que o usuário deve
fazer no estado em que o sistema se encontra: pagar - indica que o usuário deve pagar;
bebida - indica que o usuário deve escolher uma bebida alcóolica; e soda - indica que
o usuário deve escolher um refrigerante, considerando que após realizar o pagamento, o
usuário deve informar se deseja uma bebida alcóolica ou um refrigerante. Dois sistemas
de transição que descrevem este comportamento são apresentados na Figura 2.1 e, para
simplificar este exemplo, as ações foram ocultadas.
É possı́vel notar que nos modelos mostrados na Figura 2.1, o modelo N simula o
comportamento do modelo M através da seguinte relação:
Todavia, o modelo N não é simulado por M porque não existe nenhum estado em
M que “imite” o comportamento do estado t1 pois, a partir de t1 é possı́vel alcançar um
estado onde vale bebida e um estado que vale soda.
10 MODELOS COMPORTAMENTAIS
Figura 2.1 Dois sistemas de transição onde N simula o comportamento de M (BAIER; KA-
TOEN; LARSEN, 2008)
Definição 2.2.3 (Especificação Mista (ANTONIK et al., 2008)). Seja Σ um conjunto não
vazio de ações e AP um conjunto não vazio de proposições atômicas, uma especificação
mista M é a tupla pS, R , R , L , L q tal que pS, R , L q e pS, R , L q são sistemas de
transição. Em particular, R e R são subconjuntos de S Σ S, e L , L são membros
de S Ñ 2AP .
2.2.3 KMTS
Existem diversos modelos para expressar especificações parciais na literatura que são
apresentados no capı́tulo 3. Para o presente trabalho dois modelos se destacam: o Sis-
tema de Transição Modal (Modal Transition System - MTS) (Seção B.2 e o Sistema de
Transição Modal de Kripke (Kripke Modal Transistion System - KMTS).
Definição 2.2.5 (KMTS (HUTH; JAGADEESAN; SCHMIDT, 2001a)). Seja AP um
conjunto de proposições atômicas e Lit AP Yt p | p P AP u o conjunto de literais sobre
AP . Um Sistema de Transições Modais de Kripke é uma tupla M pAP, S, R , R , Lq,
onde S é um conjunto finito de estados, R S S e R S S são relações de
transição tal que R R , e L : S Ñ 2Lit é uma funçã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.4 Exemplo de refinamento. A casa mais detalhada é um refinamento da outra casa.
Adaptado de Fairbanks (2010)
Figura 2.5 Exemplo de refinamento com semântica fechada (A) e semântica aberta (B). A
casa mais detalhada é um refinamento da outra casa. Adaptado de Fairbanks (2010)
3. LM LN ;
4. L
N LM .
2.3 TEORIA DAS ESPECIFICAÇÕES PARCIAIS 15
Figura 2.7 Dois modelos parciais que não possuem uma relação de refinamento modal
A relação de refinamento modal pode ser utilizada entre especificações parciais e entre
implementações. Quando usada para comparar apenas implementações, vale notar que a
relação coincide com a definição de bissimulação B.1.
Como um modelo parcial pode ser constituı́do de diversas indeterminações, é possı́vel
que ele possa originar diversas implementações, e por isto, definimos o conjunto de im-
plementações do modelo parcial M como I pM q tI } M ¨ I u.
16 MODELOS COMPORTAMENTAIS
Existem casos em que um modelo parcial não possui implementações. Dizemos que
uma especificação parcial é consistente se e somente se ela possui pelo menos uma imple-
mentação.
Definição 2.3.3 (Consistência em especificação parcial (ANTONIK et al., 2008)). Uma
especificação parcial M é consistente sse I pM q é não-vazio.
A Figura 2.8 mostra uma especificação mista que não possui implementações possı́veis.
As setas tracejadas representam as transições possı́veis enquanto que as setas sólidas
representam as transições obrigatórias. Antonik et al. (2008) mostram que o problema de
determinar se uma especificação mista é consistente tem seu limite inferior localizado na
classes de problemas PSPACE-hard enquanto que o limite superior está em EXPTIME.
Toda especificação modal é consistente porque toda transição obrigatória é uma transição
possı́vel (sempre existe uma implementação possı́vel, escolhendo o modelo formado por
todo comportamento must) e por isto apenas uma seta sólida é utilizada para representar
as transições obrigatórias, diferentemente das especificações mistas.
et al. (2008) mostram que o limite inferior para cálculo do refinamento completo para
especificações parciais encontra-se na classe de problemas PSPACE-hard enquanto seu
limite superior na classe EXPTIME.
Existem na literatura, variações do refinamento modal, que podem ser vistas na Seçã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 é o conceito base
para todas as outras variações de refinamento.
Antonik et al. (2008) definem o refinamento comum como um dos principais problemas
de especificações parciais e mostram que seu limite inferior em termos de complexidade
é PSPACE-hard (para especificações mistas e modais) e o limite superior ainda não é
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 é, o comportamento obrigatório e possı́vel
dos dois deve ser compatı́vel. Todavia, em alguns casos não existe refinamento comum
entre dois componentes. Quando existe refinamento comum (baseado no conceito de
refinamento modal forte) entre dois componentes dizemos que eles são consistentes.
2.3 TEORIA DAS ESPECIFICAÇÕES PARCIAIS 19
A consistência também pode ser definida como uma relação sobre especificações mo-
dais (RACLET et al., 2011).
Considerando que a relação de refinamento define uma pré-ordem no espaç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 conjunção, busca-se o refinamento
comum mais próximo dos dois modelos de entrada, isto é, o refinamento comum com
mais indefinições. Esta restrição é justificada porque busca-se o modelo que represente
os outros modelos, mas que perca o mı́nimo possı́vel de indefinições. Caso os modelos se-
jam consistentes, chamamos o conjunto formado por todos os refinamentos comuns mais
próximos dos modelos de entrada de Refinamento Comum Minimal (RCM) (vale lembrar
que como a relação de refinamento é uma pré-ordem, estes elementos do RCM não são
comparáveis entre si). Alguns trabalhos chamam a operação de conjunção de merge.
Caso exista apenas um menor refinamento comum, chamamos este modelo de Menor
Refinamento Comum (MRC). O MRC é o refinamento comum mais abstrato (ou com
mais indefinições) e o RCM é um conjunto formado pelos refinamentos comuns mais
abstratos e não comparáveis entre si pela relaçã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 nó do grafo representa uma
especificação parcial e a seta representa a relação de refinamento.
Segundo (RACLET et al., 2011), o operador de conjunção deve ser associativo e co-
mutativo para garantir que a ordem de execução da conjunção não influencie o resultado
final. Além disto, as seguintes propriedades devem valer para que o operador de con-
junção (representado por ^) retorne de fato a conjunção entre os dois modelos (e não o
refinamento comum):
20 MODELOS COMPORTAMENTAIS
3
TRABALHOS RELACIONADOS
Existem na literatura diversos trabalhos que objetivam prover suporte à análise de mo-
delos comportamentais com informações parciais no contexto da engenharia de software.
Nesta seção, listamos as principais pesquisas relacionadas ao presente trabalho, desta-
cando as influências e as diferenças entre elas e o presente trabalho.
21
22 TRABALHOS RELACIONADOS
2. One Selecting MTS (1-MTS): uma variante do DMTS chamada One-Selecting MTS
é proposta em (FECHER; SCHMIDT, 2008). Esta extensão interpreta as hiper-
transições como transições exclusivas (XOR), isto é, na implementação de um One-
Selecting MTS cada hipertransição se tornará uma transição, ao contrário do DMTS
onde cada hipertransição pode se tornar mais de uma transição (OR);
3. Parametric Modal Transition System (PMTS): Beneš et al. (2011) propõem uma
extensão do MTS chamada PMTS, juntamente com uma noção geral do seu refina-
mento. Segundo os autores, o PMTS resolvem limitaçõ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) propõem a utilização
do MIO. O MIO é uma junção do MTS e do Input Output Automata (LYNCH;
TUTTLE, 1989) que permite não só especificar conhecimento parcial como também
modalidades nas operações: transições de saı́da, entrada e ações internas. O obje-
tivo do MIO é modelar interfaces de componentes, representando suas entradas e
saı́das;
5. MTS com pesos nas transições: Juhl, Larsen et al. (2012) estendem o MTS, adicio-
nando intervalo de pesos (uma sequência de valores) nas transições, descrevendo as
possibilidades de valores que podem ser usadas nas suas implementações, de forma
que na implementação, cada transição terá apenas um valor/peso associado;
6. Kripke Modal Transition System: Huth, Jagadeesan e Schmidt (2001a) estendem
modelos MTS com a possibilidade de expressar indefiniçõ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 também definem para seus modelos a operação de refi-
namento (forte ou fraco), além das operações de composição paralela e conjunção. Alguns
trabalhos ainda definem a operação de disjunção. Um resultado importante em relação
ao refinamento fraco é apresentado em (FISCHBEIN; BRABERMAN; UCHITEL, 2009),
em que autores mostram que o refinamento fraco traz resultados contrários ao senso de
refinamento e propõem uma relação chamada de refinamento de alfabeto ramificado (jun-
tamente com a semântica ramificada). Este refinamento preserva a estrutura ramificada
(como o refinamento modal forte) e permite ações observáveis e não-observáveis. Todavia,
autores mostram que não é possı́vel definir a relação de refinamento de alfabeto ramifi-
cado entre quaisquer duas especificações parciais, mas somente entre uma especificação
parcial e uma implementação e, por isto, o argumento dos autores é utilizar a ideia de
refinamento completo entre especificações parciais e utilizar o conceito de refinamento de
alfabeto ramificado entre especificações e implementações.
Outros trabalhos buscam estudar melhor os modelos parciais já propostos, demons-
trando algumas propriedades, como em (WEI; GURFINKEL; CHECHIK, ) que mostra a
equivalência entre KMTS, Especificações Mistas e o KMTS Generalizado (uma extensão
do KMTS com hipertransições, similar ao DMTS).
3.1 MODELOS COMPORTAMENTAIS PARCIAIS 23
Huth, Jagadeesan e Schmidt (2001a) propõem os modelos KMTS a partir de modelos LTS
e define conceitos de simulaçã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 explosão de estados na verificação de modelos através o
conceito de abstração de modelos. Os conceitos de abstração e refinamento são conceitos
duais e são utilizados no presente trabalho.
A semântica de 3-valores (verdade, falso, indefinido) sobre modelos KMTS usada no
presente trabalho segue a semântica definida em (SHOHAM; GRUMBERG, 2007).
Apesar de, a princı́pio, a ideia de abstração e de refinamento seguirem em sentidos
opostos, a semântica utilizada na nossa abordagem é a mesma pois, a relação de abstração
e a relação de refinamento (BAIER; KATOEN; LARSEN, 2008) possuem a mesma de-
finição (ambas são baseadas na ideia de abstração (SHOHAM; GRUMBERG, 2007)). A
única diferença entre os conceitos é o sentido da conversão: a abstraçã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
informação parcial explicitamente. Na abordagem proposta pelos autores, um KMTS
24 TRABALHOS RELACIONADOS
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 fó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 é indefinida no KMTS, o reparo consiste na aplicaçã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 operação possı́vel ao longo do desenvolvimento de
software. Esta operação de filtrar os modelos coincide, nestes casos, com a operação de
refinamento completo.
É importante ressaltar que as semânticas dadas por Shoham e Grumberg (2007),
chamada aqui de semântica de abstração, e Guerra, Andrade e Wassermann (2013a),
chamada aqui de semântica de conjuntos, podem ser utilizadas numa mesma solução
porque possuem uma certa compatibilidade. É possı́vel observar que os modelos que a
semântica de conjuntos considera como possı́veis refinamentos de um KMTS M também
são considerados como refinamento na semântica de abstração. Todavia, o refinamento da
semântica de conjuntos é restritivo demais, significando que há uma perda considerável de
modelos que poderiam ser refinamento, mas não são considerados. De qualquer maneira, o
presente trabalho propõe a utilização da revisão de modelos em alguns pontos do processo
de desenvolvimento.
Etapa III - Os diagramas de sequência são analisados para inferir a valoração das
variáveis e detectar inconsistência nas mesmas;
Figura 3.1 Visão geral do algoritmo de sı́ntese de MTS proposto por Krka et al. (2009) (KRKA
et al., 2009)
Ghezzi et al. (2013) abordam modelos parciais no desenvolvimento ágil e utilizam com-
posições de má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 presença de conhecimento incompleto e o refinamento
destes modelos para representar a evolução do comportamento dos sistemas. Nestes tra-
balhos, os autores também propõem a utilização da operação de conjunção (merge) de
modelos MTS para representar a evolução comportamental do sistema com a inclusão de
novos requisitos. Nesta abordagem os modelos gerados incialmente sã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.
É demonstrada por Brunet, Chechik e Uchitel (2006b) a possibilidade de realização da
conjunção de modelos MTS automaticamente através de um algoritmo. Brunet (2006)
mostra que o operador de conjunção utilizado possui falhas quando os dois modelos
permitem comportamentos contraditórios, mostrando que a consistência é uma condição
necessária. Quando o conceito de refinamento modal fraco é utilizado, a consistência não é
uma condição suficiente para que entre dois modelos exista um RCM ou MRC e propõem
um operador chamado cr para contornar esta limitação. Fischbein e Uchitel (2008)
mostram que o operador cr falha em alguns casos (modelos com não-determinismo) e
propõem um algoritmo que usa o operador cr de forma iterativa.
O presente trabalho se baseia no operador cr para definir o operador de conjunção,
apesar de usar apenas modelos determinı́stas. Mais uma vez, no operador de conjunção
3.3 ANÁLISE DE ESPECIFICAÇÕES PARCIAIS NO DESENVOLVIMENTO DE SOFTWARE 27
entre modelos KMTS a valoração das proposições nos estados tem que ser considerada
e, devido a isto, é possı́vel, durante a operação de conjunção, detectar problemas nos
modelos (valorações inconsistentes entre os estados) e inferir a valoração de proposições
indefinidas a partir da valoração de outros modelos. Estes dois aspectos serão detalhados
posteriormente.
Existem também trabalhos que utilizam outros modelos como utilizado por Raclet et
al. (2011), no qual os autores utilizam o MIO para análise e especificação de interfaces
para componentes reativos. Já Krka et al. (2014) e Krka e Medvidovic (2012) utilizam o
MIO para representar componentes de um sistema e suas interfaces.
É válido ressaltar que modelos KMTS são uma extensão de modelos MTS (HUTH;
JAGADEESAN; SCHMIDT, 2001a). Possivelmente, estes trabalhos que propõem ou
utilizam MTS e suas extensões podem ser mapeados para KMTS ou para extensões defi-
nidas de forma similar às definidas para o MTS. Assim, o estudo e utilização de modelos
KMTS no presente trabalho pode permitir sua aplicação nas mais diversas abordagens
que utilizam o MTS, expandindo-as através da possibilidade de expressar indefinições nos
estados.
4
SÍNTESE DE MODELOS KMTS A PARTIR DE
CENÁRIOS
O uso de modelos formais pode prover um suporte mais preciso para a verificação e
aná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 não é encontrada normalmente nas habilidades dos projetistas e de-
senvolvedores de software. Métodos automáticos ou semi-automáticos para a criação de
modelos formais pode incentivar o uso de métodos de verificação formal, trazendo uma
maior confiabilidade aos softwares desenvolvidos.
Neste capı́tulo apresentamos a definição de modelos KMTS com ações, que é utilizada
no presente trabalho e apresentamos uma adaptação do algoritmo de sı́ntese heurı́stica
de modelos MTS a partir de cenários apresentado em (KRKA et al., 2009) para modelos
KMTS. Esta adaptação modifica todas as etapas do algoritmo para funcionar com a
lógica de três valores sobre os valores das proposições e faz algumas modificações no
sentido de corrigir de problemas observados (e explicados posteriormente) e possibilitar
uma maior automatização desta tarefa. O algoritmo apresentado em (KRKA et al., 2009)
foi utilizado como referência porque apresenta uma sı́ntese de modelos parciais baseada
em artefatos comumente utilizados durante o processo de desenvolvimento de software.
A Seção 4.1 apresenta nossa definição de KMTS com ações. Esta definição é usada
ao longo deste trabalho. A Seção 4.2 apresenta o algoritmo de sı́ntese heurı́stica de mo-
delos KMTS, explicando como cada elemento do KMTS é definido através dos cenários
informados, que são representados como diagramas de sequência da UML anotados com
OCL. A Seção 4.3 apresenta uma descrição detalhada das etapas do algoritmo proposto.
A Seção 4.4 apresenta uma análise e validação do algoritmo proposto, demonstrando
sua terminação, correção e complexidade. Por fim, uma série de validações são reali-
zadas sobre uma implementação do algoritmo proposto e seus resultados e análises são
apresentadas.
31
32 SÍNTESE DE MODELOS KMTS A PARTIR DE CENÁRIOS
ps, a, s1q P R e s 99K s1 representa ps, a, s1q P R e para qualquer KMTS M tal que SM
a
definido a seguir. Uma regra OCL é composta por proposições OCL da forma vi ri
com ri P verdade, f also, indef inido que indicam condições sobre as variáveis do sistema,
onde vi é uma variável e ri sua respectiva valoração.
Definição 4.2.1 (Proposição OCL). Uma proposição OCL p é um par pv, rq com r P
tv, f, iu, onde v representa verdade, f falso e i indefinido, que é utilizada para expressar
uma informação a respeito das variáveis do sistema, onde v é uma variável e r sua
respectiva valoração.
Definição 4.2.2 (Regra OCL). Uma regra OCL r é uma fórmula ϕ p1 ^ p2 ^ ... ^ pn
onde cada pi com i 1, 2, ..., n é uma proposição OCL.
Regras OCL são utilizadas como pré e poscondições das mensagens do diagrama de
sequência. Uma mensagem, no diagrama de sequência, representa a troca de informação
entre dois componentes: (1) o componente de saı́da, que é quem envia a mensagem; e (2)
o componente de entrada, que é o componente que consome a mensagem. A mensagem
é composta pela ação (ou rótulo da mensagem), por duas regras OCL que representam
a precondição e a poscondição sobre variáveis do sistema antes e depois da troca de
mensagem e pelos componentes de saı́da e de entrada.
Definição 4.2.3 (Mensagem). Uma mensagem m é uma quı́ntupla pcs , a, ce , rpre , rpos q
onde ce e cs são os componentes de entrada e saı́da, respectivamente, a é a ação contida
na mensagem e rpre e rpos expressam as condições das variáveis do sistema antes e depois
da execução da ação a.
Definição 4.2.4 (Linha da vida). Uma linha da vida l é uma dupla pc, v q, onde c é um
componente e v rm0 , m1 , ...mn s é um vetor que representa as mensagens trocadas mi
com i 0, 1, ..., n (enviadas ou recebidas) por um componente.
34 SÍNTESE DE MODELOS KMTS A PARTIR DE CENÁRIOS
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 compõe o KMTS.
Para exemplificar estes passos, vamos assumir o exemplo do projeto de um dispositivo
eletrônico.
Este dispositivo é composto por diversos módulos, cada módulo é responsável por
um conjunto de funcionalidades e estes módulos accessam diversos sensores deste dispo-
sitivo. Para controlar o acesso aos dispositivos, existe um componente para garantir que
4.2 ALGORITMO PARA SÍNTESE DE KMTS 35
Figura 4.1 Diagrama de sequência de solicitação e acesso do componente Recurso pelo com-
ponente Módulo
um recurso não seja acessado simultaneamente por mais de um módulo. Assim, temos
três componentes: módulo, gerenciador de acesso e recurso (o dispositivo é formado por
diversos componentes do tipo módulo, um componente do tipo gerenciador de acesso e
diversos componentes do tipo recurso). Ainda não está claro para os projetistas se um
módulo pode acessar mais de um recurso simultaneamente. O funcionamento básico entre
estes três componentes é: o módulo requisita acesso ao gerenciador de recurso, que checa
se o recurso está em uso. Caso não esteja o acesso é liberado e o módulo acessa o recurso
diretamente. Caso contrário o gerenciador de recurso informa ao módulo que o recurso
está ocupado. Por fim, como só existe um gerenciador de recurso e ele tem capacidade
de processamento limitada, ele trata uma solicitação de recurso por vez.
A Figura 4.1 exibe um diagrama de sequência (anotado com regras OCL) que descreve
o cenário onde um módulo consegue acessar um determinado recurso. As regras OCL
estão descritas ao lado do diagrama de sequência.
A Figura 4.2 exibe um diagrama de sequência (anotado com regras OCL) que descreve
o caso onde um módulo não consegue acessar um determinado recurso e após o recurso
ser liberado por outro componente o módulo em questão é informado da disponibilidade
do recurso. As regras OCL estão descritas ao lado do diagrama de sequência.
A listagem a seguir contém a explicação de cada variável utilizada. As regras OCL
foram definidas de acordo com os requistos apresentados.
utilRec: variável utilizada para definir se um módulo já está utilizando um recurso
ou não;
solRec: variável utilizada para controlar se algum módulo está solicitando algum
recurso ao gerenciador de recurso;
Figura 4.2 Diagrama de sequência que representa um cenário onde o componente módulo
solicita acesso, mas não pode acessar um recurso
isto é, apenas uma parte da restrição é aplicável sobre o componente. Considerando que
não há especificação da interface de cada componente, o algoritmo define, de acordo com
os diagramas de sequência, quais são as mensagens trocadas pelos componentes, e para
cada componente, as mensagens que ele troca são classificadas como mensagens esperadas
ou mensagens recebidas.
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
Figura 4.3 Diagrama de sequência estendido antes (A) e depois da propagação (B) para o
componente Módulo baseado no diagrama de sequência da Figura 4.1
Algoritmo 2: propagaValoracaoDiagramaSequenciaAnotado
Data: Linha da vida l do componente c no diagrama de sequência anotado sda
Result: Linha da vida l com as valoraçõ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
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
apresentado. Esta função recebe dois parâmetros: um estado s e uma ação a. A ideia
desta função é modificar a valoração das proposições no estado s de forma que as pro-
posições do estado s e as proposições da poscondição possuam a mesma valoraçã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)
não possui esta recursão, e, não faz a análise correta para a adição das transições, pois ele
não checa se pode existir uma transição entre um estado já existente e um estado adicio-
nado. A recursão é utilizada para garantir que todas as combinações entre os estados (já
existentes e novos) seja avaliada para adicionar uma transição; e (ii) a existência de um
conjunto de estados iniciais em potencial calculado de forma automática, que representa
um avanço em relação ao algoritmo proposto em (KRKA et al., 2009), onde o usuário
deve informar o estado inicial.
O conjunto inicial de estados é definido de acordo com o valor das variáveis antes da
primeira mensagem ser trocada em cada linha da vida de um componente em questão
nos seus diagramas estendidos. Estes estados compõem os estados iniciais em potencial.
Diferente do defendido em (KRKA et al., 2009), acreditamos que isto não é um problema
do algoritmo visto que o conjunto de diagramas de sequência descreve os comportamen-
tos mais importantes de um componente e, consequentemente, o comportamento de um
componente ao ser inicializado é, sem dúvida, importante. No algoritmo definido por
(KRKA et al., 2009), o usuário deve definir um estado inicial. Caso o usuário defina
o estado errado, o modelo gerado não irá representar adequadamente os diagramas de
sequência. No algoritmo do presente trabalho, um grupo de estados iniciais em potencial
não significa dizer que, necessariamente, o estado inicial do KMTS está 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 usuário deve escolher qual o estado
inicial (o algoritmo pode apresentar os estados iniciais em potencial como uma possibili-
dade para o usuário). O algoritmo para detecção do estado inicial de cada diagrama de
sequência é apresentado na etapa IV.
A Figura 4.4 mostra o KMTS inicial do componente Módulo. Para facilitar a visua-
lização, os nomes das ações foram reduzidos e os estados exibem o vetor das proposições.
Ao final deste passo, é possı́vel inferir o valor de algumas proposições que possuem seu
valor indefido porque assumimos que cada combinação de valores das proposições define
um estado, de forma que não existem dois estados com as mesmas valorações. Assim,
após esta etapa é possı́vel remover incertezas e/ou remover estados (caso já exista estados
com as mesmas valorações). Todavia, este passo não foi realizado no presente trabalho,
sendo listado nos trabalhos futuros.
Toda vez que uma mensagem é enviada no diagrama de sequência, uma transição com
o mesmo rótulo da ação é realizada no KMTS, alterando seu estado corrente. Estas
transições utilizadas para percorrer no KMTS inicial têm sua modalidade alterada para
must à medida que os diagramas de sequência anotados são percorridos.
Todavia, como mostrado em (KRKA et al., 2009), este método pode transformar
transições que saem e entram em um mesmo estado (auto-transições) em um compor-
tamento obrigatório. Todavia, as auto-transições são criadas para que o máximo de
comportamento possı́vel seja adicionado e não estão, necessariamente ,expressas nos dia-
gramas de sequência. Desta forma, transformar uma auto-transição em must pode forçar
a existência de um loop no comportamento do componente que não deveria existir. A
solução proposta por (KRKA et al., 2009), e seguida no presente trabalho, é chamada
de refino e consiste em duplicar o estado s, que possui a auto-transição, gerando um s’ e
criar uma transição must entre s e s’ com a ação a da auto-transição, adicionar a auto-
transição em s’ e, para cada transição t ps, x, s2 q tal que x a, criar uma transição
t1 ps1 , x, s2 q. Desta forma, o loop fica presente no KMTS final, mas de forma opcional
(é possı́vel remover a auto-transição may criada no estado s”). A Figura 4.5 exemplifica
este processo.
(KRKA et al., 2009) chama este tratamento do auto-loop de refino porque existe uma
relação de refinamento entre os modelos antes e depois da clonagem. Este resultado é
utilizado para provar certas propriedades do algoritmo de sı́ntese.
A Figura 4.6 exibe o KMTS gerado para o componente Módulo como resultado do
algoritmo de sı́ntese.
4.3 ETAPAS DO ALGORITMO PARA SÍNTESE DE KMTS 45
Algoritmo 4: geraKMTSFinal
Data: KMTS inicial Mc e o conjunto DSac de diagramas de sequê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 ANÁLISE DO ALGORITMO DE SÍNTESE 47
um diagrama de sequência representa um trace de execução que por sua vez re-
presenta a sequência de mensagens trocadas em um diagrama de sequência sob a
perspectiva de um componente especı́fico.
a condição da linha 6 (Algoritmo 3) garante que são criadas transições (linha 12) para
todos os eventos que têm suas precondições vá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 não viola as restrições
de c. Seja o estado s P SM alcançado pela sequência de tr de tamanho n e en 1 o evento
de posição n 1 em tr. De acordo com a condição da linha 6 (Algoritmo 3), o algoritmo
irá gerar uma transição para cada evento e que tenha suas precondições satisfeitas em s,
o que inclui o evento en 1 .
(ii) segue um raciocı́nio análogo ao item (i), considerando no passo indutivo que todo
trace de tamanho n 1 que não respeite as restrições do componente c não será simulado
pelo KMTS M . Isto ocorre porque o evento en 1 não tem suas precondições satisfeitas
em s (estado alcançado pelo tr de tamanho n) e, pela condição da linha 6 (Algoritmo 3),
a transição que representa en 1 não será adicionada ao modelo M .
(iii) segue direto do fato de que um comportamento só é obrigatório no KMTS se,
e somente se, ele é especificado em algum diagrama de sequência. Este fato pode ser
observado no Algoritmmo 4 pois, ele itera sobre todas as mensagens (ações) que o com-
ponente troca (for da linha 8) e transforma uma transição may em must se a mensagem
está expressa no diagrama de sequência (linha 13).
Etapa I: nesta etapa, cada diagrama de sequência é analisado uma vez para extração
dos componentes e dados para outras etapas (existem NDS diagramas de sequência
de tamanho TDS ), representando NDS TDS iterações. Para cada componente
extraı́do (existem NC componentes), existem duas iteraçõ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 é OpNDS TDS
2 NC NE q;
Etapa II: para cada diagrama de sequência e para cada componente, um diagrama de
sequência anotado é gerado, ou seja, são gerados NDS NC diagramas de sequências
anotados. Para cada diagrama de sequência anotado, o algoritmo de propagação
(Algoritmo 2) varre a linha da vida (TDS ) três vezes (linhas 4, 10 e 16), assim, no
pior caso, a complexidade de tempo é OpNDS NC 3 TDS q;
Etapa III: no pior caso, o Algoritmo 3 desta etapa adicionará 3NCSV estados pois,
no algoritmo definido, não existem dois estados com a mesma valoração para as
4.5 VALIDAÇÃO DO ALGORITMO DE SÍNTESE 49
proposições. Como cada proposição pode assumir três valores (verdade, falso e
indefinido) e um componente tem |VS Y VE | proposições, o número máximo de
combinações das valorações das variáveis (e consequentemente o número máximo
de estados) do componente c será 3|VS YVE | , o que resulta que o algoritmo desta
etapa será invocado 3NCSV vezes. Para cada estado adicionado, existe uma iteração
sobre os eventos de cada componente (linha 4 e 5). Este passo é repetido para cada
componente (NC ), o que resulta em uma complexidade de tempo Op3NCSV NC
NE q;
Etapa IV: para cada diagrama de sequência anotado (linha 2 do Algoritmo 4), que
representa o número de diagramas de sequência vezes o número de componentes,
NDS NC ) as linhas da vida são percorridas, iterando pelas mensagens (linha 8 do
Algoritmo 4). Para cada mensagem, os estados do componente são analisados e para
cada estado do componente (linha 10 do Algoritmo 4) as ações (NE ) são analisadas
(linha 11 do Algoritmo 4). No pior caso, cada componente tem 3NCSV estados e
assim temos que a complexidade de tempo é OpNDS NC TDS 3NCSV NE q.
Todavia, como argumentado por (KRKA et al., 2009), esta complexidade exponencial
não é um problema na prática porque um componente terá um número pequeno de
variáveis significantes (NCSV ) e a quantidade destas variáveis não aumenta à medida que
o sistema cresce e, assim, em casos reais, espera-se tempos de execução polinomiais em
relação ao tamanho da entrada.
5
RELAÇÕES E OPERAÇÕES PARA MODELOS KMTS
51
52 RELAÇÕES E OPERAÇÕES PARA MODELOS KMTS
,L q
Definiçã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 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
então p P LN pnq e o valor-verdade de p em m é o mesmo valor-verdade de p em n ou p é
indefinido em m.
O operador ¤ define entre dois estados quaisquer uma relação que chamamos de
refinamento de literal, isto é, se ¤ vale entre dois estados, dizemos que um estado é um
refinamento de literal do outro estado. Usaremos ¦ para dizer que não há refinamento
de proposições entre dois estados.
1. LM pmq ¤ LN pnq;
1. LM pmq ¤ LN pnq;
Demonstração.
De maneira similar, é possı́vel mostrar que vale para qualquer estado m P SM , alcançável
a partir de m0 . Logo, R é uma relação de refinamento e M ¨ N .
Quando novos requisitos são expressos como propriedades, a análise dos modelos
KMTS pode ser realizada considerando um KMTS como uma abstração de uma estrutura
de Kripke ou como um conjunto destas estruturas.
Em (SHOHAM; GRUMBERG, 2007) uma estrutura de Kripke é abstraı́da em um
KMTS, reduzindo o tamanho do modelo para contornar o problema de explosão de es-
tados. Neste caso, técnicas de verificação de modelo parciais podem ser utilizadas para
analisar se os modelos existentes satisfazem as propriedades requeridas. Caso a veri-
ficação retorne que a propriedade é satisfeita no modelo parcial, então em qualquer imple-
mentação possı́vel daquele modelo a propriedade valerá (como mostrado anteriormente,
implementações possuem relação de refinamento com suas especificações e a relação de
refinamento preserva propriedades CTL (BAIER; KATOEN; LARSEN, 2008)). Nos ca-
sos em que a propriedade é falsa, nenhuma implementação satisfaz esta propriedade e o
modelo deve ser corrigido. Nos casos onde a propriedade é indefinida, significa dizer que o
modelo não possui informações suficientes, e ele deve ser refinado para que a propriedade
possa ser verificada. Em todos os casos, é possı́vel utilizar os contraexemplos fornecidos
pelos algoritmos para fazer a correção manual dos modelos, se necessário. É importante
destacar que nos referimos a CTL, mas utilizamos modelos baseados em ações. Todavia,
existem lógicas temporais baseadas em ações, como a ACTLW (MEOLIC; KAPUS; BRE-
ZOVCNIK, 2008) ou a α-CTL (MENEZES; BARROS; PEREIRA, 2010) que utilizam
um adaptação da CTL para a se referir às ações nas fórmulas. É importante ressaltar
que as propriedades também são preservadas para lógicas baseadas em ações (BAIER;
KATOEN; LARSEN, 2008). No nosso trabalho, o projetista possui modelos abstratos e
deseja obter modelos concretos. Apesar da diferença de objetivos, a verificação proposta
em (SHOHAM; GRUMBERG, 2007) pode ser utilizada.
Em (GUERRA; ANDRADE; WASSERMANN, 2013b) um KMTS é interpretado
como um conjunto de estruturas de Kripke. Caso a verificação de uma propriedade,
com esta semântica, retorne falso ou indefinido, é possı́vel utilizar técnicas de revisão de
modelos para refinar o modelo em questã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 não será um refinamento do modelo anterior porque
a propriedade que era falsa passa a valer e então o modelo gerado não preserva as pro-
priedades do modelo anterior. Além disto, como mostrado em (GUERRA; ANDRADE;
WASSERMANN, 2013b), pode ser feita de forma semiautomática.
Nos dois casos é necessário refletir as alterações nos modelos nos diagramas de sequência
e/ou no código-fonte. Este mapeamento entre o modelo e o diagrama de sequência (ou
código-fonte) é um ponto do processo que precisa ser estudado e é listado como trabalho
futuro.
Quando novos requisitos são expressos como diagramas de sequências, duas abor-
dagens podem ser consideradas para a atualização dos modelos: (I) utilizar todos os
diagramas de sequência existentes, gerando apenas um modelo por componente, se não
houver alguma inconsistência entre os diagramas de sequência; ou (II) utilizar apenas os
novos diagramas de sequência. Nos dois casos, existirá o modelo criado anteriormente
e o modelo criado com os novos requisitos. Estes modelos podem ser unificados através
da operação de conjunção se forem consistentes entre si (uma discussão a respeito deste
5.1 REFINAMENTO DE KMTS 57
de cada conceito deve ser levada em consideração pelo projetista e analisada sobre a neces-
sidade desejada. Por exemplo, suponha que não existe uma relação de refinamento modal
forte entre E e I, mas que exista uma relação de refinamento modal fraco. Isto significa
que não há preservação da estrutura ramificada entre os modelos, mas há preservação das
propriedades. Em alguns casos, isto pode ser o suficiente. Boas ferramentas de análise
de modelos devem trazer ao projetista os resultados para cada relação de refinamento
desejada.
Em relação à comparação de uma especificação EN e a especificação EN 1 entre
diferentes ciclos, podemos ter os seguintes resultados:
Observe que o resultado da análise entre especificações de ciclos diferentes pode ser
aplicado à análise de modelos extraı́dos de ciclos diferentes, restando comparar a especi-
ficação de um ciclo e o modelo extraı́do do outro:
isto é, nas ações que eles têm em comum. Para as outras ações, o comportamento é 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 composição paralela M ||N é 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 composição paralela representa o sistema e este é composto pela união de
componentes, o conjunto de sı́mbolos proposicionais e o conjunto de ações do sistema é,
trivialmente, a união dos sı́mbolos proposicionais e as ações de cada componente. Assim,
temos que:
SM ||N SM SN
Considerando que o estado inicial do sistema é o estado inicial dos componentes, e
que sM 0 e sN 0 são os estados iniciais de M e N respectivamente, temos que:
sM ||N 0 psM 0, sN 0q
O conjunto de transições must e may devem representar o interleaving e as ações com-
partilhadas, levando em consideração a modalidade da transição. Seguindo o que foi dito
em (ANTONIK et al., 2008), um operador de composição paralela sobre especificações
parciais pode ser criado através das regras de composição paralela para modelos LTS,
considerando as modalidades nas transações. De maneira geral, estas regras definem se
uma ação é compartilhada ou não e qual a origem e o destino de cada transição. Na
adaptação do presente trabalho, as regras definem se existe uma transição e qual a moda-
lidade da transição na composição de acordo com a existência, inexistência e modalidade
da transição em M e N . Estas regras estã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
$v
'' se LM ps, pq e LN pt, pq são verdade ou pelo menos
'& um é verdade e o outro é indefinido
se LM ps, pq e LN pt, pq são falsos ou pelo menos
Lpps, tq, pq
f
'' um é falso e o outro é indefinido
'% K se LM ps, pq e LN pt, pq são indefinidas
, caso contrário
Nem sempre o resultado da composição entre dois modelos resulta em um modelo
consistente. Quando existem estados inconsistentes que podem ser alcançados, dizemos
que estes modelos não são composicionáveis. Caso contrário eles são composicionáveis.
Definição 5.2.2. dois modelos M e N são composicionáveis entre si quando a composição
entre eles não possui estados inconsistentes alcançáveis a partir do seu estado inicial.
Dizemos que dois modelos são composicionáveis quando a composição entre eles não
possui estados inconsistentes alcançáveis a partir do seu estado inicial. Desta maneira,
nem todos os modelos são composicionáveis e por este motivo o operador de composição
definido aqui é parcial.
Finalmente, com todos os elementos definidos, podemos definir o operador de com-
posição paralela.
,L q
Definição 5.2.3 (Composiçã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 Composição Paralela (||) é um
62 RELAÇÕES E OPERAÇÕES PARA MODELOS KMTS
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 são as menores relaçõ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 é uma função rotuladora de
composição paralela (Definição 5.2.1).
Figura 5.3 Modelos KMTS para o software de vistoria remota, onde (A) representa o e-
Formulário e (B) o sincronizador.
Definição 5.3.1 (Consistência entre KMTS). Dois KMTS M e N são consistentes entre
si se existe um KMTS X tal que X é um refinamento comum de M entre N .
De maneira geral, haverá uma relação de consistência entre dois KMTS se um simula
o comportamento obrigatório do outro e vice-versa. Este comportamento obrigatório fará
parte de qualquer modelo que seja um refinamento em comum dos modelos analisados.
O comportamento possı́vel que representado nos dois modelos simultaneamente também
está presente no refinamento comum.
S M ^N SM SN
Considerando que o estado inicial do sistema é o estado inicial dos componentes, e
que sM 0 e sN 0 são os estados iniciais de M e N , respectivamente, temos que:
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
uma função rotuladora, se para todo estado ps, tq e p P APM ^N , no má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 contrário
Diferentemente da composição paralela, estados inconsistentes na conjunção repre-
sentam partes dos modelos que não são refinamento comum e devem ser removidos para
garantir que SM ^N SM SN . Para tal remoção, definimos a função poda P , que remove
estados inconsistentes. Se um estado t P SM SN , t é inconsistente se Lptq ou se
tP .
,L q e N
Definição 5.3.4 (Funçã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 função rotuladora L de conjunção em função de LM e LN (Definição 5.3.3).
A funçã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
Definição 5.3.5 (Conjunçã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 conjunção (^) é 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 são as menores relaçõ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 é uma função rotuladora de
conjunção (Definição 5.3.3).
Como dito anteriormente, o operador de conjunção pode ser aplicado entre dois KMTS
que não são consistentes entre si e o resultado da conjunção não será o refinamento comum
dos KMTS. Quando aplicada sobre dois KMTS consistentes, dizemos que a conjunção é
definida. De qualquer maneira, é possı́vel analisar o resultado da conjunção para deter-
minar se dois KMTS M e N são consistentes entre si através da relação de refinamento.
As propriedades que garantem esta afirmação são exploradas a seguir.
5.3 CONJUNÇÃO DE MODELOS KMTS 67
Figura 5.6 Duas versões do componente e-Formulário para atender a requisitos de georrefe-
renciamento e fotografia
6
JOGO DO REFINAMENTO
Existem diferentes formas de verificar se existe uma relação de refinamento entre dois
modelos quaisquer, entre elas o jogo de refinamento é caracterizado entre dois jogadores
e verifica a existência de uma relaçã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 Seção 6.1 apresenta o jogo de refinamento para modelos
KMTS de forma intuitiva e prova sua equivalência com a relação de refinamento. A
Seção 6.2 apresenta o jogo de refinamento como um grafo e até onde sabemos, esta
representação não foi realizada em nenhum outro trabalho sobre jogos de refinamentos.
A Seção 6.3 apresenta um algoritmo que verifica a relação de refinamento através do jogo
de refinamento como um grafo. Provamos a correção, terminação e complexidade deste
algoritmo. Por fim, são apresentados os resultados e as análises de uma série de validações
realizadas sobre uma implementação deste algoritmo.
71
72 JOGO DO REFINAMENTO
, L q e N pAP , Σ S , s ,
Definiçã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 é definida
RN , RN N
pelas seguintes regras:
1. O estado inicial de uma partida é o par pm0 , n0 q onde m0 e n0 são os estados iniciais
de M e de N , respectivamente;
3. Uma partida é composta por rodadas, que por sua vez é composta por dois turnos:
o turno do spoiler e o turno do duplicator, nesta ordem;
6. No seu turno, o duplicator deve executar um movimento no modelo que não foi
escolhido pelo spoiler no seu último movimento. Se ele for executar o movimento
em M então o movimento deve representar a transição t pm, a, m1 q P RM tal
que LM pm1 q ¤ LN pn1 q seja válido. Se ele executar o movimento em N então o
movimento deve representar a transição t1 pn, a, n1 q P RN tal que LM pm1 q ¤
LN pn1 q seja válido;
8. Uma partida termina em duas situações: quando ela for infinita, isto é 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
não pode se mover e, neste caso, o jogador que não consegue se mover perde o jogo,
exceto se a configuraçã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 é pm0 , n0 q e o spoiler começa o jogo, podendo escolher en-
tre jogar em M ou em N. Se ele escolhe jogar em M, sua única opção de movimento
é seguir pela transição com a ação “b”, pois é a única transição must. Se ele escolhe
jogar no modelo N, ele pode escolher jogar em qualquer das transições possı́veis, pois,
por definição, todas as transições são may (transições com as ações “a”, “b” e “c”). Su-
pomos que nesta partida ele jogou no modelo M, realizando o movimento representado
pela transição pm0 , b, m2 q. O estado corrente do jogo será pm2 , n0 q. No turno do dupli-
cator, ele deve executar um movimento no modelo N tal que a transição seja rotulada
6.1 DEFINIÇÃO INTUITIVA DO JOGO DE REFINAMENTO 73
pela mesma ação do spoiler (ação “b”) e que a transição vá para um estado n tal que
LM pm2 q ¤ LN pnq. Deste modo, o movimento que o duplicator fará será mover-se pela
transição pn0 , b, n2 q. Observemos que LM pm2 q ¤ LN pn2 q vale, caso contrário o duplicator
não poderia jogar e perderia a partida. A nova configuração do jogo é pm2 , n2 q, uma
nova rodada se inicia e é a vez do spoiler jogar. Como não existem transições disponı́veis
(nem o estado m2 nem o estado n2 possuem transições de saı́da) o spoiler nã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 transiçã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 não pode se mover e perde a partida. Consideramos agora mais
uma partida possı́vel, onde o spoiler move-se pela transição pn0 , a, n3 q. A única opção do
duplicator é se mover pela transição pm0 , a, m1 q, levando o jogo ao estado pm1 , n3 q. Na
vez do spoiler ele pode escolher entre mover-se pela transição pm1 , a, m1 q levando o jogo
para a configuração pm1 , n3 q ou mover-se pela transição pn3 , a, n2 q levando o jogo para
a configuração pm1 , a, n2 q. Para qualquer uma das duas alternativas, o duplicator terá
um movimento válido. É fácil observar que qualquer destas partidas será 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 é 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 transição
jogar, se ele puder jogar, sempre existirá uma única transição com a ação desejada. Se o
duplicator ganha em todas as possı́veis partidas do jogo de refinamento sobre os modelos
M e N, então existe uma relação de refinamento entre M e N . Caso contrário, isto é, se
o duplicator perde em pelo menos uma partida, não existe relação de refinamento entre
M e N.
É possı́vel perceber que as restrições da definição de refinamento (Definição 5.1.3) são
refletidos nas regras do jogo de refinamento (Definição 6.1.1). O Teorema 6.1.1 estabelece
uma relação entre o jogo de refinamento e a existência de uma relação de refinamento
entre dois modelos M e N, ou seja, as regras do jogo determinam as restrições para
a existência da relação de refinamento. Os movimentos, tanto do spoiler quanto do
duplicator, representam as transições nos modelos. A ideia do duplicator ter que repetir
74 JOGO DO REFINAMENTO
jogo e sempre após que o duplicator jogar. Observamos que a cada rodada, as restrições
são garantidas. Se o duplicator perde, então naquela rodada as restrições não foram
garantidas e por isto não há relação de refinamento. De forma inversa, se o spoiler perde,
é porque não há movimentos possı́veis. Como até a última rodada as restrições são
satisfeitas então para todas as transições (e estados) o duplicator imita os movimentos
do spoiler, o que representa que as restrições são satisfeitas em qualquer caso. Partidas
infinitas significam que o spoiler voltou a uma configuração onde as restrições já foram
garantidas anteriormente e que não há uma jogada diferente para ser feita.
Teorema 6.1.1 (Relaçã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 é 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.
Demonstração.
(Ñ) Suponha, por contradição, que existe pelo menos uma partida em que o duplicator
perca. Então, dois casos podem acontecer:
(a) LM pm0 q ¤ LN pn0 q não é válido: Este caso contradiz a hipótese porque M ¨ N
(o que implica em LM pm0 q ¤ LN pn0 q); ou
(b) O duplicator nã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 transição t pm, a, m1 q P RM ; ou (b) uma transição t pn, a, n1 q P
RN . Em ambos os casos se chega a uma contradição. Vamos mostrar o caso
(a) (caso (b) é similar):
O spoiler move-se em pm, a, m1 q P RM e não existe transição em RN tal que o
duplicator possa imitar o movimento do spoiler. Como M ¨ N , então existe
uma relação de refinamento R entre M e N e pm, xq P R para algum x P SN
((m, x) existe porque m é alcançavel a partir de m0 no modelo M, caso contrário
(m, n) não poderia ser uma configuração do jogo (hipótese)). Pela definição
de refinamento, se pm, xq P R então para todas as transições pm, a, k q P RM
existe uma transição px, a, x1 q P RN tal que LM pk q ¤ LN pxq onde o duplicator
pode se mover, isto é, semrpe existe uma transição onde o duplicator pode
imitar o movimento do spoiler, ou seja, chegamos a uma contradição
6.2 JOGO DO REFINAMENTO COMO UM GRAFO 75
Voltando para o exemplo da Figura 6.1, percebemos que o mais importante no jogo
de refinamento são as configurações do jogo e quais configurações são acessı́veis através
de outras configurações. A Figura 6.2 exibe todas as configurações do jogo do exemplo
da Figura 6.1 e como elas são alcançadas. A letra do lado da configuração indica se é a
vez do spoiler (s) ou duplicator (d) jogar e a direção das setas indica a acessibilidade de
uma configuração através de outra.
Como podemos perceber através da Figura 6.2, é possı́vel representar todas as possı́veis
configurações de um jogo através de um grafo.
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
LM pm1 q ¤ LN pn1 qu
Onde pi, j qS representa os vértices do spoiler e pw, a, x, k qD representa os vértices do
duplicator com i, j, w, x, k P SM Y SN e a P ΣM Y ΣN .
6.2 JOGO DO REFINAMENTO COMO UM GRAFO 77
Figura 6.3 Jogo do refinamento entre os modelos M e N da Figura 6.1 expressos em um grafo
uma partida é uma sequência de configurações do jogo, então se pi não está representada
em nenhum caminho do grafo RGM,N existem duas possibilidades: (i) existe alguma con-
figuração que não está representada no grafo e consequentemente não está em φi ; ou (ii)
todas as configurações da partida estão representadas no jogo, mas não existe pelo menos
uma aresta que ligue duas configurações consecutivas de forma a representar a partida
pi . Consideremos então a partida pi pm0 , n0 qpmx , my q...pm, nq... finita ou infinita.
(i): Suponha que uma configuração px, y q qualquer não esteja no grafo. Se px, y q
pm0, n0q chegamos a uma contradição pois, pela Definiçã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 configuração de pi
que não esteja em φi , de forma que pm0 , n0 qpmx , my q...pm, nq esteja em φi e que px, y q
é alcançável diretamente pela configuração pm, nq. Considerando que px, y q é alcançá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 é alcançável diretamente de pm, nq então existe uma
transiçã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 mudanç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 mudança foi causa pelo duplicator. Se a
mudança foi causada pelo spoiler, as condições t pm, a, m1 q P RM para algum a P ΣM e
LM pmq ¤ LN pnq garantem a existência de um vértice v pm, a, m1 , nq tal que v P VD1 ,
o que representa a configuração pm1 , nq no grafo, o que nos leva a contradição. (b) Se
px, yq pm, n1q, as condições garantiriam a existência de um vértice v pm, a, n1, nq tal
que v P VD2 . Da mesma forma, se a nova configuração fosse resultado do movimento do
duplicator, a condição LM pmq ¤ LN pnq valeria, o que garantiria um vértice v P VS , e
assim chegamos a uma contradição;
(ii): Suponha ci e ci 1 , duas configurações sucessivas da partida pi representadas no grafo
pelos vértices vi e vi 1 , respectivamente, tal que não exista uma aresta entre vi e vi 1 .
Suponha que vi pm, nq então vi 1 pm1 , nq ou vi 1 pm, n1 q. Se a transiçã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 existência de uma transição pvi , vi 1 q P E1 . Se vi 1 pm, n1 q temos que
n 99K n1 e a P ΣN , o que também garante a existência de uma transição pvi , vi 1 q P E2 .
a
Assim, para estes casos chegamos a uma contradição. Um raciocı́nio análogo pode ser
feito assumindo que a mudança de configuração foi causada pelo duplicator.
A Proposição 6.2.1 mostra que todas as partidas da Definição 6.1.1 estão representadas
no grafo, mas o inverso não é verdade. O grafo representa mais configurações do que a
Definição 6.1.1 permite. Isto acontece porque a regra de formação do conjunto de vértices
(ou de arestas) do grafo não define que os elementos deste conjunto devem ser alcançados
a partir do estado inicial, ou seja, pela Definição 6.2.1 podem existir vários subgrafos
desconexos, entretanto, é possı́vel observar que apenas um subgrafo contém o estado
inicial. Desta forma, ao utilizar o grafo para representar todas as partidas de um jogo de
refinamento, é importante utilizar o subgrafo que contém o estado inicial. A partir deste
ponto, sempre que nos referirmos ao grafo do jogo de refinamento, estamos nos referindo
ao subgrafo que contém o estado inicial (a menos que seja explı́cito o contrário). Também,
a partir de agora, usaremos o termo “jogo de refinamento” de forma intercambiável com
o termo “grafo do jogo de refinamento”.
6.2 JOGO DO REFINAMENTO COMO UM GRAFO 79
Ð Basta observar que se existe uma configuração do duplicator que não possui ares-
tas de saı́da, isto significa que naquela configuração o duplicator não pode fazer
nenhum movimento. Como o jogo começa pelo spoiler, existe algum movimento
executado pelo spoiler que levou o jogo até esta configuração. Assim, o duplicator
não pode mover-se e não consegue imitar o movimento do spoiler perdendo a par-
tida. Pelo Teorema 6.1.1, se o duplicator perde uma partida então não há relação
de refinamento entre os modelos M e N.
80 JOGO DO REFINAMENTO
Até onde sabemos, não existe nenhum algoritmo que gere o jogo de refinamento para
qualquer especificação parcial (MTS e suas variantes). A referência a este tipo de jogo na
literatura resume-se a uma lista de regras menos detalhadas que as regras apresentadas
na Definição 6.1.1 e esta caracterização em forma de jogo é utilizada apenas para provar
algumas propriedades do refinamento, como em (BENEš et al., 2009). Propomos um
algoritmo que utiliza o jogo de refinamento para analisar a existência de uma relação de
refinamento modal forte entre dois KMTS.
Verificar a não existência de refinamento entre dois KMTS através do jogo de refinamento
consiste em gerar o jogo e verificar se existe alguma partida que o duplicator perde. A
geração e verificação podem ser resumidos nos seguintes passos: (i) gerar o conjunto de
vértices do spoiler ; (ii) gerar o conjunto de vértices do duplicator ; (iii) adicionar as arestas
entre os vértices do spoiler e duplicator (e vice-versa); (iv) percorrer, a partir do estado
inicial, o grafo criado verificando se existe algum vértice do duplicator que não possui
transição de saı́da (de acordo com o Teorema 6.2.1).
O Algoritmo 5 cria o conjunto de vértices do spoiler seguindo a Definiçã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 especificação M e um estado do modelo N (for’s das
linhas 3 e 4) que cumprem a restrição do conjunto VS da Definição 6.2.1 (linha 5).
Algoritmo 5: geraVerticesDoSpoiler
Data: KMTS M e N
Result: VS tal que VS é o conjunto de vé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
Algoritmo 6: geraVerticesDoDuplicator
Data: KMTS M e N
Result: VD tal que VD é o conjunto de vé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
82 JOGO DO REFINAMENTO
Algoritmo 8: checaRefinamento
Data: KMTS M e N
Result: “SIM” se M ¨ N e “NAO” caso contrá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
conjuntos. Como nenhum laço é reiniciado e todos os conjuntos são finitos, podemos
concluir que o algoritmo sempre termina.
2. Calcular se um estado é acessı́vel a partir de outro estado por uma ação é polino-
mial: no algoritmo, existem condições em que verifica-se um estado qualquer x1 é
alcançado por uma transição com ação a a partir de um estado x (o que equivale a
verificar se a transição t px, a, x1 q pertence a algum conjunto R (ou R ). Para
fazer tal verificação, deve-se verificar se existe uma transição de saı́da rotulada com
a ação a no estado x e se o estado de chegada é igual a x1 . Considerando que as
transições dos modelos sã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 ação e
o estado de destino. Assim, a complexidade desta função é Op|R | |R |q;
Grupo
Variável
crescimento
estado transições proposiçõ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 transições 10 10
25, 30, 35, 40 25, 30, 35, 40
5, 10, 15, 20, 5, 10, 15, 20,
Nº de proposições 10 10
25, 30, 35, 40 25, 30, 35, 40
Nº modificações 4*, 7, 10, 14, 4*, 7, 10, 14,
3 3
em transições 17, 20, 24, 27 17, 20, 24, 27
Nº modificações 4*, 7, 10, 14, 4*, 7, 10, 14,
3 3
em proposições 17, 20, 24, 27 17, 20, 24, 27
Tabela 6.1 Variáveis de acordo com o grupo de teste
Quantidade de estados
25 50 75 100 125 150 175 200
Tempo médio 10 11,7 11,3 24 43,3 59,5 77,8 121,3
Desvio Padrão 8,59 4,57 1,95 8,42 10,65 15,23 12,64 32,27
Tabela 6.2 Tempo médio de execução (milissegundos) do algoritmo do jogo de refinamento de
acordo com a quantidade de estados
4. Testes com uma quantidade de mudança fixa têm um tempo médio de execução
maior que os testes com uma quantidade de mudança variável. Isto acontece porque
ao fixar a quantidade de mudanças, a especificação e o modelo são mais similares (é
válido lembrar que o modelo é uma cópia da especificação com algumas mudanças).
Quando os modelos são mais similares, a probabilidade de um par de estados sa-
tisfazerem as condições para virarem um vértice do jogo é maior e por isto, testes
com número de mudanças fixas têm jogos com mais estados que testes com número
de mudanças variáveis;
5. Os testes dos blocos iniciais tiveram desvios-padrão mais elevados que os testes
dos outros blocos. Isto ocorre porque nos blocos iniciais, os valores de tempo de
execução de cada teste são muito baixos (próximos a 0). Qualquer teste que tenha
um valor mais elevado entre os 10 testes distorce o valor da média e do desvio-
padrão. Isto significa que mesmo uniformizando as variáveis, existem casos, dentro
de um mesmo bloco, que exigem um maior tempo de execução. Acreditamos que
6.3 ALGORITMO DO JOGO DE REFINAMENTO 91
este fato seja decorrente da estrutura ramificada das entradas. Estes valores pode-
riam ter sido removidos da amostra de testes para desfazer estas distorções, todavia,
decidimos mantê-los por uma questão de transparência.
7
REPARO DE REFINAMENTO
93
94 REPARO DE REFINAMENTO
2. p = RT (s, a, s1 ) e p’ = AT ps, a, s1 q;
Demonstração. Seja um literal l P APN . Se l P LN pnq então apenas uma mudança pode
ser realizada sobre l: mudar sua valoração (CLpn, l, v q) ou removê-lo pRLpn, lqq. Caso
contrário, duas mudanças podem ser realizadas: adicionar l (ALpn, lq) e atribuir um valor
para l (CLpn, l, v q). Pela Definição 7.1.2, qualquer outra mudança que envolva l e n, em
qualquer um dos casos, será inconsistente. Assim, o número máximo de mudanças que
podem ser realizadas em um estado n em relação aos literais é 2 |APN |, caso em que
nenhum literal está definido em n.
, L q e n P S . O
Proposição 7.1.2. Seja um KMTS N pAPN , ΣN , SN , sN 0 , RN , RN N N
número de mudanças primitivas consistentes entre si que podem ser aplicadas em n em
relação às suas transições de saı́da é finito.
literais que o estado m possui (e talvez mais literais). Após este passo, é possı́vel aplicar
mudanças primitivas do tipo CL para fazer a valoração de todos os literais de n iguais à
valoração dos literais de m.
Definimos a função XRL pm, nq como a função que retorna o conjunto mı́nimo de
mudanças primitivas X para que LM pmq ¤ LN pX pnqq (esta função existe como resultado
da Proposição 7.1.4).
A Proposição 7.1.5 mostra que sempre é possı́vel adicionar uma transição entre dois
estados quaisquer de um modelo, preservando o determinismo do modelo.
1. Lpmq Lpnq;
2. se m Ñ
Ý m1, existe n Ñ
Ý n1 com pm1, n1q P E;
a a
4. se n Ñ
Ý n1, existe m Ñ
Ý m1 com pn1, m1q P E; e
a a
Dizemos que dois estados são distintos se eles não estão relacionados pela relação de
equivalência entre estados. O conceito de estados distintos é usado para analisar quantos
estados, no mı́nimo, um modelo N deve possuir para que ele seja um refinamento de uma
especificação M.
Assim, dados M e N dois KMTS tal que M ª N , existe um conjunto de mudanças
primitivas que pode transformar N em um refinamento de M se o número de classes de
equivalência sobre os estados de M é menor ou igual ao número de estados de N .
A Proposição 7.1.7 mostra que se existem estados equivalentes em um modelo M , eles
são mapeados em um mesmo estado do modelo N por uma relação de refinamento tal
que M ¨ N .
Proposição 7.1.7. Dados M pAPM , ΣM , SM , sM 0 , RM , RM , L q e N pAP , Σ ,
M N N
, L q dois KMTS, R uma relação de refinamento entre M e N e E uma
SN , sN 0 , RN , RN N
relação de equivalência entre os estados de M . Se pm, nq P R e pm, m1 q P E então
pm1, nq P R.
Demonstração. A prova é uma consequência direta da Definição 5.1.3 e Definição 7.1.3.
O Teorema 7.1.1 mostra que em determinadas condições, é possı́vel reparar um modelo
N para alcançar a relaçã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 relação de equivalência entre os estados de M . Seja SM {EM o con-
junto de classes de equivalência definido por EM sobre SM e | SM {EM | o número de classes
de equivalência do conjunto quociente SM {EM . Suponha que M ª N e | SM {EM |¤| SN |
então existe um conjunto de mudanças primitivas X tal que M ¨ X pN q.
Demonstração. Vamos criar uma relação RM que mapeia os estados de M nos estados
de N (1) e modificar N por um conjunto X de mudanças primitivas, gerando um modelo
N 1 (2) tal que RM é uma relação de refinamento entre M e N 1 (3).
(a) psM 0, sN 0q P RM ;
(b) Seja pm, nq P RM (garantido pela aplicaçã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 transiçõ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 remoção das
M
transições que existem em N e não existem em M no passo (2)).
Algoritmo 9: geraMudancasPrimitivas
,L q
Data: KMTS M pAPM , ΣM , SM , sM 0 , RM , RM M
Result: X tx | x é uma mudanç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
7.1 O PROBLEMA DO REPARO DE REFINAMENTO 101
O Algoritmo 9 itera sobre os estados do modelo de entrada (linha 3), analisando para
cada estado quais às mudanças primitivas que alteram a valoração das proposições (linhas
4-10), de forma que se, por exemplo, se uma proposição tenha a valoração verdade então
o algoritmo adiciona as mudanças primitivas para alterar a valoração da proposição para
falso e para indefinido. Após esta etapa, o algoritmo adiciona cada par de estados (for da
linha 3 com o for da linha 11) as mudanças primitivas para remover as transições existen-
tes (linhas 12-15), alterar a modalidade das transições existentes (linhas 14-17), alterar as
ações das transições existentes (linhas 18-19) e adicionar as transições inexistentes (linhas
20-23).
A Proposição 7.1.8 mostra a complexidade do Algoritmo 9.
M TD : M, N, VM P N ¡
Escolha de forma não-determinista um conjunto X tx|x P VM P N u
Se M ¨ X pN q, retorne X
A máquina M TD acima recebe como entrada os modelos M e N e o conjunto VM P N
de mudanças aplicáveis sobre o modelo N e escolhe um conjunto de mudanças primitivas
102 REPARO DE REFINAMENTO
X formado por elementos de VM P N tal que se X for aplicado sobre o modelo N, o modelo
resultante X(N) será um refinamento do modelo M, isto é, M ¨ X pN q.
Figura 7.2 Dois Modelos M e N tal que M ª N e duas saı́das do algoritmo RRE
É possı́vel ver que todas testemunhas de falhas não possuem arestas de saı́da pois,
nestes vértices o duplicator não consegue jogar. A Proposição 7.2.1 afirma que se não
existe uma relação de refinamento entre dois modelos então existe um movimento do
spoiler tal que, no próximo turno, o duplicator não pode se mover, portanto existirá, pelo
menos, uma testemunha de falha.
Demonstração. Pelo Teorema 6.1.1 se M ª N então existe, pelo menos, um partida finita
onde o duplicator não pode se mover. Se o duplicator não pode se mover então existe
Dwf P VD tal que não existe uma aresta a partir Dwf para algum vértice s P VS .
Existe um padrão nos tipos de arestas do jogo. O tipo de aresta que representa os
movimentos do duplicator depende do tipo de transição do ú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 através de uma aresta E1 então o duplicator se movimentará através
de uma aresta E11 . Se o spoiler move-se através de uma aresta E2 então o duplicator se
movimentará por uma aresta E21 . Baseado neste fato, é possı́vel obter, de acordo com as
definições de jogo, o tipo de aresta que deveria existir para conectar uma testemunha de
falha com outro vértice, permitindo que o duplicator continue jogando, evitando assim
que ele perca.
A condição ps, pq P E1 no Item (1) expressa que o spoiler jogou no modelo M movendo-
se para o estado sM . Então, o duplicator deve jogar no modelo N a partir do estado sN
para algum estado s1N tal que LpsM q ¤ Lps1N q. Todavia, não existe esta aresta porque
(sM , sN ) é testemunha de falha. A condiçã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 . Então o duplicator
deve jogar no modelo M, mas não existe um movimento possı́vel em M porque (sM , sN )
é uma testemunha de falha. Então em ambos os casos, a transição onde o spoiler joga é
a causa da falha.
Proposição 7.2.3. Dados M e N dois KMTS. Se M ª N então existe, pelo menos, uma
causa de falha no jogo de refinamentoRGM,N .
A negação da causa de uma falha cf indica o que deve ser verdade para prevenir que
o duplicator perca o jogo na configuração que originou cf e esta expressão pode ser usada
para definir um conjunto de mudanç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 é uma causa de falha do jogo de refinamento RGM,N u.
Para qualquer causa de falha, é possı́vel mudar o modelo através de mudanças primi-
tivas para removê-la, como especificado na Proposição 7.2.4.
caso 1 (linhas 4-8): a transição já existe mas, o estado de destino não é um re-
finamento de literal e neste caso os conjuntos de mudanças gerados contêm tanto
as mudanças para fazer o estado de destino ser um refinamento de literal através
da função XRL (linha 5) quanto o conjunto de possı́veis mudanças que removem
(linha 6) ou alteram a ação da transição já existente (linha 7). Esta alteração ou
remoção é realizada para que a transição com a ação deseja possa ser criada para
outro estado;
caso 3 (linhas 16-21): para cada estado n P SN são geradas combinações para
adicionar a transição e alterar n para que ele seja um refinamento de literal do estado
sM . Caso a transição com a ação a já exista, as mudanças primitivas para alterar ou
remover a transição são combinadas com as mudanças para fazer LM psM q ¤ LN psq
(linha 21).
108 REPARO DE REFINAMENTO
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
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
13 else
14 R ÐÝ R Y tN u
112 REPARO DE REFINAMENTO
Quando existem vá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 mudanças aplicado para
remover uma causa de falha. Neste novo jogo, as causas de falhas já detectadas anteri-
ormente em outro ramo de execução podem aparecer e serão reparadas novamente, ou
seja, o RRBJ, muitas vezes, repara (ou tenta reparar caso não exista um conjunto de mu-
danças primitivas consistentes que podem ser aplicadas) a mesma causa de falha porque
ela aparece em diferentes ramos de execução do algoritmo. Este fato implica diretamente
na performance do algoritmo, principalmente nos casos onde não é possı́vel reparar uma
causa de falha e ela aparece em diversos ramos. Para cada ramo o algoritmo tentará, sem
sucesso, reparar a causa de falha. Isto acontece porque o RRBJ não compartilha entre
seus ramos de execução informações sobre as causas de falha.
Para contornar esta limitação, duas outras versões do RRBJ foram analisadas: RRBJ-
C com checagem da existência de soluçã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
única vez.
O RRBJ-C verifica antes da sua chamada recursiva se cada causa de falha encontrada
possui um conjunto de mudanças primitivas que pode repará-la. Se alguma causa de falha
não possui solução então o RRBJ-C evita buscar soluções para as outras causas de falha e
retorna que aquele ramo de execução não possui soluções, continuando o processamento de
outros ramos (se existir) de forma isolada, similarmente ao RRBJ. Já o RRBJ-U verifica
se cada causa de falha possui soluções e combina todas as possı́veis soluções para cada
causa de falha (removendo as mudanças primitivas repetidas), verificando a consistência
entre todas as mudanças primitivas de cada combinação de reparo. Cada possibilidade
de reparo em conjunto é aplicada isoladamente e o algoritmo segue de maneira recursiva.
Ainda podemos imaginar outras variações do RRBJ que tentam reduzir o número de
ramos de execuções existentes, como o RRBJ-M, que escolhe, entre os possı́veis conjuntos
de mudanças primitivas para remover uma causa de falha, o menor conjunto. Ou o RRBJ-
H, que escolhe, heuristicamente, entre os possı́veis conjuntos de mudanças primitivas para
remover uma causa de falha, analisando os dois modelos em questão para que as mudanças
realizadas causem a menor quantidade de efeitos colaterais possı́veis. É possı́vel perceber
que nos casos em que a causa de falha tenha a forma (I) da Definição 7.2.2, existem
quatro possibilidades: a transição com a ação a já existir; a transição com a ação a não
existir; existir um estado que é um refinamento de literais de m; e não existir um estado
que seja refinamento de literais de m. A combinação destas possibilidades nos leva às
seguintes condições possı́veis: existir uma transição must que leva a um estado que não
é um refinamento de literal de m; existir uma transição may que leva a um estado que
não é um refinamento de literal de m; existir um estado que é refinamento de literal de
7.3 ALGORITMO DE REPARO DE REFINAMENTO BASEADO NO JOGO DE REFINAMENTO113
m, mas não existir nenhuma transição para ele; existir um estado que é refinamento de
literal de m, e existe uma transição may para ele. Nos casos onde apenas a transição
não é must, a melhor mudança é alterar a modalidade da transição. Nos outros casos, é
necessário analisar, no jogo de refinamento, qual a mudança que pode ser realizada que
não altere as relações de refinamento entre estados já existentes.
Uma série de outras variantes do RRBJ são possı́veis, inclusive combinações das vari-
antes descritas acima são possı́veis. Todavia, o presente trabalho foca no RRBJ, RRBJ-C
e RRBJ-U. O estado e análise das outras variantes faz parte do conjunto de trabalhos
futuros.
Figura 7.5 Examplo de uma solução não minimal retornada pelo algoritmo de reparo de
refinamento.
locais, outros estados, transições ou proposições são alterados pelas mudanças primitivas
para remover as causas de falhas. Estas modificações no modelo podem indiretamente
remover outras causas de falhas que não possuı́am um reparo possı́vel. Como o RRBJ
realiza o reparo de cada causa de falha isoladamente, após cada reparo, um novo modelo
gerado e causas de falhas que não possuı́am solução agora podem passar a ter. Um
raciocı́nio análogo explica porque o RRBJ-C pode encontrar mais soluções que o RRBJ-
U.
Um problema do algoritmo de reparo de refinamento apresentado no presente trabalho
é que ele retorna como soluções modelos que não são minimais em relação ao conjunto
de mudanças aplicadas, isto é, considerando que ele retorne como solução os modelos N 1
e N 2 , o conjunto de mudanças primitivas usados para gerar N 1 pode estar contido no
conjunto de mudanç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 soluções retornadas na execução de RRBJ pM, N q estã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 não
deveria retornar como solução um modelo gerado por um conjunto de mudanças primitivas
não minimais porque: (1) os modelos retornados perdem ou ganham comportamentos
(leia-se transições e valorações das proposições) que não eram necessários; e (2) isto não é
interessante no ponto de vista de desenvolvimento de software pois, suponha que N fosse
um modelo retirado do código-fonte de um software que deve ser modificado para manter
a relação de refinamento com o modelo M (especificação para este código fonte). Caso os
projetistas escolham tomar como base o modelo N 2 mais alterações seriam necessárias e,
possivelmente, isto implicaria em um maior custo.
Esta limitação pode ser contornada, verificando, dentre as soluções encontradas, quais
são formadas por conjuntos minimais, o que acarretaria em um maior custo computacional
ao algoritmo. Todavia, esta parte não foi desenvolvida neste trabalho e foi listada nos
trabalhos futuros.
Por fim, podemos argumentar que a complexidade do RRBJ é exponencial em relação
aos tamanhos dos modelos de entrada. A Proposição 7.3.3 demonstra este fato.
I II
onde (I) e (II) representam o número máximo de vértices alcançados pelos conjuntos
VD1 e VD2 , respectivamente.
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
Figura 7.8 Modelos resultantes das possı́veis mudanças para remover a causa de falha cf1
Figura 7.9 Modelos resultantes das possı́veis mudanças para remover a causa de falha cf2
Figura 7.10 Modelos resultantes das possı́veis mudanças para remover a causa de falha cf3
junto de modelos obtidos com cada um destes conjuntos de mudança é 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:
2. RRBJ-C: o RRBJ-C analisará se cada causa de falha possui pelo menos um conjunto
de mudanças que pode remove-la. Neste exemplo, as causas de falha cf1 , cf2 e cf3
possuem mudanças que a removem, e por isto, o RRBJ-C aplica as mudanç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
Este processo é repetido por cada variante. Ao final do processamento, um dos mo-
delos obtidos como solução é apresentado na Figura 7.11.
inviável na prática (modelos com 2 estados levavam mais de 5 minutos para serem re-
solvidos e geravam exceções de falta de memória) e, por isto, foi removido das análises.
Geramos casos de testes de forma similar aos realizados em (BENEš et al., 2011), variando
a quantidade de estados, número de transições entre os estados e o número de proposições
nos estados. Para validar a correção do algoritmo, dois grupos de testes foram criados,
cada um com 500 testes e cada teste consistia em uma especificação M e um modelo
N. No primeiro grupo de teste, o GRUPO-A, o modelo N era gerado a partir de um
número aleatório de modificações nas proposições dos estados, nas transições (podendo
ser alteração de ação, remoção de transição ou alteração de modalidade). Desta forma,
sempre foi possı́vel modificar N para alcançar como solução pelo menos um modelo que
fosse refinamento de M. O segundo grupo de teste, o GRUPO-B, foi feito da maneira a
não possuir soluções, isto é, M foi gerado aleatoriamente para ter todos os seus estados
distintos e um N era gerado aleatoriamente também com menos estados que M. A possi-
bilidade de adição de estados foi desabilitada e assim, nã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 solução e NÃO caso contrário.
Caso algum algoritmo respondesse NÃO para o GRUPO-A ou SIM para o GRUPO-
B, a entrada era inspecionada e corrigida e/ou em caso necessário o(s) algoritmos eram
reparados (ou seja, a implementação possuı́a erros). Nos casos de alteração na entrada ou
no algoritmo, todo o processo era repetido para todos os algoritmos. No fim desta etapa,
23 correções foram necessárias e todos os algoritmos apresentavam os mesmos resultados.
A quantidade de soluções encontradas não foi levada em consideração, apenas o fato de
encontrar pelo menos uma solução ou não.
Após a etapa de validação, foram gerados testes para analisar o tempo de execução dos
algoritmos. Como podemos analisar pela expressão da complexidade, o fator primário que
influencia no tempo de execução é a quantidade de causas de falhas encontradas. Todavia,
algumas variáveis influenciam de forma secundária o tempo de execução: quantidade de
estados, quantidade de transições e quantidade de proposições por estado. Assim, quatro
grupos de testes baseados em quatro combinações dos valores das variáveis secundárias
foram criados. Os grupos e os valores das variáveis podem ser vistos na Tabela 7.1.
Cada grupo é composto por 07 blocos, de forma que cada bloco contém 10 testes e
cada teste é composto pela especificaçã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
120 REPARO DE REFINAMENTO
Grupo
Variável
GRUPO-UM GRUPO-DOIS GRUPO-TRES
Nº de estados 2 5 8
Nº de transições 2 3 4
Nº de proposições 3 3 4
Nº modificações
2 2 2
em transições
Nº modificações
2 2 2
em proposições
Tabela 7.1 Variáveis de acordo com o grupo de teste
Figura 7.13 Gráfico do tempo médio de execução, em milissegundos, dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-UM
Figura 7.14 Gráfico do tempo médio de execução, em milissegundos, dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-DOIS
Figura 7.15 Gráfico do tempo médio de execução, em milissegundos, dos algoritmos de reparo
de refinamento por quantidade de causas de falha do GRUPO-TRES
7.3 ALGORITMO DE REPARO DE REFINAMENTO BASEADO NO JOGO DE REFINAMENTO123
Figura 7.16 Gráfico do tempo médio de execuçã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 solução dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-TRES
Figura 7.17 Quantidade de modelos encontrados como solução dos algoritmos de reparo de
refinamento por quantidade de causas de falha do GRUPO-TRES
124 REPARO DE REFINAMENTO
1. É possı́vel usar técnicas de programação dinâmica para reusar as soluções já pro-
duzidas para as causas de falhas já analisadas;
3. É possı́vel definir algumas heurı́sticas para evitar analisar todos os casos das possı́veis
mudanças. Estas heurı́sticas podem utilizar informações do jogo de refinamento
para fazer modificações sem gerar (ou gerando o mı́nimo possı́vel) novas causas de
falhas.
Capı́tulo
8
“Nós só podemos ver um pouco do futuro, mas o suficiente para perceber que há muito a fazer”, Alan
Turing
CONCLUSÕES
Neste trabalho, apresentamos como sistemas de transições modais de kripke podem ser
utilizados no processo de desenvolvimento de software com informaçõ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 várias
perspectivas: sı́ntese de modelos; relações e operações sobre os modelos; verificação de
refinamento; e reparo de refinamento.
125
126 CONCLUSÕES
A relação de refinamento modal forte definida pode ser utilizada para analisar se as
propriedades de um modelo são preservadas em outro modelo e difere de outras relações
de refinamento previamente definidas na literatura por levar em consideração as ações
nos modelos e as indefinições nos estados. Baseado na relação de refinamento modal
forte, uma definição de refinamento completo foi proposta e a relação entre modelos
determinı́sticos e estas duas definições de refinamento foi estudada.
O operador de composição paralela proposto gera um único modelo KMTS que repre-
senta a execução em paralelo de diversos modelos KMTS através de interleaving e troca
de mensagens sı́ncronas nas ações compartilhadas entre os modelos, de forma similar
ao definido na literatura para outros modelos comportamentais parciais. O conceito de
composicionalidade entre dois modelos também foi definido e reflete quando dois modelos
podem ser executados em paralelo sem que a composição atinja algum estado inconsis-
tente no que diz respeito às proposições dos estados. A análise das proposições no estado
da composição também pode ser usada para inferir valores de proposições definidas pelo
usuário como indefinidas, auxiliando assim o trabalho de análise de requisitos.
O operador de conjunção proposto unifica dois modelos em um único modelo tal
que represente a interseção do comportamento dos dois modelos. O comportamento
obrigatório de ambos os modelos é preservado e o comportamento possı́vel dos modelos
é preservado quando o comportamento possı́vel é definido nos dois modelos. Todavia,
nem sempre é possı́vel unir dois modelos, e para detectar quando a união é possı́vel,
definimos o conceito de consistência entre modelos KMTS, de forma similar aos trabalhos
relacionados.
Propomos um jogo para analisar o refinamento entre dois modelos KMTS. Até onde
sabemos, nenhum outro trabalho propõ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 série de regras do jogo sobre modelos MTS. O
presente trabalho, além de caracterizar o jogo com uma série de regras, o caracteriza como
um grafo, mostrando a relação do grafo com as regras e com a relação de refinamento.
Por fim, um algoritmo para geração do jogo de refinamento entre modelos KMTS é
apresentado, estudado e validado, mostrando a natureza polinomial deste problema.
das, estes algoritmos também podem ser utilizados para ajudar a reparar modelos que
não possuem uma relação de refinamento com sua especificação.
8.5 CONTRIBUIÇÕES
Este trabalho traz contribuições tanto no estudo dos modelos parciais quanto na sua
aplicação no desenvolvimento de software.
Citamos como contribuição no estudo de modelos parciais as definições, operaçõ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 existência da relação
de refinamento através do jogo de refinamento proposto possui uma performance que
pode ser utilizada na prática, e por isto este resultado é interessante. Sobre o algoritmo
de reparo de refinamento, ate onde sabemos, este é o primeiro algoritmo proposto para
reparar um modelo comportamental parcial de forma a garantir uma relação de refina-
mento. Também acreditamos que este algoritmo pode ser usado para prover suporte na
área de análise de impacto no contexto de desenvolvimento de software incremental e
iterativo. O impacto de uma mudança pode ser mensurado associando pesos para cada
tipo de mudança primitiva e calculando o custo de mudança para cada modelo produzido
pelo algoritmo de reparo de refinamento.
Do lado do desenvolvimento de software em meio à presença de conhecimento parcial,
o presente trabalho traz como uma das contribuições a análise das caracterı́sticas, propri-
edades e operações sobre KMTS neste contexto. Além disto, a presente abordagem utiliza
diagramas consolidados em projetos de desenvolvimento de software para gerar modelos
comportamentais na presença de conhecimento parcial. Utilizar os modelos KMTS pos-
sibilita o uso de técnicas de verificação formal para análise e evolução dos componentes
de um software. O uso destas técnicas adicionará mais uma camada de análise nos mo-
delos comportamentais, trazendo maior confiabilidade ao modelo proposto e ocultando
do usuário a complexidade do processo de verificação formal. Isto pode tornar a presente
proposta aplicável na prática durante um processo real de desenvolvimento de software.
A partir das contribuições na construção, análise e reparo de modelos KMTS, o pre-
sente trabalho define a base para um framework formal que pode ser utilizado na cons-
trução e evolução de software com informação incompleta.
3. Reparo de refinamento
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. 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.
BENEš, N.; ČERNá, I.; KřETı́NSKý, 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.
129
130 REFERÊNCIAS BIBLIOGRÁFICAS
BENEš, 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.
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.
CHA, S.-H. On complete and size balanced k-ary tree integer sequences. Citeseer.
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.
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.
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
132 REFERÊNCIAS BIBLIOGRÁFICAS
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.
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.
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. 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.
REFERÊNCIAS BIBLIOGRÁFICAS 133
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.
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.
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.
OMG. UML 2.4.1. 2011. Último acesso em 30 de Janeiro de 2015. Disponı́vel em: view-
source:http://www.omg.org/spec/UML/2.4.1/.
134 REFERÊNCIAS BIBLIOGRÁFICAS
OMG. OCL 2.4. 2014. Último acesso em 30 de Janeiro de 2015. Disponı́vel em: view-
source:http://www.omg.org/spec/OCL/2.4/.
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.
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.
SOMMERVILLE, I. Engenharia de Software. 9th. ed. São Paulo, SP, BR: Pearson Pren-
tice Hall, 2011. ISBN 9788579361081.
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.
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.
A
TÓPICOS DE ENGENHARIA DE SOFTWARE
A.1 CENÁRIOS
Diagramas de sequência, definidos pela UML, permitem modelar interações entre atores
e objetos do sistema ou entre os objetos, definindo uma ordem de execução (OMG, 2011).
Um diagrama de sequência descreve as interações que ocorrem num caso de uso ou em
uma instância do mesmo, expressando apenas parcialmente o comportamento pretendido,
possı́vel ou proibido do sistema (RUNDE; REFSDAL; STøLEN, 2013).
Na Figura A.1, são identificados os principais elementos que compõem um diagrama
de sequência:
137
138 TÓPICOS DE ENGENHARIA DE SOFTWARE
Figura A.1 Elementos do Diagrama de Sequência da UML 2.0. Adaptado de Lund e Stølen
(2006)
3. Descrever guardas, que representam condições que devem ser satisfeitas para dis-
parar determinados eventos/ações;
context GerenciadorLogin::LoginOK():void
pre: self.usuarioLogado = false
pos: self.usuarioLogado = true
Este par de regras definem que a precondição para a execução da ação LoginOK é que
a variável usuarioLogado seja falsa e após a execução desta ação esta variável será ver-
dadeira. Não apresentaremos no presente trabalho a sintaxe da OCL por entender que
o conhecimento da sintaxe não alterará o entendimento das soluções presentes neste tra-
balho. É suficiente para o leitor entender que é possı́vel indicar a entidade, o método
e especificar as pré e poscondições como expressões booleanas. Como dito acima, vale
destacar que a OCL vai além desta simples utilização.
Tanto o diagrama de sequência, com suas entidades e mensagens, a OCL, e suas re-
gras, são abstrações que descrevem os requisitos do software. Neste contexto, é possı́vel
interpretar o software como a composição de partes menores, isto é, de componentes. Esta
abordagem é voltada para o reuso da definição, implementação e composição de compo-
nentes independentes e fracamente acoplados em sistemas (SOMMERVILLE, 2011). Um
componente é parte do sistema, quase independente porém substituı́vel, com uma função
clara no contexto de uma modelagem de software bem definida (BROWN; WALLNAN,
1996). É possı́vel compor um componente ou criar um sistema a partir da composição
de outros componentes sem ter o conhecimento sobre suas implementações, apenas co-
nhecendo suas interfaces. A utilização de componentes está relacionada com o reuso de
partes de um ou mais sistemas já testadas e implementadas, mais rapidamente, seguindo
a ideia do desenvolvimento incremental (SOMMERVILLE, 2011).
Estas abstrações de software representam requisitos, mas nã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 é desenvolvido como
uma sequência de atividades (análise, projeto, desenvolvimento, teste e suporte). As
soluções presentes neste trabalho não se limitam a determinadas abordagens de desenvol-
vimento, todavia, o foco são abordagens onde o conhecimento do domı́nio não é completo
durante o desenvolvimento do software, como abordagens de desenvolvimento iterativas
e incrementais (PRESSMAN, 2005) quando o software é entendido como a composição
de componentes.
B
DEFINIÇÕES RELACIONADAS
B.1 BISSIMULAÇÃO
A bissimulação é uma relação binária entre sistemas de transição que associa sistemas
que possuem um comportamento idêntico, não sendo diferenciadas por um observador,
isto é, eles alcançam a mesma valoração (ou estados equivalentes) quando são submetidos
as mesmas ações.
3. LM psq LN ptq.
145
146 DEFINIÇÕES RELACIONADAS
Figura B.1 Dois sistemas de transição bissimilares representando uma máquina de vender
bebidas e refrigerante (BAIER; KATOEN; LARSEN, 2008)
mapeados entre si de forma que os estados relacionados alcancem também estados com
as mesmas valorações (que por sua vez estão relacionados também).
Todavia, apesar de bastante úteis na descrição comportamental, os sistemas de transições
não permitem especificar explicitamente conhecimento parcial pois, não é possı́vel expres-
sar modalidade diretamente sobre eles (BAIER; KATOEN; LARSEN, 2008).
da ocorrência das ações. As ações externas são as ações observáveis tanto pelo modelo
quanto por outros modelos.
A diferença entre os dois refinamentos está em considerar a ideia de estado alcançável
diretamente. Para o refinamento modal forte, um estado m1 só é alcançável diretamente
por um estado m se houver uma transição que os conecte. Para o refinamento modal fraco,
m1 é alcançável diretamente por m se houver um caminho formado obrigatoriamente por
uma transição com uma ação observável e, opcionalmente, por outras transições com
ações não-observáveis, não necessariamente nesta ordem.
q 99K
a
p99K
τ
qs1 com ps1, t1q P <.
Ao considerar as ações internas, o refinamento modal fraco reconhece como refina-
mento de um modelo M , certos modelos que não seriam um refinamento forte de M, por
permitir uma maior flexibilidade na comparação da estrutura dos dois modelos. De certa
forma, podemos comparar o refinamento forte e fraco com o refinamento de semântica
fechada e aberta, respectivamente. A Figura B.2 mostra um exemplo de dois modelos que
não possuem uma relação de refinamento forte, mas possuem uma relação de refinamento
fraco.
Figura B.2 Exemplo de dois modelos que não possuem relação de refinamento forte, mas
possuem uma relação de refinamento fraco
148 DEFINIÇÕES RELACIONADAS
C
PROVAS DO CAPÍTULO 6
(a) LA paq ¤ LB pbq: pela Definiçã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 entã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 composiçã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. É possı́vel deduzir pelas regras
da transições da Figura 5.2:
Se a1 pm1 , nq entã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 entã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 entã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 transição pa, t, a1 q P RA , existe
uma transição correspondente pb, t, b1 q P RB e pela definição de <, pa1 , b1 q P <.
149
150 PROVAS DO CAPÍTULO 6
M ||pN ||P q.
Demonstraçã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 relaçã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 são composicionáveis então sA0 ppm0 , n0 q, p0 q
e sB0 pm0 , pn0 , p0 qq, ou seja, psA0 , sB0 q P <. Vamos mostrar que < é uma relação
de refinamento pois, para todo pa, bq P < vale:
(a) LA paq ¤ LB pbq: pela Definiçã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 entã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 composiçã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 existência de t P ΣM , em ΣN ou t P ΣP ) sendo
m1 P SM , n1 P SN e p1 P SP estados quaisquer. É possı́vel deduzir pelas regras
de transições da Figura 5.2:
Se a1 ppm, n1 q, pq entã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 entã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 entã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 . Entã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 entã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 entã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 entã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 CAPÍTULO 6 151
gerar N ||P , existe ppn1 , p1 q, t, pn1 , p1 qq P RN ||P e entã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 entã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 entã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 entã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 entã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 transição pa, t, a1 q, existe uma
transição correspondente pb, t, b1 q em RB e pela definição de <, pa1 , b1 q P <.
entã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 : pelas regras da composiçã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 existência de t P ΣM , t P ΣN ou t P ΣP
e da modalidade da transição em M e N) sendo m1 P SM , n1 P SN e p1 P SP
estados quaisquer. É possı́vel deduzir pelas regras de transições que:
, pn, t, n1 q P R , pm, t, m1 q R
Se b1 pm, pn1 , pqq entã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
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: entã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 entã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: entã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: entã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
152 PROVAS DO CAPÍTULO 6
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: entã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: entã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 transição pb, t, b1 q, existirá uma
e pela definição de <, pa1 , b1 q P <.
transição equivalente pa, t, a1 qem RA
Assim, como A ¨ B e B ¨ A temos que A B, isto é, pM ||N q||P M ||pN ||P q.
Proposiçã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 são consistentes entre si sse existir uma relação
de consistência CM N entre M e N .
(Ð) Pela Definição 5.3.2 é suficiente mostrar que existe um modelo que é refinamento
de M e de N. Vamos mostrar que este modelo é CI pela relação de refinamento
< tpm, pm, nqq | pm, nq P CM N u, temos que M ¨ CI
LM pmq ¤ Lppm, nqq: por hipótese M e N estão relacionados por uma relação
de consistê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 relação de con-
sistência CM N ). Assim, pelas regras da Definição 5.3.2 (hipótese), para todo
pm, a, m1q P RM existe ppm, nq, a, pm1, n1qq P < e como pm1, n1q P CM N entã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 Definição 5.3.2 (hipótese), para todo ppm, nq, a, pm1 , n1 qq P
(ou R ).
< existe pm, a, m1 q P RM M
Logo M e N são consistentes entre si se, e somente se, existir uma relação de consistência
CM N entre M e N .
(b) se pa, t, a1 q P RA entã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 transições do operador de conjunção, o estado a1 só
pode ter a seguinte forma (m’, n’), isto é, 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 combinações, existe
N
uma transição pb, t, b1 q P RB tal que b1 pn1 , m1 q. Assim, para toda transição
pa, t, a1q P RA sempre existirá uma transição pb, t, b1q equivalente em RB e, pela
definição de <, pa1 , b1 q P <;
entã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 : pelas regras das transições no operador de conjunção, o estado
A
B ¨A : A prova deste item segue de maneira análoga a prova acima e por isto não será
apresentada.
Demonstração. Sejam M , N e P trê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) LA paq ¤ LB pbq: pela definição de função rotuladora (Definiçã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 entã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 transições do operador de conjunção, o
estado a1 ppm1 , n1 q, p1 q entã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
combinações, pelas regras de transições do operador de conjunção, sempre
existirá pb, t, b1 q P SB tal que b’ = (m’, (n’, p’)). Assim sempre existirá uma
transição equivalente em RB e, pela definição de <, pa1 , b1 q P <.
entã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
com
e t P ΣB : pela regra (1), o estado b1 pm1 , pn1 , p1 qq, isto é, 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’,
PROVAS DO CAPÍTULO 6 155
p’)). Assim, para toda transição pb, t, b1 q P RB , sempre existirá uma transição
pa, t, a1q P RA e, pela definição de <, pa1, b1q P <.
B ¨ A: A prova deste item segue de maneira análoga à prova acima e por isto não será
apresentada.
Demonstração.
(a) LM pmq ¤ LM ^N ppm, nqq: pela definição de função rotuladora (Definiçã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 são consistentes, para toda uma transição t
pm, a, m1q P RM existe pn, a, n1q P RN . Assim, pelas regras de transições do
operador de conjunção, para toda transiçã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 então pm, a, m q P
1 1 1 1 1
.
RM
(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 é, 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;
156 PROVAS DO CAPÍTULO 6
(b) p@p P LpnqqpLN pn, pq LM pm, pqouLM pm, pq Kq: a prova deste item segue
análoga a prova do item acima;
(c) p@l, m1qppm, a, m1q P RM , então existe pn, a, n1q P RN com pm1, n1q P C q: como
M ¨ X então para todo t pm, a, m1 q P RM existe um t1 px, ax1 q P RX , e
como N ¨ X então para todo t px, a, x1 q P RX existe um t1 pn, an1 q P R ,
isto é, 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 , então existe pm, a, m1q P RM com pm1, n1q P C q: a prova
deste item segue análoga a prova do item acima.
Como CM,N é uma relação de consistência, pela Proposição 5.3.2, M e N são consis-
tentes entre si e por isto M ^ N é definido.