TSC: uma abordagem para o controle de restrições de integridade em bancos de dados eventualmente consistentes

(1)

TSC: UMA ABORDAGEM PARA O CONTROLE DE RESTRIC¸ ˜OES DE INTEGRIDADE EM BANCOS DE

DADOS EVENTUALMENTE CONSISTENTES

Disserta¸cão submetida ao Programa de Pós-Gradua¸cão em Ciência da Com-puta¸cão para a obten¸cão do Grau de Mestre em Ciência da Computa¸cão. Orientador: Prof. Frank Augusto Si-queira

Florian´opolis 2017

(2)

Flores, Paulo Arion

TSC: Uma abordagem para o controle de restrições de integridade em bancos de dados eventualmente consistentes / Paulo Arion Flores ; orientador, Frank Augusto Siqueira, 2017.

111 p.

Dissertação (mestrado) - Universidade Federal de Santa Catarina, Centro Tecnológico, Programa de Pós Graduação em Ciência da Computação, Florianópolis, 2017.

Inclui referências.

1. Ciência da Computação. 2. Bancos de Dados Distribuídos (BDDs). 3. Restrições de Integridade. 4. Consistência Eventual. 5. NoSQL. I. Siqueira, Frank Augusto. II. Universidade Federal de Santa

Catarina. Programa de Pós-Graduação em Ciência da Computação. III. Título.

(3)

TSC: UMA ABORDAGEM PARA O CONTROLE DE RESTRIC¸ ˜OES DE INTEGRIDADE EM BANCOS DE

DADOS EVENTUALMENTE CONSISTENTES

Esta Disserta¸cão foi julgada aprovada para a 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.

Florian´opolis, 20 de agosto 2017.

Prof. Dr. Jos´e Lu´ıs Almada G¨untzel Coordenador do Curso Banca Examinadora:

(4)

Prof. Mario Antonio Ribeiro Dantas Universidade Federal de Santa Catarina

Prof. Ronaldo dos Santos Mello Universidade Federal de Santa Catarina

Prof. Fabiano Baldo

(5)

que os filhos estudassem em uma univer-sidade e ao sobrinho Dante, novo membro da fam´ılia.

(6)

(7)

Agrade¸co ao meu orientador Frank Siqueira, pela nova amizade, por me dar essa oportunidade de voltar a estudar na UFSC, me acom-panhar em todo o processo de escolha e realiza¸cão do projeto da dis-serta¸cão e elabora¸cão de artigos, pelos conselhos dados, paciência, in-contáveis revisões e dicas de como escrever e desenvolver o projeto. Agrade¸co a Rossana Cunha, pelo carinho, ter sido parceira e por ter dividido comigo os momentos de estudo em horários alternativos de-gustando chás de diferentes lugares. Agrade¸co a minha irmã Leandra Flores e ao Emerson Fedechen pelos muitos momentos que passamos juntos todo ano. Ao Denis Dalzotto pelos cafés e amizade. Agrade¸co ao meu amigo Ramon Hugo, por publicarmos juntos e pela grande ajuda para que eu voltasse a estudar na UFSC, e pelas águas tônicas falando bobagem. Agrade¸co a Claudia Pereira pela ajuda no inglês na elabora¸cão de artigos e boas conversas. Agrade¸co ao professor Mario Dantas, que sempre procurou realizar trabalhos conjuntos, procurou me ajudar no tema da disserta¸cão e me encaminhou ao meu orientador, sem o qual não seria poss´ıvel iniciar o curso. Agrade¸co conjuntamente aos professores Mario Dantas e Ronaldo dos Santos Mello pelas observa¸cões para que o meu trabalho fosse aperfei¸coado. Agrade¸co ao José Ernesto, Pablo Beber e Omar Afif, da Secretaria de Estado da Fazenda de Santa Catarina, pelo apoio e compreensão, o que tornou poss´ıvel realizar o mestrado e continuar trabalhando ao mesmo tempo. Agrade¸co também a UFSC, que novamente me proporcionou uma forma¸cão que me faz crescer profissionalmente.

(8)

(9)

Com a crescente demanda para armazenamento de dados provenien-tes de sistemas computacionais, os bancos de dados NoSQL surgiram como uma op¸cão de Bancos de Dados Distribu´ıdos (BDDs) para lidar com grandes massas de dados sem comprometer o desempenho do sis-tema. Porém, diferentemente dos bancos de dados relacionais, os ban-cos de dados NoSQL não suportam transa¸cões ACID (Atomicidade, Consistência, Isolamento e Durabilidade) que visam garantir a con-sistência dos dados, dificultando o desenvolvimento de aplica¸cões que necessitam manter algumas invariâncias do sistema. Diferentes abor-dagens surgiram na literatura com o intuito de manter a integridade em BDDs: o uso de Replicated Data Types (RDTs) para controlar o conflito de opera¸cões de atualiza¸cão; e o uso de diferentes modelos de consistência para cada tipo de opera¸cão, empregando lógica de primeira ordem (FOL) e provadores de teoremas (TP). Não obstante, o uso de RDTs e a descri¸cão de Restri¸cões de Integridade (RIs) através de FOL ainda são de dif´ıcil utiliza¸cão para os desenvolvedores. Com o objetivo de simplificar a constru¸cão de aplica¸cões que necessitam de consistência em BDDs, esta disserta¸cão define uma abordagem para a constru¸cão de RIs na camada de aplica¸cão utilizando RDTs com base nos poss´ıveis estados de transi¸cão das opera¸cões, denominada Transition State Con-sistency (TSC). A abordagem TSC extrai as opera¸cões de uma RI em um RDT e define a consistência de cada opera¸cão, levando em consi-dera¸cão a semântica das invariâncias e as poss´ıveis anomalias dessas invariâncias quando utilizadas em BDDs. Nos experimentos realizados em um BDD com consistência eventual, em cenários em que diversas opera¸cões impactam RIs, foi justificado o uso da abordagem TSC para o controle da consistência, já que a diferencia¸cão das opera¸cões pelo estado de transi¸cão permitiu reduzir a quantidade de opera¸cões exe-cutadas com consistência forte, causando uma melhora significativa no desempenho do sistema.

Palavras-chave: Bancos de Dados Distribu´ıdos (BDDs). NoSQL. Restri¸c˜oes de Integridade (RIs). RDT. Consistˆencia Eventual.

(10)

(11)

With the increasing demand for data storage from computational sys-tems, NoSQL databases have emerged as an option of Distributed Da-tabases (BDD) in order to handle a significant amount of data without compromising system’s performance. However, unlike relational data-bases, NoSQL databases mostly have no ACID transactions (Atomicity, Consistency, Isolation, and Durability) designed to ensure data consis-tency, hindering the development of applications that need to maintain some system invariance. Different approaches have emerged in the li-terature to support integrity in BDDs: the use of replicated data types (RDTs) to control conflicting updates; and the use of different consis-tencies models for each type of operation, using first-order logic (FOL) and theorem provers (TP). Notwithstanding, the use of RDT or the integrity constraints (RI) descriptions through languages using FOL is still difficult to be used by programmers. Aiming to simplify the cons-truction of applications that require consistency in BDDs, this work proposes an approach to the creation of RIs at the application layer, using RDTs based on the possible states of transition of operations, cal-led Transition State Consistency (TSC). The TSC approach extracts the operations of an RI in an RDT and defines the consistency of each operation, taking into account the semantics of the invariances and the possible anomalies of those invariances when using BDDs. In the expe-riments carried out in a BDD with eventual consistency with scenarios in which several operations impact RIs, the use of the TSC approach for consistency control was justified since the differentiation of operati-ons by the transition state allowed to reduce the number of operatioperati-ons performed with strong consistency, causing a significant improvement in system performance.

Keywords: Distributed Databases (DDBs). NoSQL. Integrity Cons-traints. RDT. Eventual Consistency.

(12)

(13)

Figura 1 Exemplo de um RDT em BDDs. . . 43

Figura 2 Arquitetura TSC. . . 58

Figura 3 Persistˆencia dos RDTs. . . 59

Figura 4 Mapeamento de consistˆencia por opera¸c˜ao. . . 61

Figura 5 Modelo de dados. . . 63

Figura 6 Exemplo com TSC. . . 66

Figura 7 Mapeamento das opera¸c˜oes para cria¸c˜ao dos RDTs. . . 67

Figura 8 Exemplos de anomalias. . . 69

Figura 9 Exemplo de uso da abordagem TSC. . . 73

Figura 10 Arquitetura do experimento. . . 77

Figura 11 Modelo de dados do experimento. . . 79

Figura 12 RDTs dos casos do experimento. . . 80

Figura 13 Tempo de dura¸cão total das opera¸cões da inequa¸cão. . . . 81

Figura 14 Throughput das opera¸c˜oes da inequa¸c˜ao. . . 82

Figura 15 Erros ocorridos nas opera¸c˜oes da inequa¸c˜ao. . . 83

Figura 16 Tempo de dura¸c˜ao total das opera¸c˜oes de chave estran-geira. . . 84

Figura 17 Throughput das opera¸c˜oes da chave estrangeira. . . 85

Figura 18 Erros evitados nas opera¸c˜oes da chave estrangeira. . . 86

Figura 19 Tempo de dura¸cão total das opera¸cões da inferência. . . . 87

Figura 20 Throughput das opera¸c˜oes da inferˆencia. . . 88

(14)

(15)

Tabela 1 Caracter´ısticas de cada aplica¸cão. . . 54 Tabela 2 Consistência necessária nas opera¸cões com TSC. . . 71 Tabela 3 Compara¸cão do TSC com os trabalhos relacionados. . . . 90 Tabela 4 Artigos publicados. . . 111

