Uso de Sistemas de Transições Modais de Kripke para Representacão de Comportamento Parcial no Desenvolvimento incremental e interativo de software

(1)

UNIVERSIDADE FEDERAL DA BAHIA

DISSERTAC

¸ ˜

AO DE MESTRADO

Sistemas de Transi¸

c˜

oes Modais de Kripke para Representa¸

c˜

ao de

Comportamento Parcial no Desenvolvimento Incremental e

Iterativo de Software

Efraim Zalmoxis de Almeida Machado

Programa de P´

os-Gradua¸

c˜

ao em Ciˆ

encia da Computa¸

c˜

ao

Salvador

(2)

(3)

EFRAIM ZALMOXIS DE ALMEIDA MACHADO

SISTEMAS DE TRANSIC

¸ ˜

OES MODAIS DE KRIPKE PARA

REPRESENTAC

¸ ˜

AO DE COMPORTAMENTO PARCIAL NO

DESENVOLVIMENTO INCREMENTAL E ITERATIVO DE

SOFTWARE

Esta

Disserta¸c˜

ao de Mestrado foi

apresentada ao Programa de P´

os-Gradua¸c˜

ao em Ciˆ

encia da

Com-puta¸c˜

ao da Universidade Federal da

Bahia, como requisito parcial para

obten¸c˜

ao do grau de

Mestre em

Ciˆ

encia da Computa¸c˜

ao.

Orientadora: Aline Maria Santos Andrade

Salvador

(4)

Sistema de Bibliotecas - UFBA Machado, Efraim Zalmoxis de Almeida.

Sistemas de Transi¸c˜oes Modais de Kripke para Representa¸c˜ao de Com-portamento Parcial no Desenvolvimento Incremental e Iterativo de Software / Efraim Zalmoxis de Almeida Machado – Salvador, 2016.

154p.: il.

Orientadora: Prof. Dr. Aline Maria Santos Andrade.

Disserta¸c˜ao (Mestrado) – Universidade Federal da Bahia, Instituto de Matem´atica, 2016.

1. KMTS. 2. Informa¸cão Parcial. 3. Desenvolvimento de Software. 4. Conjun¸cão. 5. Composi¸cão Paralela. 6. Jogo de Refinamento. 7. Reparo de Refinamento. I. Andrade, Aline Maria Santos. II. Universidade Federal da Bahia. Instituto de Matemática. III T´ıtulo.

CDD – XXX.XX CDU – XXX.XX.XXX

(5)

TERMO DE APROVAC

¸ ˜

AO

EFRAIM ZALMOXIS DE ALMEIDA MACHADO

SISTEMAS DE TRANSIC

¸ ˜

OES MODAIS DE

KRIPKE PARA REPRESENTAC

¸ ˜

AO DE

COMPORTAMENTO PARCIAL NO

DESENVOLVIMENTO INCREMENTAL E

ITERATIVO DE SOFTWARE

Esta Disserta¸cão de Mestrado foi julgada adequada à obten¸cão do t´ıtulo de Mestre em Ciência da Computa¸cão e aprovada em sua forma final pelo Programa de Pós-Gradua¸cão em Ciência da Computa¸cão da Universidade Federal da Bahia.

Salvador, 30 de Novembro de 2016

Profa. Dra. Aline Maria Santos Andrade Universidade Federal da Bahia Prof. Dr. Adolfo Almeida Duran

Universidade Federal da Bahia

Prof. Dr. Alexandre Cabral Mota Universidade Federal de Pernambuco

(6)

(7)

Este trabalho é dedicado a todos que, de forma direta ou indireta, contribu´ıram para que eu o conclu´ısse, sem esque-cer daqueles que sentiram minha ausência neste per´ıodo, mas aceitaram e compreenderam que, muitas vezes, minha falta era necessária.

(8)

(9)

AGRADECIMENTOS

Agrade¸co à minha orientadora, Profª Dra. Aline Andrade, pela paciência em ter me ouvido, pela dedica¸cão em ter me ensinado e por todo incentivo dado. Esta aten¸cão foi muito importante para que eu conclu´ısse minha disserta¸cão e por isto, serei eternamente grato.

Agrade¸co 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.

(10)

(11)

Andar sobre as águas e fazer software a partir de uma especifica¸cão é simples se ambas estiverem congeladas. —EDWARD V BERARD

(12)

(13)

RESUMO

O projeto de software, na abordagem iterativa e incremental, lida com novos requisitos ao longo do desenvolvimento, que implicam em constantes mudan¸cas no projeto, e me-canismos que deem suporte para o desenvolvimento na presen¸ca de informa¸cão parcial e incompleta são importantes para reduzir o impacto dessas mudan¸cas. Expressar incerte-zas a respeito do comportamento pretendido do software (ou dos seus componentes) pode evitar a tomada de decisões precipitadas, que poderiam acarretar em erros de projeto. Neste contexto, diversos trabalhos utilizam sistemas de transi¸cões modais na modelagem de sistemas, que permitem expressar incerteza de forma expl´ıcita através de modalidades em suas transi¸cões.

Um Sistema de Transi¸cão Modal de Kripke (KMTS) além de conter modalidades em suas transi¸cões, também expressa indefini¸cões em n´ıvel de proposi¸cões nos estados. A in-determina¸cão nos estados é interessante, pois permite que vários estados sejam abstra´ıdos em um mesmo estado, evitando uma defini¸cão prévia de todos os estados do sistema nas fases iniciais do desenvolvimento. Todavia, existem poucos trabalhos que utilizam KMTS para especifica¸cão parcial aplicados no desenvolvimento de software.