(16)

(17)

ACID Atomicidade, Consistˆencia, Isolamento e Durabilidade ADS Abstract Data Store

ADT Abstract Data Type BD Banco de Dados

BDDs Bancos de dados distribu´ıdos CRDT Conflict-free replicated data type EC Consistˆencia Eventual

FOL L´ogica de primeira ordem MAV Monotonic Atomic View MVC Model-view-controller ORM Object-relational mapping RC Read Committed

RDT Replicated data type RI Restri¸c˜ao de Integridade RR Repeatable Read

SMT Satisfiability modulo theories TP Theorem Prover

(18)

(19)

1 INTRODUÇ ÃO . . . 21 1.1 JUSTIFICATIVA . . . 25 1.2 OBJETIVO GERAL . . . 26 1.3 OBJETIVOS ESPECÍFICOS . . . 26 1.4 METODOLOGIA . . . 26 1.5 ORGANIZAÇ ÃO DO TEXTO . . . 27

2 BANCOS DE DADOS NOSQL . . . 29

2.1 BANCOS DE DADOS CHAVE-VALOR . . . 29

2.2 BANCOS DE DADOS ORIENTADOS A COLUNA . . . 30

2.3 BANCOS DE DADOS ORIENTADOS A DOCUMENTO 31 2.4 BANCOS DE DADOS ORIENTADOS A GRAFOS . . . 32

2.5 BANCOS DE DADOS NOSQL X BANCOS DE DADOS NEWSQL . . . 33

2.6 CONSIDERAÇ ÕES FINAIS DO CAPÍTULO . . . 34

3 CONSIST ˆENCIA EM BANCOS DE DADOS . . . . 37

3.1 CONSIST ˆENCIA SEM ˆANTICA . . . 37

3.2 CONSIST ÊNCIA EM TRANSAÇ ÕES . . . 40

3.3 CONSIST ÊNCIA NA DISTRIBUIÇ ÃO E REPLICAÇ ÃO 41 3.4 CONSIST ÊNCIA EVENTUAL . . . 42

3.5 RDT . . . 42

4 REVIS ˜AO BIBLIOGR ´AFICA . . . 45

4.1 QUELEA . . . 45 4.2 ADS . . . 47 4.3 INDIGO . . . 49 4.4 CISE . . . 50 4.5 REDBLUE E SIEVE . . . 51 4.6 I-CONFLUENCE . . . 52 4.7 PROTOCOLO HOMEOSTASIS . . . 52

5 TSC . . . 57

5.1 ARQUITETURA DE SOFTWARE . . . 57

5.2 QUELEA COM TSC . . . 59

5.3 MODELO DE DADOS . . . 62

5.4 RESTRIC¸ ˜OES DE INTEGRIDADE . . . 64

5.5 RDTS, CONTRATOS E TSC . . . 68

(20)

5.6 CONSIDERAÇ ÕES FINAIS DO CAPÍTULO . . . 74 6 AVALIAÇ ÃO DA PROPOSTA . . . 77 6.1 AVALIAÇ ÃO EXPERIMENTAL . . . 77 6.1.1 Caso 1 . . . 80 6.1.2 Caso 2 . . . 84 6.1.3 Caso 3 . . . 86

6.1.4 Considera¸c˜oes Finais dos Experimentos . . . 89

6.2 AN ´ALISE QUALITATIVA . . . 89

7 CONCLUS ˜OES E TRABALHOS FUTUROS . . . . 97

7.1 CONTRIBUIC¸ ˜OES . . . 98

7.2 TRABALHOS FUTUROS . . . 99

REFER ˆENCIAS . . . 103

(21)

1 INTRODUC¸ ˜AO

BDDs hoje são uma tendência para as novas aplica¸cões que sur-gem no mercado. Requisitos como a disponibilidade, desempenho e escalabilidade come¸cam a fazer parte do conhecimento necessário que desenvolvedores de sistemas e profissionais em banco de dados (BD) devem possuir. O aumento da capacidade vertical de servidores de aplica¸cão, aumentando a memória e o número de processadores para oferecer maior disponibilidade e desempenho, não é suficiente para al-gumas aplica¸cões, sendo necessária a distribui¸cão do processamento e do armazenamento (POKORNY, 2013).

BDs relacionais foram adaptados para permitir trabalhar de for-ma distribu´ıda, porém, com uma grande complexidade envolvida, já que garantir as propriedades ACID não é algo facilmente escalável ( PO-KORNY, 2013). O surgimento da Web 2.0 e de aplica¸cões com integra¸cão com smarthphones, tablets e outros dispositivos móveis permitiu o ar-mazenamento de uma vasta quantidade de dados de diferentes fontes e estruturas. Esse crescimento criou uma demanda por BDs mais apro-priados que os BDs relacionais para trabalhar com essa quantidade de informa¸cões.

BDs NoSQL apareceram como uma das solu¸cões alternativas para o armazenamento, como no caso do Bigtable (CHANG et al., 2008). A escalabilidade dos BDs chamados NoSQL acontece de forma mais natural devido a sua estrutura de dados e à forma de consistência ofe-recida. Existem diversos modelos usados em bancos NoSQL, sendo os principais os que trabalham com chave-valor, apropriados para armaze-namento de informa¸cões sem estrutura de dados, em que a recupera¸cão dos dados acontecem somente pela chave do registro; os BDs orien-tados a documentos, que possibilitam a cria¸cão de estruturas com o uso de formatos como XML ou JSON (SADALAGE; FOWLER, 2012); BDs orientados a coluna, que permitem o armazenamento dos mes-mos tipos de informa¸cão em uma coluna, possibilitando a utiliza¸cão de indexa¸cão e compressão dos dados de forma mais eficiente; e BDs de grafos, viáveis para modelos de dados que possuem muitos relaciona-mentos. BDs NewSQL surgiram para oferecer a escalabilidade dos BDs NoSQL e ao mesmo tempo suportar transa¸cões utilizando as proprie-dades ACID e um modelo de dados relacional, procurando trazer para o desenvolvedor, acostumado com BDs relacionais, uma maior facili-dade na adapta¸cão para trabalhar com BDDs (PAVLO; ASLETT, 2016). Porém, a utiliza¸cão de outros modelos de dados e a possibilidade de

(22)

ex-plorar de forma mais granularizada o controle da consistência, ou seja, diferenciar a consistência por opera¸cão, ao invés de utilizar transa¸cões com garantia ACID, estimulam o uso de BDs NoSQL.

Uma dificuldade encontrada em aplica¸cões com diversas fontes de dados, como aplicativos Mobile e aplicativos Web, é a versatilidade do modelo de dados que estes necessitam. BDs e as aplica¸cões clientes possuem um desafio de mapeamento entre os dados persistidos e os dados mantidos em memória, como no caso de BDs relacionais usados por aplica¸cões orientadas a objetos. BDs relacionais possuem como vantagem a possibilidade de interoperabilidade mais simplificada entre diversas aplica¸cões que acessam o mesmo BD por possu´ırem uma alta granularidade, através da normaliza¸cão das tabelas, permitindo a repre-senta¸cão de diferentes visões dos dados mais facilmente. Apesar disso, a grande diferen¸ca na estrutura de dados dos modelos de dados usados em aplica¸cões e o modelo relacional gera a necessidade de mapeamento objeto-relacional (ORM). Uma alternativa para isso é criar BDs ori-entados para uma aplica¸cão (SADALAGE; FOWLER, 2012), permitindo uma defini¸cão de estrutura dos dados mais rica no BD e dessa forma, evitando uma maior complexidade na tradu¸cão dos dados persistidos para os dados em memória. BDs relacionais trabalham com tuplas e rela¸cões e não permitem a defini¸cão de estruturas de dados mais com-plexas. Porém, alguns BDs como o Mysql (ORACLE, 2017a), Oracle (ORACLE, 2017b) e PostgreSQL (GROUP, 2017) fornecem suporte na-tivo para Json e alguns trabalhos surgiram para fornecer suporte nana-tivo de formatos mais complexos em BDs relacionais, como o suporte para o formato XML de forma nativa, usando consultas XQuery (MOHAN, 2013) e o trabalho de (LIU; GAWLICK, 2015) que cria um esquema de dados flex´ıvel em BDs relacionais.

Já os BDs NoSQL se adaptam melhor para representar dados complexos de aplica¸cões. Os modelos de dados NoSQL permitem cons-truir estruturas mais similares às estruturas de dados da aplica¸cão. Porém, modelar a estrutura de dados de aplica¸cões que usam BDs NoSQL resulta em uma maior complexidade para o desenvolvedor do sistema, como, por exemplo, a cria¸cão de estruturas de dados otimiza-dos para consultas (MIOR, 2014). Nos experimentos de (SCHERZINGER et al., 2013) foi simulada a escrita de dados em um ambiente de nu-vem utilizando dois modelos distintos e foi constatada grande diferen¸ca no desempenho e na quantidade de falhas ocorridas, dependendo do modelo escolhido para a representa¸cão dos dados. A complexidade, portanto, fica na escolha do melhor modelo, dependendo da utiliza¸cão da aplica¸cão.

(23)