O presente trabalho estuda o uso de modelos KMTS para explicitar informa¸cões par-ciais durante o desenvolvimento de software, trazendo contribui¸cões na cria¸cão, na análise e no reparo destes modelos. Em rela¸cão à cria¸cão de modelos, propomos um algoritmo de s´ıntese de modelos KMTS a partir de diagramas de sequência, que é uma adapta¸cão de um algoritmo proposto na literatura para Modal Transition System (MTS). Em rela¸cão `

a análise de modelos, definimos as opera¸cões de conjun¸cão e de composi¸cão paralela bem como a rela¸cão de refinamento modal forte para modelos KMTS. O conceito de refinamento para KMTS é também caracterizado nessa disserta¸cão como um jogo e um algoritmo para o jogo do refinamento é proposto, discutido e validado. A contribui¸cão no reparo de modelos se dá através do estudo do problema de reparo do refinamento para KMTS, isto é, como alterar um modelo KMTS para que ele seja um refinamento de outro modelo KMTS. Para este problema, algoritmos são também propostos, discutidos e vali-dados. Entendemos que esta solu¸cão poderá trazer contribui¸cões no reparo automático de modelos e pode ser aplicada, por exemplo, na análise de impacto de mudan¸cas para de-terminar qual a mudan¸ca menos custosa a se fazer em um determinado modelo de forma a satisfazer determinadas propriedades. A partir das contribui¸cões na constru¸cão, análise e reparo de modelos KMTS, o presente trabalho define uma base para um framework formal que pode ser utilizado na constru¸cão e evolu¸cão de modelos comportamentais de software.

Palavras-chave: KMTS; Informa¸cão Parcial; Desenvolvimento de Software; Con-jun¸cão; Composi¸cão Paralela; Jogo de Refinamento; Reparo de Refinamento;

(14)

(15)

ABSTRACT

The software design, in the iterative and incremental approach, deals with new require-ments throughout development that imply constant changes in the design, and mecha-nisms that support development in the presence of partial and incomplete information are important to reduce the impact of these Changes. Expressing uncertainties about the intended behavior of the software (or its components) can avoid making hasty decisions that could lead to design errors. In this context, several studies use modal transition system to modeling systems and to express explicitally uncertainty through modalities in their transitions.

A Kripke Modal Transition System (KMTS), besides containing modalities in its transitions, also expresses propositional level indefinits in the states. Indeterminacy in states is interesting because it allows several states to be abstracted in the same state, avoiding a prior definition of all states of the system in the early stages of development. However, there are few papers that use KMTS for partial specification applied in software development.

The present work studies the use of KMTS models to represent partial information du-ring software development, introduzing contributions in the creation, analysis and repair of these models. In relation to the modeling, we propose an algorithm for the synthesis of KMTS models from sequence diagrams, which is an adaptation of an algorithm proposed in the literature for Modal Transition System (MTS). In relation to the model analysis, we define the conjunction and parallel composition operations as well as the strong mo-dal refinement relation for KMTS models. The concept of refinement for KMTS is also characterized in this dissertation as a game and an algorithm for the refinement game is proposed, discussed and validated. The contribution in model repair is through the study of the refinement repair problem for KMTS, that is, how to change a KMTS model so that it is a refinement of another KMTS model. For this problem, algorithms are also proposed, discussed and validated. We believe that this solution can bring contributions to automatic model repair and can be applied, for example, in the impact analysis of changes to determine which is the least costly change to be made in a given model in order to satisfy certain properties

From the contributions in the construction, analysis and repair of KMTS models, the present work defines a basis for a formal framework that can be used in the construction and evolution of software behavioral models.

Keywords: KMTS; Partial Information; Software Development; Conjunction; Parallel Composition; Refinement Game; Refinement Repair;

(16)

(17)

SUM ´

ARIO

Cap´ıtulo 1—Introdu¸c˜ao 1

1.1 Escopo do Trabalho e Contribui¸c˜oes . . . 4

1.2 Organiza¸c˜ao da Disserta¸c˜ao . . . 6

Cap´ıtulo 2—Modelos Comportamentais 7 2.1 Modelos de Software . . . 7

2.2 Sistemas de Transi¸c˜ao e Especifica¸c˜oes Modais . . . 8

2.2.1 Simula¸c˜ao . . . 9

2.2.2 Especifica¸c˜oes Comportamentais Parciais . . . 10

2.2.3 KMTS . . . 11

2.3 Teoria das Especifica¸c˜oes Parciais . . . 12

2.3.1 Rela¸c˜ao de Refinamento . . . 13

2.3.2 Operador de Composi¸c˜ao Paralela . . . 17

2.3.3 Operador de Conjun¸c˜ao . . . 17

Cap´ıtulo 3—Trabalhos Relacionados 21 3.1 Modelos Comportamentais Parciais . . . 21

3.1.1 Sistema de Transi¸c˜ao Modal de Kripke . . . 23

3.2 Constru¸cão de Especifica¸cões Parciais no Desenvolvimento de Software . 24 3.3 Análise de Especifica¸cões Parciais no Desenvolvimento de Software . . . . 26

3.3.1 Jogo de Refinamento . . . 27

3.4 Reparo de Refinamento . . . 27

3.5 Posicionamento do Presente Trabalho em Rela¸c˜ao aos Demais . . . 28

Cap´ıtulo 4—S´ıntese de Modelos KMTS a partir de Cen´arios 29 4.1 Modelos KMTS com A¸c˜oes . . . 30

4.2 Algoritmo para S´ıntese de KMTS . . . 30

4.2.1 Entradas e Sa´ıdas . . . 30

4.3 Etapas do Algoritmo para S´ıntese de KMTS . . . 34

4.3.1 Etapa I: Restri¸c˜oes por Componente . . . 34

4.3.2 Etapa II: Diagrama de Sequˆencia por Componente . . . 36

4.3.3 Etapa III: KMTS Inicial por Componente . . . 38

4.3.4 Etapa IV: Comportamento Obrigat´orio por Componente . . . 42

4.4 An´alise do Algoritmo de S´ıntese . . . 44

4.5 Valida¸c˜ao do Algoritmo de S´ıntese . . . 47 xv

(18)

xvi SUM ´ARIO

Cap´ıtulo 5—Rela¸c˜oes e Opera¸c˜oes para Modelos KMTS 49

5.1 Refinamento de KMTS . . . 49

5.1.1 Propriedades da Rela¸c˜ao de Refinamento . . . 52

5.1.2 Rela¸c˜ao de Refinamento no Desenvolvimento de Software . . . 53

5.2 Composi¸c˜ao Paralela para Modelos KMTS . . . 57

5.2.1 Propriedades do Operador de Composi¸c˜ao Paralela . . . 59

5.2.2 Exemplo de Opera¸c˜ao de Composi¸c˜ao Paralela no Desenvolvimento de Software . . . 60

5.3 Conjun¸c˜ao de Modelos KMTS . . . 61

5.3.1 Propriedades do Operador de Conjun¸c˜ao . . . 64

5.3.2 Exemplo de Opera¸cão de Conjun¸cão no Desenvolvimento de Software 65 Cap´ıtulo 6—Jogo do Refinamento 69 6.1 Defini¸cão Intuitiva do Jogo de Refinamento . . . 69

6.2 Jogo do Refinamento Como um Grafo . . . 73

6.3 Algoritmo do Jogo de Refinamento . . . 78

6.3.1 An´alise do Algoritmo do Jogo de Refinamento . . . 80

6.3.2 Valida¸c˜ao do Algoritmo do Jogo de Refinamento . . . 82

Cap´ıtulo 7—Reparo de Refinamento 91 7.1 O Problema do Reparo de Refinamento . . . 91

7.1.1 Representando Mudan¸cas em Modelos KMTS . . . 92

7.1.2 An´alise do Problema do Reparo de Refinamento . . . 94

7.1.3 Uma Solu¸c˜ao Algor´ıtmica para o Reparo de Refinamento . . . 100

7.2 Reparo de Refinamento Baseado no Jogo do Refinamento . . . 102

7.3 Algoritmo de Reparo de Refinamento Baseado no Jogo de Refinamento . 107 7.3.1 Varia¸c˜oes do RRBJ . . . 109

7.3.2 An´alise do RRBJ . . . 110

7.3.3 Exemplo de Execu¸c˜ao do RRBJ e Algumas de Suas Varia¸c˜oes . . 113

7.3.4 Valida¸c˜ao dos Algoritmos de Reparo . . . 116

Cap´ıtulo 8—Conclus˜oes 123 8.1 S´ıntese de KMTS a partir de Cen´arios . . . 123

8.2 Rela¸cão de Refinamento e Opera¸cões de Composi¸cão Paralela e Conjun¸cão 123 8.3 Jogo de Refinamento . . . 124

8.4 Reparo do Refinamento . . . 124

8.5 Contribui¸c˜oes . . . 125

8.6 Trabalhos Futuros . . . 125

Apêndice A—Tópicos de Engenharia de Software 135 A.1 Cenários . . . 135

(19)

SUM ´ARIO xvii

A.2 Diagrama de Sequˆencia . . . 135

A.3 Object Constraint Language (OCL) . . . 136

A.4 Desenvolvimento Incremental e Iterativo . . . 138

A.4.1 Especifica¸c˜ao e Implementa¸c˜ao . . . 140

Apêndice B—Defini¸cões Relacionadas 143 B.1 Bissimula¸cão . . . 143

B.2 Sistema de Transi¸c˜ao Modal - MTS . . . 144

B.3 Variantes do Refinamento Modal Forte . . . 144

(20)

(21)

LISTA DE FIGURAS

1.1 Visão de alto-n´ıvel de um processo de desenvolvimento que utiliza KMTS suportado por métodos formais . . . 5 2.1 Dois sistemas de transi¸cão onde N simula o comportamento de M (BAIER;

KATOEN; LARSEN, 2008) . . . 9 2.2 Exemplo do sinal de trˆansito . . . 11 2.3 Uma estrutura de Kripke . . . 12 2.4 Exemplo de refinamento. A casa mais detalhada ´e um refinamento da

outra casa. Adaptado de Fairbanks (2010) . . . 13 2.5 Exemplo de refinamento com semˆantica fechada (A) e semˆantica aberta

(B). A casa mais detalhada é um refinamento da outra casa. Adaptado de Fairbanks (2010) . . . 14 2.6 Um modelo parcial M e uma implementa¸cão N . . . 15 2.7 Dois modelos parciais que não possuem uma rela¸cão de refinamento modal 15 2.8 Uma especifica¸cão mista que não possui implementa¸cões . . . 16 2.9 Duas especifica¸cões mistas M e N com IpMq IpNq, mas não vale M ¨ N 16 2.10 Exemplo da incompletude da rela¸cão de refinamento modal em rela¸cão ao

operador de composi¸c˜ao paralela . . . 18 2.11 Exemplos de MRC em (A) e de RCM em (B) . . . 19 3.1 Vis˜ao geral do algoritmo de s´ıntese de MTS proposto por Krka et al. (2009)

(KRKA et al., 2009) . . . 25 4.1 Diagrama de sequˆencia de solicita¸c˜ao e acesso do componente Recurso pelo

componente Módulo . . . 33 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 . . . 34 4.3 Diagrama de sequência estendido antes (A) e depois da propaga¸cão (B)

para o componente Módulo baseado no diagrama de sequência da Figura 4.1 38 4.4 KMTS inicial do componente Módulo da Figura 4.1 . . . 41 4.5 Opera¸cão de Refino para evitar auto-loop obrigatório . . . 42 4.6 KMTS inicial do componente Módulo . . . 44 5.1 KMTSs representando os poss´ıveis comportamentos da câmera. Em (A)

uma especifica¸cão do comportamento da câmera. Em (B) um poss´ıvel refi-namento da especifica¸cão mostrada em (A). Em (C) um modelo de compor-tamento da câmera que não é um refinamento da especifica¸cão mostrada em (A). . . 51

(22)

xx LISTA DE FIGURAS 5.2 Regras das transi¸c˜oes do operador de composi¸c˜ao paralela . . . 58 5.3 Modelos KMTS para o software de vistoria remota, onde (A) representa o

e-Formulário e (B) o sincronizador. . . 61 5.4 Composi¸cão paralela dos modelos e-Formulário e Sincronizador. . . 62 5.5 Regras do transi¸cões do operador de conjun¸cão . . . 63 5.6 Duas versões do componente e-Formulário para atender a requisitos de

georreferenciamento e fotografia . . . 66 5.7 Conjun¸c˜ao entre os modelos exibidos na Figura 5.6 . . . 66 6.1 Dois KMTS M, N, onde vale M ¨ N. . . 71 6.2 Configura¸c˜oes poss´ıveis de um jogo de refinamento entre os modelos M e

N da Figura 6.1 . . . 74 6.3 Jogo do refinamento entre os modelos M e N da Figura 6.1 expressos em

um grafo . . . 75 6.4 Estrutura dos testes realizados por grupo . . . 84 6.5 Gráfico do tempo médio de execu¸cão (milissegundos) do algoritmo do jogo

de refinamento de acordo com a quantidade de estados . . . 85 6.6 Gráfico do tempo médio de execu¸cão (milissegundos) do algoritmo do jogo

de refinamento de acordo com a quantidade de transi¸cões por estado . . . 86 6.7 Gráfico do tempo médio de execu¸cão (milissegundos) do algoritmo do jogo

de refinamento de acordo com a quantidade de proposi¸cões por estado . . 86 6.8 Gráfico do tempo médio de execu¸cão (milissegundos) do algoritmo do jogo

de refinamento de acordo com o crescimento proporcional do modelo . . . 87 6.9 Gráfico do cruzamento dos dados do Grupo-estado e Grupo-proporcao . . 88 7.1 Gráfico do tempo de execu¸cão (em milissegundos) do Algoritmo 10 em

rela¸cão número de mudan¸cas primitivas aplicáveis . . . 101 7.2 Dois Modelos M e N tal que M ª N e duas sa´ıdas do algoritmo RRE . . 101 7.3 Jogo de refinamento entre os modelos M e N da Figura 7.1 . . . 102 7.4 Exemplo de execu¸cão do algoritmo de reparo de refinamento entre os

mo-delos M e N . . . 107 7.5 Examplo de uma solu¸c˜ao n˜ao minimal retornada pelo algoritmo de reparo

de refinamento. . . 112 7.6 Modelos M e N tal que M ª N . . . 114 7.7 Jogo do refinamento entre os modelos M e N da Figura 7.6(A) e entre os

modelos M e N 9 da Figura 7.10 . . . 114 7.8 Modelos resultantes das poss´ıveis mudan¸cas para remover a causa de falha

cf1 . . . 115

7.9 Modelos resultantes das poss´ıveis mudan¸cas para remover a causa de falha cf2 . . . 115

7.10 Modelos resultantes das poss´ıveis mudan¸cas para remover a causa de falha cf3 . . . 115

7.11 Um modelo resultante do processo de reparo de refinamento pelos algorit-mos RRBJ, RRBJ-C e RRBJ-U . . . 116

(23)

LISTA DE FIGURAS xxi 7.12 Estrutura dos testes realizados por grupo . . . 118 7.13 Gráfico do tempo médio de execu¸cão, em milissegundos, dos algoritmos de

reparo de refinamento por quantidade de causas de falha do GRUPO-UM 118 7.14 Gráfico do tempo médio de execu¸cão, em milissegundos, dos algoritmos de

reparo de refinamento por quantidade de causas de falha do GRUPO-DOIS 119 7.15 Gráfico do tempo médio de execu¸cão, em milissegundos, dos algoritmos de

reparo de refinamento por quantidade de causas de falha do GRUPO-TRES120 7.16 Gráfico do tempo médio de execu¸cão, em milissegundos, do algoritmo

RRBJ por quantidade de causas de falha e por grupo . . . 121 7.17 Quantidade de modelos encontrados como solu¸c˜ao dos algoritmos de reparo

de refinamento por quantidade de causas de falha do GRUPO-TRES . . 121 A.1 Elementos do Diagrama de Sequˆencia da UML 2.0. Adaptado de Lund e

Stølen (2006) . . . 136 A.2 Exemplo de diagrama de sequência do fluxo de login . . . 137 A.3 Modelo de desenvolvimento incremental . . . 139 A.4 Modelo de desenvolvimento iterativo . . . 140 A.5 Modelo de desenvolvimento iterativo e incremental . . . 141 B.1 Dois sistemas de transi¸cão bissimilares representando uma máquina de

vender bebidas e refrigerante (BAIER; KATOEN; LARSEN, 2008) . . . . 144 B.2 Exemplo de dois modelos que n˜ao possuem rela¸c˜ao de refinamento forte,

mas possuem uma rela¸c˜ao de refinamento fraco . . . 145 B.3 Exemplo de refinamento fraco que contradiz o senso de refinamento . . . 146

(24)

(25)

LISTA DE TABELAS

6.1 Variáveis de acordo com o grupo de teste . . . 84 6.2 Tempo médio de execu¸cão (milissegundos) do algoritmo do jogo de

refina-mento de acordo com a quantidade de estados . . . 85 6.3 Tempo m´edio de execu¸c˜ao (milissegundos) do algoritmo do jogo de

refina-mento de acordo com a quantidade de transi¸cões por estado . . . 85 6.4 Tempo médio de execu¸cão (milissegundos) do algoritmo do jogo de

refina-mento de acordo com a quantidade de proposi¸cões por estado . . . 86 6.5 Tempo médio de execu¸cão (milissegundos) do algoritmo do jogo de

refina-mento de acordo com o crescirefina-mento proporcional do modelo . . . 87 7.1 Variáveis de acordo com o grupo de teste . . . 117 7.2 Tempo médio de execu¸cão, em milissegundos, dos algoritmos de reparo de

refinamento por quantidade de causas de falha do GRUPO-UM . . . 118 7.3 Tempo m´edio de execu¸c˜ao, em milissegundos, dos algoritmos de reparo de

refinamento por quantidade de causas de falha do GRUPO-DOIS . . . . 119 7.4 Tempo m´edio de execu¸c˜ao, em milissegundos, do algoritmos de reparo de

refinamento por quantidade de causas de falha do GRUPO-TRES . . . . 120 7.5 Quantidade de modelos encontrados como solu¸c˜ao dos algoritmos de reparo

de refinamento por quantidade de causas de falha do GRUPO-TRES . . 121

(26)

(27)

Cap´ıtulo

1

INTRODUC

¸ ˜

AO

Nos dias atuais, em um ambiente globalizado, onde mudan¸cas 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¸cão tanto do cliente quanto dos seus projetistas. Mudan¸cas 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¸cã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¸cão c´ıclica das quatro etapas de desenvol-vimento de software: análise de requisitos, projeto, implementa¸cão e teste. Esta inter-cala¸cão faz com que o software seja constru´ıdo em partes e, desta forma, durante o ciclo de desenvolvimento do mesmo, o cliente consegue definir melhor quais as suas necessidades, `