Porém, apesar dos BDs NoSQL permitirem o armazenamento de estruturas mais complexas, algumas facilidades normalmente encontra-das em BDs relacionais, como o controle da integridade dos dados, man-tendo a consistência das invariâncias do sistema, ainda é um desafio. Invariâncias do sistema são propriedades que a aplica¸cão deve sempre manter verdadeira, como, por exemplo, as RIs. Segundo (GHAZIZADEH; MUKKAMALA; OLARIU, 2013), a integridade em BDs é uma das grandes preocupa¸cões na terceiriza¸cão de servi¸cos de tecnologia da informa¸cão, como servi¸cos de nuvens. A integridade em BDs visa garantir o estado dos dados (ou transi¸cão de estados) correto, ou seja, a consistência dos dados. Para isso são definidas regras através de declara¸cões chama-das de RIs semânticas. Segundo (_{OZSU; VALDURIEZ}¨ _{, 2001), o controle}

dessas RIs é um dos requisitos para manter a consistência, além do controle de concorrência, da confiabilidade e da prote¸cão.

A integridade em BDDs possui desafios diferenciados. Ao proje-tar o modelo de dados e suas restri¸cões, é preciso calcular o impacto em opera¸cões, como consultas e atualiza¸cões, além do planejamento da sin-croniza¸cão entre os dados necessária para manter a consistência reque-rida pela aplica¸cão. Segundo (_{OZSU; VALDURIEZ}¨ _{, 2001), v´}_{arias solu¸}_c˜_oes

têm sido desenvolvidas procurando diminuir o número de assertivas de integridade utilizadas em opera¸cões no BD. Procura-se, com isso, di-minuir a quantidade de dados acessados, principalmente quando esses dados estão espalhados em parti¸cões diferentes; evitar opera¸cões que acarretam desfazer muitas atualiza¸cões ao detectar uma inconsistência; e aplicar regras de integridade em tempo de compila¸cão sempre que poss´ıvel.

Algumas RIs, como a dependência entre dados, podem se man-ter consistentes em BDs NoSQL que oferecem garantia de atomicidade nas opera¸cões. Com a utiliza¸cão de um modelo de dados com in-forma¸cões “agregadas” (SADALAGE; FOWLER, 2012), em que todos os dados relacionados são armazenados na mesma unidade de informa¸cão, as opera¸cões de atualiza¸cão, com garantia de atomicidade, sempre são mantidas consistentes. Porém, em algumas situa¸cões, a dependência ocorre entre dados não armazenados na mesma unidade de informa¸cão, sendo necessário, para manter a RI entre os dados, que as opera¸cões se-jam sincronizadas e existam mecanismos de recupera¸cão ou preven¸cão tratadas pela própria aplica¸cão devido à falta de suporte na maioria dos bancos NoSQL. De forma semelhante, quando existe a necessidade de que dados replicados mantenham a consistência entre as réplicas, é necessário que a aplica¸cão crie mecanismos para o controle. Apesar dos BDs relacionais oferecerem um bom suporte para garantir RIs, fazendo

(24)

uso de transa¸cões com propriedades ACID, segundo (SADALAGE; FO-WLER, 2012), isso não significa que são adequados para este fim, pois o desempenho das opera¸cões de consulta e escrita se torna problemático. Devido ao conflito entre consistência e desempenho em siste-mas geo-replicados, muitos BDs implementaram diferentes combina¸cões de garantias de consistência e protocolos para replica¸cão (ALMEIDA; LEIT ÃO; RODRIGUES, 2013). Execu¸cão de atualiza¸cões sem sincro-niza¸cão entre os vários nodos normalmente é alcan¸cada através de um modelo de consistência mais fraco utilizando BDDs com consistência eventual (EC), em que os dados estarão consistentes em um deter-minado momento. Uma tendência atual é oferecer tanto modelos de consistência forte como modelos de consistência fraca, em BDDs com EC, dependendo de cada opera¸cão, pois nem todas as opera¸cões ne-cessitam de garantias de consistência fortes. Ao contrário dos modelos de consistência forte, como o modelo linear, que oferece para o de-senvolvedor uma semântica intuitiva (ALMEIDA; LEIT ÃO; RODRIGUES, 2013), os sistemas com múltiplos modelos de consistência são de dif´ıcil implementa¸cão, pois é necessário que cada opera¸cão seja classificada corretamente a fim de garantir a consistência requerida pela aplica¸cão. Para definir e controlar os diversos modelos de consistência para as opera¸cões podem ser utilizadas implementa¸cões na camada de aplica-¸cão, através de extensões do BD em uso, possibilitando, dessa forma, que os modelos de consistência possam ser representados através de lin-guagens de programa¸cão e controlados através de solu¸cões na camada de aplica¸cão. Uma das formas em que os modelos de consistência po-dem ser especificados é através do uso de FOL, sendo que uma das formas de declarar e controlar RIs é através do uso de RDTs. RDT é um tipo de dado que encapsula variáveis cujos valores podem sofrer al-tera¸cões de forma concorrente em diferentes servidores e mesmo assim convergir de forma consistente na combina¸cão das opera¸cões realiza-das no RDT em cada servidor. Originalmente os RDTs são tipos de dados para valores replicados que devem assegurar que, em um ambi-ente com EC, a resolu¸cão de conflitos entre as réplicas seja uniforme e que convirja para o mesmo valor (BURCKHARDT et al., 2014). Desse modo, RDTs se tornam uma op¸cão para encapsular as opera¸cões re-lacionadas às RIs em BDDs com EC. A escolha do modelo adequado de consistência para cada opera¸cão de um RDT pode ser especificado através do uso de FOL (SIVARAMAKRISHNAN; KAKI; JAGANNATHAN, 2015), pois é poss´ıvel declarar as rela¸cões entre as opera¸cões do RDT e utilizar TP para escolher o modelo apropriado de consistência. Com isso, o controle das RIs é realizado na camada de aplica¸cão, sem a

(25)

neces-sidade de suporte espec´ıfico nos BDs. Apesar disso, as implementa¸cões de RDTs existentes descrevem invariâncias de uma variável em sua es-pecifica¸cão, sendo que, algumas RIs são especificadas utilizando mais de uma variável, o que exige uma complexidade maior de controle dos RDTs ao serem utilizadas em BDDs eventualmente consistentes.

1.1 JUSTIFICATIVA

BDs que não implementam as propriedades ACID em sua to-talidade somente podem ser eventualmente consistentes (POKORNY, 2013). Dessa forma, ao invés de usar transa¸cões com propriedades ACID, aplica¸cões que utilizam EC procuram controlar programatica-mente a sincroniza¸cão das atualiza¸cões a fim de manter a consistência no final das opera¸cões. BDs NoSQL utilizam EC nas opera¸cões, evi-tando o uso de consistência forte e transa¸cões com propriedades ACID (POKORNY, 2013). Por essa razão, BDs NoSQL levam o desenvolvedor do sistema a gastar muito tempo com a implementa¸cão de controles de poss´ıveis inconsistências (PAVLO; ASLETT, 2016), com uma grande complexidade na implementa¸cão de opera¸cões de atualiza¸cão e leitura dos dados. Isso porque deve ser de conhecimento prévio do desenvol-vedor o n´ıvel de consistência requerido por cada tipo de opera¸cão da aplica¸cão. Em sistemas distribu´ıdos, a replica¸cão e a distribui¸cão dos dados também dificultam o controle da consistência.

A extra¸cão das RIs e das opera¸cões em um n´ıvel intermediário que permita o mapeamento para n´ıveis de consistência necessários por cada opera¸cão, de acordo com as RIs descritas, permite uma dimi-nui¸cão da complexidade para o desenvolvedor do sistema ao projetar um sistema que mantenha as garantias de consistência. Além disso, ´

e poss´ıvel economizar recursos, pois a classifica¸cão das opera¸cões per-mite utilizar o modelo de consistência mais fraco poss´ıvel que atenda as RIs, favorecendo com isso o desempenho e a disponibilidade. Porém, apesar da existência de formas de representar na camada de aplica¸cão invariâncias do sistema, assim como formas de especificar a consistência por opera¸cão, existe uma complexidade em encontrar formas de espe-cificar invariâncias mais complexas, como chaves estrangeiras e fun¸cões envolvendo mais de uma variável.

(26)

1.2 OBJETIVO GERAL

Este trabalho tem como objetivo desenvolver uma abordagem para possibilitar a cria¸cão, na camada de aplica¸cão, de um modelo de dados intermediário que represente e controle RIs simples e complexas, possibilitando que uma aplica¸cão com RIs utilize BDs replicados com EC.

1.3 OBJETIVOS ESPEC´IFICOS

Este trabalho pretende alcan¸car os seguintes objetivos espec´ıficos: • Definir um modelo de dados para representar as RIs que podem

ser descritas em um RDT;

• Especificar uma abordagem atrav´es da qual, a partir das RIs mul-tivari´aveis, seja poss´ıvel construir RDTs customizados;

• Classificar, a partir da abordagem proposta, o n´ıvel de consistência necessário para cada opera¸cão executada no BD, utilizando con-tratos escritos em FOL.

• Executar experimentos para validar RDTs criados com a aborda-gem proposta e para avaliar o seu desempenho.

1.4 METODOLOGIA

Para controlar as RIs na camada de aplica¸cão, ao utilizar BDs re-plicados e eventualmente consistentes, esta abordagem utiliza um mid-dleware constru´ıdo com base em uma versão modificada no framework QUELEA. As modifica¸cões no framework QUELEA possibilitaram o controle de RDTs para invariâncias multivariáveis constru´ıdos com a abordagem TSC. Para isso são executadas as seguintes atividades:

• Revisão dos trabalhos relacionados: identifica¸cão dos trabalhos recentes que desenvolveram modelos e metodologias para contro-lar as invariâncias em n´ıvel de aplica¸cão;