a medida que novos requisitos surgem. Outras abordagens complementares ao desenvol-vimento iterativo focam na constru¸cã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¸cão ainda mais desafiadora.

Neste contexto, uma das etapas mais complexas no processo de desenvolvimento é a constru¸cão do projeto, devido às recorrentes mudan¸cas que implicam em constante adapta¸cão de uma solu¸cã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¸cão ao conhecimento do problema e a necessidade de definir uma solu¸cão completa podem ter como consequência decisões

(28)

2 INTRODUC¸ ˜AO

precipitadas que acarretam em projetos incorretos. Erros no projeto implicam em refazer parte do trabalho j´a realizado e, consequentemente, em um maior custo.

Na fase de projeto, modelos são constru´ıdos para modelar componentes e o sistema como um todo. Muitas vezes os modelos propostos no projeto de um software são analisa-dos manualmente ou testaanalisa-dos através de um protótipo. Todavia, softwares são formados por componentes que interagem entre si ou com outros sistemas e, analisar ou testar o comportamento e a intera¸cão entre os modelos dos componentes é uma tarefa exaustiva, principalmente no contexto de constantes mudan¸cas do desenvolvimento iterativo e incre-mental. O uso de técnicas de verifica¸cão formal de modelos permite automatizar a análise da corre¸cão de modelos de sistemas e modelos de componentes (CLARKE; GRUMBERG; PELED, 1999).