• Modelo intermediário: criar um modelo para representar as in-variâncias de um sistema, opera¸cões e n´ıveis de consistência;

(27)

• Abordagem para extra¸cão de RIs e suas opera¸cões: criar uma abordagem para criar RDTs para RIs que envolvem uma ou mais variáveis;

• N´ıvel de consistência por opera¸cão: para cada opera¸cão presente na aplica¸cão, criar um método para classificar o n´ıvel de con-sistência requerida de acordo com a semântica e sintaxe das in-variâncias, utilizando como base o framework QUELEA;

• Desenvolvimento:

– Modifica¸cão do framework QUELEA para poder trabalhar com opera¸cões com múltiplas variáveis que possuam depen-dência entre si;

– Abordagem para cria¸cão de RDTs para invariâncias com uma ou mais variáveis levando em conta os estados de uma invariância antes e depois da atualiza¸cão;

– Mapeamento para a classifica¸cão das opera¸cões no n´ıvel de consistência necessário para cada tipo de invariância; – Implementa¸cão de um experimento para verificar o

desempe-nho dos RDTs criados com a abordagem em um cluster com nodos executando o BD Cassandra, por se tratar de um BD eventualmente consistente e com implementa¸cão do controle de RDTs já pronta no framework QUELEA. Foi utilizado dois cenários para compara¸cão: uso apenas de consistência forte, para simular o uso de propriedades ACID; e outro so-mente com EC, para simular BDDs com EC sem controle da consistência;

• Análise dos resultados: descri¸cão das vantagens, limita¸cões e poss´ıveis melhorias na abordagem desenvolvida.

1.5 ORGANIZAC¸ ˜AO DO TEXTO

Este trabalho est´a organizado nos seguintes cap´ıtulos:

• CAPÍTULO 1 - INTRODUÇ ÃO: contextualiza o problema do controle de consistência em BDDs, descrevendo o problema, a motiva¸cão, a justificativa, os objetivos e a abordagem empregada no trabalho;

• CAP´ITULO 2 - BANCOS DE DADOS NOSQL: descreve os prin-cipais tipos de BDs NoSQL e as diferen¸cas com BDs NewSQL;

(28)

• CAPÍTULO 3 - CONSISTÊNCIA EM BANCOS DE DADOS: descreve as formas de consistência existentes no armazenamento dos dados;

• CAPÍTULO 4 - REVIS ÃO BIBLIOGR ÁFICA: apresenta os tra-balhos relacionados que buscam controlar as invariâncias do sis-tema em n´ıvel de aplica¸cão;

• CAPÍTULO 5 - TSC: apresenta a abordagem para a cria¸cão de RDTs para as RIs de uma aplica¸cão, possibilitando, dessa forma, o controle de consistência em BDDs eventualmente consistentes; • CAPÍTULO 6 - AVALIAÇ ÃO DA PROPOSTA: implementa¸cão de testes de desempenho comparativo entre esquemas de EC, forte e utilizando a abordagem proposta e análise qualitativa em rela¸cão aos trabalhos relacionados;

• CAPÍTULO 7 - CONCLUS ÕES E TRABALHOS FUTUROS: descri¸cão das contribui¸cões que a abordagem TSC oferece para o controle de integridade em BDDs eventualmente consistentes, vantagens e desvantagens do uso da abordagem TSC e trabalhos futuros.

(29)

2 BANCOS DE DADOS NOSQL

NoSQL é um termo usado para denominar um conjunto de BDs que não utilizam o modelo relacional e que são mais apropriados para lidar com dados em grande escala e para representa¸cão de dados semi-estruturados, não estruturados ou de estruturas de dados mais seme-lhantes ao modelo seguido na aplica¸cão. Uma grande vantagem do uso desses BDs no desenvolvimento de aplica¸cões é que as formas de arma-zenamento dispon´ıveis não exigem do usuário uma defini¸cão de mode-lagem mais elaborada, suprindo a necessidade de formas mais flex´ıveis de armazenar grandes e diversificadas quantidades de informa¸cões.

Entre os grupos de BDs NoSQL mais comuns est˜ao os orienta-dos a chave-valor, os orientaorienta-dos a coluna, os orientaorienta-dos a documento e os orientados a grafos. Os BDs orientados a chave-valor, documen-tos e colunas possuem como caracter´ıstica em comum a possibilidade de armazenamento de estruturas de dados complexas, com a possibili-dade de modelagem de dados mais “agregados” (SADALAGE; FOWLER,

2012) e, portanto, abrindo um campo de possibilidades de modelagens que possam tirar proveito das caracter´ısticas espec´ıficas das aplica¸cões. Já os BDs orientados a grafos se distanciam dos demais por serem apropriados para aplica¸cões espec´ıficas que necessitam de muitos re-lacionamentos entre as entidades. Este cap´ıtulo descreve os quatro principais tipos de BDs NoSQL, com ênfase no esquema de dados e na consistência, assim como, descreve a diferen¸ca entre BDs NoSQL e NewSQL.

2.1 BANCOS DE DADOS CHAVE-VALOR

BDs chave-valor armazenam estruturas no formato de hash ta-ble, em que uma informa¸cão é gravada, recuperada e removida através de uma chave, de forma semelhante a uma chave primária. Estes BDs controlam a consistência normalmente usando o conceito de EC, o que significa que em algum momento os dados estarão consistentes. BDs chave-valor são adequados para aplica¸cões que precisam de alta dis-ponibilidade para armazenamento de dados, como sessões de usuários, carrinhos de compras e informa¸cões de perfis, permitindo a utiliza¸cão e compartilhamento dessas informa¸cões em vários dispositivos ao mesmo tempo. Porém, esses bancos não são adequados quando as consultas envolvem o conteúdo interno dos dados, assim como não são

(30)

adequa-dos para aplica¸c˜oes com relacionamento entre os dados (SADALAGE; FOWLER, 2012).

Exemplos de BDs chave-valor utilizados pela comunidade são o Riak (BASHO, 2015) e o Voldemort (LINKEDIN, 2016). No Riak o n´ıvel de consistência é configurável, ou seja, pode ser ajustado pelo usuário. No caso, pode ser configurado o número de réplicas, a quantidade de no-dos acessano-dos necessários para considerar uma leitura válida e o número de nodos necessário para considerar uma grava¸cão válida.

2.2 BANCOS DE DADOS ORIENTADOS A COLUNA

BDs orientados a coluna armazenam os dados em colunas ma-peadas por uma chave, sendo que as colunas podem ser agrupadas em fam´ılias de colunas. Fam´ılias de colunas são agrupamentos de dados relacionados e servem como mapeamento para as pesquisas juntamente com as chaves. Uma coluna tem o formato nome-valor, sendo que o nome pode ser usado também como chave em pesquisas. Cada coluna pode ser armazenada também com um timestamp, que é usado para resolver conflitos e diagnosticar um dado desatualizado, entre outras funcionalidades.

Uma linha em uma fam´ılia de colunas é composta por múltiplas e dinâmicas colunas relacionadas a uma chave. Cada linha não possui necessariamente as mesmas colunas, e pode ser modificada a qualquer momento sem acarretar uma atualiza¸cão de outras linhas da mesma fam´ılia. Cada coluna pode ser um valor simples ou pode ser uma super-coluna. A super-coluna acontece quando o valor é um mapeamento para várias outras colunas. Super-colunas são úteis para armazenar dados agregados que devem sempre ser retornados na pesquisa.

BDs orientados a coluna são apropriados para Analytics, OLAP, gravar eventos de log, informa¸cões de blogs e dados de administra¸cão de sistemas. Porém, não são aconselhados para quem precisa das propri-edades ACID nas leituras e grava¸cões de dados (SADALAGE; FOWLER, 2012), além de não serem eficientes para dados com muitos relaciona-mentos que necessitam de valida¸cão.

Um exemplo de BD orientado a coluna é o Cassandra (APACHE, 2015), utilizado pela abordagem TSC nos experimentos. O Cassan-dra controla a consistência através de logs e de uma memtable. Uma grava¸cão é considerada válida se ambos, logs e memtable, foram atu-alizados com o novo valor. Periodicamente os valores são persistidos em uma estrutura chamada SSTable. Essa estrutura é sempre criada,

(31)

nunca atualizada, e as estruturas não mais usadas são também periodi-camente revisadas. A consistência é controlada através de parâmetros informados para o sistema. É poss´ıvel configurar o número de réplicas, a quantidade de nodos necessários para validar uma leitura e o número de nodos necessários para validar uma grava¸cão. Ao configurar estes parâmetros se busca sempre respeitar a fórmula (R + W ) > N , sendo R o parâmetro para leitura, W o parâmetro para escrita e N o parâmetro para o número de réplicas. A importância de atender essa fórmula é para que o sistema não fique indispon´ıvel se algum nodo falhar.

No Cassandra as transa¸cões não funcionam da mesma maneira que a forma tradicional de um BD relacional. Cada atualiza¸cão é re-alizada de forma atômica e o que importa é a grava¸cão acontecer no logs e na memtable dos nodos conforme configurado no parâmero W. É poss´ıvel usar bibliotecas externas, como o ZooKeeper (APACHE, 2016), para coordenar a sincroniza¸cão de múltiplas atualiza¸cões.

No Cassandra as opera¸cões poss´ıveis são GET, SET e DEL. A intera¸cão com o banco pode ser feita através de comandos, através de bi-bliotecas como o Hector (ECHAGUE; MCCALL, 2011) e também através

de CQL (APACHE, 2011), uma linguagem de consulta semelhante ao SQL. É poss´ıvel também criar ´ındices em colunas para consultas muito usadas. Qualquer escrita e leitura pode ser feita em todas as colunas de uma chave ou em uma coluna espec´ıfica, ganhando com isso desem-penho. Durante a modelagem é importante decidir quais dados devem ser usados com uma chave diretamente ao invés de pertencer a uma coluna para melhorar o desempenho das consultas.

2.3 BANCOS DE DADOS ORIENTADOS A DOCUMENTO

BDs orientados a documento suportam a utiliza¸cão de dados es-truturados, como os formatos JSON, BSON e XML, de forma nativa no armazenamento. Isso possibilita o uso de indexadores e pesquisas com mais facilidade, como por exemplo, pesquisas utilizando um atributo presente em um documento no formato JSON. Em BDs orientados a documento, cada documento possui seu próprio conjunto de colunas, porém, apesar de ser comum cole¸cões de documentos possu´ırem colunas iguais, não existe uma restri¸cão para impor isso, facilitando modelos de dados que evoluem com o tempo na aplica¸cão. É normal também ter cole¸cões de dados relacionados no próprio documento, ganhando em desempenho nas consultas.

(32)

na mesma unidade de informa¸cão, facilitando o mapeamento entre a estrutura de dados da aplica¸cão e o BD. BDs orientados a documentos também são adequados para armazenar dados que sofrem altera¸cão com frequência na estrutura interna do modelo de dados, pois não é necessária uma modifica¸cão na estrutura de armazenamento no BD.

Um exemplo de BD orientado a documentos bastante utilizado no mercado é o MongoDB (MONGODB, 2016). A organiza¸cão do Mon-goDB utiliza conceitos como database, collection e document similares aos conceitos de database, table e row, respectivamente, em um BD re-lacional. O MongoDB realiza consultas sobre dados JSON, ou seja, é poss´ıvel consultar os dados utilizando os atributos internos dos docu-mentos. O MongoDB trabalha a consistência através de replica sets, onde são configurados, por exemplo, o número de nodos necessários para considerar uma escrita como válida. Isso pode ser realizado no próprio comando para a escrita, como por exemplo configurando o parâmetro w como majority implica em validar o comando somente se a maioria dos nodos participaram do comando. Em uma leitura é poss´ıvel configurar a opera¸cão com o método slaveOK para poder usar um nodo de backup como origem do dado, melhorando o desempenho mas também correndo o risco de trazer um dado não atualizado. A escrita dos dados também pode ser configurada usando a propriedade writeConcern, através da qual é poss´ıvel configurar para a opera¸cão ser considerada válida somente quando todos os nodos estiverem atualiza-dos ou, ao contrário, considerar válida com somente um nodo atuali-zado.

Apesar de existirem bancos NoSQL que utilizam transa¸cões, como o RavenDB (RHINOS, 2015), a maioria dos BDs NoSQL utiliza transa¸cões atômicas simples, envolvendo uma opera¸cão, como na atua-liza¸cão de um documento no MongoDB. A disponibilidade é garantida no MongoDB através também da configura¸cão das replicas sets, onde podem ser definidos os critérios para a escolha do novo nodo principal quando da falha de um dos nodos (SADALAGE; FOWLER, 2012).

2.4 BANCOS DE DADOS ORIENTADOS A GRAFOS

BDs orientados a grafos armazenam entidades (nodos) e os re-lacionamentos entre as entidades. Tanto os nodos quanto as rela¸cões podem possuir propriedades, sendo que não existe um limite para o número de rela¸cões de cada nodo. Estes bancos são apropriados para aplica¸cões que requerem dependências complexas entre os dados, como

(33)

em uma aplica¸c˜ao de rede social. As diferen¸cas entre um banco ori-entado a grafos e um banco relacional se tornam claras em pesquisas: enquanto bancos relacionais utilizam chaves estrangeiras para poder na-vegar entre os relacionamentos dos dados, um banco orientado a grafos consegue, a partir de um dado pesquisado, navegar pelos relacionamen-tos de forma muito mais eficiente.

O Neo4J (NEO, 2016) é um exemplo de um banco orientado a grafos. Nesse banco é poss´ıvel criar nodos e rela¸cões, além de indicar a dire¸cão que cada rela¸cão possui, ou seja, qual é o nodo de origem e de destino em cada rela¸cão. Cada rela¸cão pode ter propriedades, o que ajuda a enriquecer os tipos de pesquisas poss´ıveis no grafo. Uma carac-ter´ıstica em bancos com grafos é que a modelagem dos dados deve ser bem trabalhada previamente, pois mudan¸cas de relacionamentos po-dem se tornar custosas quando já em uso (SADALAGE; FOWLER, 2012). A consistência nesses BDs normalmente se dá através de transa-¸

cões ACID quando não há distribui¸cão dos dados. Porém, quando os dados são distribu´ıdos em diferentes clusters, a consistência se torna eventual. No Neo4J não se usa distribui¸cão dos dados em clusters e cada atualiza¸cão dos dados deve ser efetuada como uma transa¸cão ACID. O Neo4J pode prover alta disponibilidade através de réplicas com uma EC coordenada pelo ZooKeeper.

2.5 BANCOS DE DADOS NOSQL X BANCOS DE DADOS NEWSQL

NewSQL pode ser definido como uma classe de BDs relacionais moderna que procura prover a mesma escalabilidade e desempenho que os BDs NoSQL para opera¸cões de leitura e escrita em Online Tran-saction Processing (OLTP), porém, mantendo as garantias ACID nas transa¸cões. Os BDs NewSQL também fazem uso de instru¸cões SQL para executar as transa¸cões concorrentes que modificam o estado do BD. Isso evita a necessidade do desenvolvedor controlar no código da aplica¸cão as consequências do uso da EC, como necessário ao utilizar BDs NoSQL (PAVLO; ASLETT, 2016). Implementa¸cões em NewSQL de-vem ser livres de bloqueios para controlar a concorrência e devem pos-suir a arquitetura distribu´ıda shared-nothing (PAVLO; ASLETT, 2016), arquiteturas onde cada nodo servidor não compartilha recursos de ar-mazenamento e memória (STONEBRAKER, 1986).

Devido ao uso de transa¸c˜oes com propriedades ACID, os BDs NewSQL disponibilizaram para o desenvolvedor uma forma de traba-lhar com BDs relacionais distribu´ıdos sem a preocupa¸c˜ao do controle

(34)

da consistência. Porém, o baixo desempenho para manter as RIs ainda permanece, sendo amenizado em grande parte pela utiliza¸cão de meios de armazenamento mais rápidos, como o uso do BD em memória, além de melhorias na infraestrutura.

2.6 CONSIDERAÇ ÕES FINAIS DO CAPÍTULO

A fam´ılia de BDs NoSQL proporciona às aplica¸cões novas formas de modelagem dos dados. As estruturas de dados disponibilizadas nos BDs NoSQL são mais apropriadas para o armazenamento de alguns tipos de informa¸cões presentes nas aplica¸cões que lidam com grandes volumes de dados, como por exemplo o uso de BD orientados a grafos para armazenamento de informa¸cões de redes sociais.

BDDs também são mais facilmente desenvolvidos quando utili-zado BDs NoSQL, com exce¸cão dos orientados a grafos, que são mais adaptados para serem utilizados de forma centralizada. O escalona-mento dos dados se torna menos complexo com o uso de BDs orien-tados a documentos e orienorien-tados a colunas, que permitem armazenar dados agregados em uma unidade de informa¸cão, diferindo do modelo relacional que armazena em cada atributo somente valores atômicos. Com a possibilidade de dados aninhados em um único documento ou coluna é poss´ıvel decidir de forma mais fácil a distribui¸cão se compa-rado com os dados normalizados espalhados em diferentes tabelas em um BD relacional. Além disso, quando em um ambiente distribu´ıdo, a modelagem dos dados nos bancos NoSQL requer cuidado. Devem ser levadas em conta, por exemplo, as pesquisas realizadas na aplica¸cão e as garantias de integridade, já que consultas e atualiza¸cões podem resultar em opera¸cões onerosas. De forma diferente, os BDs NewSQL se especializaram em manter para o desenvolvedor as facilidades do uso de SQL e ao mesmo tempo utilizar BDDs, mantendo um modelo de dados com o qual o desenvolvedor está adaptado.

Porém, os BDs NewSQL não oferecem formas de controlar as RIs sem o uso de consistência forte. Ao mesmo tempo, os BDs NoSQL pos-suem algumas limita¸cões em rela¸cão aos bancos relacionais. Aspectos como a consistência dos dados NoSQL não são tão facilmente abstra´ıdos como são em BDs relacionais. A consistência em bancos NoSQL, dife-rentemente dos BDs relacionais, que oferecem uma consistência forte, pode ser usada de forma configurável, podendo, por exemplo, no caso de replica¸cão dos dados, ser relevada uma inconsistência temporária para favorecer o desempenho de uma atualiza¸cão. Porém, o suporte

(35)

para RIs, que buscam garantir a consistência dos dados, não é de fácil implementa¸cão, com exce¸cão de algumas formas simples de RIs, como a unicidade de chaves.

(36)

(37)

3 CONSIST ˆENCIA EM BANCOS DE DADOS