Considerar poss´ıveis comportamentos do software pode auxiliar na elabora¸cão e im-plementa¸cão de projetos mais fiéis aos requisitos levantados e menos propensos a erros (D’IPPOLITO et al., 2008a). Quanto mais cedo os erros forem descobertos menos eles irão implicar no custo do software (VLIET; VLIET; VLIET, 1993), (BOEHM, 1984).

Existem diferentes modelos formais capazes de representar explicitamente informa¸cão parcial como em Uchitel, Kramer e Magee (2003a), em que os autores utilizam Modal Transition System (MTS) para representar comportamento parcial de sistemas. Existem outros modelos que estendem o MTS, aumentando sua expressividade, mas com a mesma finalidade, como Disjuntive Modal Transition System (BENEˇs; ˇCERNá; KˇrET´ıNSKý, 2011) ou o Parametric Modal Transition System (PMTS) (BENEˇs et al., 2011).

Um outro modelo proposto na literatura é o Kripke Modal Transition System (KMTS) (HUTH; JAGADEESAN; SCHMIDT, 2001a), que é um diagrama de transi¸cão de estados que permite expressar comportamentos requeridos e poss´ıveis através de indefini¸cões nos seus estados e modalidades nas suas transi¸cões. Os KMTS têm dois tipos de transi¸cões: obrigatórias e poss´ıveis, e seus estados podem ser definidos através de proposi¸cões que podem ser verdade (V), falso (F) ou indefinido (K). Assim, é poss´ıvel utilizar um KMTS para modelar, por exemplo, o comportamento de um componente de software, deixando expl´ıcitas as indefini¸cões presentes em seus estados e em suas intera¸cões. É válido ressaltar que nem o MTS nem suas extensões permitem o uso de indefini¸cões nos estados dos modelos, como o KMTS. A indetermina¸cão nos estados é interessante, pois permite que vários estados sejam abstra´ıdos em um mesmo estado, evitando uma defini¸cão prévia de todos os estados do sistema nas fases iniciais do desenvolvimento. Todavia, existem poucos trabalhos que utilizam KMTS como modelos para especifica¸cão parcial aplicados no desenvolvimento de software.

Independente do modelo utilizado, em cada ciclo, no contexto de desenvolvimento iterativo e incremental, três atividades são fundamentais: a constru¸cão dos modelos; a análise dos modelos; e o reparo dos modelos se for necessário. O presente trabalho traz contribui¸cões em cada uma destas atividades.

A cria¸cão de modelos formais (parciais) requer um conhecimento que não é comum entre os projetistas de software. Assim, apesar de métodos de análise/verifica¸cão for-mal serem eficazes, eles são menos empregados porque necessitam de expertise para a constru¸cão dos modelos. Projetistas de software, geralmente, representam os softwares através de linguagens informais ou semiformais como UML. Modelos comportamentais e

(29)

INTRODUC¸ ˜AO 3

de intera¸cão se limitam, muitas vezes, a diagramas de sequência (UCHITEL; KRAMER; MAGEE, 2003a). Como será mostrado posteriormente, existem algumas pesquisas que focam nesta atividade de forma a semi-automatizar a constru¸cão dos modelos parciais tanto a partir de artefatos comumente gerados antes da implementa¸cão dos requisitos quanto a partir do código-fonte. O presente trabalho contribui nesta atividade através da adapta¸cão de um algoritmo de s´ıntese de modelos parciais a partir de cenários (KRKA et al., 2009) para a constru¸cão de modelos KMTS a partir de diagramas de sequência ano-tados com OCL. Não tratamos neste trabalho o caminho inverso, isto é, gerar diagramas de sequência a partir de modelos KMTS.

Em rela¸cão à análise de modelos, uma teoria de especifica¸cão parcial (BAUER, 2012), (ALFARO; HENZINGER, 2005) define as opera¸cões e as rela¸cões sobre modelos parci-ais para que expressem adequadamente o comportamento de um sistema composto por componentes com informa¸cão parcial expl´ıcita ao longo do processo de desenvolvimento (BAUER, 2012). Apesar de não existir uma defini¸cão exata dos operadores que devem es-tar presentes em uma teoria da especifica¸cão, existem duas opera¸cões presentes na maioria das defini¸cões: a opera¸cão de composi¸cão paralela e a opera¸cão de conjun¸cão. A opera¸cão de composi¸cão paralela consiste em representar o comportamento de diversos componen-tes, que executam em paralelo, em um único modelo que representa o modelo do sistema. A opera¸cão de conjun¸cão tem como finalidade realizar a jun¸cão de vários modelos que representam um mesmo componente em um único modelo. Além destas opera¸cões, a rela¸cão de refinamento é a base de toda teoria de especifica¸cão parcial, pois todos os ope-radores são definidos com base nesta rela¸cão ao longo do processo de desenvolvimento. O presente trabalho contribui com a defini¸cão de uma teoria da especifica¸cão parcial para modelos KMTS a partir da defini¸cão da rela¸cão de refinamento e das opera¸cões de conjun¸cão e composi¸cão paralela. Após a constru¸cão, em um ciclo de desenvolvimento incremental, os modelos gerados devem ser analisados sob duas perspectivas: se eles sa-tisfazem propriedades pretendidas naquele ciclo e se, para um mesmo componente, os modelos gerados respeitam as propriedades dos modelos dos ciclos anteriores.

Para a segunda perspectiva, é necessário um meio de verificar se os modelos gerados nas novas itera¸cões e/ou incrementos respeitam os modelos previamente definidos de um determinado componente, isto é, se o novo modelo representa um detalhamento maior do modelo anterior sem perder nenhuma propriedade já definida. Esta rela¸cão entre os modelos é chamada de refinamento. A rela¸cão de refinamento introduz a rela¸cão de ”menos abstrato que” entre dois modelos. Entre dois modelos de um mesmo componente, o modelo mais abstrato possui mais indefini¸cões e é chamado de especifica¸cão e o menos abstrato, isto é, com menos indefini¸cões, é o modelo que refina a especifica¸cão. Diversos trabalhos focam no uso de modelos parciais e nos conceitos de refinamento, como em (UCHITEL; KRAMER; MAGEE, 2003b), para a etapa de análise de modelos.

A maior parte dos trabalhos que utilizam modelos parciais para expressar modelos ao longo do desenvolvimento de software definem e caracterizam uma rela¸cão de refinamento para suas estruturas modais e utilizam técnicas para analisar se existe uma rela¸cão de refinamento entre a especifica¸cão e um modelo. Uma abordagem baseada em um jogo entre dois jogadores é uma das técnicas utilizadas para verificar se um modelo é um refinamento de uma especifica¸cão. O presente trabalho define um jogo de refinamento

(30)

4 INTRODUC¸ ˜AO

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¸cão de refinamento modal forte a partir deste grafo (até onde sabemos nenhum outra pesquisa definiu tal algoritmo). A nossa solu¸cão possui complexidade polinomial, o que garante uma performance comparável aos principais algoritmos de verifica¸cão de refinamento encontrados na literatura.

Quando não há uma rela¸cão de refinamento entre a especifica¸cão e o modelo, o último deve ser reparado para garantir que ele preserve as propriedades definidas na especifica¸cão. Todavia, nenhum dos trabalhos encontrados focam na altera¸cão do modelo para garantir uma rela¸cão de refinamento com a especifica¸cão. Automatizar esta tarefa não é um problema trivial pois é necessário detectar os motivos que fazem com que não haja uma rela¸cão de refinamento. Chamamos esta atividade de reparo de modelos. O presente trabalho contribui com a automatiza¸cã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¸cão de refinamento entre o modelo e a sua especifica¸cão. A extra¸cão dos motivos a partir do jogo permite que o modelo em questão seja reparado automaticamente.

1.1 ESCOPO DO TRABALHO E CONTRIBUIC¸ ˜OES

No processo de desenvolvimento iterativo de software, surge a necessidade de métodos e algoritmos que deem suporte cont´ınuo para a constru¸cão, análise e corre¸cão de modelos comportamentais que expressam conhecimento parcial expl´ıcito de componentes dentro de um contexto formal. Neste sentido, idealizamos um esbo¸co de um processo de de-senvolvimento incremental e iterativo de software, baseado em componentes e amparado pela teoria das especifica¸cões para especificar o escopo do nosso trabalho e como nossas contribui¸cões se relacionam. Na Figura 1.1 apresentamos uma visão de alto n´ıvel de um ciclo deste processo. As etapas de análise de requisitos, projeto, implementa¸cão, testes e integra¸cão de um ciclo de desenvolvimento são representadas pelos blocos de cor amarela e são repetidas a cada novo ciclo. A etapa de integra¸cão é responsável por integrar as diversas partes desenvolvidas (o que é poss´ıvel no desenvolvimento incremental) em um ´