Consistência em BDs é um conceito fundamental ao projetar aplica¸cões que necessitam armazenar informa¸cões. Apesar da importˆ an-cia, projetos que utilizam BDs centralizados, sem distribui¸cão dos da-dos, conseguem usufruir de abstra¸cões da complexidade envolvida na garantia de consistência, não exigindo no projeto a cria¸cão de mecanis-mos sofisticados, pois o próprio BD fornece funcionalidades para ad-ministrar a consistência, como por exemplo com transa¸cões ACID em BDs relacionais e a atomicidade das opera¸cões em BDs NoSQL. Porém, para aplica¸cões que necessitam de distribui¸cão dos dados, as facilida-des que garantem uma consistência forte nesses bancos se tornaram um problema de desempenho. Apesar da adapta¸cão para trabalhar em clusters de alguns BDs relacionais, estes ainda não possuem a mesma facilidade em escalonamento horizontal (SCHREINER; DUARTE; MELLO, 2015). Com o crescimento do uso de BDDs, em especial dos bancos NoSQL, a defini¸cão dos requisitos de consistência passa a ser uma fase importante no desenvolvimento das aplica¸cões.

A consistência pode ser definida em termos de RIs, sendo que, essas assertivas devem permanecer em um estado válido após cada mudan¸ca de valor das variáveis persistidas no BD. (DECKER; MU ˜ NOZ-ESCOÍ; MISRA, 2015) distingue quatro situa¸cões em que uma altera¸cão no BD pode violar as RIs. A primeira é o caso de uma simples atu-aliza¸cão que viola diretamente uma regra de integridade; a segunda ´

e quando alguma redundância ou dependência não foi considerada na atualiza¸cão do dado; a terceira resulta de problemas causados por fa-lhas em sistemas de controle de concorrência; e a quarta em problemas ocasionados por defeitos em sistemas de distribui¸cão e replica¸cão dos dados.

Este cap´ıtulo descreve alguns dos principais tópicos de consistˆ en-cia em BDs: a consistência semântica, consistência em transa¸cões, con-sistência na distribui¸cão e replica¸cão dos dados, EC e RDT.

3.1 CONSIST ˆENCIA SEM ˆANTICA

A consistência semântica pode ser vista como o conjunto de es-tados (ou transi¸cão de estados) válidos poss´ıveis que um BD pode as-sumir. A consistência semântica é garantida através do uso da teoria de integridade, usando um conjunto de RIs. Essas RIs são regras que

(38)

representam o conhecimento acerca do dom´ınio de aplica¸c˜ao de um projeto. Segundo (_{OZSU; VALDURIEZ}¨ _{, 2001), RIs definem as}

proprie-dades estáticas ou dinâmicas de um dom´ınio que não podem ser cap-tadas diretamente pelos conceitos de objeto e opera¸cão de um modelo de dados, ou seja, o conceito de regra de integridade está fortemente relacionado com o de um modelo de dados, no sentido de que mais in-forma¸cões semânticas sobre o aplicativo podem ser captadas por meio dessas regras. Exemplos de RIs são RIs referenciais, de dom´ınio dos valores e obrigatoriedade, assim como regras de negócio que podem en-volver campos de diferentes tabelas. Segundo (DECKER; MU ÑOZ-ESCOÍ; MISRA, 2015), na prática não são muito bem suportadas pelos BDs re-lacionais, pois esses não possuem uma única solu¸cão para declarar e aplicar as RIs, de modo que muitas aplica¸cões impõem restri¸cões mais complexas através de triggers, stored procedures, códigos em n´ıvel de aplica¸cão e transa¸cões compensatórias.

Segundo (_{OZSU; VALDURIEZ}¨ _{, 2001) podemos distinguir dois tipos}

principais de RIs: restri¸cões estruturais e restri¸cões comportamentais. As “restri¸cões estruturais” são as inerentes ao modelo de dados, como por exemplo, chaves estrangeiras no modelo relacional. Já as “restri¸cões comportamentais” são relacionadas à semântica da aplica¸cão: os rela-cionamentos entre entidades, estruturas de dados e propriedades dos objetos.

Os m´etodos declarativos para expressar as RIs, de acordo com (_{OZSU; VALDURIEZ}¨ _{, 2001), surgiram com o modelo relacional para}

ate-nuar os problemas da dependência de programas e dados, redundâncias de código e o baixo desempenho de métodos procedurais. Com o uso de assertivas do cálculo de predicados, a declara¸cão e altera¸cão de regras de integridade se tornam mais fáceis. Porém, o controle de integridade semântica possui desafios para lidar com verifica¸cões complexas que podem utilizar um grande conjunto de dados para a valida¸cão, o que se torna ainda mais cr´ıtico quando o BD é distribu´ıdo.

Segundo (IBRAHIM, 2006) um sistema de verifica¸c˜ao eficiente em BDDs ´e crucial pois:

• Os dados necessários para verificar uma RI podem estar espalha-dos em diversos noespalha-dos, o que acarreta em transferência de dados entre os nodos para realizar a valida¸cão;

• Em ambientes que usam a técnica de fragmenta¸cão na distri-bui¸cão dos dados, RIs adicionais devem ser criadas junto com os fragmentos a fim de preservar a consistência. Além disso na replica¸cão dos dados também deve ser garantido que os valores

(39)

estejam iguais;

• Atualiza¸c˜oes frequentes podem acarretar verifica¸c˜oes dispendiosas de RIs;

• Atualiza¸cões em que o processamento é abortado ao finalizar a opera¸cão são ineficientes, pois devem realizar o retorno aos esta-dos anteriores através de cancelamentos de opera¸cões (rollback ) e recupera¸cões (recovery) em poss´ıveis nodos distintos que parti-ciparam do processamento tornando a opera¸cão onerosa.

RIs em BDs relacionais, segundo (_{OZSU; VALDURIEZ}¨ _{, 2001), s˜}_ao

definidas como assertivas, sendo que uma “assertiva” é uma expressão do cálculo relacional de tuplas, podendo assumir o valor verdadeiro ou falso. De acordo com (_{OZSU; VALDURIEZ}¨ _{, 2001), duas solu¸}_c˜_{oes para o}

controle de integridade semˆantica podem ser diferenciadas: a primeira em um sistema centralizado e a segunda em um sistema distribu´ıdo.

Em um “sistema centralizado” que usa o modelo relacional pode-mos especificar as RIs através de restri¸cões predefinidas, pré-compiladas e gerais, de acordo com (_{OZSU; VALDURIEZ}¨ _{, 2001). As restri¸}_c˜_oes

“pre-definidas” são as regras mais comuns do modelo relacional como o atri-buto não nulo, chave exclusiva, chave estrangeira e dependência funci-onal. As restri¸cões “pré-compiladas” são as que expressam condi¸cões que devem ser respeitadas por todas as tuplas de uma rela¸cão para uma atualiza¸cão, remo¸cão ou inclusão. Podem ser criados, por exemplo, res-tri¸cões de dom´ınio em que um campo deve assumir um valor simples ou pertencente a um intervalo de valores. Em uma restri¸cão “geral” a defini¸cão envolve fórmulas que podem conter mais de uma rela¸cão e, por isso, são mais concisas de serem declaradas que as restri¸cões “pré-compiladas”.

De acordo com (_{OZSU; VALDURIEZ}¨ _{, 2001), em um “sistema}

dis-tribu´ıdo”, a especifica¸cão deve levar em conta que os dados podem es-tar fragmentados. Usando o cálculo relacional, as “assertivas” podem ser separadas em três classes: assertivas individuais, assertivas orien-tadas a conjuntos e assertivas que incluem agregados, segundo (_OZSU;¨ VALDURIEZ, 2001). “Assertivas individuais” são as que envolvem uma variável em uma rela¸cão. Seu funcionamento envolve todos os nodos que contêm fragmentos dos dados envolvidos na “assertiva”. Caso al-guns dos fragmentos não satisfa¸ca o predicado presente na “assertiva”, pelo motivo do fragmento possuir um predicado incompat´ıvel ou porque o dado presente no fragmento não satisfazer o predicado da “assertiva” testada, então esta será rejeitada globalmente. Um exemplo dessas “assertivas individuais” são as restri¸cões de dom´ınio. As “assertivas

(40)

orientadas a conjuntos” podem envolver diversas variáveis relaciona-das através de predicados de jun¸cão. Apesar dos predicados de jun¸cão poderem envolver mais de uma rela¸cão, quando as variáveis presentes na jun¸cão pertencem a rela¸cões diferentes, cada “assertiva orientada a conjuntos” especifica uma restri¸cão envolvendo uma rela¸cão. Dessa forma, a verifica¸cão de compatibilidade exige a jun¸cão dos fragmentos das rela¸cões envolvida no predicado, o que pode tornar as opera¸cões dispendiosas. Como exemplo de “assertivas orientadas a conjuntos” temos as restri¸cões de chave estrangeira. As “assertivas que incluem agregados”, são as mais dispendiosas, envolvendo fun¸cões como o so-matório, m´ınimo, máximo e total de registros em uma rela¸cão. Essas “assertivas” contém uma parte que descreve uma proje¸cão nos dados e outra parte que envolve a sele¸cão. Por exemplo, uma “assertiva” que envolve um somatório de um aglomerado de dados no modelo relacional poderia ser uma regra em que, para uma tabela que possui os dados dos gastos mensais de uma pessoa, a soma dos gastos no mês atual nunca ultrapasse um limite definido.

3.2 CONSIST ÊNCIA EM TRANSAÇ ÕES