unico artefato.

Esta figura também destaca o escopo do nosso trabalho mostrando quais as atividades são suportadas pelo mesmo (blocos de cor azul) e quais ainda não foram desenvolvidas para KMTS mas que podem ser adaptadas para estes modelos (blocos de cor verde). O bloco “verifica¸cão de modelos” possui duas cores porque métodos de verifica¸cão de modelos para modelos KMTS já existem, mas o presente trabalho define um operador que permitem representar o sistema em diversos n´ıveis (componentes e sistema), contribuindo de forma indireta para a verifica¸cão de sistemas em diversos n´ıveis.

Assim, o presente trabalho propõe o uso de modelos KMTS ao longo do processo de desenvolvimento de software iterativo e incremental, focando nas três atividades básicas ao longo do processo: constru¸cão de modelos KMTS a partir de diagramas de sequências; análise de modelos KMTS, suas rela¸cões e suas opera¸cões no processo de desenvolvimento; e reparo de refinamento entre modelos KMTS para que os mesmos satisfa¸cam os requisitos desejados. Para cada um destes pontos, definimos meios e/ou métodos que podem auxiliar

(31)

1.1 ESCOPO DO TRABALHO E CONTRIBUIC¸ ˜OES 5

Figura 1.1 Vis˜ao de alto-n´ıvel de um processo de desenvolvimento que utiliza KMTS suportado por m´etodos formais

`

as atividades de constru¸c˜ao, an´alise e reparo de modelos.

Em rela¸cão à constru¸cão de modelos, definimos e implementamos um algoritmo de s´ıntese de modelos KMTS a partir de diagramas de sequência da UML baseado no al-goritmo de s´ıntese de modelos MTS proposto em (KRKA et al., 2009). É importante destacar que este algoritmo apenas converte diagramas de sequência em modelos KMTS. A atividade inversa (KMTS para diagrama de sequência) não é abordado neste trabalho. Em rela¸cão à análise de modelos, definimos rela¸cões e opera¸cões sobre modelos KMTS, de forma a caracterizar uma teoria da especifica¸cão parcial para modelos KMTS:

Definimos o conceito de refinamento forte e completo para modelos KMTS e suas rela¸c˜oes entre si;

Caracterizamos o conceito de refinamento como um jogo entre dois jogadores e um algoritmo para verificar o refinamento;

Definimos um operador de composi¸c˜ao paralela juntamente com o conceito de com-posicionalidade para representar diversos KMTSs interagindo em conjunto, como componentes de um software executando em paralelo;

Definimos um operador de conjun¸cão para KMTS de forma a permitir a união dos diversos modelos KMTS de um mesmo componente e permitir representar o sistema em diversos n´ıveis de abstra¸cão (componente e sistema).

(32)

6 INTRODUC¸ ˜AO

Em rela¸c˜ao ao reparo de modelos:

Definimos e estudamos o problema do reparo de refinamento, sua complexidade e tipos de solu¸c˜oes;

Definimos algoritmos para o problema do reparo de refinamento de um modelo em rela¸cão a uma especifica¸cão, isto é, métodos que realizam modifica¸cões de modelos KMTS com a finalidade de criar uma rela¸cão de refinamento entre a especifica¸cão e o modelo; e

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

1.2 ORGANIZAÇ ÃO DA DISSERTAÇ ÃO

O restante do presente trabalho é estruturado da seguinte forma: o Cap´ıtulo 2 apresenta os principais conceitos sobre modelagem comportamental de sistemas e componentes e sobre o desenvolvimento incremental e iterativo. O Cap´ıtulo 3 apresenta modelos com-portamentais parciais, suas rela¸cões e o uso de verifica¸cão formal sobre eles. O Cap´ıtulo 4 apresenta os principais trabalhos relacionados à nossa proposta. O Cap´ıtulo 5 apre-senta um algoritmo de s´ıntese de modelos KMTS a partir de diagramas de sequência anotados por regras OCL e resultados de sua implementa¸cão. O Cap´ıtulo 6 mostra o uso de KMTS para representar comportamento parcial no desenvolvimento de sistemas, apresentando rela¸cões e operadores sobre modelos KMTS. O Cap´ıtulo 7 caracteriza for-malmente o jogo de refinamento, apresentando um algoritmo para verificar a rela¸cão de refinamento através do jogo. O Cap´ıtulo 8 aborda o problema do reparo de refinamento, sua complexidade, poss´ıveis solu¸cões e algoritmos para resolver este problema. Por fim, o Cap´ıtulo 9 apresenta as contribui¸cões, resultados alcan¸cados e trabalhos futuros.

(33)

Cap´ıtulo

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¸cã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¸cões com o cliente/usuário, o que torna a tarefa de entender os requisitos do sistema e propor uma solu¸cã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¸cã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.

2.1 MODELOS DE SOFTWARE

Uma modelagem de sistema é uma descri¸cão, através de um modelo abstrato, de um sistema (SOMMERVILLE, 2011). Engenheiros de requisitos utilizam modelos para en-tender melhor o sistema e extrair novos requisitos. Engenheiros e arquitetos de software utilizam estes modelos para entender e projetar o sistema.

Um sistema pode possuir diversos modelos, pois um modelo é uma abstra¸cão de um sistema em rela¸cão a diferentes visões em rela¸cão a requisitos espec´ıficos. Desta forma, é poss´ıvel construir diversos modelos a partir das diversas perspectivas de um sistema.

´

E poss´ıvel, por exemplo, descrever uma perspectiva de intera¸c˜ao, onde s˜ao modeladas 7

(34)

8 MODELOS COMPORTAMENTAIS

as intera¸cões entre o ambiente e o sistema ou entre os componentes do sistema, ou uma perspectiva comportamental, onde o comportamento dinâmico do sistema é modelado, descrevendo como o sistema reage a eventos.

A modelagem do sistema pode ser representada por modelos formais ou por alguma nota¸cão gráfica, como a Unified Modeling Language (UML). Modelos formais são menos empregados na indústria porque requerem, geralmente, um expertise pelo profissional que os elabora, embora tragam vantagens através de métodos que podem garantir uma maior confiabilidade aos modelos gerados. Já os modelos que utilizam uma nota¸cão gráfica menos formal são mais empregados porque são mais fáceis de se ler e escrever. Entretanto, muitas vezes, não permitem uma verifica¸cão automatizada.

Para a constru¸cão de modelos, analistas de requisitos utilizam vários métodos para extra¸cão da informa¸cão que servem de base para modelar o sistema. Entrevistas, cenários, etnografia, dentre outros, são exemplos de técnicas aplicadas. Dentre estas técnicas, o uso de cenários (Apêndice A.1 e A.2) se destaca pela sua simplicidade de entendimento e capacidade de detalhar o comportamento do sistema e por isto é amplamente utilizado.

Durante o ciclo de desenvolvimento incremental e iterativo é comum que os projetistas não conhe¸cam todos os requisitos do software a ser constru´ıdo ou evolu´ıdo. A incerteza pode estar presente nas mais diversas perspectivas do software. O presente trabalho foca na incerteza em rela¸cão ao comportamento pretendido e em técnicas formais e por isto, neste cap´ıtulo, são apresentados os principais tópicos e conceitos que motivam o presente trabalho em rela¸cão a especifica¸cões comportamentais parciais em um contexto formal de desenvolvimento de software.

Especifica¸cões comportamentais ou apenas especifica¸cões (no presente trabalho) são modelos utilizados para descrever o comportamento de sistemas. Como mostrado poste-riormente, existem diversos modelos para descri¸cão comportamental, sendo o sistema de transi¸cão (TS) (BAIER; KATOEN; LARSEN, 2008), o modelo mais utilizado para esta finalidade.

2.2 SISTEMAS DE TRANSIÇ ÃO E ESPECIFICAÇ ÕES MODAIS

Um sistema de transi¸cão é um modelo descrito por um grafo dirigido onde os nós são os estados e as arestas são as transi¸cões que representam a evolu¸cão temporal dos estados do sistema (BAIER; KATOEN; LARSEN, 2008).

Defini¸cão 2.2.1 (Sistema de Transi¸cão (BAIER; KATOEN; LARSEN, 2008)). Um sis-tema de transi¸cão TS é uma tupla pS, Σ, R, I, AP, Lq onde S é um conjunto de estados, Σ um conjunto de a¸cões, R P S Σ S é uma rela¸cão de transi¸cão, I P S é o conjunto de estados iniciais, AP o conjunto de proposi¸cões atômicas e L : S Ñ 2AP _´_{e uma fun¸c˜}_ao

rotuladora.

Esta defini¸cão é genérica e, muitas vezes, alguns elementos da defini¸cão não são utili-zados, como por exemplo o conjunto de proposi¸cões ou as a¸cões que rotulam as transi¸cões. A partir deste ponto, omitiremos o conjunto de estados iniciais e assumiremos, para fins de simplifica¸cão, que cada sistema de transi¸cão possui um único estado inicial, ao qual chamaremos de s0 sendo S o conjunto de estados do modelo em questão.

(35)

2.2 SISTEMAS DE TRANSIÇ ÃO E ESPECIFICAÇ ÕES MODAIS 9

Sistemas de transi¸cão são úteis para a análise e verifica¸cão formal de propriedades (BAIER; KATOEN; LARSEN, 2008). Diversas técnicas ou métodos podem ser utilizados para esta finalidade, como por exemplo a verifica¸cão de modelos (CLARKE; LERDA, 2007). Todavia, muitas vezes, quando existe mais de um sistema de transi¸cão que descreve o comportamento de um software (ou componente de software) é necessário compar´ a-los entre si de forma a entender melhor a rela¸cão entre os seus comportamentos. Esta compara¸cão pode ser utilizada, por exemplo, para descobrir se dois modelos descrevem o mesmo comportamento ou se um modelo N consegue simular um outro modelo M , de forma que N é capaz de reproduzir todo o comportamento de M , além de possuir outros comportamentos.

2.2.1 Simula¸c˜ao

A simula¸cão é uma rela¸cão binária entre sistemas de transi¸cã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¸cão T SN simula um

sistema de transi¸c˜ao 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˜ao s˜ao descritos em T SM.

Defini¸c˜ao 2.2.2 (Simula¸c˜ao (BAIER; KATOEN; LARSEN, 2008)). Seja T SM pSM, Σ,

RM, APM, LMq e T SN pSN, Σ, RN, APN, LNq dois sistemas de transi¸c˜ao tal que

ps0, t0q P SMSN com s0 e t0os estados iniciais de T SM e T SN respectivamente. Dizemos

que t0 simula s0 sse existir uma rela¸c˜ao < SM SN tal que ps0, t0q P < e para todo

ps, tq P < vale:

1. Se ps, a, s1q P RM ent˜ao existe t1 tal que pt, a, t1q P RN com ps1, t1q P <;

2. LMpsq LNptq.

O seguinte exemplo esclarece melhor a rela¸cão de simula¸cão: suponha dois sistemas de transi¸cão que descrevem o comportamento de uma máquina de vender refrigerantes e bebidas alcóolicas. Existem três proposi¸cões que indicam qual a a¸cã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¸cão que descrevem este comportamento são apresentados na Figura 2.1 e, para simplificar este exemplo, as a¸cões foram ocultadas.

´

E poss´ıvel notar que nos modelos mostrados na Figura 2.1, o modelo N simula o comportamento do modelo M atrav´es da seguinte rela¸c˜ao:

R tps0, t0q, ps1, t1q, ps2, t1q, ps3, t2q, ps4, t3qu

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¸car um

(36)

Figura 2.1 Dois sistemas de transi¸c˜ao onde N simula o comportamento de M (BAIER; KA-TOEN; LARSEN, 2008)

Existem situa¸cões em que M simula N e N simula M simultaneamente através de uma rela¸cão R e sua rela¸cão inversa, R. Quando este fato ocorre, dizemos que R é uma rela¸cão de bissimula¸cão e que M e N são bissimilares. Uma defini¸cão de bissimula¸cão pode ser encontrada no Apêndice B.1.

2.2.2 Especifica¸c˜oes Comportamentais Parciais

Especifica¸cões parciais são uma extensão de sistemas de transi¸cão que permitem expressar parcialmente (ou integramente) o comportamento de um software (ou seu componente), possibilitando explicitar comportamentos em que não estão totalmente definidos (com-portamentos poss´ıveis) e com(com-portamentos já definidos (obrigatórios) através de modali-dades nas suas transi¸cões e indefini¸cões nas proposi¸cões dos seus estados (ANTONIK et al., 2008). Existem dois tipos de especifica¸cões parciais: especifica¸cões mistas e especi-fica¸cões modais. A diferen¸ca básica entre estas defini¸cões dizem respeito à defini¸cão de comportamentos obrigatórios e poss´ıveis.

Defini¸cão 2.2.3 (Especifica¸cão Mista (ANTONIK et al., 2008)). Seja Σ um conjunto não vazio de a¸cões e AP um conjunto não vazio de proposi¸cões atômicas, uma especifica¸cão mista M é a tuplapS, R , R, L , Lq tal que pS, R , L q e pS, R, Lq são sistemas de transi¸cão. Em particular, R e R são subconjuntos de SΣS, e L , L são membros de S Ñ 2AP_.

Assim, uma especifica¸cão mista é composta de duas partes separadas: pS, R , L q que especifica as proposi¸cões e comportamento obrigatório e pS, R, Lq que especifica

(37)

2.2 SISTEMAS DE TRANSIÇ ÃO E ESPECIFICAÇ ÕES MODAIS 11

as proposi¸cões e comportamento poss´ıvel. Uma especifica¸cão modal é uma especifica¸cão mista com restri¸cões nos seus componentes obrigatórios e poss´ıveis de forma que todo comportamento obrigatório é necessariamente poss´ıvel.

Defini¸cão 2.2.4 (Especifica¸cão Modal (ANTONIK et al., 2008)). Uma especifica¸cão modal M é uma especifica¸cão mista onde R R e L psq Lpsq para todo s P S. 2.2.3 KMTS

Existem diversos modelos para expressar especifica¸cõ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¸cão Modal (Modal Transition System - MTS) (Se¸cão B.2 e o Sistema de Transi¸cão Modal de Kripke (Kripke Modal Transistion System - KMTS).

Defini¸cão 2.2.5 (KMTS (HUTH; JAGADEESAN; SCHMIDT, 2001a)). Seja AP um conjunto de proposi¸cões atômicas e Lit AP Yt p | p P AP u o conjunto de literais sobre AP . Um Sistema de Transi¸cõ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¸cões de transi¸cão tal que R R, e L : S Ñ 2Lit _´_{e uma fun¸c˜}_{ao rotuladora, tal que para todo}

estado s e pP 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, s1q P R.

Figura 2.2 Exemplo do sinal de trˆansito

Na Figura 2.2 ´e apresentado um KMTS com trˆes estados s0, s1 e s2, onde no estado

s0 e s2 valem p e em s1 vale p K. As linhas tracejadas representam as transi¸c˜oes may

(R) enquanto as linhas s´olidas representam as transi¸c˜oes must (R ).

Quando o KMTS é utilizado como um modelo parcial, suas poss´ıveis implementa¸cões são expressas como estruturas de Kripke. Uma estrutura de Kripke é um grafo dirigido onde os vértices, que representam os estados do sistema, são rotulados com um conjunto de proposi¸cões atômicas que representam propriedades básicas que são verdade no estado correspondente ao vértice. As arestas do grafo são chamadas de transi¸cões (CLARKE; LERDA, 2007).

Defini¸cão 2.2.6 (Estrutura de Kripke). Uma estrutura de Kripke é uma tupla K = (AP, S, S0, R, L) onde AP é o conjunto de proposi¸cões atômicas; S é um conjunto finito de

estados, S0 S são os estados iniciais, R S S e uma rela¸cão de transi¸cão sobre S, e

(38)

1

A Figura 2.3 apresenta uma estrutura de Kripke.

Figura 2.3 Uma estrutura de Kripke

Com o crescente uso de especifica¸cões parciais para modelagem comportamental de sistemas, alguns estudos (BAUER, 2012) propõem uma teoria das especifica¸cões parciais que define um conjunto m´ınimo de elementos (classes de modelos, rela¸cões e opera¸cões sobre estes modelos) com determinadas propriedades que permitem expressar o compor-tamento de um sistema, de forma parcial, adequadamente.

2.3 TEORIA DAS ESPECIFICAC¸ ˜OES PARCIAIS

Não há um consenso sobre a defini¸cão exata do conjunto básico de opera¸cões que definem uma teoria da especifica¸cão, isto é, alguns autores definem algumas opera¸cões que outros autores não consideram como sendo opera¸cões básicas. A maior parte das pesquisas so-bre especifica¸cões comportamentais parciais estão concentradas nos modelos MTS, suas opera¸cões e suas extensões. Modelos KMTS são uma extensão de modelos MTS com a possibilidade de expressar indefini¸cões nos estados (HUTH; JAGADEESAN; SCHMIDT, 2001a). Todavia, modelos KMTS são pouco estudados no contexto de desenvolvimento comportamental parcial. Esta é uma das motiva¸cões do presente trabalho: considerando que modelos KTMS são uma extensão de modelos MTS, analisar quais opera¸cões e propri-edades podem ser adaptados para modelos KMTS e o impacto da indefini¸cão nos estados nestas adapta¸cões. De qualquer maneira, uma classe de modelos parciais e a rela¸cão de refinamento está presente em todos os trabalhos e os principais operadores definidos pe-los principais trabalhos sobre teoria das especifica¸cões até o presente momento (até onde sabemos) são os operadores de composi¸cão paralela e o operador de conjun¸cão.

Assim, uma teoria da especifica¸c˜ao T h ´e definida por uma tupla T h pS , ¨, k, ^q

Onde S é o espa¸co de modelos, ¨ é a rela¸cão de refinamento, k é o operador de com-posi¸cão paralela e ^ é o operador de composi¸cão. Outros estudos ampliam teorias das

1_{Estruturas de Kripke s˜}_{ao normalmente definidas com uma rela¸}_c˜_{ao total de transi¸}_c˜_{ao, tal requerimento}

´

e desprezado aqui. Assumimos estruturas de Kripke com uma rela¸c˜ao de transi¸c˜ao parcial sem nenhum impacto nesta pesquisa.

(39)

2.3 TEORIA DAS ESPECIFICAC¸ ˜OES PARCIAIS 13

especifica¸cões para contratos (BAUER et al., 2012a), acrescentando a descri¸cão compor-tamental do ambiente e definindo as rela¸cões e opera¸cões considerando sempre o modelo do componente e o modelo do ambiente. Todavia, o estudo de contratos não faz parte do escopo do presente trabalho e, por isto, não será detalhado.

Assim como acontece nos sistemas de transi¸cão, muitas vezes é necessário comparar o comportamento de duas especifica¸cões parciais pois, ao longo do processo de desenvolvi-mento, existirão diversas versões de modelos comportamentais de um mesmo componente (ou software). As versões podem ser diferentes porque em uma delas há um detalhamento maior a respeito de algo que ainda não tinha sido definido quando a versão foi criada. To-davia, os conceitos de simula¸cão e bissimula¸cão não podem ser empregados diretamente em especifica¸cões parciais porque pode haver diferen¸cas nos comportamentos dos modelos devido a novos requisitos. Neste caso, os modelos podem descrever o mesmo comporta-mento em diferentes n´ıveis de abstra¸cão e isto deve ser levado em considera¸cão. Uma rela¸cão que pode ser usada para comparar o comportamento de dois modelos parciais considerando diferentes n´ıveis de abstra¸cão é a rela¸cão de refinamento.

2.3.1 Rela¸c˜ao de Refinamento

Numa abordagem informal, o refinamento é uma rela¸cão entre duas representa¸cões (uma mais e a outra menos detalhada) de um mesmo componente. A ideia de refinamento é utilizada para comparar modelos de uma mesma entidade em diferentes ciclos. Um exemplo de rela¸cão de refinamento pode ser visto na Figura 2.4, onde a casa com portas e janelas é um refinamento da outra casa.

Figura 2.4 Exemplo de refinamento. A casa mais detalhada ´e um refinamento da outra casa. Adaptado de Fairbanks (2010)

A semântica do refinamento especifica qual tipo de detalhes pode ser introduzido. Duas semânticas são poss´ıveis, a semântica aberta e a semântica fechada (FAIRBANKS, 2010).

Semântica fechada: na semântica fechada, o refinamento só pode introduzir detalhes restritos a uma lista de poss´ıveis detalhamentos.

Semântica aberta: na semântica aberta, o refinamento pode introduzir qualquer tipo de mudan¸ca que for necessária.

A Figura 2.5 exibe um exemplo de refinamento fechado e aberto na casa: janelas ou portas seriam detalhes que poderiam ser adicionados no refinamento de semântica fe-chada; adi¸cão de uma garagem e chaminés representaria um refinamento com a semântica aberta.

(40)

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)

Considerando o uso especifica¸cões modais, quando dois modelos parciais descrevem o mesmo comportamento em diferentes n´ıveis de abstra¸cão (ou de detalhamento), dizemos que o modelo mais detalhado é um refinamento do outro modelo (o mais abstrato). Em rela¸cão a modelos parciais, a exclusão de certas possibilidades de comportamento pela remo¸cão de incertezas (através da remo¸cão de comportamentos poss´ıveis ou conversão deles em comportamentos obrigatórios) representa o conceito informal de refinamento. Este conceito introduz a rela¸cão ”menos abstrato que” entre dois modelos. De forma similar à rela¸cão de simula¸cão (ou bissimula¸cão), a rela¸cão de refinamento mapeia estados entre os modelos. Se um estado s do modelo M é mapeado em um estado t do modelo N , diz-se que t é refinamento do estado s. Um estado t é um refinamento de um estado s se o comportamento obrigatório de s é preservado em t e se todo comportamento poss´ıvel de t é herdado de s. Observe que t pode ter os mesmos comportamentos poss´ıveis ou menos comportamentos poss´ıveis do que s, mas o inverso nunca é verdade. Esta verifica¸cão é aplicada de forma co-indutiva para os estados sucessores de s e t.

O refinamento é baseado na ideia de simula¸cão/bissimula¸cão sobre sistemas de transi¸cão (PARK, 1981) e pode ser entendido da seguinte forma: o modelo N é um refinamento de um modelo M se e somente se N simula todo o comportamento obrigatório de M e M simula todo o comportamento poss´ıvel de N . Quando isto acontece qualquer com-portamento poss´ıvel foi adicionado em N . Este conceito de refinamento é chamado de refinamento modal e sua defini¸cão segue abaixo:

Defini¸c˜ao 2.3.1 (Refinamento Modal (ANTONIK et al., 2008)). Seja M pSM, R_M, R_M,

L_M, L_Mq e N pSN, RN, RN, LN, LNq duas especifica¸c˜oes mistas e ps0, t0q P SM SN

com s0 e t0 os estados iniciais de M e N , respectivamente. Dizemos que t0 refina s0 sse

existir uma rela¸c˜ao < SM SN tal que ps0, t0q P < e para todo ps, tq P < vale:

1. Para todops, a, s1q P R_M existe algum pt, a, t1q P R_N com ps1, t1q P <; 2. Para todopt, a, t1q P R_N existe algum ps, a, s1q P R_M com ps1, t1q P <; 3. L_M L_N;

(41)

Quando o modelo N é um refinamento do modelo M, escrevemos M ¨ N. Esta rela¸cã de refinamento é reflexiva e transitiva, garantindo assim um ordenamento (no sentido de “mais abstrato que”) entre especifica¸cões parciais (ANTONIK et al., 2008).

A Figura 2.6 e a Figura 2.7 exibem dois casos onde há e onde não há uma rela¸cão de refinamento entre os modelos (respectivamente) pois, não há nenhum estado de N que pode ser mapeado em s0 do modelo M. As setas tracejadas representam as transi¸cões

poss´ıveis enquanto que as setas sólidas representam as transi¸cões obrigatórias. Voltando para a Figura 2.6, podemos observar que existe uma rela¸cão de refinamento modal entre o modelo M e o modelo N . Também é poss´ıvel observar, que neste exemplo, o modelo N não expressa nenhum comportamento poss´ıvel que não seja obrigatório. Quando uma especifica¸cão parcial não expressa nenhum comportamento pass´ıvel de mudan¸ca, dá-se o nome de implementa¸cão a esta especifica¸cão.

Defini¸cão 2.3.2 (Implementa¸cão (ANTONIK et al., 2008)). Uma implementa¸cão é uma especifica¸cão parcial onde R R e L L.

Figura 2.6 Um modelo parcial M e uma implementa¸c˜ao N

Figura 2.7 Dois modelos parciais que n˜ao possuem uma rela¸c˜ao de refinamento modal

A rela¸cão de refinamento modal pode ser utilizada entre especifica¸cões parciais e entre implementa¸cões. Quando usada para comparar apenas implementa¸cões, vale notar que a rela¸cão coincide com a defini¸cão de bissimula¸cão B.1.

Como um modelo parcial pode ser constitu´ıdo de diversas indetermina¸cões, é poss´ıvel que ele possa originar diversas implementa¸cões, e por isto, definimos o conjunto de im-plementa¸cões do modelo parcial M como IpMq tI } M ¨ Iu.

(42)

Existem casos em que um modelo parcial não possui implementa¸cões. Dizemos que uma especifica¸cão parcial é consistente se e somente se ela possui pelo menos uma imple-menta¸cão.

Defini¸cão 2.3.3 (Consistência em especifica¸cão parcial (ANTONIK et al., 2008)). Uma especifica¸cão parcial M é consistente sse IpMq é não-vazio.

A Figura 2.8 mostra uma especifica¸cão mista que não possui implementa¸cões poss´ıveis. As setas tracejadas representam as transi¸cões poss´ıveis enquanto que as setas sólidas representam as transi¸cões obrigatórias. Antonik et al. (2008) mostram que o problema de determinar se uma especifica¸cão mista é consistente tem seu limite inferior localizado na classes de problemas PSPACE-hard enquanto que o limite superior está em EXPTIME. Toda especifica¸cão modal é consistente porque toda transi¸cão obrigatória é uma transi¸cão poss´ıvel (sempre existe uma implementa¸cão poss´ıvel, escolhendo o modelo formado por todo comportamento must ) e por isto apenas uma seta sólida é utilizada para representar as transi¸cões obrigatórias, diferentemente das especifica¸cões mistas.

Figura 2.8 Uma especifica¸cão mista que não possui implementa¸cões

Independente do modelo ser consistente ou não, existem casos em que a rela¸cão de refinamento não reproduz a ideia intuitiva de refinamento porque dados dois modelos parciais M e N , se M ¨ N então IpNq IpMq, todavia, o inverso, se IpNq IpMq então M ¨ N nem sempre é verdade (ANTONIK et al., 2008). Autores em (BENEˇs et al., 2009) mostram que o inverso é verdade quando um dos modelos é determin´ıstico. Este resultado é demonstrado para modelos KMTS no presente trabalho. A Figura 2.9 exibe dois modelos que possuem o mesmo conjunto de implementa¸cão, mas um não refina o outro.

Para evitar estes casos, é poss´ıvel definir um conceito de refinamento baseado apenas na inclusão do conjunto de implementa¸cões e este conceito é chamado de refinamento completo.

Defini¸c˜ao 2.3.4 (Refinamento Completo (ANTONIK et al., 2008)). O Modelo N ´e um refinamento completo do modelo M , M ¨c N , sse IpNq IpMq.

Todavia, calcular o refinamento completo tem um custo computacional elevado, e por isto o refinamento modal continua sendo utilizado (ANTONIK et al., 2008). Antonik

(43)

Figura 2.9 Duas especifica¸c˜oes mistas M e N com IpMq IpNq, mas n˜ao vale M ¨ N

et al. (2008) mostram que o limite inferior para c´alculo do refinamento completo para especifica¸c˜oes parciais encontra-se na classe de problemas PSPACE-hard enquanto seu limite superior na classe EXPTIME.

Existem na literatura, varia¸cões do refinamento modal, que podem ser vistas na Se¸cã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¸cões de refinamento.

2.3.2 Operador de Composi¸c˜ao Paralela

Um software pode ser formado por vários componentes que são executados de forma paralela e interagem entre si. Todavia, existem propriedades que não são satisfeitas por nenhum componente isoladamente e sim pelo sistema como um todo, ou seja, propriedades que somente se tornam presentes quando determinados componentes interagem entre si. Assim, modelos em n´ıvel de sistema se fazem necessários para uma análise mais precisa de um sofware (KRKA et al., 2009).

´

E poss´ıvel sintetizar modelos comportamentais do sistema a partir da composi¸cão dos modelos dos seus componentes através do operador de composi¸cão paralela. O operador de composi¸cão paralela definido por uma teoria da especifica¸cão é comumente estrutural, isto é, cada estado do sistema é composto da união dos estados dos componentes indivi-duais, onde a¸cões dos componentes são convertidas em a¸cões na composi¸cão. A¸cões em comum entre os componentes são representadas como transi¸cões na composi¸cão que al-teram os estados de vários componentes simultaneamente e as a¸cões não-compartilhadas são simuladas por interleaving, representando, na composi¸cão, a altera¸cão do estado um ou mais componentes.

O operador de composi¸cão paralela deve ser comutativo e associativo para garantir que a ordem de execu¸cão da composi¸cão não influencie no resultado final da composi¸cão. A Figura 2.10 mostra um exemplo de composi¸cão paralela, representada por M k N dos modelos M e N . A figura também mostra um exemplo em que a rela¸cão de refinamento modal não é completa com respeito ao operador de composi¸cão paralela, isto é, a composi¸cão paralela dos modelos parciais M e N pode ser vista no modelo M k N e o modelo I representa uma implementa¸cão do modelo M k N que não consegue ser

(44)

formado a partir da composi¸c˜ao de quaisquer implementa¸c˜oes dos modelos M e N .

Figura 2.10 Exemplo da incompletude da rela¸cão de refinamento modal em rela¸cão ao opera-dor de composi¸cão paralela

2.3.3 Operador de Conjun¸c˜ao

Muitas vezes, um componente (ou um software) é desenvolvido por diversas equipes. Cada uma pode ser responsável por uma visão do componente o que resultará em dife-rentes modelos a respeito de um mesmo componente. Unificar os diversos modelos em apenas um é a fun¸cão do operador de conjun¸cão. Considerando que todos os modelos descrevem um mesmo componente, a abordagem mais utilizada para calcular o operador de conjun¸cão consiste em encontrar um modelo que seja um refinamento em comum dos modelos desejados.

Defini¸c˜ao 2.3.5 (Refinamento Comum). Dados os modelos parciais M e N , um modelo X ´e um refinamento comum entre M e N sse M ¨ X e N ¨ X.

Antonik et al. (2008) definem o refinamento comum como um dos principais problemas de especifica¸c˜oes parciais e mostram que seu limite inferior em termos de complexidade ´

e PSPACE-hard (para especifica¸cõ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.

(45)

Defini¸cão 2.3.6 (Consistência). Duas especifica¸cões modais, M e N são ditos consistentes se existe um modelo parcial C tal que C é um refinamento comum de M e de N.

A consistência também pode ser definida como uma rela¸cão sobre especifica¸cões mo-dais (RACLET et al., 2011).

Defini¸c˜ao 2.3.7 (Consistˆencia (RACLET et al., 2011)). Seja M pSM, RM, RMq e

N pSN, RN, RNq duas especifica¸c˜oes modais e ps0, t0q P SM SN com s0 e t0 os estados

iniciais de M e N , respectivamente. Dizemos que os modelos M e N s˜ao consistentes sse existir uma rela¸c˜ao < SM SN tal que ps0, t0q P < e para todo ps, tq P < vale:

1. (@l, s1qpps, a, s1q P R_M existe algum pt, a, t1q P R_N com ps1, t1q P <q; 2. (@l, t1qppt, a, t1q P R_N existe algum ps, a, s1q P R_M com ps1, t1q P <q.

Considerando que a rela¸cão de refinamento define uma pré-ordem no espa¸co 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¸cão, busca-se o refinamento comum mais próximo dos dois modelos de entrada, isto é, o refinamento comum com mais indefini¸cões. Esta restri¸cão é justificada porque busca-se o modelo que represente os outros modelos, mas que perca o m´ınimo poss´ıvel de indefini¸cõ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¸cão de refinamento é uma pré-ordem, estes elementos do RCM não são comparáveis entre si). Alguns trabalhos chamam a opera¸cão de conjun¸cã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¸cões) e o RCM é um conjunto formado pelos refinamentos comuns mais abstratos e não comparáveis entre si pela rela¸cã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¸cão parcial e a seta representa a rela¸cão de refinamento.

Defini¸cão 2.3.8 (Refinamento Comum Minimal). Dados dois modelos M e N , o modelo X pertence ao RCM de M e N sse X é um refinamento comum entre M e N e para todo modelo X1 tal que M ¨ 1X e N ¨ X1 então X ª X1 e X1 ª X.

Defini¸cão 2.3.9 (Menor Refinamento Comum). Dados dois modelos M e N , o modelo X é o MRC de M e N sse X é um refinamento comum entre M e N e para todo modelo X1 tal que M ¨ X1 e N ¨ X1 então X ¨ X1.

Segundo (RACLET et al., 2011), o operador de conjun¸cão deve ser associativo e co-mutativo para garantir que a ordem de execu¸cão da conjun¸cão não influencie o resultado final. Além disto, as seguintes propriedades devem valer para que o operador de con-jun¸cão (representado por ^) retorne de fato a conjun¸cão entre os dois modelos (e não o refinamento comum):

(46)

Figura 2.11 Exemplos de MRC em (A) e de RCM em (B)

1. M ^ N é definido sse existe um modelo parcial X tal que M ¨ X e N ¨ X; 2. Se M ^ N é definido então para todo modelo parcial X tal que M ¨ X e N ¨ X