Consistência em transa¸cões é a garantia da integridade dos da-dos ao executar um grupo de transa¸cões concorrentes. Considerando uma história H com T transi¸cões, ao executar cada transi¸cão T, de forma isolada, cada transa¸cão não deve violar o conjunto de regras semânticas existentes no BD, segundo (BERNSTEIN; HADZILACOS; GO-ODMAN, 1987). Ao executar transa¸cões sem concorrência entre si em uma história, a integridade semântica é facilmente garantida, porém, quando existem transa¸cões concorrentes, mesmo que cada transa¸cão seja executada de forma individual e consistente, um conflito entre transa¸cões pode gerar erros comuns de concorrência, como por exem-plo, uma atualiza¸cão perdida em que uma transa¸cão sobrescreve um dado gravado por outra transa¸cão concorrente. Para conseguir traba-lhar com transa¸cões concorrentes, uma solu¸cão usada é a serializa¸cão de dados, de acordo com (GRAY et al., 1976).

Em transa¸cões, as propriedades ACID descrevem as caracter´ısti-cas que uma transa¸cão deve fornecer. Isolamento, também chamado em (TRAIGER et al., 1982) de concorrência transparente, garante que cada transa¸cão execute de forma independente, mesmo sendo executada de forma concorrente com outras transa¸cões. A consistência garante que cada transa¸cão em um conjunto de transa¸cões resultará em um estado

(41)

válido dos dados. Atomicidade garante que tudo é persistido ou nada, evitando atualiza¸cões parciais dos dados. A durabilidade é relacionada com a garantia da persistência dos dados ao final de sessões, final de transa¸cões, execu¸cões de programas e recupera¸cão dos dados em uma falha.

3.3 CONSIST ÊNCIA NA DISTRIBUIÇ ÃO E REPLICAÇ ÃO

A consistência na distribui¸cão dos dados tem o objetivo traba-lhar de forma que os mecanismos de consistência entre BDs distintos fiquem transparentes para os usuários. Segundo (DECKER; MU ˜ NOZ-ESCOÍ; MISRA, 2015) isso pode ser expresso pela consistência na

transa-¸

c˜ao, somada `a atomicidade em um commit.

Na distribui¸cão dos dados, os conflitos na atualiza¸cão podem ser controlados de forma otimista ou de forma pessimista. A forma pessimista previne a atualiza¸cão de um dado quando já existe uma outra atualiza¸cão concorrente em andamento, como por exemplo, com o uso de mecanismos de reserva exclusiva (lock ) em um dado. Apesar de garantir a consistência, a reserva exclusiva traz como consequências problemas de desempenho, já que um dos clientes deve esperar pelo final da reserva, podendo ocasionar erros dif´ıceis de detectar, como deadlocks. A forma otimista permite a atualiza¸cão concorrente dos dados, podendo gerar problemas como a perda de uma atualiza¸cão. Uma forma comum de método otimista é a atualiza¸cão condicional, na qual pode ocorrer falha antes de salvar o dado se verificado que ocorreu outra modifica¸cão no intervalo de tempo do processamento da atualiza¸cão. Outra forma otimista é tratar os dados diferentes através de merge automático ou manual.

Já a consistência na replica¸cão dos dados requer uma sincro-niza¸cão das opera¸cões de leitura e escrita que garanta um estado válido nas atualiza¸cões e nos cancelamentos de transa¸cões. Segundo (DECKER; MU ÑOZ-ESCOÍ; MISRA, 2015), isso pode ser expresso usando um proto-colo com a propriedade de serializa¸cão one-copy (1SR) (BERNSTEIN; HADZILACOS; GOODMAN, 1987) e a consistência na distribui¸cão. Em replica¸cões, conflitos nas atualiza¸cões de dados podem ser controlados mais facilmente, pois a maioria dos modelos de replica¸cão, com exce¸cão dos modelos peer-to-peer, utiliza um nodo para centralizar atualiza¸cões para cada dado, segundo (SADALAGE; FOWLER, 2012).

(42)

3.4 CONSIST ˆENCIA EVENTUAL

A EC garante que, em um dado momento, os dados estarão atu-alizados. Segundo (SAITO; SHAPIRO, 2005), a EC pode ser vista como uma forma de consistência de replica¸cão atrasada, que enfraquece a serializa¸cão em favor da alta disponibilidade, porém, com um acordo entre as réplicas para que eventualmente as opera¸cões convirjam para os mesmos valores com a mesma ordena¸cão. As cópias replicadas nessa forma de consistência estarão consistentes em um determinado mo-mento, ou seja, as viola¸cões das RIs não existirão no final do processo de replica¸cão segundo (DECKER; MU ÑOZ-ESCOÍ; MISRA, 2015).

O teorema CAP é bastante utilizado para justificar essa forma de consistência. Segundo o teorema CAP (GILBERT; LYNCH, 2002), somente é poss´ıvel atender dois dos três requisitos: consistência, dispo-nibilidade e tolerância ao particionamento. Em clusters que utilizam principalmente bancos NoSQL, enfraquecer a consistência para fornecer disponibilidade e tolerância ao particionamento é comum. Além disso, (BREWER, 2012) afirma que a escolha entre consistência e disponibili-dade, quando o BD é tolerante ao particionamento, deve ser feito de forma ponderada. Já que, falhas de particionamento são raras; a con-sistência pode ser diferenciada por opera¸cão ou dado envolvido; deve ser levado em conta que os BDDs normalmente possuem uma alta taxa de disponibilidade; diferentes esquemas de consistência são poss´ıveis; e as falhas de particionamento possuem diferentes nuances de como ocorrem.

3.5 RDT

O conceito de RDT foi proposto por diferentes trabalhos ( PRE-GUICA et al., 2009), (BURCKHARDT; LEIJEN, 2011), (ROH et al., 2011) e (SHAPIRO et al., 2011a), e consiste em um tipo de dados que encapsula a complexidade de replica¸cão e resolu¸cão de conflitos relacionados ao controle de um dado em sistemas distribu´ıdos, com garantias de confia-bilidade, disponibilidade e tempo de resposta. Um RDT é similar a um tipo de dados simples, como um simples registrador de leitura e escrita, um conjunto de valores, um mapa de valores ou um grafo, porém, com opera¸cões de manipula¸cão dos dados adaptados para o uso em BDDs replicados.

Do ponto de vista de um Abstract Data Type (ADT), um RDT possui opera¸c˜oes para controlar o estado interno dos dados

(43)

encapsu-lados. Por exemplo, um RDT para encapsular um registrador é cons-truido com opera¸cões para ler e configurar o valor do registrador. Da mesma forma, um RDT para encapsular um conjunto de valores, deve possuir opera¸cões para verificar a existência de elementos, assim como, adicionar e remover elementos do conjunto (SHAPIRO, 2017).

Figura 1: Exemplo de um RDT em BDDs.

A Figura 1 ilustra um RDT sendo utilizado em um sistema com BDDs com fator de replica¸cão 3. Os dados encapsulados pelo RDT são replicados sempre que uma nova opera¸cão for executada em um dos RDTs, através de um dos três servidores. Cada uma das opera¸cões de um RDT pode operar com uma consistência diferente, possibilitando que configura¸cões com um maior desempenho possam ser utilizadas para o controle de invariâncias do sistema, de acordo com a semântica da invariância que o RDT procura preservar.

3.6 CONSIDERAÇ ÕES FINAIS DO CAPÍTULO

A consistência em BDs envolve diversos mecanismos: formas de especifica¸cão de regras de integridade, uso de transa¸cões para a garantia da consistência entre múltiplas opera¸cões, controle da consistência nas réplicas dos dados e, no caso de fragmenta¸cão dos dados, o controle da consistência tanto na fragmenta¸cão quanto com as regras de integridade especificadas. Além disso, em alguns sistemas, principalmente em clus-ters, é preciso especificar o n´ıvel de consistência dos dados necessários, levando em conta que a disponibilidade e a tolerância ao particiona-mento vão ser afetadas. Outros mecanismos de consistência em n´ıvel

(44)

de hardware, em n´ıvel de comunica¸cão e seguran¸ca também são ne-cessários, porém, foram descritos os mais relacionados à consistência semântica, que será usada para descrever a proposta do trabalho.

(45)

4 REVIS ˜AO BIBLIOGR ´AFICA

Neste cap´ıtulo são revisados trabalhos que desenvolveram for-mas de descri¸cão e valida¸cão de invariâncias de um sistema em n´ıvel de aplica¸cão através de linguagens para especifica¸cão das invariâncias e mapeamentos para modelos de consistência apropriados nas opera¸cões relacionadas as invariâncias. Os trabalhos relacionados buscaram solu-¸

cões do controle de consistência em aplica¸cões com opera¸cões concor-rentes e BDDs com EC.

4.1 QUELEA

Em (SIVARAMAKRISHNAN; KAKI; JAGANNATHAN, 2015) foi cri-ada uma linguagem de programa¸cão chamada QUELEA para BDDs com EC. Através dessa linguagem são declaradas propriedades que es-pecificam a consistência de forma detalhada em n´ıvel de aplica¸cão. O objetivo dessa linguagem é identificar o n´ıvel de consistência necessária para que as restri¸cões presentes na aplica¸cão não sejam violadas.

A linguagem QUELEA é uma extensão da linguagem de pro-grama¸cão funcional Haskell (HASKELL.ORG, 2015). A extensão dispo-nibiliza funcionalidades para valida¸cão dos dados replicados de forma axiomática, envolvendo um conjunto de execu¸cões permitidas em um tipo de dado replicado. Essas valida¸cões fazem parte do contrato que, através de um sistema de verifica¸cão do contrato, mapeiam estatistica-mente as opera¸cões no n´ıvel de consistência dispon´ıvel no BD utilizado. O modelo descrito envolve um BD distribu´ıdo constitu´ıdo de réplicas com objetos armazenados. O estado de cada objeto em uma réplica é o conjunto de todas as atualiza¸cões, denominadas efeitos, efetuado no objeto. Cada objeto é associado com um conjunto de opera¸cões, através dessas opera¸cões, os clientes conseguem executar a¸cões nos objetos no BD. Uma sequência de opera¸cões executadas pelo cliente no BD é denominada sessão.

Através de um replicated data type foram definidas opera¸cões em uma aplica¸cão simulando um sistema bancário. As opera¸cões cri-adas, getBalance, deposit e withdraw, através da linguagem QUELEA, são opera¸cões atômicas. Para evitar algumas formas de anomalia que violam as RIs da aplica¸cão, como atualiza¸cões concorrentes no mesmo objeto, foram especificados contratos no QUELEA. Esses contratos, ex-pressos pela sintaxe da linguagem Haskell, permitem mapear o n´ıvel de

(46)

consistência que cada opera¸cão necessita manter e dessa forma, evitar as anomalias que violam as RIs da aplica¸cão. Por exemplo, considerando que uma das opera¸cões definidas, a opera¸cão withdraw, somente é exe-cutada quando houver saldo dispon´ıvel, ou seja, existe uma fun¸cão no servidor local da atualiza¸cão que não permite que a opera¸cão aconte¸ca se o valor resultante negativar o saldo, a regra definida no contrato para controlar essa opera¸cão e evitar que o BD crie uma valor negativo na conta corrente da aplica¸cão ao ser executado concorrentemente em diferentes servidores, é expresso pelo seguinte contrato ψω:

∀(a : withdraw)sameobj(a, ˆη) ⇒ a = ˆη ∨ vis(a, ˆη) ∨ vis(ˆη, a) (4.1) O contrato ψω define que, dadas duas opera¸c˜oes withdraw, o efeito ˆ

η de uma das opera¸cões deve ser igual ao efeito a resultante da ou-tra opera¸cão ou um dos efeitos deve ser vis´ıvel para o outro. Dessa forma, é poss´ıvel garantir, quando respeitado esse contrato, que as duas opera¸cões de withdraw não se sobreponham e mantenham uma consistência forte.

A sintaxe do contrato é baseada em FOL. Dessa forma, foi de-finido para a linguagem do contrato opera¸cões, efeitos, predicados e rela¸cões. Os efeitos podem ser classificados pelas opera¸cões que par-ticipam, como a sintaxe a : withdraw, significando que o efeito a é da opera¸cão withdraw. Os predicados são formados pelas rela¸cões, permitindo as fun¸cões matemáticas de conjun¸cão (∨), disjun¸cão (∧) e implica¸cão (⇒). As rela¸cões são formadas por um par de efeitos, como vis, so e sameobj, significando, respectivamente, que um efeito é vis´ıvel para outro, dois efeitos estão na mesma sessão e os dois efeitos são originados do mesmo objeto. As fun¸cões matemáticas poss´ıveis nas rela¸cões são a união (∪), interseçcão (∩) e fechamento transitivo (R+). Para mapear a consistência requerida de uma opera¸cão na ca-mada de aplica¸cão para o n´ıvel de consistência necessário no BD, foram definidos, através dos contratos, três n´ıveis de consistência poss´ıveis -eventual, causal e forte - nos BDs. O n´ıvel de EC acontece quando não ocorre sincroniza¸cão e coordena¸cão entre os servidores para as opera¸cões de atualiza¸cões, porém, mantendo a garantia de que os efei-tos das atualiza¸cões aconte¸cam em algum momento. Já a consistência causal ocorre quando as opera¸cões necessitam de coordena¸cão ao se-rem executadas nos servidores, ou seja, o efeito de uma opera¸cão só é considerado quando as outras opera¸cões, as quais essa opera¸cão possui dependência, já tenham sido realizadas no servidor atual da opera¸cão. A consistência forte acontece quando é necessário uma coordena¸cão e

(47)

sincroniza¸cão entre todos os servidores participantes da replica¸cão dos dados, afim de evitar que outras atualiza¸cões conflitantes possam ser realizadas antes que a opera¸cão atual seja sincronizada entre os servi-dores. Com a consistência dos BDs e as RIs da aplica¸cão mapeadas por contratos, foi poss´ıvel, através de TP, comparar e determinar se uma opera¸cão, com um contrato definido de acordo com as regras da aplica¸cão, pode ser atendida pelo n´ıvel de consistência oferecido no BD. Caso não possa, um n´ıvel mais forte de consistência é requisitado para o BD ao executar a opera¸cão.

No caso de opera¸cões envolvendo muitos objetos, a sintaxe de QUELEA possui uma extensão para trabalhar com transa¸cões. Como, por exemplo, a rela¸cão sametxn, indicando que os efeitos pertencem à mesma transa¸cão. É poss´ıvel especificar no contrato a semântica de transa¸cões sem coordena¸cão (coordination-free transactions) como, por exemplo, Read Committed (BERENSON et al., 1995) (RC), Monotonic Atomic View (MAV) (BAILIS et al., 2013) e Repeatable Read (RR) ( BE-RENSON et al., 1995). A classifica¸cão para o mapeamento das restri¸cões da aplica¸cão para a transa¸cão adequada é realizada de forma similar ao mapeamento realizado com os n´ıveis de semântica do BD. Seguindo uma classifica¸cão, é escolhida a transa¸cão mais simples para atender a restri¸cões da aplica¸cão.

QUELEA foi implementada através de uma extensão do compi-lador Haskell GHC (HASKELL.ORG, 2007) e testada no BD Cassandra. Através de templates em Haskell (SHEARD; JONES, 2002) foram cri-adas classifica¸cões para os contratos, sendo que, para trabalhar com as provas lógicas, foi utilizada a ferramenta Z3 (MOURA; BJØRNER, 2008). Através da interface disponibilizada no Cassandra foi criada uma camada para interceptar as requisi¸cões no BD e garantir a re-plica¸cão e consistência dos dados. Foi suportada EC, causal e forte na implementa¸cão para as opera¸cões que não envolvem transa¸cões. Para as opera¸cões com transa¸cões foram suportadas as semânticas de con-sistência RC, MAV e RR.

4.2 ADS

Em (BOCI Ć; BULTAN, 2014) é desenvolvido um mecanismo para preservar as invariâncias do sistema da aplica¸cão através da verifica¸cão das a¸cões executadas na mesma. Para isso foi criada uma especifica¸cão, chamada Abstract Data Store (ADS), para representar o modelo de dados da aplica¸cão. A ADS contém um conjunto de objetos, rela¸cões

(48)

e a¸cões e é criada de forma automatizada através da instrumenta¸cão do código seguida da transforma¸cão do código instrumentado para a linguagem ADS. Com a linguagem ADS é poss´ıvel uma redu¸cão para uma especifica¸cão de FOL e o uso de TP para que, através de uma verifica¸cão indutiva de invariância, seja poss´ıvel validar as invariâncias do modelo de dados. O TP usado foi o Spass (WEIDENBACH et al., 2009), e como o TP é indecid´ıvel em alguns casos, foi usado um limitador no tempo de espera na execu¸cão do provador.

A linguagem ADS, formalmente, segue a estrutura DS =< C, R, A, I >, sendo DS o BD representando, C o conjunto de classes, R o conjunto de rela¸cões, A o conjunto de a¸cões e I o conjunto de in-variâncias. Cada rela¸cão segue a estrutura r =< c0, ct, card >, com r ∈ R, sendo c0 a classe de origem, ct a classe destino e card a car-dinalidade da rela¸cão, como muito para muitos ou um para muitos por exemplo. O conjunto de todos os estados poss´ıveis em um BD é denotado por DS, que possui a estrutura < O, T >, sendo O o con-junto de objetos e T o concon-junto de tuplas. Cada a¸cão no BD é re-presentada pelo conjunto de transi¸cões poss´ıveis entre os estados do BD: (< O, T >, < O0_{, T}0 _{>) ⊆ DSXDS. Uma invariˆ}_{ancia corresponde} a uma fun¸cão booleana no formato: DS → {true, f alse}. Um com-portamento no BD é formado por um conjunto de estados, sendo que cada par de estados é uma a¸cão e o primeiro estado está de acordo com as invariâncias da aplica¸cão. Dessa forma, ao usar a verifica¸cão via FOL, um BD será consistente quando todos os estados alcan¸cáveis satisfazem todas as invariâncias da aplica¸cão, ou seja, DS é consistente quando ∀(< O, T > | < O, T >∈ DSR∧ i ∈ I → i(< O, T >) = true.

O mecanismo de gera¸cão da linguagem ADS foi desenvolvido utilizando a linguagem Ruby no framework Rails (RUBYONRAILS.ORG, 2017). Em Rails, o modelo de dados é implementado usando a bi-blioteca de persistência e ORM ActiveRecord. Dessa forma, o me-canismo de cria¸cão da linguagem ADS é baseado na transforma¸cão de métodos como User.find by name, instrumentando o código, de-vido principalmente à dinamicidade na gera¸cão automática de código pelo framework. A gera¸cão da linguagem ADS requer que o código implementado pela aplica¸cão siga corretamente a arquitetura Model-view-controller MVC. A¸cões na interface não são capturadas na trans-forma¸cão. As invariâncias do sistema são descritas usando uma sintaxe próxima a FOL em uma extensão criada para o framework Rails. A descri¸cão das invariâncias foi feita manualmente, observando o código fonte dos projetos testados.