otimizando sistemas intensivos em es através de programação concorrente
Post on 11-Feb-2018
223 Views
Preview:
TRANSCRIPT
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 1/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 2/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 3/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 4/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 5/162
Para meus pais, Stelio e Henrriete.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 6/162
Agradecimentos
Quero agradecer, em primeiro lugar, à minha esposa, Karina. Sem o seu apoio
incondicional, não teria ido tão longe. Agradeço também à minha filha, Alice. Sua chegada,
no início desta pesquisa, encheu-nos de alegria.
Diversos outros agradecimentos são devidos. Ao meu pai, Stelio, que me apresentou
ao computador e, ainda mais importante, ao violão, quando eu ainda era criança. À minha
mãe, Henrriete, que foi minha primeira professora de Matemática e, portanto, de Ciência
da Computação. À minha irmã Stella, que deu, por mim, o primeiro passo para que esta
pesquisa fosse possível. À minha sogra Tânia, que, assim como meus pais, nos ajudou acuidar de Alice.
Ao meu amigo e, agora, orientador, Silvio. Quase duas décadas depois de nossa
primeira colaboração, seu entusiasmo continua sendo uma poderosa força motriz para
mim. Aos professores Kiev e Nelson, cuja participação foi fundamental para a publicação
de alguns dos resultados alcançados nesta pesquisa. Ao professor Airton, que, com muita
paciência, me ensinou Análise Real.
Aos meus grandes amigos Fábio, Idevan, Celso e Humberto. Esta pesquisa é,
também, fruto de tudo o que aprendemos juntos na NEWStorm e na Pitang.
Por fim, gostaria de agradecer ao Banco Central do Brasil, que patrocinou esta
pesquisa, e aos colegas com quem trabalho, os quais assumiram minhas funções durante
minha ausência.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 7/162
“This is the springtime of my loving
The second season I am to know”
(Page - Plant, The Rain Song)
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 8/162
Resumo
ORMs (Object-Relational Mappers) são bastante populares porque eles reduzem o esforço
de desenvolvimento de camadas de acesso a dados ao permitir, entre outras coisas, que
sistemas manipulem objetos transientes e persistentes de maneira similar. Em particular,
ORMs permitem que sistemas naveguem por objetos de ambos os tipos exatamente
da mesma maneira. Infelizmente, entretanto, navegar por objetos persistentes é muito
mais lento do que navegar por objetos transientes. Para atenuar este problema, ORMs
pré-carregam objetos executando consultas SQL (Structured Query Language) que, no
lugar de carregar os atributos de um único objeto, tal como ocorre quando objetos são
carregados sob demanda, carregam os atributos de vários objetos. Em muitos casos, estas
consultas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMsexecuta consultas apenas sequencialmente.
Esta pesquisa visa aumentar o desempenho de sistemas baseados em ORMs. Para tanto,
ela define uma DSL (Domain-Specific Language) de especificação de navegações por objetos
chamada Litoral. Também integra esta pesquisa o projeto e a implementação de um
interpretador de especificações Litoral. O interpretador navega por objetos transientes
(aqueles que existem apenas na memória primária) e persistentes (aqueles que armazenados
em um banco de dados relacional) e pré-carrega os do segundo tipo executando consultassequencialmente ou concorrentemente.
A estratégia desta pesquisa foi avaliada com os benchmarks sintéticos Emeio e OO7,
desenvolvidos, respectivamente, no contexto desta pesquisa e por terceiros. No primeiro,
pré-carregar objetos executando consultas concorrentemente aumentou a velocidade de
execução em até 323,6%. No segundo, o aumento foi de até 245,7%. Os benchmarks
também foram implementados com os ORMs Hibernate e EcliseLink JPA, os quais
aderem à especificação JPA (Java Persistence Architecture). O primeiro foi escolhido
por ser bastante popular. O segundo foi escolhido por ser a implementação de referência
desta especificação. As implementações baseadas no Hibernate e EclipseLink JPA foram
significativamente otimizadas. Entretanto, em todos os cenários de Emeio e OO7 que
oferecem oportunidades para pré-carregar objetos executando consultas concorrentemente,
o desempenho delas foi inferior ao da implementação baseada no interpretador de Litoral.
Palavras-chaves: Mapeamento objeto-relacional. Pré-carregamento. Concorrência.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 9/162
Abstract
ORMs (Object-Relational Mappers) are quite popular because they reduce the effort of
developing data access layers by allowing, among other things, systems manipulate transient
and persistent objects in similar ways. In particular, ORMs allow systems navigate through
objects of both types exactly the same way. Unfortunately, however, navigating through
persistent objects is much slower than navigating through transient ones. To alleviate this
problem, ORMs prefetch objects executing SQL (Structured Query Language) queries
that fetch the attributes of multiple objects. In many cases, these queries can be executed
concurrently. However, most ORMs execute queries sequentially only.
In this research, we aim to increase the performance of ORM based systems. To thisend, we define a DSL (Domain-Specific Language) for specifying navigations through
objects called Litoral. We also implement a Litoral interpreter that navigates through
transient (objects that exist only in the primary memory) and persistent objects (objects
stored in a relational database) and prefetches the second type with queries executed
sequentially or concurrently.
We evaluated our strategy with the synthetic benchmarks Emeio and OO7. In the first
one, prefetching objects with queries concurrently executed increased execution speed upto 323.6%. In the second one, the increase was up to 245.7%. We also implemented the
benchmarks with the Hibernate and EcliseLink JPA ORMs, which adhere to the JPA (Java
Persistence Architecture) specification. We chose the first one because it is quite popular
and the second one because it is the reference implementation of JPA. We optimized
the implementations based on Hibernate and EclipseLink JPA extensively. However, in
all scenarios of Emeio and OO7 that offer opportunities for prefetching objects with
queries concurrently executed, their performance was inferior to the performance of the
implementations based on the Litoral interpreter.
Keywords: Object-relational mapping. Prefetching. Concurrency.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 10/162
Lista de ilustrações
Figura 1 – Trecho de código Java que navega por objetos. . . . . . . . . . . . . . . 17
Figura 2 – Especificação Litoral que declara navegações de mensagens para seus
remetentes e destinatários. . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 3 – Trecho de código Java que pré-carrega objetos com o interpretador de
Litoral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Figura 4 – Trecho de código Java que requisita objetos especificando o predicado
que eles devem satisfazer. . . . . . . . . . . . . . . . . . . . . . . . . . 26
Figura 5 – Consultas SQL que ORMs executam para carregar sob demanda os
atributos de mensagens manipulados pelo trecho de código da Figura 4. 26Figura 6 – Consulta SQL que pré-carrega todos os atributos do primeiro tipo de
uma mensagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Figura 7 – Consulta SQL que pré-carrega todos os atributos do tipo I de uma
mensagem e, através de uma junção, também seu remetente. . . . . . . 27
Figura 8 – Consulta SQL que pré-carrega todos os atributos de uma mensagem. . 29
Figura 9 – Consultas que pré-carregam os destinatários e os remetentes de várias
mensagens através do operador in de SQL. . . . . . . . . . . . . . . . . 29
Figura 10 – Trecho de código Java que informa a ORMs compatíveis com a especifi-cação JPA quais objetos eles devem pré-carregar. . . . . . . . . . . . . 30
Figura 11 – Método Java que carrega as mensagens enviadas por um usuário. . . . 33
Figura 12 – Método Java que carrega as mensagens enviadas por um usuário e
pré-carrega seus remetentes. . . . . . . . . . . . . . . . . . . . . . . . . 33
Figura 13 – Gramática de Litoral em notação EBNF e em diagramas de sintaxe. 34
Figura 14 – Trecho de código Java que navega por objetos. . . . . . . . . . . . . . . 35
Figura 15 – Especificação Litoral que navega através de um único atributo. . . . 36
Figura 16 – Geração da especificação da Figura 15 a partir da gramática de Litoral. 36
Figura 17 – Especificação Litoral que navega através de coleções de objetos. . . . 36
Figura 18 – Especificação Litoral que navega através de mais de um atributo. . . 37
Figura 19 – Geração da especificação da Figura 18 a partir da gramática de Litoral. 37
Figura 20 – Especificação Litoral que navega por um único atributo. . . . . . . . 37
Figura 21 – Especificação Litoral que navega indiretamente. . . . . . . . . . . . . 38
Figura 22 – Especificação Litoral que encadeia navegações indiretas. . . . . . . . 38
Figura 23 – Especificação Litoral que replica uma navegação. . . . . . . . . . . . 39
Figura 24 – Especificação Litoral que define uma travessia. . . . . . . . . . . . . 39
Figura 25 – Geração da especificação da Figura 24 a partir da gramática de Litoral. 40Figura 26 – Especificação Litoral que define uma travessia recursiva. . . . . . . . 41
Figura 27 – Representação de classes e objetos no interpretador definidor. . . . . . 42
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 11/162
Figura 28 – Criação de classes no interpretador definidor. . . . . . . . . . . . . . . 43
Figura 29 – Representação de especificações Litoral no interpretador definidor. . 43
Figura 30 – Criação de uma especificação Litoral no interpretador definidor. . . . 44
Figura 31 – Analisador semântico. . . . . . . . . . . . . . . . . . . . . . . . . . . . 45Figura 31 – Analisador semântico - continuação . . . . . . . . . . . . . . . . . . . . 46
Figura 31 – Analisador semântico - continuação. . . . . . . . . . . . . . . . . . . . 47
Figura 31 – Analisador semântico - continuação. . . . . . . . . . . . . . . . . . . . 48
Figura 32 – Teorema que assegura que o analisador semântico do interpretador
definidor sempre é capaz de validar especificações Litoral em um
número finito de recursões. . . . . . . . . . . . . . . . . . . . . . . . . . 50
Figura 33 – Interpretador definidor. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Figura 33 – Interpretador definidor - continuação. . . . . . . . . . . . . . . . . . . . 52
Figura 33 – Interpretador definidor - continuação. . . . . . . . . . . . . . . . . . . . 53
Figura 34 – Função filter que impede navegações. . . . . . . . . . . . . . . . . . . . 54
Figura 35 – Semântica 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Figura 36 – Especificação Litoral que entra em recursão infinita na semântica 1. . 55
Figura 37 – Mensagem que se auto-referencia. . . . . . . . . . . . . . . . . . . . . . 55
Figura 38 – Semântica 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Figura 39 – Teorema que assegura que, sob a semântica 2, especificações Litoral
não entram em recursão infinita. . . . . . . . . . . . . . . . . . . . . . 57
Figura 40 – Programa Litoral que especifica navegações que não são realizadasna semântica 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 41 – Especificação Litoral que permuta os passos de uma outra especifi-
cação e, na semântica 2, navega por objetos pelos quais a original não
navega. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Figura 42 – Semântica 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Figura 43 – Cálculo de b2 − 4ac compondo invocações de métodos. . . . . . . . . . 63
Figura 44 – Cálculo de b2 − 4ac com funções assíncronas. . . . . . . . . . . . . . . . 64
Figura 45 – Estratégia de Afluentes para combinar as vantagens de funçõessíncronas e assíncronas. . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Figura 46 – Interfaces ISyncFn0, ISyncFn1 e ISyncFn2. . . . . . . . . . . . . . . . . 66
Figura 47 – Cálculo de b2 − 4ac compondo invocações de funções síncronas. . . . . 66
Figura 48 – Interface ICallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Figura 49 – Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2. . . . . . . . . . . . . . . 67
Figura 50 – Funções sub e mul definidas com as interfaces IAsyncFn2. . . . . . . . 67
Figura 51 – Interface IEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Figura 52 – Interfaces IEval0 e IEval1. . . . . . . . . . . . . . . . . . . . . . . . . . 68Figura 53 – Cálculo de b2 − 4ac compondo invocações de funções síncronas. . . . . 69
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 12/162
Figura 54 – Cálculo de b2 − 4ac compondo invocações de funções síncronas e assín-
cronas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Figura 55 – Processo de avaliação de b2 − 4ac. . . . . . . . . . . . . . . . . . . . . . 69
Figura 56 – Cálculo do somatório dos preços dos produtos de uma lista compondoinvocações de funções síncronas. . . . . . . . . . . . . . . . . . . . . . . 71
Figura 57 – Cálculo do somatório dos preços dos produtos de uma lista compondo
avaliadores de funções assíncronas e de funções sobre listas. . . . . . . 72
Figura 58 – Interface IEvalHolder. . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Figura 59 – Proxy que implementa a interface IEvalHolder. . . . . . . . . . . . . . 73
Figura 60 – Interface IPrefetcher. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
Figura 61 – Trecho de código Java que usa o interpretador de Litoral. . . . . . . 74
Figura 62 – Gramática de Litoral na metalinguagem do ANTLR. . . . . . . . . . 75
Figura 63 – Especificação Litoral cuja árvore sintática e AST são exibidas nas
figuras 64a e 64b, respectivamente. . . . . . . . . . . . . . . . . . . . . 76
Figura 64 – Árvore sintática e AST da especificação da Figura 63 . . . . . . . . . . 77
Figura 65 – Tabela de símbolos da especificação Litoral da Figura 63. . . . . . . 78
Figura 66 – Interpretação de especificações Litoral . . . . . . . . . . . . . . . . . 80
Figura 66 – Interpretação de especificações Litoral - Continuação . . . . . . . . . 81
Figura 66 – Interpretação de especificações Litoral - Continuação . . . . . . . . . 82
Figura 67 – Especificações Litoral que compõem o benchmark Emeio. . . . . . . 86
Figura 68 – Tabelas adicionadas ao banco de dados para otimizar a implementaçãode Emeio baseada no Hibernate. . . . . . . . . . . . . . . . . . . . . . 87
Figura 69 – Índices criados no banco de dados de Emeio. . . . . . . . . . . . . . . 87
Figura 70 – Resultado das otimizações da implementação de Emeio baseada no
Hibernate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Figura 70 – Resultado das otimizações da implementação de Emeio baseada no
Hibernate - continuação. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Figura 71 – Tempo total de execução das implementações de Emeio baseadas no
interpretador de Litoral, Hibernate e EclipseLink JPA. . . . . . . . . 91Figura 72 – Índices de OO7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Figura 73 – Especificações Litoral que fazem parte de OO7. . . . . . . . . . . . . 93
Figura 74 – Resultados da otimização da implementação de OO7 baseada no Hi-
bernate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Figura 75 – Tempo total de execução das implementações de Emeio baseadas no
interpretador de Litoral, Hibernate e EclipseLink JPA. . . . . . . . . 95
Figura 76 – Especificação Program Summary que declara navegações das mensagens
enviadas por um usuário para seus remetentes e destinatários. . . . . . 96Figura 77 – Tabelas de Emeio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Figura 78 – Tabelas de OO7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 13/162
Lista de abreviaturas e siglas
API Application Programming Interface
AST Abstract Syntax Tree
BCB Banco Central do Brasil
CAD Computer Aided Design
CAM Computer Aided Manufacturing
CASE Computer Aided Software Engineering
DSL Domain-Specific Language
EBNF Extended Backus-Naur Form
E/S Entrada/Saída
JPA Java Persistence Architecture
JPQL Java Persistence Query Language
ORM Object-Relational Mapper
OODBMS Object-Oriented Database Management System
REST Representational State Transfer
RMI Remote Method Invocation
SGBD Sistema de Gerenciamento de Banco de Dados
SOAP Simple Object Access Protocol
SQL Structured Query Language
VLSI Very Large Scale Integration
XPath XML Path Language
XML Extensible Markup Language
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 14/162
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.1 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2 ORMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.4 Estratégia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4.1 Viabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.2 Generalidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Avaliação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201.6 Organização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 CONCEITOS BÁSICOS . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.1 Sistemas Intensivos em Processamento e em E/S . . . . . . . . . . . 22
2.2 Otimização de Sistemas Intensivos em E/S . . . . . . . . . . . . . . 23
2.2.1 Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.2 Agregação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.3 Carregamento sob Demanda e Pré-carregamento . . . . . . . . . . . . . . 23
2.2.3.1 Pré-carregamento Informado e Especulativo . . . . . . . . . . . . . . . . . . . . 24
2.2.4 Compressão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.5 Concorrência . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.3 Carregamento sob Demanda, Pré-carregamento e Agregação em
ORMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.1 Tipos de Atributo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3.2 Carregamento de Atributos do Tipo I . . . . . . . . . . . . . . . . . . . . 27
2.3.3 Carregamento de Atributos do Tipo II que Referenciam Objetos . . . . . . 27
2.3.4 Carregamento de Atributos do Tipo II que Referenciam Coleções . . . . . . 282.3.5 Pré-carregamento Informado . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.3.6 Pré-carregamento Especulativo . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4 Hipótese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3 LITORAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.2 Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.3 Semântica Informal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.3.1 Navegando Através de um Único Atributo . . . . . . . . . . . . . . . . . . 363.3.2 Navegando Através de mais de um Atributo . . . . . . . . . . . . . . . . . 36
3.3.3 Navegando Indiretamente . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 15/162
3.3.4 Travessias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.3.5 Travessias Recursivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.4 Interpretador Definidor . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1 Representação de Classes e Objetos . . . . . . . . . . . . . . . . . . . . . 423.4.2 Representação de Especificações Litoral . . . . . . . . . . . . . . . . . 43
3.4.3 Análise Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.4.4 Interpretação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.4.4.1 Argumentos S, filter e s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.4.2 Semântica 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.4.4.3 Semântica 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4.4.4 Semântica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.4.5 Escolha de uma Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4 INTERPRETADOR . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1 Afluentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.1 Modelo de Programação . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.2 Funções Síncronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.3 Funções Assíncronas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.4 Avaliadores, Avaliações e Processo de Avaliação . . . . . . . . . . . . . . . 65
4.1.5 Representando Funções Síncronas . . . . . . . . . . . . . . . . . . . . . . 65
4.1.6 Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 664.1.7 Representando Funções Assíncronas . . . . . . . . . . . . . . . . . . . . . 67
4.1.8 Avaliações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1.9 Avaliadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.10 Funções sobre Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.11 Avaliadores de Funções sobre Listas . . . . . . . . . . . . . . . . . . . . . 70
4.2 Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.3 Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.3.1 Análise Léxica e Sintática . . . . . . . . . . . . . . . . . . . . . . . . . . . 744.3.2 Análise Semântica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
4.3.3 Interpretação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.3.1 Nós que Atuam Sobre Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3.3.2 Nós que Atuam Sobre Listas . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5 AVALIAÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.1 Emeio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.1.1 Implementação Baseada no Hibernate . . . . . . . . . . . . . . . . . . . . 85
5.1.2 Implementação Baseada no EclipseLink JPA . . . . . . . . . . . . . . . . . 895.1.3 Implementação Baseada no Interpretador de Litoral . . . . . . . . . . . 89
5.1.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 16/162
5.2 OO7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
5.2.1 Implementação Baseada no Hibernate . . . . . . . . . . . . . . . . . . . . 93
5.2.2 Implementação Baseada no EclipseLink JPA . . . . . . . . . . . . . . . . . 94
5.2.3 Implementação Baseada no Interpretador de Litoral . . . . . . . . . . . 945.2.4 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 96
6.1 Program Summaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.2 Scalpel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
6.3 AutoFetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6.4 Outros Trabalhos sobre Pré-carregamento Especulativo . . . . . . . 100
7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017.1 Contribuições . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
APÊNDICE A – EMEIO . . . . . . . . . . . . . . . . . . . . . . . . 109
A.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
A.2 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
APÊNDICE B – OO7 . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.1 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
B.2 Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
APÊNDICE C – DEMONSTRAÇÕES . . . . . . . . . . . . . . . . . 115
C.1 Seq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.2 NatSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
C.3 ListSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
C.4 Lim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
C.5 ListOptionSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
C.6 Sublist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
C.7 LitoralFacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
C.8 AnalyzeSpecFacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
C.9 InterpretSpecFacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 17/162
16
1 Introdução
Sistemas computacionais são pervasivos em nossa sociedade. Em boa parte, isto se
deve à maior eficácia e eficiência observadas quando a sociedade executa diferentes processos
de negócio apoiada por tais sistemas. No Brasil, por exemplo, o uso da computação permite
que eleitores conheçam os resultados de eleições apenas algumas horas depois de encerradas
as votações. Antes das urnas eletrônicas, a apuração de votos durava vários dias. Além disto,
como votos eram computados manualmente, esta etapa do processo eleitoral estava mais
sujeita a erros e fraudes. A otimização de sistemas computacionais, portanto, contribui,
em última análise, para uma sociedade mais eficaz e eficiente.
Muitos sistemas sobre os quais a sociedade se apóia são construídos em linguagens
orientadas a objetos e manipulam dados armazenados em bancos de dados relacionais
através de ORMs (Object-Relational Mappers). No BCB (Banco Central do Brasil), por
exemplo, existe a diretriz de que todos os sistemas devem ser desenvolvidos em linguagens
orientadas a objetos, devem armazenar dados em bancos relacionais e, por fim, devem
interagir com estes bancos de dados através de ORMs. Esta diretriz se aplica não só aos
sistemas corporativos (utilizados por mais de um departamento do BCB) como também
aos departamentais (utilizados por um único departamento), independentemente destes
sistemas serem desenvolvidos pelo próprio BCB ou contratados a terceiros.
1.1 Objetivo
Dada a sua importância para a sociedade, esta pesquisa visa aumentar o desempenho
de sistemas baseados em ORMs.
1.2 ORMsORMs são populares porque eles reduzem o esforço de desenvolvimento de camadas
de acesso a dados ao permitir, entre outras coisas, que sistemas manipulem objetos
transientes e persistentes de maneira similar. Em particular, ORMs permitem que sistemas
naveguem por objetos de ambos os tipos exatamente da mesma maneira. Por exemplo, o
trecho de código Java (GOSLING et al., 2014) da Figura 1 navega de mensagens para seus
remetentes (linha 4) e destinatários (linha 5), não importando se estes objetos existem
apenas na memória primária (ou seja, são transientes) ou se um banco de dados relacional
os armazena (ou seja, são persistentes). Infelizmente, este trecho de código é muito maislento no segundo caso porque, para que ele navegue de uma mensagem para um objeto
destino, ORMs precisam primeiro carregar o objeto destino do banco de dados.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 18/162
Capítulo 1. Introdução 17
1 List <Message> messages = getMessages ( ) ;
2 f o r ( Mes sa ge m e ss a ge : m e s sa g e s ) {
3 print Messa ge ( message ) ;
4 pr int User ( message . getSender ( ) ) ;
5 f o r ( U ser r e c i p i e n t : m es sa ge . g e t R e c i pi e n t s ( ) ) {6 p r i n tU s e r ( r e c i p i e n t ) ;
7 }
8 }
Figura 1 – Trecho de código Java que navega por objetos.
ORMs atenuam este problema pré-carregando (prefetching) objetos, ou seja, carre-
gando objetos antes de um sistema navegar por eles. O pré-carregamento propriamente
dito não reduz o tempo tc que ORMs levam para carregar objetos, mas dá a ORMs achance de pré-carregarem vários objetos executando uma única consulta SQL (Structured
Query Language) (EISENBERG et al., 2004). Pré-carregar os mesmos objetos executando
menos consultas é o que realmente reduz tc, pois isto diminui a incidência das latências
dos canais de comunicação entre ORMs e bancos de dados sobre tc (BERNSTEIN; PAL;
SHUTT, 2000).
Voltando ao exemplo da Figura 1: sem pré-carregamento, ORMs executam duas
consultas para cada execução das linhas 4–5. A primeira carrega o remetente de uma
mensagem sob demanda. A segunda carrega seus destinatários sob demanda. Portanto, se ométodo getMessages retorna n mensagens, então ORMs executam 2n consultas. Por outro
lado, com pré-carregamento, ORMs podem pré-carregar remetentes e destinatários de todas
as mensagens executando apenas 2 consultas quando a linha 1 é executada, não importando
quantas mensagens getMessages retorna, reduzindo assim tc significativamente.
Como as consultas que pré-carregam remetentes e destinatários são independentes,
elas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMs executa
consultas apenas sequencialmente.
1.3 Hipótese
Esta pesquisa parte da hipótese de que o pré-carregamento, em muitos casos,
também dá a ORMs a chance de executar consultas concorrentemente e que, combinando
esta otimização com consultas que carregam vários objetos, ORMs podem reduzir tc ainda
mais.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 19/162
Capítulo 1. Introdução 18
1 [ s e nd e r r e c i p i e n t s ]
Figura 2 – Especificação Litoral que declara navegações de mensagens para seus reme-tentes e destinatários.
1 List <Message> messages = getMessages ( ) ;
2
3 S t r i n g s p ec = " [ s e n d er r e c i p i e n t s ] " ;
4 IPr e fet cher <List <Message>> pre fe tc he r =
5 new Pre fetc herI mpl <List <Message>>(spec ) {};
6 pr e f et ch er . pre fet ch ( messages ) ;
7
8 f o r ( Mes sa ge m e ss a ge : m e s sa g e s ) { / ∗ . . . ∗/ }
Figura 3 – Trecho de código Java que pré-carrega objetos com o interpretador de Litoral.
1.4 Estratégia
Esta pesquisa define uma DSL (Domain-Specific Language) (DEURSEN; KLINT;
VISSER, 2000) de especificação de navegações por objetos chamada Litoral. A Figura
2, por exemplo, exibe uma especificação Litoral que declara navegações de mensagens
para seus remetentes e destinatários.
Também faz parte desta pesquisa o projeto e a implementação de um interpretadorque executa especificações Litoral. O interpretador navega por objetos transientes e
persistentes e pré-carrega os do segundo tipo executando consultas concorrentemente. O
interpretador foi projetado de forma a absorver todas as questões relativas à concorrência,
delegando a ORMs questões relativas à interação com bancos de dados. Graças a esta
divisão de responsabilidades, qualquer ORM pode embutir o interpretador e assim pré-
carregar objetos executando consultas concorrentemente. A Figura 3, por exemplo, exibe
o trecho de código previamente exibido na Figura 1 modificado para usar o interpretador.
A linha 4 instancia o interpretador a partir da especificação Litoral contida nalinha 3. A linha 5 executa o interpretador passando-lhe como parâmetro uma lista de
mensagens. Quando a execução da linha 5 chega ao fim, o interpretador terá pré-carregado
os remetentes e destinatários das mensagens. A grande diferença entre os trechos de código
exibidos nas Figuras 1 e 3 é que no primeiro, que não faz uso do interpretador, ORMs
pré-carregam objetos executando consultas sequencialmente, enquanto que no segundo o
interpretador pré-carrega objetos executando consultas concorrentemente.
Um aspecto positivo desta estratégia é que ela permite que programadores desen-
volvam sistemas que pré-carregam objetos executando consultas concorrentemente sem,contudo, lidar com programação concorrente, reconhecidamente difícil (NANZ; WEST;
SILVEIRA, 2013).
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 20/162
Capítulo 1. Introdução 19
Outro aspecto que merece destaque nesta estratégia é que ela pode ser adotada
pontualmente e também a posteriori. O trecho de código da Figura 3, por exemplo, é
funcionalmente idêntico com ou sem o interpretador. A diferença nestes dois casos é apenas
não-funcional. Com o interpretador, o trecho de código é executado mais rapidamente.Portanto, pode-se identificar em códigos preexistentes os pontos que oferecem maiores
oportunidades para pré-carregar objetos executando consultas concorrentemente e adotar
o interpretador apenas nestes pontos.
1.4.1 Viabilidade
Existe um debate em torno da viabilidade de programadores especificarem navega-
ções. De um lado do debate, (IBRAHIM; COOK, 2006) argumenta que é difícil especificar
navegações corretamente. Adicionalmente, manutenções evolutivas e corretivas podeminvalidar especificações previamente válidas. Estes trabalhos propõem métodos que permi-
tam a ORMs especular quais navegações sistemas executam, eliminando a necessidade de
programadores especificarem navegações.
Do outro lado do debate, (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) defende
que programadores especialistas podem especificar navegações com relativa facilidade e
que o aumento de desempenho obtido a partir delas compensa seus custos. Uma evidência
de que esta opinião é no mínimo razoável é que ORMs bastante populares (BLAKE-
LEY et al., 2006; ADYA et al., 2007; CASTRO; MELNIK; ADYA, 2007; LINSKEY;PRUD’HOMMEAUX, 2007; O’NEIL, 2008) oferecem mecanismos para que programadores
especifiquem navegações. Além disto, como os métodos de especulação são falíveis, eles
podem resultar no pré-carregamento de mais ou menos objetos do que o necessário, preju-
dicando o desempenho dos sistemas que os adotam. Portanto, pelo menos nestes casos, é
preciso um mecanismo que permita ao programador sobrepor as especulações dos métodos.
Apesar desta pesquisa se alinhar aos trabalhos que defendem que os benefícios
superam os custos, ela continuará válida mesmo que esta hipótese não se confirme. Isto
acontece porque a otimização que ela propõe, ou seja, pré-carregar objetos executandoconsultas concorrentemente, pode ser implementada a partir de navegações especificadas
automaticamente ou manualmente.
1.4.2 Generalidade
O projeto do interpretador é genérico o bastante para que ele possa delegar a
interação com o repositório de objetos não só a um ORM (caso os objetos estejam
armazenados em um banco de dados relacional), mas também a qualquer outro mecanismo
de acesso a objetos, independentemente de qual é o repositório subjacente. É possível,
por exemplo, usar o interpretador para pré-carregar concorrentemente objetos que estão
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 21/162
Capítulo 1. Introdução 20
armazenados em um outro sistema. Basta que o último adote algum mecanismo de
computação distribuída tal como RMI (WALDO, 1998), SOAP (RYMAN, 2001), REST
(FIELDING; TAYLOR, 2002), etc. É por conta desta generalidade que a presente pesquisa
é intitulada “Otimizando Sistemas Intensivos em Entrada/Saída Através de ProgramaçãoConcorrente”.
1.5 Avaliação
A estratégia da Seção 1.4 foi avaliada com os benchmarks sintéticos (CURNOW;
WICHMANN, 1976) Emeio, desenvolvido no contexto desta pesquisa, e OO7 (CAREY;
DEWITT; NAUGHTON, 1993; CAREY et al., 1994). No primeiro, pré-carregar objetos
executando consultas concorrentemente aumentou a velocidade de execução em até 323,6%.No segundo, o aumento foi de até 245,7%.
Os benchmarks também foram implementados com os ORMs Hibernate (O’NEIL,
2008) e EcliseLink JPA (KEITH; SCHINCARIOL, 2009), os quais aderem à especificação
JPA (Java Persistence Architecture) (GROUP, 2013). O primeiro foi escolhido por ser
bastante popular. O segundo foi escolhido por ser a implementação de referência desta
especificação (FOUNDATION, 2008). As implementações baseadas no Hibernate e Eclip-
seLink JPA foram significativamente otimizadas. Entretanto, em todos os cenários de
Emeio e OO7 que oferecem oportunidades para pré-carregar objetos executando consul-tas concorrentemente, o desempenho delas foi inferior ao da implementação baseada no
interpretador de Litoral.
1.6 Organização
O restante desta dissertação está organizado nos seguintes capítulos:
• o Capítulo 2 discute conceitos básicos para o entendimento desta pesquisa e, a partirdeles, justifica a hipótese da Seção 1.3;
• o Capítulo 3 apresenta a sintaxe de Litoral em notação EBNF (Extended Backus-
Naur Form) e sua semântica através de exemplos e de um interpretador definidor
(definitional interpreter) (REYNOLDS, 1972) desenvolvido com o assistente de provas
(GEUVERS, 2009) Coq (BERTOT; CASTÉRAN, 2004);
• o Capítulo 4 apresenta o projeto e a implementação do interpretador de Lito-
ral, o qual foi construído sobre o framework Afluentes (ARAUJO et al., 2014),
desenvolvido no contexto desta pesquisa e também apresentado neste capítulo;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 22/162
Capítulo 1. Introdução 21
• o Capítulo 5 apresenta os bechmarks Emeio e OO7 e as implementações destes
benchmarks baseadas no Hibernate, EclipseLink JPA e no interpretador de Litoral,
comparando o desempenho destas implementações;
• o Capítulo 6 discute trabalhos relacionados a esta pesquisa;
• o Capítulo 7 conclui esta dissertação elencando suas contribuições e possíveis traba-
lhos futuros.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 23/162
22
2 Conceitos Básicos
Este capítulo discute conceitos básicos para o entendimento da presente pesquisa e,
a partir deles, justifica a hipótese da Seção 1.3.
2.1 Sistemas Intensivos em Processamento e em E/S
O tempo total tt que um sistema computacional leva para executar uma tarefa é
formado por duas parcelas:
1. o tempo te/s que o processador está ocioso, esperando que operações de E/S transfiram
dados para a memória primária e secundária, respectivamente. No caso de sistemas
baseados em ORMs, esta parcela incorpora o tempo de carregamento de objetos tc,
discutido na seção 1.2;
2. o tempo t p que o processador está ocupado, processando os dados transferidos para
a memória primária.
A caracterização de te/s apresentada acima é a usualmente encontrada em livros desistemas operacionais (TANENBAUM, 2008). Provavelmente ela é reminiscente de um
tempo em que operações de E/S eram realizadas apenas para transferir dados entre a
memória primária e meios de armazenamento de massa tais como fitas e discos magnéticos.
Atualmente, operações de E/S são realizadas também para outros propósitos, tais como
comunicação entre processos e em redes de computadores. Portanto, parece mais adequado
chamar esta parcela de tempo de comunicação, seja esta comunicação com uma controladora
de fita, de disco, com outro processo ou com outro computador. Esta pesquisa atribui a
te/s esta última caracterização, mais ampla.
Em muitos sistemas, uma destas parcelas domina tt. Os sistemas nos quais te/s é
dominante, como os que processam dados comerciais, são chamados de intensivos em E/S.
Já os sistemas nos quais t p é dominante, como os que realizam cálculos científicos, são
chamados de intensivos em processamento.
Dada a natureza dos sistemas intensivos em processamento, só é possível aumentar
significativamente o seu desempenho reduzindo t p. Nestes sistemas, reduções em te/s têm
baixo impacto sobre tt. Por exemplo, suponha que em um sistema te/s e t p respondam por
20% e 80% de tt, respectivamente. Neste caso, uma redução de 50% em te/s reduzirá tt emapenas 10%. Já uma redução de também 50% em t p reduzirá tt em 40%.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 24/162
Capítulo 2. Conceitos Básicos 23
Nos sistemas intensivos em E/S, os papéis se invertem. Reduções em t p têm baixo
impacto sobre tt. Portanto, nestes sistemas, reduzir te/s é a melhor estratégia quando se
deseja reduzir tt.
2.2 Otimização de Sistemas Intensivos em E/S
Esta seção discute estratégias para aumentar o desempenho de sistemas intensivos
em E/S.
2.2.1 Caching
Caching consiste em armazenar na memória primária o resultado das operações
de entrada que um sistema executa repetidas vezes. Desta forma, quando um sistema
precisa, pela primeira vez, de um dado que não está na memória primária, uma operação
de entrada é executada. Quando o sistema precisar novamente do mesmo dado, ele já se
encontrará na memória primária, não sendo necessário efetuar uma operação de entrada
novamente.
2.2.2 Agregação
Operações de E/S exibem uma latência significativa. Ou seja, o intervalo de tempotranscorrido entre o início e o fim de uma operação de E/S não é desprezível, mesmo
quando o volume de dados transferidos é o menor possível (um bloco de um disco, por
exemplo). Agregando diversas operações de E/S em uma única operação que produz os
mesmos efeitos das operações agregadas, a latência das operações de E/S incide sobre um
sistema uma única vez ao invés de diversas vezes.
2.2.3 Carregamento sob Demanda e Pré-carregamento
Dados podem ser carregados sob demanda ou pré-carregados. No primeiro caso,eles são carregados imediatamente antes do instante t em que um sistema os manipula.
No segundo caso, eles são carregados com alguma antecedência a t.
O pré-carregamento propriamente dito não é uma otimização. Entretanto, por ser
necessário à agregação de operações de entrada, ele é muitas vezes confundido com a
última, esta sim uma otimização. Tal confusão é lamentável, pois, apesar de necessário, o
pré-carregamento não é suficiente para a agregação, já que é possível pré-carregar dados
executando operações de entrada que não foram agregadas.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 25/162
Capítulo 2. Conceitos Básicos 24
2.2.3.1 Pré-carregamento Informado e Especulativo
O pré-carregamento pode ser informado ou especulativo. No primeiro caso, é
necessário que programadores informem quais dados devem ser pré-carregados. O segundo
caso elimina esta necessidade empregando métodos que especulam quais dados sistemasmanipulam. Os métodos se baseiam em informações coletadas estática ou dinamicamente.
De maneira geral, quanto mais próximas do sistema forem as informações coletadas, mais
corretas são as especulações dos métodos.
Como os métodos de especulação são falíveis, o pré-carregamento baseado neles
pode carregar menos ou mais dados do que o necessário, reduzindo o desempenho de
sistemas. Um método que costuma falhar por excesso, por exemplo, consiste em supor que
sistemas sempre manipulam todos os dados associados a um dado inicial. Graças a métodos
imprecisos como este, o carregamento sob demanda é visto como uma otimização, pois elenunca carrega mais dados do que o necessário. É importante ressaltar, entretanto, que o
carregamento sob demanda nunca é mais rápido do que o pré-carregamento executado a
partir de informações ou especulações corretas e costuma ser significativamente mais lento
do que este pré-carregamento combinado com a agregação de operações de entrada.
2.2.4 Compressão
O tempo de execução de operações de E/S é uma função monotônica não-decrescentedo volume de dados transferidos. Portanto, comprimindo dados antes de transferi-los, reduz-
se potencialmente o tempo de execução de operações de E/S. É necessário descomprimir
os dados após transferi-los, o que aumenta t p. Este aumento, entretanto, não costuma ser
significativo frente à redução no tempo de execução das operações de E/S, fazendo com
que o saldo final desta estratégia seja positivo.
2.2.5 Concorrência
Caching, agregação e compressão reduzem te/s otimizando as operações de E/S queum sistema executa. Uma estratégia ortogonal às anteriores para reduzir te/s consiste em
executar estas operações concorrentemente, sem atuar sobre seu desempenho. Por exemplo,
suponha que um sistema executa duas operações independentes cujos tempos de execução
são t1 e t2, respectivamente. Se o sistema executa estas operações sequencialmente, então te/sserá a soma de t1 e t2. Entretanto, se o sistema executa estas operações concorrentemente,
então te/s vai variar do máximo entre t1 e t2 (melhor caso) à soma de t1 e t2 (pior caso). O
melhor caso ocorrerá se existirem os recursos necessários à execução paralela das operações.
No outro extremo, se só existirem recursos suficientes para executar uma operação de cadavez, ocorrerá o pior caso.
O exemplo anterior, apesar de bastante simples, ilustra as condições que um sistema
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 26/162
Capítulo 2. Conceitos Básicos 25
deve satisfazer para que a execução concorrente de operações de E/S seja uma otimização
eficaz:
1. o sistema executa um número significativo de operações independentes;
2. os tempos de execução das operações são similares;
3. existem recursos computacionais suficientes para executar as operações em paralelo.
Se a primeira condição é falsa, então existem poucas oportunidades para executar
operações de E/S em paralelo. Se a segunda condição não é verdadeira, então a diferença
entre o tempo que o processador espera pela execução sequencial e paralela das operações
não é significativo. Por fim, se a terceira condição não é satisfeita, então as operações sãoexecutadas sequencialmente mesmo quando o sistema as requisita concorrentemente.
2.3 Carregamento sob Demanda, Pré-carregamento e Agregação
em ORMs
Sistemas requisitam objetos a ORMs especificando seus identificadores, ou seja,
valores que os identificam unicamente, ou predicados que eles devem satisfazer. O trecho
de código Java da Figura 4 exemplifica o segundo tipo de requisição. A linha 1 contémuma consulta JPQL (Java Persistence Query Language) (GROUP, 2013) que especifica as
mensagens enviadas pelo usuário cujo identificador é igual a 1. As linhas 2–3 requisitam
estas mensagens a ORMs compatíveis com a especificação JPA. As seções A.1 e A.2 contêm
o código das classes que este trecho de código manipula e as tabelas que armazenam seus
objetos, respectivamente.
2.3.1 Tipos de Atributo
Objetos possuem dois tipos de atributo. O tipo I armazena informações acerca do
objeto propriamente dito. O nome de um usuário e a data de envio de uma mensagem
são exemplos deste tipo. O tipo II representa associações entre objetos. Exemplos deste
último tipo são o remetente, os destinatários e os anexos de uma mensagem.
Na maioria dos casos, sistemas requisitam objetos sem especificar quais atributos
devem ser carregados. Se ORMs carregam atributos sob demanda, então eles executam
uma consulta SQL para carregar cada atributo de cada objeto que os sistemas manipulam.
A Figura 5, por exemplo, exibe as consultas SQL que ORMs executam para carregar sob
demanda os atributos de mensagens manipulados pelo trecho de código da Figura 4.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 27/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 28/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 29/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 30/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 31/162
Capítulo 2. Conceitos Básicos 30
1 S tr i n g j p q l = " s e l e c t m f r om Mes sa ge m whe re m . s e n d e r . i d = 1 " ;
2 TypedQuery<Message> query = jpa . crea teQ uer y ( jp ql , Message . c l a s s ) ;
3
4 EntityGraph<Message> spe c = manager . crea teE nti tyG rap h ( Message . c l a s s ) ;
5 spec . addSubgraph( " re ci pi en t s " ) ;6 sp ec . addSub graph ( " f i l e s " ) ;
7 query . set Hin t ( " javax . pe rs is te nc e . loadgrap h " , spec ) ;
8
9 List <Message> messages = query . get Res ul tL ist ( ) ;
10
11 f o r ( Mes sa ge m e ss a ge : m e s sa g e s ) { / ∗ . . . ∗/ }
Figura 10 – Trecho de código Java que informa a ORMs compatíveis com a especificaçãoJPA quais objetos eles devem pré-carregar.
A Figura 10 exemplifica o primeiro. Ela adiciona ao trecho de código da Figura 4 as linhas
4–7. Elas requisitam a ORMs compatíveis com a especificação JPA o pré-carregamento
dos destinatários e anexos das mensagens resultantes da consulta JPQL da linha 1.
2.3.6 Pré-carregamento Especulativo
O laço da Figura 4 é bastante regular. Ele sempre navega de cada mensagem para seu
remetente, destinatários e anexos. Regularidades como esta motivaram (BERNSTEIN; PAL;SHUTT, 2000) a propor um método de especulação que consiste em ORMs armazenarem
o contexto em que eles carregaram ou pré-carregaram objetos.
O contexto de um objeto A é o conjunto de objetos que foi carregado ou pré-
carregado pela operação (consulta, navegação, etc.) que carregou ou pré-carregou A.
Quando um sistema navega de A para outro objeto B através de um atributo b, ORMs
pré-carregam todos os objetos referenciados pelos objetos do contexto de A através do
atributo b.
Aplicando este método no trecho de código da Figura 4, ORMs pré-carregam osdestinatários e os anexos de todas as mensagens quando as linhas 12 e 17 são executadas,
respectivamente, pela primeira vez.
2.4 Hipótese
A partir das discussões e exemplos das seções anteriores, esta seção justifica a
hipótese de que o tempo que ORMs levam para pré-carregar objetos executando consultas
concorrentemente é menor do que sequencialmente.Sistemas baseados em ORMs adotam o estilo de programação exibido na Figura 4
(IBRAHIM; WIEDERMANN; COOK, 2009). Neste estilo, é comum que sistemas, exceto os
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 32/162
Capítulo 2. Conceitos Básicos 31
mais simples, naveguem através de dois ou mais atributos do tipo II. Nestes casos, tal como
exemplificado na Subseção 2.3.5, as consultas que pré-carregam os objetos referenciados
pelos atributos são independentes.
As consultas que ORMs executam para pré-carregar objetos referenciados poratributos do tipo II são bastante simples. Como elas são compostas apenas por restrições
sobre chaves primárias e estrangeiras, seus tempos de execução costumam ser dominados
pelas latências dos canais de comunicação entre ORMs e bancos de dados (BERNSTEIN;
PAL; SHUTT, 2000). Isto faz com que estes tempos sejam similares.
Sistemas de gerenciamento de banco de dados são executados com frequência em
instalações que possuem os recursos necessários para a execução paralela de diversas
consultas. O surgimento e a popularização da computação em nuvem (ARMBRUST et al.,
2010) têm contribuído para que isto ocorra cada vez mais.
Como ORMs executam consultas através de operações de E/S, as últimas gozam
das propriedades das primeiras. Por exemplo, se duas consultas são independentes, então
as operações de E/S através das quais elas são executadas também são independentes.
Conclui-se, portanto, que, em muitos casos, ORMs pré-carregam objetos executando
operações de E/S independentes, cujos tempos de execução são similares e existem recursos
computacionais suficientes para executar estas operações em paralelo. Ou seja, o pré-
carregamento de objetos executado por ORMs satisfaz as condições discutidas na seção
2.2.5 para que a execução concorrente de operações de E/S seja uma otimização eficaz.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 33/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 34/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 35/162
Capítulo 3. Litoral 34
(a)
(b)
Figura 13 – Gramática de Litoral em notação EBNF e em diagramas de sintaxe.
uma única alternativa, manter as duas versões de getMessages no sistema, utilizandocada uma delas quando for mais apropriado.
É fácil ver que existe uma forte tensão entre desempenho e reuso de código
(IBRAHIM; COOK, 2006). O problema aqui é que a especificação de quais objetos devem
ser carregados faz parte da API (Application Programming Interface) de um ORM e,
portanto, está confinada às camadas de acesso a dados de sistemas, onde seu uso pode
ter efeitos globais devido ao reuso de código. Especificações Litoral, por outro lado,
podem ser incorporadas aos pontos mais externos de sistemas (por exemplo, nas camadas
de apresentação), tendo, portanto, efeitos mais localizados.
3.2 Sintaxe
A figura 13 apresenta a gramática de Litoral em notação EBNF (Extended
Backus–Naur Form) e também através de diagramas de sintaxe. Os símbolos s p e c i f i c a t i o n ,
t r a v e r s a l , path e s te p são não-terminais. ID e os símbolos entre aspas simples são
terminais. s p e c i f i c a t i o n é o símbolo inicial. A expressão regular [ a−zA−Z ] [ a−zA−Z0−9]∗
gera ID, ou seja, um ID é formado por uma letra seguida de outras letras ou números.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 36/162
Capítulo 3. Litoral 35
1 void pr in tMessage ( Message message) {
2 pr in tl n ( message . getDate ( ) ) ;
3 p r i n t l n ( m es s ag e . g e tS u b j e c t ( ) ) ;
4 pr in tl n ( message . getBody ( ) ) ;
5
6 pr int User ( message . getSender ( ) ) ;
7
8 f o r ( U ser r e c i p i e n t : m es sa ge . g e t R e c i pi e n t s ( ) ) {
9 p r i n tU s e r ( r e c i p i e n t ) ;
10 }
11
12 f o r ( Fi le attachment : message . getAttachments () ) {
13 pr in tl n ( attachment . getName ( ) ) ;
14
15 printMediaType( attachment . getMediaType ( ) ) ;16 }
17
18 f o r ( M e ss ag e r e p l y : m es sa ge . g e t R e p l i e s ( ) ) {
19 pr intMessage ( repl y ) ;
20 }
21 }
22
23 void p r i n tU s e r ( U se r u s e r ) {
24 pr in tl n ( use r . getName ( ) ) ;
25
26 p r i n t F i l e ( u s e r . g e t P i c t u r e ( ) ) ;
27 }
28
29 void p r i n t F i l e ( F i l e f i l e ) {
30 pr in tl n ( f i l e . getName ( ) ) ;
31
32 printMediaTyp e ( f i l e . getMediaType ( ) ) ;
33 }
34
35 void printMediaType (MediaType mediaType) {36 pr in tl n (mediaType . getType ( ) ) ;
37 pr in tl n (mediaType . getSubtype ( ) ) ;
38 }
Figura 14 – Trecho de código Java que navega por objetos.
3.3 Semântica Informal
Esta seção se inspira em (MEYEROVICH et al., 2009) e apresenta a semântica deLitoral informalmente através de vários exemplos que, progressivamente, especificam as
navegações que o trecho de código Java exibido na Figura 14 executa.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 37/162
Capítulo 3. Litoral 36
1 s e n d e r
Figura 15 – Especificação Litoral que navega através de um único atributo.
1 s p e c i f i c a t i o n // s ím bo lo i n i c i a l 2 t r a v e r s a l ∗ path // s u b s t it u i ç ã o de s p e c i f i c a t i o n
3 path // t r a v e r s a l é o p ci o na l
4 s t e p | [ s t ep + ] // s u b s t i t u i ç ã o de p at h
5 s te p // e s c o l h a do p r i me i r o ramo
6 ID | ID . p at h | ID ( ) // s u b s t i t u i ç ão de s t e p
7 ID // e s c o l h a do p r i me i r o ramo
8 s e n d e r // ID g e ra s e n de r
Figura 16 – Geração da especificação da Figura 15 a partir da gramática de Litoral.
1 r e c i p i e n t s
Figura 17 – Especificação Litoral que navega através de coleções de objetos.
3.3.1 Navegando Através de um Único Atributo
O método pr intMessage da Figura 14 recebe uma mensagem como parâmetro e,
na linha 6, navega para seu remetente através do atributo s e n d e r . A Figura 15 exibe
a especificação Litoral que declara esta navegação. Ela não faz nenhuma referênciaà mensagem, pois o objeto que dá início a navegações fica implícito nas especificações
Litoral. Por um lado, esta característica dificulta a compreensão de especificações
Litoral quando lidas independentemente do código onde elas serão embutidas. Por outro
lado, entretanto, ela torna as especificações Litoral mais concisas.
A Figura 16 mostra como gerar esta especificação a partir da gramática de Litoral.
Para Litoral é irrelevante se atributos referenciam objetos ou coleções de objetos.
A sintaxe que especifica navegações através de atributos é a mesma em ambos os casos.
A especificação Litoral da Figura 17, por exemplo, declara uma navegação atravésdo atributo r e c i p i e n t s , que referencia uma coleção de objetos. Ela possui a mesma
estrutura sintática que a especificação da Figura 15, a qual declara uma navegação através
do atributo sender , que referencia um único objeto.
3.3.2 Navegando Através de mais de um Atributo
Nas linha 8 e 12, o método pr intMessage da Figura 14 também navega para
destinatários e anexos de mensagens através dos atributos r e c i p i e n t s
e attachments
,respectivamente. A Figura 18 exibe a especificação Litoral que declara navegações de
mensagens para seus remetentes, destinatários e anexos. Os caracteres [ (abre colchetes) e
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 38/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 39/162
Capítulo 3. Litoral 38
1 [
2 s e n d e r
3 r e c i p i e n t s
4 at tac hme nts . mediaType
5 ]
Figura 21 – Especificação Litoral que navega indiretamente.
1 [
2 sen der . pi ct ur e . mediaType
3 r e c i p i e n t s
4 at tac hme nts . mediaType
5 ]
Figura 22 – Especificação Litoral que encadeia navegações indiretas.
bastante para especificar navegações indiretas, ou seja, navegações de um objeto inicial
para um objeto intermediário e, deste último, para um objeto final, e assim por diante. Por
exemplo, na linha 15 da Figura 14, o método pr intMessage navega de um anexo de uma
mensagem para o seu tipo. Neste exemplo, a mensagem, o anexo e o tipo atuam como o
objeto inicial, intermediário e final, respectivamente. A linha 4 da especificaçãoLitoral
exibida na Figura 21 incorpora esta navegação indireta através do operador . (ponto).
Em navegações indiretas, é comum que um objeto intermediário funcione como oobjeto inicial de uma nova navegação indireta. Navegações deste tipo são especificadas
em Litoral encadeando aplicações do operador . (ponto). O método pr intMessage
da Figura 14, por exemplo, navega de uma mensagem para seu remetente através do
atributo sender , deste remetente para sua fotografia através do atributo p i c t u r e e desta
fotografia para o tipo do arquivo que a armazena através do atributo mediaType. A linha
2 da especificação Litoral exibida na Figura 22 incorpora esta navegação encadeando o
operador . (ponto).
Em navegações indiretas, é possível que o atributo que leva ao objeto intermediário
não referencie nenhum objeto ou referencie uma coleção vazia. Isto aconteceria, por exemplo,
se as navegações que a especificação da Figura 22 declara fossem realizadas a partir de
uma mensagem sem remetente ou sem anexos. No primeiro caso, não seria possível navegar
para a foto do remetente. No segundo caso, não seria possível navegar para o tipo dos
arquivos anexados à mensagem. Na maioria das linguagens de programação, navegações
indiretas através de atributos que não referenciam nenhum objeto provocam um erro em
tempo de execução. Estes erros não acontecem em Litoral pois as navegações indiretas
declaradas por uma especificação Litoral só serão realizadas quando possível, ou seja,quando existir o objeto intermediário e, caso ele seja uma coleção de objetos, apenas se
não for uma coleção vazia.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 40/162
Capítulo 3. Litoral 39
1 [
2 sen der . pi ct ur e . mediaType
3 re c i pi en ts . p ic tu re . mediaType
4 at tac hme nts . mediaType
5 ]
Figura 23 – Especificação Litoral que replica uma navegação.
1 v i s i tU s e r = p i c t u r e . m ed iaTyp e
2 [
3 s e n d e r . v i s i t U s e r ( )
4 r e c i p i e n t s . v i s i t U s e r ( )
5 at tac hme nts . mediaType
6 ]
Figura 24 – Especificação Litoral que define uma travessia.
3.3.4 Travessias
O método pr intMessage da Figura 14 navega não só de uma mensagem até o
tipo da fotografia do seu remetente, mas também até o tipo da fotografia de cada um dos
destinatários desta mensagem. A linha 3 da especificação Litoral exibida na Figura 23
incorpora esta última navegação.
Apesar de correta, a especificação da Figura 23 possui uma replicação indesejável,
pois mudanças no método p r i n tU s e r da Figura 14 precisarão ser refletidas nela duas
vezes. Litoral permite que replicações deste tipo sejam eliminadas com travessias, que
nada mais são do que caminhos nomeados. Uma vez definida, pode-se usar o nome de uma
travessia para percorrer o seu caminho, iniciando a partir de diferentes objetos, quantas
vezes for necessário. A linha 1 da Figura 24, por exemplo, define uma travessia chamada
v i s i t U s e r cujo caminho é pi ct ur e . mediaType. As linhas 4 e 5 iniciam esta travessia a
partir do remetente e dos destinatários de uma mensagem, respectivamente.
A Figura 25 mostra como gerar esta especificação a partir da gramática de Litoral.
3.3.5 Travessias Recursivas
Travessias podem iniciar outras travessias e, em particular, a si mesmas. Isto nos
permite escrever a versão final da especificação Litoral que declara os objetos pelos
quais o método pr intMessage da Figura 14 navega. Esta última versão, exibida na Figura
26, define nas linhas 1 e 3 as travessias v i s i t U s e r e v i s i t M e s s a g e , respectivamente. A
travessia v i s i t M e s s a g e , além de iniciar a travessia v i s i t U s e r nas linhas 4 e 5, inicia asi mesma na linha 8.
A linha 8 da especificação da Figura 26 sugere uma recursão infinita. Entretanto,
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 41/162
Capítulo 3. Litoral 40
1 s p e c i f i c a t i o n // s ím bo lo i n i c i a l
2 t r a v e r s a l ∗ path // s u b s t i t u i ç ã o de program
3 t r a v e r s a l p at h // s u b s t it u i ç ã o de t r a v e rs a l ∗
4 ID=path path // s u b s t it u i ç ã o de t r a v e rs a l
5
6 ID=path // e s p aç o s em b ra nc o s ão i g n o r ad o s
7 path
8
9 v i s i tU s e r = p a th // ID g er a v i s i t U s e r 10 path
11
12 v i s i tU se r=pic tur e . mediaType / / p a th gera p ic tu r e . med ia Type
13 [ // p at h g er a [
14 send er . ste p // sen d er . s t e p
15 r e c i p i e n t s . s t e p // r e c i p i e n t s . s t e p
16 ] // ]
17
18 v i s i tU se r=pic tur e . mediaType
19
[20 s e n d er . ( ID | ID . p at h | ID ( ) ) // s u b s t it u i ç ã o de s t ep
21 r e c i p i e n t s . ( ID | ID . pa th | ID ( ) ) // s u b s t it u i ç ã o de s t ep
22 ]
23
24 v i s i tU se r=pic tur e . mediaType
25 [
26 sender . ID( ) // e s c o l ha do t e r c e i r o ramo
27 r e c i p i e n t s . ID ( ) // e s c o l ha do t e r c e i r o ramo
28 ]
29
30 v i s i tU se r=pic tur e . mediaType
31 [
32 s e n d e r . v i s i t U s e r ( ) // ID g er a v i s i t U s e r
33 r e c i p i e n t s . v i s i t U s e r ( ) // ID g er a v i s i t U s e r
34 ]
Figura 25 – Geração da especificação da Figura 24 a partir da gramática de Litoral.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 42/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 43/162
Capítulo 3. Litoral 42
1 Inductive CLASS : = C l a s s : s t r i n g −> l i s t ( s t r i n g ∗ s t r i n g ) −> CLASS.
2
3 Inductive OBJ := Obj : s t r i n g −> l i s t ( s t r i n g ∗ l i s t s t r i n g ) −> OBJ.
Figura 27 – Representação de classes e objetos no interpretador definidor.
apenas o primeiro. Outra diferença importante é que apenas funções totais1 são definíveis
em Gallina. Standard ML, por outro lado, suporta tanto funções totais quanto parciais.
3.4.1 Representação de Classes e Objetos
Litoral foi concebida para ser embarcada em linguagens orientadas a objetos que
suportam reflexão. Infelizmente, classes, objetos e reflexão não estão presentes em Gallina.Portanto, o primeiro passo para implementar o interpretador consiste em representar estes
conceitos a partir daqueles suportados por Gallina.
Do ponto de vista de Litoral, objetos são apenas entidades que associam nomes
a valores. Conceitos como herança e polimorfismo, por exemplo, não são relevantes.
Adicionalmente, não importa para Litoral se um atributo referencia um único objeto ou
uma coleção de objetos. Por fim, a distinção entre objetos e valores de tipos primitivos
presentes em algumas linguagens orientadas a objetos como Java também não é relevante.
Estas observações, acrescidas da necessidade de reflexão, motivam a representação declasses e objetos com os tipos exibidos na Figura 27.
Um valor do tipo CLASS representa uma classe e é construído a partir do nome
( s t r i n g ) e dos atributos ( l i s t ) desta classe. Cada atributo é representado por um par
( s t r i n g ∗ s t r i n g ) onde o primeiro e o segundo elemento são, respectivamente, o nome
do atributo ( s t r i n g ) e o nome de sua classe ( s t r i n g ) .
Por sua vez, um valor do tipo OBJ representa um objeto e é construído a partir
do identificador ( s t r i n g ) e dos atributos ( l i s t ) deste objeto. Cada atributo é repre-
sentado por um par ( s t r i n g ∗ l i s t s t r i n g ) onde o primeiro e o segundo elemento são,respectivamente, o nome ( s t r i n g ) e o valor do atributo ( l i s t s t r i ng ) .
O valor de um atributo é representado por uma lista de identificadores de objetos.
Esta representação simplifica a implementação do interpretador, pois permite que ele lide
uniformemente com atributos que referenciam um único objeto ou coleções de objetos.
Valores do tipo CLASS referenciam-se indiretamente através de seus nomes. De
maneira similar, valores do tipo OBJ referenciam-se indiretamente através de seus identifi-
cadores. Por um lado, estas indireções dificultam a implementação do interpretador. Por
outro lado, elas tornam possível a definição e a instanciação de classes e objetos que se1 Uma função f é chamada de total quando para todo elemento x de seu domínio existe um elemento y
de seu contradomínio tal que f (x) = y, caso contrário, f é chamada de parcial.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 44/162
Capítulo 3. Litoral 43
1 Definition c l a s s e s : = [
2 Class "MediaType" [ ] ;
3 Class " Fi le " [ ( " mediaType " , "MediaType " ) ]
4 Cl a s s " U se r " [ ( " p i c t u r e " , " F i l e " ) ] ;
5 C l a s s " M e ss ag e " [ ( " s e n de r " , " U s er " ) ; ( " r e c i p i e n t s " , " U s er " ) ;6 (" re p l i es " , " Message " ) ] ;
7 ] .
Figura 28 – Criação de classes no interpretador definidor.
1 Definition I D : = s t r i n g .
2
3 Inductive STEP :=
4 L a st S t ep : ID −> STEP | S tep : ID −> PATH −> STEP | I n i t : ID −> STEP
5
6 with PATH := Path : nat −> l i s t STEP −> PATH.
7
8 Inductive TRAV := Trav : ID −> PATH −> TRAV.
9
10 Inductive SPEC := Spec : l i s t TRAV −> PATH −> SPEC.
Figura 29 – Representação de especificações Litoral no interpretador definidor.
auto-referenciam direta ou indiretamente. O código Gallina da Figura 28, por exemplo,cria as classes MediaType, F i l e , User e Message. Esta última se auto-referencia no
atributo r e p l i e s .
3.4.2 Representação de Especificações Litoral
Especificações Litoral são representadas através de tipos que mimetizam a
gramática da linguagem, tal como exibido na Figura 29. O trecho de código Gallina exibido
na Figura 30, por exemplo, mostra como instanciar a especificação Litoral da Figura 26
a partir destes tipos.
Um valor do tipo PATH é criado, tal como especificado pela gramática de Litoral,
a partir de uma lista de passos ( l i s t STEP) e também de um número natural ( n a t )
cuja função será descrita na seção 3.4.3. Por hora, é suficiente saber que valores do tipo
PATH podem ser criados a partir do número 0, tal como exemplificado na Figura 30.
3.4.3 Análise Semântica
Uma especificação Litoral
é semanticamente válida quando ela:
1. não define travessias com nomes repetidos;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 45/162
Capítulo 3. Litoral 44
1 Definition s p ec := S pec [
2 Trav " v i s i t U s e r " ( P at h 0 [
3 S tep " p i c t u r e " (Path 0 [ L a s tS te p " m ed ia Ty pe " ] )
4 ] ) ;
5 Trav " v i s i t M e s s a g e " ( P at h 0 [6 S tep " s e n d e r " (Path 0 [ In i t " v i s i t U s e r " ] ) ;
7 S te p " r e c i p i e n t s " ( P at h 0 [ I n i t " v i s i t U s e r " ] ) ;
8 Step " attachments " (Path 0 [ LastSt ep "mediaType " ] ) ;
9 S te p " r e p l i e s " ( P ath 0 [ I n i t " v i s i t M es s a g e " ] )
10 ] )
11 ] ( P ath 0 [ I n i t " v i s i t M e s s a g e " ] ) .
Figura 30 – Criação de uma especificação Litoral no interpretador definidor.
2. não inicia travessias inexistentes;
3. não referencia atributos inexistentes.
A função analyzeSpec da Figura 31d verifica se especificações Litoral satisfazem
estas condições dividindo o trabalho entre as funções aninhadas indexSpec da Figura
31a, analyzeTravs da Figura 31d, analyzePath da Figura 31c e a n a l y z e Cl a s s Pa th s
da Figura 31d.
A função indexSpec recebe uma especificação Litoral como argumento e retornauma tripla cujo primeiro elemento é uma nova especificação spec2 quase idêntica à
primeira. A única diferença entre elas é que os índices (os números naturais) dos caminhos
contidos em s p e c 2 são únicos. Portanto, é possível decidir se dois caminhos contidos em
s p e c 2 são iguais comparando seus índices. O terceiro elemento da tripla retornada por
indexSpec é uma lista formada pelos caminhos contidos em spec2 . O segundo elemento,
por sua vez, é o tamanho desta lista.
A função analyzeTravs verifica a primeira condição. Por ser trivial, esta subseção
não discute sua implementação.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 46/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 47/162
Capítulo 3. Litoral 46
1 Definition s t r E q x y : = i f s t r i n g _ d e c x y then t r u e e l s e f a l s e .
2
3 Definition g e tPath tr a v s nm :=
4 l e t
5 f t ra v := l e t ’Trav nm’ _ := trav in str Eq nm’ nm6 in
7 match f i n d f t r a v s with
8 | None => None
9 | Some (Trav _ path) => Some path
10 end .
11
12 Definition emptyPath := Path 0 [ ] .
13
14 Definition g e t C l a s s c l a s s e s nm :=
15 f i n d ( f un c l a s s => l e t ’ C l a s s nm ’ _ := c l a s s in s t r Eq nm ’ nm) c l a s s e s .16
17 Definition g e t C l a s s A t t r c l a s s nm :=
18 l e t
19 f ( a tt r : s t r i n g ∗ s t r i n g ) := l e t (nm ’ , _) : = a tt r in str Eq nm’ nm
20 in
21 l e t ’ C la ss _ a t t r s := c l a s s in f i n d f a t t r s .
22
23 Definition g e tA t t r Cl a s s c l a s s e s c l a s s nm :=
24 match g e t C la s s At t r c l a s s nm with
25 | None => None26 | Some (_, nm ’ ) => g e tCl a s s c l a s s e s nm ’
27 end .
28
29 Definition a na ly ze St ep c l a s s e s t r av s c l a s s s t ep :=
30 l e t g e tA ttr Cl a s s H e l p e r n m p a th : =
31 match g et A tt r Cl a ss c l a s s e s c l a s s nm with
32 | None => None
33 | Some c l a s s => Some ( c l a s s , p ath )
34 end
35 in
36 match s te p with
37 | LastStep nm => getA ttrC lass Helpe r nm emptyPath
38 | Step nm path => getAt trCl assHe lper nm path
39 | In i t nm =>
40 match g etPa th tr a v s nm with
41 | None => None
42 | Some path => Some ( c l as s , path)
43 end
44 end .
(b)
Figura 31 – Analisador semântico - continuação
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 48/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 49/162
Capítulo 3. Litoral 48
1 Fixpoint an a ly z eC l as s Pa t hs c l a s s e s p at hs t r a v s s c l a s s Pa t h s n :=
2 match n with
3 | 0 => (s , Some c l a s s Pa t h s )
4 | S n ’ =>
5 match a n al y ze C la s sP a th s c l a s s e s p at hs t r a v s s c l a s sP a t h s n ’ with
6 | ( s ’ , None) => (s ’ , None)
7 | ( s ’ , Some [ ] ) => (s ’ , Some [ ] )
8 | ( s ’ , Some ( c l a s s P a t h : : c l a s s Pa t h s ’ ) ) =>
9 i f c o n t a in s C l a ss P a t h s ’ c l a s s P a t h then ( s ’ , Some c l a s s Pa th s ’ )
10 e l s e
11 i f
12 c o n t a in s C l a s sP a t h ( l i s t _ p r o d c l a s s e s p at h s ) c l a s s P a t h
13 then
14 l e t s ’ ’ := c l a ss P a t h : : s ’ in
15 l e t ( c l a s s , p at h ) := c l a s s P a t h in
16 match a na ly ze Pa th c l a s s e s t r a v s c l a s s p at h with
17 | None => ( s ’ ’ , None)
18 | Some c lassP aths ’ ’ =>
19 (s ’ ’ , Some ( c lassP aths ’ ++ c lassP aths ’ ’ ) )
20 end
21 e l s e
22 ( s ’ , Some c l a s s Pa th s ’ )
23 end
24 end .
25
26 Definition analyzeTravs ( tra vs : l i s t TRAV) := true .
27
28 Definition a na ly ze Sp ec c l a s s e s c l a s s s pe c n :=
29 l e t ’ ( s p ec 2 , i d x , p a ths ) := i n d ex S p e c s p e c in
30 l e t ’ S pe c t r a v s p at h : = s p e c2 in
31 i f a n al y z e Tr av s t r a v s then
32 a n al y ze C la s sP a th s c l a s s e s p at hs t r a v s [ ] [ ( c l a s s , p a th ) ] n
33 e l s e ( [ ] , None ) .
(d)
Figura 31 – Analisador semântico - continuação.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 50/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 51/162
Capítulo 3. Litoral 50
1 Theorem analyzeSpecLim :
2 f o r a l l c l a ss e s c l a s s spec ,
3 e x i s t s N,
4 f o r a l l n ,
5 l e t ( _, t ) := a n al y ze Sp e c c l a s s e s c l a s s s p ec (N + n ) in
6 t = None \/ t = Some [ ] .
Figura 32 – Teorema que assegura que o analisador semântico do interpretador definidorsempre é capaz de validar especificações Litoral em um número finito derecursões.
um um número finito de recursões N suficiente para que a função analyzeSpec conclua
se a especificação spec é ou não semânticamente válida. O teorema também afirma que a
conclusão da função a n a l yz e S p e c é definitiva, pois permitir que a função a n a l yz e S p e c
invoque a si mesma recursivamente um número de vezes maior do que N (ou seja, um
número da forma N + n, onde n é um número natural qualquer), não modifica a conclusão
da função analyzeSpec . A Seção C.8 contém a demonstração deste teorema verificada
por Coq. Ela se baseia no fato de que sequências monótonas e limitadas são convergentes
(THOMSON; BRUCKNER; BRUCKNER, 2008).
3.4.4 Interpretação
A função i n t e r p r e t S p e c exibida na Figura 33c recebe os argumentos S, f i l t e r ,
s , spec , a l l O b j s , o b j s e n e retorna uma tripla na qual o primeiro elemento é uma lista
de objetos. Esta seção discutirá S, f i l t e r e s em breve. Os argumentos spec , o b j s ,
a l l O b j s e n, são, respectivamente, uma especificaçãoLitoral, uma lista formada pelos
objetos a partir dos quais s p e c navega, uma lista contendo todos os objetos pelos quais
s p e c navega e o número de vezes que a função i n te r p r e tO b j s Pa th s invocará a si mesma.
Sejam SVal, f i l t e r V a l e sVal valores apropriados para os argumentos S, f i l t e r
e s , respectivamente. Então i n t e r p r e t S p e c SVal f i l t e r V a l s Va l é uma função que
associa especificações Litoral a funções que recebem e retornam listas de objetos, ou
seja,
interpretSpec SVal filterVal sVal define uma semântica para Litoral
Mais especificamente, i n t er p r et S p ec SVal f i l t e r V a l s Va l é uma função que associa
especificações Litoral a funções que:
• recebem os argumentos a l l O b j s , o b j s e n;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 52/162
Capítulo 3. Litoral 51
1 Definition get Obj a l l i d : =
2 f i n d ( f u n o b j => l e t ’ Obj i d ’ _ := o b j in s tr Eq i d ’ i d ) a l l .
3
4 Fixpoint ge tO bj s a l l i d s : =
5 match i d s with
6 | [ ] => Some [ ]
7 | i d : : i d s ’ =>
8 match g et Ob js a l l i d s ’ with
9 | None => None
10 | Some objs ’ =>
11 match get Ob j a l l i d with
12 | None => None
13 | Some obj => Some ( obj : : objs ’ )
14 end
15 end
16 end .
17
18 Definition g e tO bj A ttr a t tr s nm :=
19 l e t
20 f ( a tt r : s t r i n g ∗ l i s t s t r i n g ) : = l e t (nm ’ , _) := a tt r in strEq nm’ nm
21 in
22 f i nd f a t t r s .
23
24 Definition g e tV al a l l o bj nm :=
25 l e t ’ O b j _ a t t r s : = o b j in
26 match ge tO bj A ttr a t tr s nm with
27 | None => None
28 | Some (_ , v a l ) => g e tO b js a l l v a l
29 end .
30
31 Fixpoint g e tV a ls a l l o b j s nm :=
32 match o b j s with
33 | [ ] => Some [ ]
34 | o b j : : o b js ’ =>
35 match g e tV a ls a l l o bj s ’ nm with
36 | None => None
37 | Some vals ’ =>
38 match ge tV al a l l o b j nm with
39 | None => None
40 | Some val => Some ( val ++ vals ’ )
41 end
42 end
43 end .
(a)
Figura 33 – Interpretador definidor.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 53/162
Capítulo 3. Litoral 52
1 Definition i n t er p re t St e p t ra vs a l l o bj s s te p :=2 l e t
3 g e tV a l s H e l p e r nm p ath : =
4 match ge t Va l s a l l o b j s nm with
5 | None => None
6 | Some vals => Some ( vals , path)
7 end
8 in
9 match s te p with
10 | Last Step nm => get Vals Help er nm emptyPath
11 | Step nm path => getVals Helper nm path12 | In i t nm =>
13 match g etPa th tr a v s nm with
14 | None => None
15 | Some path => Some ( objs , path)
16 end
17 end .
18
19 Fixpoint i n t er p re t St e p s t ra vs a l l o bj s s t ep s : =
20 match s t e p s with
21 | [ ] => Some [ ]22 | s t e p : : s t ep s ’ =>
23 match i n t er p r e t St e p s t r av s a l l o b js s te ps ’ with
24 | None => None
25 | Some objsPath ’ =>
26 match i nt e rp r et S te p t ra vs a l l o bj s s te p with
27 | None => None
28 | Some objsPath => Some ( objsPath : : objsPath ’ )
29 end
30 end
31 end .32
33 Definition i n t er p re t Pa t h t r av s a l l o b js pat h :=
34 l e t ’ P ath _ s t e p s := p at h in i n t e r p re t S t e p s t r av s a l l o b js s t e ps .
35
36 Definition F i l t e r S : = S −> l i s t OBJ −> PATH −> S ∗ l i s t OBJ .
(b)
Figura 33 – Interpretador definidor - continuação.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 54/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 55/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 56/162
Capítulo 3. Litoral 55
1 Definition f i l t e r 1 ( s : l i s t OBJ) ( obj s : l i s t OBJ) ( path : PATH) :=
2 ( s , o b j s ) .
3
4 Definition i n t e r p r e t S p e c 1 : =
5 int erp ret Spe c (S := l i s t OBJ) f i l t e r 1 [ ] .
Figura 35 – Semântica 1.
1 v i s i t M e s s a g e= r e p l i e s . v i s i t M e s s a g e ( )
2 v i s i t Me s s a g e ( )
Figura 36 – Especificação Litoral que entra em recursão infinita na semântica 1.
1 Definition p i c t u r e := Obj " p1 " [ ] .
2
3 Definition u s e r : = Obj " u 1 " [ ( " p i c t u r e " , [ " p 1 " ] ) ] .
4
5 Definition message := Obj "m1" [ ( " sender " , [ " u1 " ] ) ;
6 (" re c i pi en ts " , [ " u1 " ] ) ;
7 (" re pl ie s " , [ " m1 " ] ) ] .
Figura 37 – Mensagem que se auto-referencia.
do passado para tomar esta decisão, ela retorna o mesmo estado recebido como argumento,ou seja, a função f i l t e r 1 permanece sempre em seu estado inicial.
A função i n t e r p r e t S p e c 1 é construída a partir de i n t e r p r e t S p e c adotando como
filtro a função f i l t e r 1 e como estado inicial uma lista vazia. A função i n t e r p r e t S p e c 1 ,
portanto, define uma semântica para Litoral. Esta semântica será denominada de
semântica 1.
A semântica 1 possui uma propriedade indesejável: ela associa especificações Li-
toral recursivas a funções que entram em recursão infinita ao navegar por objetos que se
auto-referenciam direta ou indiretamente. Isto acontece, por exemplo, com a especificaçãoLitoral spec1 e o objeto message exibidos nas Figuras 36 e 37, respectivamente.
É fácil ver por que spec1 entra em recursão infinita neste caso. A primeira coisa
que spec1 faz é iniciar a travessia v i s i t M e s s a g e a partir de uma lista contendo message:
[ message ] . vi si tM es sag e ()
A substituição de v i s i t M e s s a g e por seu caminho resulta em
[ message ] . r ep l i es . v is it Mes sage ()
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 57/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 58/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 59/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 60/162
Capítulo 3. Litoral 59
1 Definition objPathEq ( objPath objPath ’ : OBJ ∗ PATH) :=
2 l e t ( o b j , p ath ) : = o b j Path in
3 l e t ( obj ’ , path ’ ) := objPath ’ in
4 i f o bj Eq o b j o b j ’ then pathEq path path ’ e l s e f a l s e .
5
6 Fixpoint c o n ta in s O bj Pa th o b j Path s o b jPa th :=
7 match objPaths with
8 | [ ] => f a l s e
9 | objPath ’ : : objPaths ’ =>
10 i f containsObjPath objPaths ’ objPath then t r u e
11 e l s e objPathEq objPath ’ objPath
12 end .
13
14 Fixpoint f i l t e r 3 ( paths : l i s t PATH) ( al lO bj s : l i s t OBJ)
15 ( s : l i s t (OBJ ∗ PATH)) ( obj s : l i s t OBJ) ( path : PATH) :=16 match o b j s with
17 | [ ] => (s , [ ] )
18 | o b j : : o b js ’ =>
19 l e t ( s ’ , o u tO b js ) : = f i l t e r 3 p a th s a l l O b j s s o b j s ’ p ath in
20 l e t o b j Pa th := ( o b j , p ath ) in
21 i f c o n ta i n sO b j Pa th ( l i s t_ p r o d a l l O b j s p a ths ) o b jPa th then
22 i f containsObjPath s ’ objPath then ( s ’ , o u tO b js )
23 e l s e ( o b j Pa th : : s ’ , o b j : : o ut Ob js )
24 e l s e
25 ( s ’ , o u tO b js )26 end .
27
28 Definition i n t e r pr e t Sp e c3 s pe c a l l Ob j s o b js n :=
29 l e t ’ ( s p ec ’ , _ , _) := i n d e xS p e c s p e c in
30 i n te r p r e t S p e c (S := l i s t (OBJ ∗ PATH)) f i l t e r 3 [ ] spec ’ a l l Obj s objs n .
Figura 42 – Semântica 3.
Portanto, na semântica 3 spec1 não entra em recursão infinita ao navegar a partir demessage .
Voltando ao primeiro exemplo da seção 3.4.4.3, f i l t e r 3 permitirá que spec2
navegue novamente de message para u s e r através do atributo r e c i p i e n t s , pois spec2
ainda não percorreu o caminho p i c t u r e a partir de u s e r , resultando na lista
[ m es sa ge , u s e r , u s e r , p i c t u r e ]
ou seja, na semântica 3 spec2 parte de message e realiza todas as navegações especificadas.Por fim, voltando ao segundo exemplo da seção 3.4.4.3, ao navegar a partir de
message , spec3 resulta na lista
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 61/162
Capítulo 3. Litoral 60
[ m es sa ge , u s e r , p i c tu r e , u s e r ]
mostrando que na semântica 3 spec2 e spec3 partem de message e navegam pelos
mesmos objetos, ainda que em ordens diferentes.
3.4.4.5 Escolha de uma Semântica
Dentre as semânticas 1, 2 e 3, a última deve ser escolhida preferencialmente, pois ela
está livre dos problemas das anteriores. Entretanto, se há segurança de que as especificações
Litoral que serão executadas não definem travessias recursivas a partir de objetos que se
auto-referenciam, então a semântica 1 pode ser adotada. Especificamente nestes casos, a
semântica 1, assim como a semântica 3, também associa especificações Litoral a funções
que não entram em recursão infinita e que estão livres dos problemas da semântica 2.Adotar a semântica 1 é vantajoso, pois, por permanecer sempre em seu estado inicial, ela
é mais simples e demanda menos memória e processamento do que a semântica 3.
A discussão anterior pressupõe que a escolha de uma semântica é estática, ou seja,
toda e qualquer especificação Litoral será executada sob a mesma semântica. Entretanto,
também é possível escolher uma semântica dinamicamente, em função da especificação
Litoral que será executada. Pode-se, por exemplo, procurar por travessias recursivas
na especificação Litoral. Se elas forem encontradas, a semântica 3 é adotada. Caso
contrário, a escolha recai sobre a semântica 1.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 62/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 63/162
Capítulo 4. Interpretador 62
dependências entre tarefas, sejam elas de dados ou temporais, e também declara quais
tarefas devem ser executadas em um novo contexto de execução2, cabendo ao ambiente de
tempo de execução gerenciar:
• a sincronização, ou seja, executar as tarefas em uma ordem que respeite suas
dependências e, quando for o caso, em um novo contexto de execução (SCOTT,
2006);
• a comunicação, isto é, disponibilizar para uma tarefa o resultado das tarefas das
quais ela depende (SCOTT, 2006).
Diferentemente de frameworks que foram criados para paralelizar processamento de
dados ((LEA, 2000), por exemplo), Afluentes pode ser utilizado com primitivas de E/Sassíncronas, baseadas em callbacks ou multiplexadas, e também com primitivas síncronas.
4.1.1 Modelo de Programação
Esta subseção dá uma visão geral do modelo de programação de Afluentes. Neste
modelo, tarefas são avaliações de funções. Por exemplo, sejam as funções sub(x, y) = x− y
e mul(x, y) = x × y. Então as avaliações sub(0, 1) e mul(2, 3) são tarefas.
Dependências entre tarefas são composições das avaliações subjacentes. Por exem-plo, dados a, b e c, podemos calcular o valor de b2 − 4ac com a composição de avaliações
sub(mul(b, b),mul(4,mul(a, c))). Ao se deparar com esta composição, Afluentes identi-
fica, por exemplo, que a tarefa mul(4,mul(a, c)) depende da tarefa mul(a, c) e, portanto,
a primeira só pode ser executada depois da última.
Ao inspecionar composições de avaliações, Afluentes também identifica tarefas
independentes. Afluentes supõe que a execução de cada uma destas tarefas não tem
efeitos indesejáveis sobre as demais, portanto elas podem ser executadas concorrentemente.
No exemplo anterior, Afluentes
identificaria que as tarefas mul(b, b) e mul(a, c) sãoindependentes e, portanto, podem ser executadas concorrentemente.
A independência de tarefas é uma condição necessária, mas não suficiente, para que
elas sejam executadas concorrentemente. Isto acontecerá apenas se uma destas tarefas for
a avaliação de uma função assíncrona. Funções síncronas e assíncronas serão discutidas em
breve. Para os fins desta subseção, é suficiente saber que funções assíncronas são avaliadas
em um novo contexto de execução.
4.1.2 Funções SíncronasO código da Figura 43 calcula o valor de b2− 4ac compondo invocações de métodos.
2 O termo thread foi evitado pois normalmente ele é interpretado como um processo leve.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 64/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 65/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 66/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 67/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 68/162
Capítulo 4. Interpretador 67
1 p ub l ic i n t e r f a c e I Ca ll ba ck <Y> {
2 void y(Y y ) ;
3 void t ( Throwable t ) ;
4 }
Figura 48 – Interface ICallback.
1 p ub l ic i n t e r f a c e IAsyncFn0<Y> {
2 void y( IC all bac k<Y> cb ) ;
3 }
4
5 p ub l ic i n t e r f a c e IAsyncFn1<X1, Y> {
6 void y (X1 x1 , IC all bac k<Y> cb ) ;
7 }
8
9 p ub l ic i n t e r f a c e IAsyncFn2<X1, X2, Y> {
10 void y(X1 x1 , X2 x2 , ICal lback <Y> cb ) ;
11 }
Figura 49 – Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2.
1 IAsyncFn2<Double , Double , Double> sub = (x , y , cb) −> {
2 new Thread ( ( ) −> c b . y (x − y ) ) . s t a r t ( ) ;
3 } ;
4
5 IAsyncFn2<Double , Double , Double> mul = (x , y , cb) −> {
6 new Thread ( ( ) −> c b . y (x ∗ y ) ) . s t a r t ( ) ;
7 } ;
Figura 50 – Funções sub e mul definidas com as interfaces IAsyncFn2.
4.1.7 Representando Funções Assíncronas
As interfaces IAsyncFn0, ..., IAsyncFn16 exibidas na Figura 49 são versões
assíncronas das interfaces ISyncFn0, ..., ISyncFn16. Como funções assíncronas entregam
o resultado de suas avaliações através de callbacks, os métodos y das interfaces IAsyncFn0,
..., IAsyncFn16 têm tipo de retorno vo id e recebem como último parâmetro um callback.
A Figura 50 exibe as funções assíncronas mul e su b, mas desta vez definidas com
as interfaces IAsyncFn2.
4.1.8 Avaliações
Avaliações são objetos cujas classes implementam a interface IEval exibida naFigura 51. Ao ser invocado pela primeira vez, o método y executa o processo de avaliação
descrito na seção 4.1.4. O resultado deste processo é armazenado na avaliação de forma
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 69/162
Capítulo 4. Interpretador 68
1 p ub l ic i n t e r f a c e IEval<Y> {
2 Y y ( ) ;
3 }
Figura 51 – Interface IEval.
1 p ub l ic i n t e r f a c e IFnEval0<Y> {
2 IEval<? extends Y> y ( ) ;
3 }
4
5 p ub l ic i n t e r f a c e IF nEva l1<X1 , Y> {
6 IEval<? extends Y> y( X1 x1 ) ;
7 IEval<? extends Y> y ( IEval <? extends X1> x1 );
8 }
Figura 52 – Interfaces IEval0 e IEval1.
que invocações subsequentes do método y não precisam executar o processo de avaliação
novamente.
4.1.9 Avaliadores
Avaliadores são objetos cujas classes implementam uma das interfaces IFnEval0,
..., IFnEval16. A Figura 52 exibe as duas primeiras.
As classes ISyncEval0, ..., ISyncEval16 e IAsyncEval0, ..., IAsyncEval16
são adaptadores que transformam funções síncronas e assíncronas, respectivamente, em
avaliadores. Elas podem ser vistas em ação nos códigos das figuras 53 e 54 que calculam
b2− 4ac, mas desta vez compondo invocações de avaliadores de funções síncronas e
assíncronas. A comparação destes códigos concorda com as afirmações da seção 4.1.3:
• a transformação de funções assíncronas em avaliadores (linhas 1 a 3 da Figura 54)
permite que suas invocações sejam compostas (linha 8 da Figura 54) com a mesma
facilidade do caso síncrono (linha 6 da Figura 53);
• a transformação de funções síncronas em avaliadores (linhas 1 e 3 da Figura 53 e
linha 5 da Figura 54) permite que os dois tipos de funções sejam misturados em
uma mesma composição de avaliações (linha 6 da Figura 53).
Apesar dos métodos d e l t a das figuras 53 e 54 serem idênticos, suas execuções são
bastante diferentes. O primeiro é executado sequencialmente, pois envolve apenas funçõessíncronas. O último é executado concorrentemente, pois envolve tanto funções síncronas
quanto assíncronas.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 70/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 71/162
Capítulo 4. Interpretador 70
percorre esta árvore em busca de avaliações que podem ser executadas. As avaliações
m u l ( b , b ) e mul (a , c ) satisfazem este critério. Elas são executadas concorrentemente,
pois estão relacionadas a funções assíncronas.
Suponha que m u l ( b , b ) seja concluída primeiro, levando a árvore de avaliações àconfiguração da Figura 55b. Afluentes percorre esta configuração em busca, novamente,
de avaliações que podem ser executadas, mas desta vez não encontrará nenhuma.
A Figura 55c exibe a configuração da árvore de avaliações quando mul (a , c )
é concluída. Neste momento, Afluentes executa uma nova busca e descobre que
mul(4 .0 , mul(a , c )) já pode ser executada. Quando esta avaliação é concluída, a árvore
de avaliações evolui para a configuração da Figura 55d. Uma nova busca revela que a raíz
da árvore de avaliações pode, enfim, ser executada. Quando esta avaliação chega ao fim, a
árvore de avaliações evolui para a configuração final exibida na Figura 55e.
4.1.10 Funções sobre Listas
Sejam X1 e Y tipos quaisquer. Funções sobre listas são objetos que implementam
a interface ISyncFn1<List<X1>, Y>, ou seja, são funções síncronas cujo domínio e con-
tradomínio são, respectivamente, listas de X1 e Y. O código da Figura 56, por exemplo,
define as funções sobre listas sum e p r o d u c t s . A primeira associa uma lista de produtos
ao somatório dos seus preços. A segunda associa uma lista de códigos de produtos a uma
lista dos respectivos produtos.
4.1.11 Avaliadores de Funções sobre Listas
Existem casos em que é necessário aplicar uma função sobre listas
ISyncFn 1<Li st <X1>, Y> a uma lista de avaliações de X1 ( List<IEval<X1>>). O Adapta-
dor SyncEval1 não ajudará nestes casos, pois ele permite que a função sobre listas seja
aplicada a avaliações de listas de X1 ( IEval<List<X1>>) mas não a listas de avaliações
de X1. O adaptador L i s t E v a l , por outro lado, permite a última aplicação. L i s tEv a lrecebe uma lista de avaliações de X1, espera que todas as avaliações sejam concluídas,
constrói uma nova lista contendo o resultado das avaliações ( List<X1>) e, finalmente,
aplica a função à nova lista.
Voltando ao exemplo da Figura 56, o método t o t a l recebe uma lista de códigos de
produtos e calcula o somatório dos preços dos respectivos produtos compondo invocações
das funções sum e products . Como products carrega os produtos para a memória
primária invocando a função product , podemos aumentar o desempenho de t o t a l
tornando product assíncrona, pois assim os produtos serão carregados concorrentemente.O código da Figura 57 incorpora esta mudança. Como a função product tornou-se
um avaliador, o contradomínio da função products passou de List<Product> para
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 72/162
Capítulo 4. Interpretador 71
1 ISyncFn1<Integ er , Product> product = id −> { / ∗ . . . ∗/ } ;
2
3 ISyncFn1<List<Int ege r >, Lis t<Product>> pr oduc ts = id s −> {
4 Lis t<Product> ps = new ArrayList <>();
5 f o r ( I n t eg e r i d : i d s ) {6 Product p = product . y( id ) ;
7 ps . add( p ) ;
8 }
9 return ps ;
10 } ;
11
12 ISyncFn1<Li st <Product >, Double> sum = ps −> {
13 double s = 0 ;
14 f o r ( P rod uct p : p s ) {
15 s += p . pr ic e ;16 }
17 return s ;
18 } ;
19
20 double to ta l ( L i s t< In te g e r > i d s ) {
21 return sum. y( products . y( id s )) ;
22 }
Figura 56 – Cálculo do somatório dos preços dos produtos de uma lista compondo invoca-ções de funções síncronas.
Lis t<IEval<? ext ends Product>>. Portanto, para que possamos aplicar a função sum
aos resultados de products , precisamos transformá-la em um avaliador com o adaptador
L i s tEv a l .
4.2 Projeto
A fase de implementação (MERNIK; HEERING; SLOANE, 2005) do desenvol-vimento de Litoral determinou que seu interpretador deveria atender aos requisitos a
seguir.
Baixo acoplamento: se um sistema usa um mecanismo de carregamento de
objetos que se integra com o interpretador, então as únicas mudanças no código do sistema
necessárias ao uso do interpretador devem ser sua instanciação e execução.
Transparência: o uso do interpretador não deve modificar um sistema funcional-
mente. Seu único efeito deve ser a redução do tempo de carregamento de objetos.
Independência: o interpretador deve ser capaz de interagir com qualquer meca-
nismo de carregamento de objetos.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 73/162
Capítulo 4. Interpretador 72
1 IFnEval1<Inte ger , Product> product = new AsyncEval1<>((id , cb ) −> {
2 / ∗ . . . ∗/
3 } ) ;
4
5 ISyncFn1<List<Int ege r >, Lis t<IEval<? extends Product>>> p rod uct s = id s −> {6 List<IEval<? extends Prod uct>> ps = new ArrayList <>();
7 f o r ( I n te g er i d : i d s ) {
8 IEval<? extends Product> p = product . y( id ) ;
9 ps . add( p ) ;
10 }
11 return ps ;
12 } ;
13
14 IL ist Eva l<Product , Double> sum = new ListEval<>(ps −> { / ∗ . . . ∗/ } ) ;
15
16 double to ta l ( L i s t< In te g e r > i d s ) {
17 return sum. y( products .y( ids )) . y ( ) ;
18 }
Figura 57 – Cálculo do somatório dos preços dos produtos de uma lista compondo avalia-dores de funções assíncronas e de funções sobre listas.
1 p ub l ic i n t e r f a c e I Eva lHo ld er <Y> {
2 IEval<? extends Y> getE val ( ) ;
3 }
Figura 58 – Interface IEvalHolder.
Baixa exigência: o interpretador deve fazer poucas exigências aos mecanismos
de carregamento de objetos que desejam se integrar com ele.
O interpretador atende ao último requisito fazendo uma única exigência: os meca-
nismos devem carregar objetos sob demanda com proxies que implementam a interface
IEvalHolder exibida na Figura 58. O parâmetro de tipo Y determina a classe do objetoque será carregado. O método getEval retorna a avaliação que carrega este objeto.
Mecanismos de carregamento de objetos atendem facilmente à exigência do interpre-
tador gerando proxies que, similarmente ao exibido na Figura 59, armazenam a avaliação
retornada pelo método getEval no atributo e v a l e sobrepõem todos os métodos de suas
classes-alvo. Os novos métodos obtêm os objetos-alvo dos proxies executando o processo
de avaliação ( e v a l . y ( ) ) e repassam para eles suas invocações.
A geração de proxies similares ao da Figura 59 também é responsável pelo cumpri-
mento do requisito de transparência. Quando um método do proxy é invocado, não fazdiferença se o interpretador já carregou o objeto-alvo do proxy executando o processo de
avaliação. Em caso positivo, a invocação será repassada para o objeto-alvo imediatamente.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 74/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 75/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 76/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 77/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 78/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 79/162
Capítulo 4. Interpretador 78
(“”, Message)
(“visitMessage”, Message) (“visitMessage”, List<Message>)
Figura 65 – Tabela de símbolos da especificação Litoral da Figura 63.
4.3.3 Interpretação
A idéia principal por trás da interpretação de especificações Litoral com Aflu-
entes consiste em construir composições de avaliações a partir de suas tabelas de símbolos.
As avaliações navegam por objetos, carregando-os para a memória primária se necessário.
As tabelas de símbolos contêm cópias das subárvores das ASTs das especificaçõesLitoral. As composições de avaliações são construídas à medida que os nós das subárvores
são percorridos. Os nós estão anotados com as classes dos objetos sobre os quais eles
atuam. Os objetos podem ser listas de outros objetos, ou seja, suas classes são subclasses
de L i s t .
4.3.3.1 Nós que Atuam Sobre Objetos
Se n é um nó que atua sobre um objeto, então n dá origem a uma composição de
avaliações das funções head e e v a l u a t i o n s 1 .A função e v a l u a t i o n s 1 recebe como argumentos os filhos de n e um objeto e
retorna uma lista de avaliações. A primeira avaliação da lista carrega o objeto. Se ele
implementa a interface IEvalHolder , então a primeira avaliação é a retornada pelo método
getEval . Caso contrário, é a avaliação da função identidade aplicada ao objeto. As demais
avaliações da lista retornada por e v a l u a t i o n s 1 correspondem a avaliações de funções
que, a partir do objeto recebido como argumento:
• navegam através dos atributos cujos nomes estão contidos nos filhos de n; ou
• iniciam as travessias cujos nomes estão contidos nos netos de n.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 80/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 81/162
Capítulo 4. Interpretador 80
(a) (b)
(c)
(d)
(e)
Figura 66 – Interpretação de especificações Litoral
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 82/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 83/162
Capítulo 4. Interpretador 82
(j)(k)
(l)
(m)
Figura 66 – Interpretação de especificações Litoral - Continuação
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 84/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 85/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 86/162
Capítulo 5. Avaliação 85
• associações de cardinalidade muitos para muitos são mapeadas para tabelas cujas
chaves primárias são formadas por chaves estrangeiras que referenciam as tabelas
das classes associadas. Os atributos das associações, quando existirem, são mapeados
para colunas de suas tabelas;
• subclasses são mapeadas para tabelas que contêm apenas seus atributos próprios
(aqueles que não foram herdados das superclasses). As tabelas das subclasses possuem
chaves estrangeiras que referenciam as tabelas das superclasses.
A Seção A.2 exibe as tabelas resultantes do mapeamento objeto-relacional. O banco
de dados é populado com um tipo de arquivo, uma marcação e cem usuários. Cada usuário
possui uma imagem e iniciou (ou seja, enviou a primeira mensagem de) mil conversações.
Cada uma das nove primeiras mensagens de uma conversação possui uma réplica, enquantoa última não possui réplicas. Portanto, cada conversação possui dez mensagens. Cada
mensagem possui um anexo e está associada a uma marcação. Resumindo, o banco de
dados é populado com 1 tipo de arquivo, 1 marcação, 100 usuários, 1.000.000 mensagens e
1.000.100 arquivos.
Emeio é composto pelas especificações Litoral exibidas na Figura 67. As especi-
ficações C e G declaram navegações executadas durante a exibição da lista de mensagens
enviadas e recebidas por um usuário, respectivamente. A especificação L declara navegações
executadas durante a exibição de todas as mensagens que compõem uma conversação.As especificações A–B, D–F e H–K são versões simplificadas das especificações C, G e L,
respectivamente.
As especificações A–C e D–G são executadas, respectivamente, a partir das 50
últimas mensagens enviadas e recebidas por um usuário escolhido aleatoriamente. As
especificações H–L são executados a partir de mensagens escolhidas também aleatoriamente.
Todas as especificações são executadas 6.000 vezes. As 1.000 primeiras são ignoradas para
minimizar a interferência de custos de inicialização (por exemplo, carregamento de classes
e compilação just in time).
5.1.1 Implementação Baseada no Hibernate
A implementação de Emeio baseada no Hibernate sofreu as seguintes otimizações:
1. atributos do tipo II são carregados através de consultas que fazem uso do operador i n
de SQL para carregar vários objetos, ou seja, a anotação @BatchSize foi adicionada
aos atributos anotados com @ManyToOne ou @ManyToMany;
2. atributos do tipo II que referenciam objetos são carregados sob demanda, ou seja, o
atributo f e t c h das anotações @ManyToOne recebu o valor FetchType .LAZY;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 87/162
Capítulo 5. Avaliação 86
1 r e c i p i e n t s // A
2
3 r e c i p i e n t s t ag s // B
4
5 r e c i p i e n t s t a gs f i l e s // C 6
7 s e n d e r // D
8
9 s en de r r e c i p i e n t s // E
10
11 s en de r r e c i p i e n t s t ag s // F
12
13 s e nd e r r e c i p i e n t s t a gs f i l e s // G
14
15 v i s i t M e s s a g e = [ r e p l i e s . v i s i t M e s s a g e ( ) ] // H 16 v i s i t Me s s a g e ( )
17
18 v i s i t M e s s a g e = [ s e n de r r e p l i e s . v i s i t M e s s a g e ( ) ] // I
19 v i s i t Me s s a g e ( )
20
21 v i s i t M es s a g e = [ s en d er r e c i p i e n t s r e p l i e s . v i s i t M es s a g e ( ) ] // J
22 v i s i t Me s s a g e ( )
23
24 v i s i t M es s a g e = [ s en d er r e c i p i e n t s t a g s r e p l i e s . v i s i t Me s s a ge ( ) ] // K
25 v i s i t Me s s a g e ( )26
27 v i s i t M es s a g e = [ s en d er r e c i p i e n t s t a g s f i l e s r e p l i e s . v i s i t Me s s a ge ( ) ] // L
28 v i s i t Me s s a g e ( )
Figura 67 – Especificações Litoral que compõem o benchmark Emeio.
3. índices foram criados para as chaves estrangeiras de todas as tabelas;
4. as tabelas message_sender_view e message_rec ipient_view exibidas na Figura68 foram adicionadas ao banco de dados. Elas armazenam, respectivamente, as 50
últimas mensagens enviadas e recebidas por cada usuário do sistema;
5. índices foram criados para os pares de colunas das tabelas message_sender_view e
message_rec ipient_view com os comandos SQL exibidos na Figura 69.
As figuras 70a–70e exibem o tempo total de execução das especificaçõesLitoral
A–L com diferentes versões da implementação de Emeio baseada no Hibernate. A Figura
70a exibe os tempos com as versões não otimizada e com a otimização 1, a Figura 70bexibe os tempos das versões com a otimização 1 e com as otimizações 1 e 2 combinadas,
e assim sucessivamente. Nas figuras 70a–70d o tempo total corresponde a 10 execuções
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 88/162
Capítulo 5. Avaliação 87
Figura 68 – Tabelas adicionadas ao banco de dados para otimizar a implementação deEmeio baseada no Hibernate.
1 create index on m e s s ag e _ r ec i p i en t_ v i ew ( r e c i p i e n t _ i d e n t i f i e r ,
2 m e s s a g e _ i d e n t i f i e r desc ) ;
3
4 create index on message_sender_view ( se nde r_i den ti f i er ,
5 m e s s a g e _ i d e n t i f i e r desc ) ;
Figura 69 – Índices criados no banco de dados de Emeio.
de cada especificação Litoral, enquanto que na Figura 70e ele corresponde a 5.000
execuções. Foi necessário aumentar o número de execuções porque a redução no tempo
total proporcionada pela otimização 5 só se torna aparente com um número maior de
execuções.
Os dados exibidos nas figuras 70a–70e são sintetizados pelas seguintes observações:
• aplicar a otimização 1 à versão não otimizada reduz o tempo total de execução das
especificações Litoral A–C e E–G em 75,1–78,8%;• aplicar a otimização 2 à versão com a otimização 1 reduz o tempo total de execução
das especificações Litoral A–G em 15,5–52,0%;
• aplicar a otimização 3 à versão com as otimizações 1–2 reduz o tempo total de
execução de todas especificações Litoral em 67,5–99,7%;
• aplicar a otimização 4 à versão com as otimizações 1–3 reduz o tempo total de
execução das especificações Litoral A–G em 68,1–89,6%;
• aplicar a otimização 5 à versão com as otimizações 1–4 reduz o tempo total de
execução das especificações Litoral A–G em 10,6–25,3%.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 89/162
Capítulo 5. Avaliação 88
(a)
(b)
(c)Figura 70 – Resultado das otimizações da implementação de Emeio baseada no Hibernate.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 90/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 91/162
Capítulo 5. Avaliação 90
recarregamento de objetos, enquanto a implementação baseada no interpretador não adota
esta otimização.
5.1.4 ResultadosAs figuras 71a–71c exibem o tempo total de execução das especificações A–L com
as implementações de Emeio baseadas no Hibernate, EclipseLink JPA e no interpretador
de Litoral.
Em muitos casos, o tempo total de execução com o interpretador no modo sequencial
é menor do que o obtido com o Hibernate e o EclipseLink JPA. É bastante provável que
isto ocorra porque o ORM com o qual o interpretador foi integrado possui apenas as
funcionalidades necessárias à implementação dos benchmarks, enquanto o Hibernate e
o EclipseLink JPA implementam uma série de outras funcionalidades que ajudam o
desenvolvedor, mas, eventualmente, reduzem o desempenho.
O tempo total de execução das especificações A, D e H com o interpretador no
modo concorrente foi 0,9–9,9% maior do que no sequencial. Este aumento ocorre porque a
otimização 1 da seção 5.1.1 elimina destas especificações as oportunidades para concorrência.
Em casos assim, o aumento no tempo de processamento oriundo do gerenciamento da
concorrência não é compensado por uma redução no tempo de E/S, pois as consultas
são executadas sequencialmente. Esta observação sugere que o interpretador deveria ser
capaz de identificar se uma especificação oferece oportunidades para concorrência. Em
caso negativo, o interpretador operaria no modo sequencial mesmo quando solicitado a
operar no modo concorrente.
Por outro lado, o tempo total de execução das demais especificações com o inter-
pretador no modo concorrente foi 33,3–69,1% menor do que no sequencial. De maneira
geral, quanto maiores forem as oportunidades para concorrência (especificações C, G e L),
maior é a redução no tempo total de execução.
Em algumas especificações, o tempo total de execução com o interpretador no modosequencial foi menor do que com as implementações baseadas no Hibernate (especificações
A–D e G–H) e EclipseLink JPA (especificações A–C e G). Em outras, foi maior. O pior
desempenho foi observado na especificação I, na qual o tempo total de execução mais
que dobrou. Entretanto, em todas as especificações que oferecem oportunidades para
pré-carregar objetos executando consultas concorrentemente, esta otimização fez com que
o tempo total de execução com o interpretador no modo concorrente fosse menor do que
com as implementações baseadas no Hibernate (8–62,3%) e EclipseLink JPA (8,1–56,4%).
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 92/162
Capítulo 5. Avaliação 91
(a)
(b)
(c)
Figura 71 – Tempo total de execução das implementações de Emeio baseadas no inter-pretador de Litoral, Hibernate e EclipseLink JPA.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 93/162
Capítulo 5. Avaliação 92
5.2 OO7
OO7 é um benchmark livremente inspirado em sistemas de CAD (Computer Aided
Design), CAM (Computer Aided Manufacturing) e CASE (Computer Aided Software
Engineering). Ele foi projetado para avaliar o desempenho de navegações, atualizações e
consultas em OODBMs. Como o interpretador deLitoral influencia apenas o desempenho
de navegações, a implementação de OO7 desenvolvida nesta pesquisa, tal como (IBRAHIM;
COOK, 2006), se limita a esta parte do benchmark.
Os principais conceitos modelados por OO7 são:
• partes compostas (CompositePart) representam primitivas de projeto básicas como,
por exemplo, um registrador em um sistema VLSI (Very Large Scale Integration)
CAD ou um procedimento em um sistema CASE. Uma parte composta possui uma
parte atômica (AtomicPart) raiz;
• partes atômicas (AtomicPart) representam as unidades que compõem as partes
compostas. Em um sistema CASE, por exemplo, elas representariam variáveis,
comandos, expressões, etc. Uma parte atômica possui conexões com outras partes
atômicas;
• conexões ( Conne ction ) representam a conexão entre uma parte atômica de origem
e outra de destino;
• montagens (Assembly) representam construções de projeto de alto nível como, por
exemplo, uma unidade lógica e aritmética em um sistema VLSI CAD. Montagens
podem ser formadas por partes compostas, caso em que são chamadas de montagens
base (BaseAssembly) , ou por outras montagens, caso em que são chamadas de
montagens complexas (ComplexAssembly) ;
• módulos (Module) representam hierarquias de montagens complexas. Um módulo
possui um manual (Manual) e uma montagem complexa raiz;
• manuais (Manual) representam a documentação de um módulo.
A implementação de OO7 desenvolvida nesta pesquisa adota o banco de dados
(modelo, índices e dados) da desenvolvida em (ZYL, 2010). A Seção B.2 exibe suas tabelas
principais. A Figura 72 exibe os comandos SQL que criam seus índices.
OO7 especifica três tamanhos de banco de dados: pequeno, médio e grande. Esta
pesquisa, tal como (IBRAHIM; COOK, 2006), adotou o tamanho pequeno. Nele, o banco
de dados é populado com 500 partes compostas, 10.000 partes atômicas, 30.000, 60.000 ou
90.000 conexões para cada parte atômica (esta pesquisa adotou 30.000), 729 montagens
básicas, 365 montagens complexas e 1 módulo.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 94/162
Capítulo 5. Avaliação 93
1 create index on assembly ( des ign id ) ;
2 create index on atomic_parts ( bui l ddat e ) ;
3 create index on atomic_parts ( des ign id ) ;
4 create index on composite_parts ( des ign id ) ;
5 create index on document ( t i t l e ) ;6 create index on module( bui ldda te ) ;
Figura 72 – Índices de OO7.
1 v is i t Atomi cPart=toConnections . to . v is it Atomi cPart () // T1
2 v i s i tA s s e m b l y = [
3 subAssemblies . v is i tAsse mbly ()
4 componentsPrivate . rootPart . v is it Atomi cPart ()
5 ]
6 des ignRoot . v is it Assem bly ()7
8 v i s i tA s s e m b l y = [ // T6
9 subAssemblies . v is i tAsse mbly ()
10 componentsP rivate . root Part
11 ]
12 des ignRoot . v is it Assem bly ()
Figura 73 – Especificações Litoral que fazem parte de OO7.
OO7 é composto por sete cenários denominados T1, T2, T3, T6, T8, T9 e CU
(Cache Update). Os cenários T2, T3 e CU realizam as mesmas navegações que T1 e,
adicionalmente, atualizam objetos. Os cenários T8 e T9 consistem em carregar um manual
e varrer o seu conteúdo (uma cadeia de caracteres). Como o interpretador de Litoral
influencia apenas o desempenho de navegações, esta pesquisa, tal como (IBRAHIM; COOK,
2006), ignora T2, T3 e CU. Ela também ignora T8 e T9, já que estes cenários não oferecem
opotunidades para concorrência. A Figura 73 exibe as especificações Litoral que declaram
as navegações executadas em T1 e T6. As duas especificações são executadas a partir
de um módulo. A Seção B.1 exibe as classes dos objetos pelos quais estas especificações
navegam.
5.2.1 Implementação Baseada no Hibernate
A implementação de OO7 baseada no Hibernate sofreu uma única otimização:
atributos do tipo II são carregados através de consultas que fazem uso do operador i n
de SQL para carregar vários objetos, ou seja, a anotação @BatchSize foi adicionada aos
atributos anotados com @OneToMany, @ManyToOne e @ManyToMany. A Figura 74 exibe otempo total de 10 execuções das especificações T1 e T6 com as versões não otimizada e
otimizada. A última é 91,5–91,8% mais rápida do que a primeira.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 95/162
Capítulo 5. Avaliação 94
Figura 74 – Resultados da otimização da implementação de OO7 baseada no Hibernate.
5.2.2 Implementação Baseada no EclipseLink JPA
A implementação de OO7 baseada no EclipseLink JPA sofreu a mesma otimização
que a baseada no Hibernate. Entretanto, uma limitação do EclipseLink JPA impediu que
os objetos referenciados pelos atributos componentsPrivate da classe BaseAssembly e
subAssemblies da classe ComplexAssembly fossem carregados através de consultas que
fazem uso do operador i n de SQL para carregar vários objetos. Mais especificamente,
a exceção o r g . e c l i p s e . p e r s i s te n c e . e x c e p t i o n s . Q u er y Ex c ep t io n é levantada com
o código de erro 6169 quando a anotação @BatchFetch( va lu e=BatchFetchType . IN) é
adicionada a estes atributos.
5.2.3 Implementação Baseada no Interpretador de Litoral
A implementação de OO7 baseada no interpretador de Litoral sofreu a mesma
otimização que a baseada no Hibernate. Entretanto, diferentemente do Hibernate e do
EclipseLink JPA, ela não armazena objetos em um cache.
5.2.4 Resultados
A Figura 75 exibe o tempo total de execução das especificações T1 e T6 com as
implementações de OO7 baseadas no Hibernate, EclipseLink JPA e no interpretador de
Litoral. O tempo total de execução das especificações T1 e T6 com o interpretador no
modo concorrente foi 49,5–59,3% menor do que no sequencial.
O tempo total de execução das especificações T1 e T6 com o interpretador no
modo sequencial foi menor do que com as implementações baseadas no Hibernate e
EclipseLink JPA. A única exceção foi a especificação T6 com o Hibernate. Entretanto, o
tempo total de execução com o interpretador no modo concorrente foi menor do que com as
implementações baseadas no Hibernate (52,4–58,0%) e no EclipseLink JPA (95,2–96,5%).
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 96/162
Capítulo 5. Avaliação 95
Figura 75 – Tempo total de execução das implementações de Emeio baseadas no inter-
pretador de Litoral, Hibernate e EclipseLink JPA.
No caso do Hibernate, a redução no tempo total de execução se deve majoritariamente à
execução concorrente de consultas. Entretanto, no caso do EclipseLink JPA, a contribuição
desta otimização foi minoritária, pois o tempo total de execução com o interpretador no
modo sequencial já é muito menor (90,4–91,5%) do que com o EclipseLink JPA.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 97/162
96
6 Trabalhos Relacionados
Este capítulo discute trabalhos (Program Summaries, Scalpel, AutoFetch, etc.) que,
assim como esta pesquisa, visam aumentar o desempenho de sistemas baseados em ORMs.
De maneira geral, eles alcançam este objetivo produzindo consultas SQL que, quando
executadas sequencialmente, minimizam o tempo de pré-carregamento de objetos. Um
aspecto interessante, evidenciado no Capítulo 5, é que estas consultas, na maioria dos
casos, também podem ser executadas concorrentemente, reduzindo ainda mais o tempo de
pré-carregamento de objetos.
6.1 Program Summaries
(GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) aumenta o desempenho de
sistemas baseados em ORMs pré-carregando objetos com consultas que carregam vários
objetos. Para isto, ele define uma linguagem chamada Program Summary, baseada na
linguagem XPath (CLARK; DEROSE et al., 1999), que permite especificar navegações
por objetos. A Figura 76, por exemplo, exibe uma especificação Program Summary que
declara navegações das mensagens enviadas pelo usuário cujo identificador é igual a 1
para seus remetentes e destinatários.
Sejam S uma especificação Program Summary, G um grafo de objetos e v um
vértice deste grafo. (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define formalmente
o traço T S,v(G) de S sobre o vértice v com respeito a G. Intuitivamente, o traço corresponde
aos vértices de G pelos quais a especificação S , iniciando por v, navega.
(GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) apresenta três estratégias para
transformar uma especificação Program Summary S em programas que, dados um grafo
de objetos G e um vértice v deste grafo, carregam T S,v(G). Estes programas são formadospelas operações open, fetch e decode, consultas SQL e laços.
A primeira estratégia é chamada de Lazy e corresponde ao carregamento sob
demanda dos vértices de G. Esta estratégia, portanto, é a que executa mais consultas SQL.
1 @db. Message [ sender . id e n t i f i e r =1] {
2 @sender {} ;
3 @ r e c i p i e n t s { }
4 }
Figura 76 – Especificação Program Summary que declara navegações das mensagens envi-adas por um usuário para seus remetentes e destinatários.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 98/162
Capítulo 6. Trabalhos Relacionados 97
A segunda estratégia, chamada de Single, faz uso de junções (AHO; BEERI;
ULLMAN, 1979) e do operador union de SQL para carregar vários objetos executando
uma única consulta. A desvantagem desta estratégia é que o resultado da consulta que ela
executa tende a ter um número muito grande de linhas e colunas.A terceira estratégia é chamada de Decorrelation e executa uma consulta SQL para
cada tabela que contém vértices de T S,v(G). Ela é uma estratégia intermediária entre a
Lazy e a Single, já que, como a Lazy, ela executa mais de uma consulta SQL e, como a
Single, ela executa consultas que carregam vários objetos.
(GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define o custo de execução de
uma especificação Program Summary como sendo a combinação linear
C open ×N open + C net ×N fetch + C decode ×N decode
, onde C open, C net e C decode, são os pesos relativos das operações open, fetch e decode e
N open, N net e N decode são os números de vezes que estas operações são executadas.
Ele supõe que os pesos C open, C net e C decode são similares e propõe um algoritmo
que transforma uma especificação Program Summary S em um programa que combina as
estratégias Lazy, Single e Decorrelation de forma a minimizar a soma N open+N fetch+N decode
e, portanto, minizar o custo de execução de S .
Para avaliar sua proposta, (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009)implementa uma extensão do Hibernate que aplica o algoritmo de otimização a uma
especificação Program Summary e pré-carrega seu traço. A partir desta extensão, ele
propõe e implementa um benchmark que adota o banco de dados do benchmark TPC-H
(POESS; FLOYD, 2000).
Em comum com esta pesquisa, (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009)
define uma linguagem que permite especificar navegações por objetos e projeta e implementa
um interpretador que executa especificações desta linguagem, pré-carregando os objetos
pelos quais ele navega.
Entretanto, uma diferença fundamental entre (GUÉHIS; GOASDOUÉ-THION;
RIGAUX, 2009) e esta pesquisa é que o primeiro se propõe a reduzir o tempo de pré-
carregamento t p de objetos encontrando as consultas que, quando executadas sequen-
cialmente, minimizam t p, enquanto que esta pesquisa reduz t p executando consultas
concorrentemente.
Outras diferenças importantes são:
• (GUÉHIS; GOASDOUÉ-THION; RIGAUX, 2009) define a sintaxe de Program
Summary a partir da sintaxe de um subconjunto de XPath, sem precisar que
subconjunto é este. Esta pesquisa define a sintaxe de Litoral completamente;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 99/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 100/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 101/162
Capítulo 6. Trabalhos Relacionados 100
As restrições que AutoFetch impõe à estratégia Single evitam, na maioria dos casos,
que ela execute consultas que aumentam o tempo de pré-carregamento ao invés de reduzi-
lo. Entretanto, por adotar apenas uma variação da estratégia Single, o desempenho de
AutoFetch é, provavelmente, pior que o de Program Summaries nos casos em que este últimodetermina que a estratégia Single não é a que minimiza o tempo de pré-carregamento.
Em comum com Program Summaries e Scalpel, AutoFetch aumenta o desempenho
de sistemas baseados em ORMs agrupando consultas que são executadas sequencialmente.
Trata-se, portanto, de um trabalho relacionado, mas que explora uma otimização diferente
da proposta nesta pesquisa.
6.4 Outros Trabalhos sobre Pré-carregamento Especulativo
Esta seção relaciona outros trabalhos sobre pré-carregamento especulativo em
sistemas baseados em ORMs e similares que, assim como AutoFetch, focam em métodos de
especulação. Diferentemente desta pesquisa, nenhum deles pré-carrega objetos executando
consultas concorrentemente.
(HAN; WHANG; MOON, 2005; IBRAHIM; COOK, 2006): classificam estes traba-
lhos nas categorias a seguir.
Baseados em páginas: são aqueles que, tais como os OODBMs (Object-Oriented
Database Management Systems) Orion (KIM et al., 1990) e ObjectStore (LAMB et al.,
1991), pré-carregam objetos que estão armazenados em uma mesma página de memória;
Baseados em padrões de acesso a objetos/páginas: são aqueles que, ao
carregarem um objeto/página, pré-carregam outros objetos/páginas cujos acessos estão
correlacionados com os do primeiro. (PALMER, 1991) é um cache que implementa esta
técnica. (CUREWITZ; KRISHNAN; VITTER, 1993; VITTER; KRISHNAN, 1996) em-
pregam métodos de compressão de dados para identificar correlações. (GARBATOV;
CACHOPO, 2010; GARBATOV et al., 2011) empregam métodos estocásticos;
Baseados em contexto: (BERNSTEIN; PAL; SHUTT, 2000) foi o primeiro
trabalho deste tipo. A seção 2.3 discute o método de especulação que ele propôs, o qual
(HAN et al., 2001; HAN; MOON; WHANG, 2003; HAN; WHANG; MOON, 2005) refinaram
posteriormente.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 102/162
101
7 Conclusão
Esta pesquisa partiu da hipótese de que ORMs podem aumentar o desempenho de
sistemas executando concorrentemente consultas que pré-carregam objetos e se propôs a
desenvolver esta otimização.
As avaliações descritas no capítulo 5 são evidências de que a hipótese é verdadeira e
de que o desenvolvimento da otimização foi bem sucedido. De fato, no benchmark Emeio,
a execução concorrente de consultas reduziu o tempo total de execução em até 69,1%,
ou seja, aumentou a velocidade de execução em até 323,6%. Já no benchmark OO7, o
tempo total de execução foi reduzido em até 59,3%, ou seja, a velocidade de execução foiaumentada em até 245,7%.
Nos dois benchmarks, em todos os cenários que oferecem oportunidades para a
execução concorrente de consultas que pré-carregam objetos, o tempo total de execução com
esta otimização foi menor do que com importantes ORMs industriais, os quais executam
estas consultas apenas sequencialmente. Este resultado é mais uma evidência de que o
desempenho de sistemas baseados em ORMs será maior se estes últimos adotarem a
otimização proposta e desenvolvida nesta pesquisa.
7.1 Contribuições
As contribuições principais desta pesquisa foram:
1. identificar a oportunidade de pré-carregar objetos pelos quais sistemas baseados em
ORMs navegam executando consultas concorrentemente;
2. produzir evidências de que, explorando esta oportunidade, pode-se aumentar signifi-
cativamente o desempenho destes sistemas.
Adicionalmente, a forma como esta pesquisa explorou tal oportunidade produziu
as seguintes contribuições:
3. a DSL Litoral, a qual permite a especificação de navegações iterativas e recursivas
por objetos;
4. o interpretador definidor de Litoral, o qual se aproxima de uma definição formal
desta DSL;
5. o projeto e a implementação do interpretador de Litoral, o qual pode ser facilmente
integrado a ORMs e outros mecanismos de carregamento de objetos;
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 103/162
Capítulo 7. Conclusão 102
6. o benchmark Emeio, voltado para a avaliação de desempenho de navegações em
ORMs;
7. o projeto e a implementação do framework Afluentes (ARAUJO et al., 2014),
o qual permite que sistemas que executam operações de E/S sequencialmente ou
concorrentemente através de primitivas de E/S síncronas ou assíncronas sejam
desenvolvidos com um mesmo modelo de programação.
7.2 Trabalhos Futuros
Possíveis desdobramentos desta pesquisa são:
1. identificar e explorar outras oportunidades de aumentar o desempenho de sistemasbaseados em ORMs através da execução concorrente de consultas;
2. produzir mais evidências de que sistemas baseados em ORMs oferecem oportuni-
dades para pré-carregar os objetos pelos quais eles navegam executando consultas
concorrentemente e que explorando esta oportunidade aumenta-se o desempenho
destes sistemas;
3. evoluir modelos de custos de carregamento de objetos tais como o de ( GUÉHIS;
GOASDOUÉ-THION; RIGAUX, 2009) para levar em conta a concorrência, pois asconsultas que minimizam o tempo de carregamento de objetos quando executadas
sequencialmente podem não gozar desta propriedade quando executadas concorren-
temente.
O segundo desdobramento pode ser conduzido aplicando-se o mesmo método desta
pesquisa, ou seja, implementando benchmarks sintéticos com um ORM mínimo integrado
ao interpretador de Litoral e também com ORMs industriais e, em seguida, comparando
o desempenho das implementações.Uma alternativa consiste em integrar o interpretador de Litoral a um ORM
popular. Apesar desta alternativa demandar um esforço inicial maior, ela tem a grande
vantagem de permitir que a otimização desenvolvida nesta pesquisa seja avaliada com
qualquer sistema baseado no ORM com o qual o interpretador de Litoral foi integrado.
Outra alternativa consiste em registrar as consultas que sistemas baseados em
ORMs executam para pré-carregar objetos e analisar quais delas podem ser executadas
concorrentemente. Por fim, simula-se a execução sequencial e concorrente das consultas. A
partir do tempo total de execução de cada simulação é possível estimar os efeitos que aotimização desenvolvida nesta pesquisa terá sobre os sistemas.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 104/162
103
Referências
ADYA, A. et al. Anatomy of the ado. net entity framework. In: ACM. Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p.877–888. Citado na página 19.
AHO, A. V.; BEERI, C.; ULLMAN, J. D. The theory of joins in relational databases.ACM Transactions on Database Systems (TODS), ACM, v. 4, n. 3, p. 297–314, 1979.Citado 2 vezes nas páginas 27 e 97.
ARAUJO, S. M. d. et al. Afluentes concurrent i/o made easy with lazy evaluation. In:IEEE. Parallel, Distributed and Network-Based Processing (PDP), 2014 22nd Euromicro
International Conference on . [S.l.], 2014. p. 279–287. Citado 3 vezes nas páginas 20, 61e 102.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM , ACM,v. 53, n. 4, p. 50–58, 2010. Citado na página 31.
BERNSTEIN, P. A.; PAL, S.; SHUTT, D. Context-based prefetch–an optimization forimplementing objects on relations. The VLDB Journal , Springer-Verlag, v. 9, n. 3, p.177–189, 2000. Citado 5 vezes nas páginas 17, 30, 31, 83 e 100.
BERTOT, Y.; CASTÉRAN, P. Interactive theorem proving and program development .[S.l.]: Springer Science & Business Media, 2004. Citado 2 vezes nas páginas 20 e 41.
BLAKELEY, J. A. et al. The ado. net entity framework: making the conceptual level real.ACM SIGMOD Record , ACM, v. 35, n. 4, p. 32–39, 2006. Citado na página 19.
BONCZ, P. A.; KWAKKEL, F.; KERSTEN, M. L. High performance support for ootraversals in monet. CWI (Centre for Mathematics and Computer Science), 1995. Citadona página 83.
BOWMAN, I. T.; SALEM, K. Optimization of query streams using semantic prefetching.ACM Transactions on Database Systems (TODS), ACM, v. 30, n. 4, p. 1056–1101, 2005.Citado na página 98.
BOWMAN, I. T.; SALEM, K. Semantic prefetching of correlated query sequences. In:IEEE. Data Engineering, 2007. ICDE 2007. IEEE 23rd International Conference on .[S.l.], 2007. p. 1284–1288. Citado 2 vezes nas páginas 27 e 98.
CAREY, M. J. et al. A status report on the oo7 oodbms benchmarking effort. ACM SIGPLAN Notices , ACM, v. 29, n. 10, p. 414–426, 1994. Citado 2 vezes nas páginas 20e 83.
CAREY, M. J.; DEWITT, D. J.; NAUGHTON, J. F. The 007 benchmark . [S.l.]: ACM,1993. Citado 2 vezes nas páginas 20 e 83.
CASTRO, P.; MELNIK, S.; ADYA, A. Ado. net entity framework: raising the level of abstraction in data programming. In: ACM. Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p. 1070–1072. Citado napágina 19.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 105/162
Referências 104
CLARK, J.; DEROSE, S. et al. Xml path language (xpath). W3C recommendation , v. 16,1999. Citado na página 96.
CUREWITZ, K. M.; KRISHNAN, P.; VITTER, J. S. Practical prefetching via data
compression. ACM SIGMOD Record , ACM, v. 22, n. 2, p. 257–266, 1993. Citado napágina 100.
CURNOW, H. J.; WICHMANN, B. A. A synthetic benchmark. The Computer Journal ,Br Computer Soc, v. 19, n. 1, p. 43–49, 1976. Citado na página 20.
DEURSEN, A. V.; KLINT, P.; VISSER, J. Domain-specific languages: An annotatedbibliography. Sigplan Notices , v. 35, n. 6, p. 26–36, 2000. Citado na página 18.
EISENBERG, A. et al. Sql: 2003 has been published. ACM SIGMoD Record , ACM, v. 33,n. 1, p. 119–126, 2004. Citado na página 17.
FIELDING, R. T.; TAYLOR, R. N. Principled design of the modern web architecture.ACM Transactions on Internet Technology (TOIT), ACM, v. 2, n. 2, p. 115–150, 2002.Citado na página 20.
FOUNDATION, E. Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation . 2008. Disponível em: <http://www.eclipse.org/org/press-release/20080317_Eclipselink.php>. Citado na página 20.
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented Software . Pearson Education, 1994. ISBN 9780321700698. Disponível em: <http://books.google.com.br/books?id=6oHuKQe3TjQC> . Citado na página 28.
GARBATOV, S.; CACHOPO, J. Predicting data access patterns in object-orientedapplications based on markov chains. In: IEEE. Software Engineering Advances (ICSEA),2010 Fifth International Conference on . [S.l.], 2010. p. 465–470. Citado na página 100.
GARBATOV, S. et al. Data access pattern analysis and prediction for object-orientedapplications. INFOCOMP Journal of Computer Science , v. 10, n. 4, p. 1–14, 2011. Citadona página 100.
GERSEN, C. M. ORM Optimization through Automatic Prefetching in WebDSL.Dissertação (Mestrado) — Delft University of Technology, 2013. Citado na página 83.
GEUVERS, H. Proof assistants: History, ideas and future. Sadhana , Springer, v. 34, n. 1,p. 3–25, 2009. Citado 2 vezes nas páginas 20 e 41.
GOSLING, J. et al. The Java Language Specification, Java SE 8 Edition . PearsonEducation, 2014. ISBN 9780133900798. Disponível em: <http://books.google.com.br/books?id=1DaDAwAAQBAJ>. Citado na página 16.
GROUP, J. P. . E. JSR 338: Java TM Persistence API, Version 2.1. 2013. Disponível em:<http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html>.Citado 2 vezes nas páginas 20 e 25.
GUÉHIS, S.; GOASDOUÉ-THION, V.; RIGAUX, P. Speeding-up data-driven applicationswith program summaries. In: ACM. Proceedings of the 2009 International Database Engineering & Applications Symposium . [S.l.], 2009. p. 66–76. Citado 5 vezes nas páginas19, 96, 97, 98 e 102.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 106/162
Referências 105
GUERRAOUI, R.; KAPALKA, M.; VITEK, J. Stmbench7: A benchmark forsoftware transactional memory. In: Proceedings of the 2Nd ACM SIGOPS/EuroSys European Conference on Computer Systems 2007 . New York, NY, USA: ACM,2007. (EuroSys ’07), p. 315–324. ISBN 978-1-59593-636-3. Disponível em:
<http://doi.acm.org/10.1145/1272996.1273029> . Citado na página 83.
HAN, W.-S.; MOON, Y.-S.; WHANG, K.-Y. Prefetchguide: capturing navigationalaccess patterns for prefetching in client/server object-oriented/object-relational dbmss.Information Sciences , Elsevier, v. 152, p. 47–61, 2003. Citado na página 100.
HAN, W.-S.; WHANG, K.-Y.; MOON, Y.-S. A formal framework for prefetching based onthe type-level access pattern in object-relational dbmss. Knowledge and Data Engineering,IEEE Transactions on , IEEE, v. 17, n. 10, p. 1436–1448, 2005. Citado 2 vezes naspáginas 83 e 100.
HAN, W.-S. et al. Prefetching based on the type-level access pattern in object-relationaldbmss. In: IEEE. Data Engineering, 2001. Proceedings. 17th International Conference on .[S.l.], 2001. p. 651–660. Citado na página 100.
HAROLD, E. Java I/O . O’Reilly Media, 2006. ISBN 9781449390884. Disponível em:<http://books.google.com.br/books?id=42etT\_9-\_9MC>. Citado na página 61.
HOVEMEYER, D.; SPACCO, J.; PUGH, W. Evaluating and tuning a static analysis tofind null pointer bugs. In: ACM. ACM SIGSOFT Software Engineering Notes . [S.l.], 2005.v. 31, n. 1, p. 13–19. Citado na página 32.
IBRAHIM, A.; COOK, W. R. Automatic prefetching by traversal profiling in objectpersistence architectures. ECOOP 2006–Object-Oriented Programming , Springer BerlinHeidelberg, p. 50–73, 2006. Citado 7 vezes nas páginas 19, 34, 83, 92, 93, 99 e 100.
IBRAHIM, A.; WIEDERMANN, B.; COOK, W. R. Coordinating database andprogramming language research. In: CITESEER. ESSAY SUBMITTED TO CIDR 2009 MONTEREY, CALIFORNIA USA. [S.l.], 2009. Citado na página 30.
JR, R. L. B. et al. Safe nondeterminism in a deterministic-by-default parallel language. In:ACM. ACM SIGPLAN Notices . [S.l.], 2011. v. 46, n. 1, p. 535–548. Citado na página 83.
KEITH, M.; SCHINCARIOL, M. Pro jpa 2. Mastering the Java Persistence API , Springer,2009. Citado na página 20.
KIM, W. et al. Architecture of the orion next-generation database system. Knowledge and Data Engineering, IEEE Transactions on , IEEE, v. 2, n. 1, p. 109–124, 1990. Citado napágina 100.
LAMB, C. et al. The objectstore database system. Communications of the ACM , ACM,v. 34, n. 10, p. 50–63, 1991. Citado na página 100.
LEA, D. A java fork/join framework. In: ACM. Proceedings of the ACM 2000 conference on Java Grande . [S.l.], 2000. p. 36–43. Citado 2 vezes nas páginas 61 e 62.
LI, Y. G. et al. Xoo7: applying oo7 benchmark to xml query processing tool. In:ACM. Proceedings of the tenth international conference on Information and knowledge management . [S.l.], 2001. p. 167–174. Citado na página 83.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 107/162
Referências 106
LINSKEY, P. C.; PRUD’HOMMEAUX, M. An in-depth look at the architecture of anobject/relational mapper. In: ACM. Proceedings of the 2007 ACM SIGMOD international conference on Management of data . [S.l.], 2007. p. 889–894. Citado na página 19.
MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specificlanguages. ACM computing surveys (CSUR), ACM, v. 37, n. 4, p. 316–344, 2005. Citado2 vezes nas páginas 32 e 71.
MEYEROVICH, L. A. et al. Flapjax: a programming language for ajax applications. In:ACM. ACM SIGPLAN Notices . [S.l.], 2009. v. 44, n. 10, p. 1–20. Citado na página 35.
MILNER, R. The definition of standard ML: revised . [S.l.]: MIT press, 1997. Citado napágina 41.
NANZ, S.; WEST, S.; SILVEIRA, K. S. D. Examining the expert gap in parallel
programming. In: Euro-Par 2013 Parallel Processing . [S.l.]: Springer, 2013. p. 434–445.Citado na página 18.
O’NEIL, E. J. Object/relational mapping 2008: hibernate and the entity data model(edm). In: ACM. Proceedings of the 2008 ACM SIGMOD international conference on Management of data . [S.l.], 2008. p. 1351–1356. Citado 2 vezes nas páginas 19 e 20.
PALMER, M. S. zdonik,“fido: A cache that learns to fetch,”. In: Proceedings of the 1991International Conference on Very Large Databases . [S.l.: s.n.], 1991. Citado na página100.
PARR, T. The definitive ANTLR reference: building domain-specific languages . [S.l.]:
Pragmatic Bookshelf, 2007. Citado na página 74.
PARR, T. J.; QUONG, R. W. Antlr: A predicated-ll (k) parser generator. Software:Practice and Experience , Wiley Online Library, v. 25, n. 7, p. 789–810, 1995. Citado napágina 74.
PEIERLS, T. et al. Java Concurrency in Practice . Pearson Education, 2006. ISBN9780132702256. Disponível em: <http://books.google.com.br/books?id=EK43StEVfJIC>.Citado na página 61.
PINTER, C. A Book of Abstract Algebra: Second Edition . Dover Publications, 2012. ISBN
9780486134796. Disponível em: <https://books.google.com.br/books?id=qviuEUavE4IC>.Citado na página 115.
POESS, M.; FLOYD, C. New tpc benchmarks for decision support and web commerce.ACM Sigmod Record , ACM, v. 29, n. 4, p. 64–71, 2000. Citado na página 97.
REYNOLDS, J. C. Definitional interpreters for higher-order programming languages.In: ACM. Proceedings of the ACM annual conference-Volume 2 . [S.l.], 1972. p. 717–740.Citado 2 vezes nas páginas 20 e 41.
ROY, P. V. et al. Programming paradigms for dummies: What every programmer should
know. New computational paradigms for computer music , IRCAM/Delatour France,v. 104, 2009. Citado 2 vezes nas páginas 41 e 61.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 108/162
Referências 107
RYMAN, A. Simple object access protocol (soap) and web services. In: IEEE COMPUTERSOCIETY. Software Engineering, International Conference on . [S.l.], 2001. p. 0689–0689.Citado na página 20.
SCOTT, M. Programming Language Pragmatics . Morgan Kaufmann, 2006.(Programming Language Pragmatics, v. 1). ISBN 9780126339512. Disponível em:<http://books.google.com.br/books?id=TLbvODF1uIEC>. Citado na página 62.
SIPELSTEIN, J. M.; BLELLOCH, G. E. Collection-oriented languages. Proceedings of the IEEE , IEEE, v. 79, n. 4, p. 504–523, 1991. Citado na página 32.
SUBRAMANIAM, V. Functional Programming in Java: Harnessing the Power of Java 8 Lambda Expressions . Pragmatic Programmers, LLC, 2014. (Pragmaticprogrammers). ISBN 9781937785468. Disponível em: <http://books.google.com.br/books?id=4Y7TngEACAAJ>. Citado na página 63.
TANENBAUM, A. Modern Operating Systems . Pearson Prentice Hall, 2008. (GOALSeries). ISBN 9780136006633. Disponível em: <http://books.google.com.br/books?id=DxNiQgAACAAJ>. Citado na página 22.
THOMSON, B.; BRUCKNER, J.; BRUCKNER, A. Elementary Real Analysis, Second Edition . Createspace Independent Pub, 2008. ISBN 9781434843678. Disponível em:<http://books.google.com.br/books?id=vA9d57GxCKgC> . Citado 3 vezes nas páginas50, 57 e 115.
VITTER, J. S.; KRISHNAN, P. Optimal prefetching via data compression. Journal of the
ACM (JACM), ACM, v. 43, n. 5, p. 771–793, 1996. Citado na página 100.WALDO, J. Remote procedure calls and java remote method invocation. Concurrency,IEEE , IEEE, v. 6, n. 3, p. 5–7, 1998. Citado na página 20.
WELC, A.; JAGANNATHAN, S.; HOSKING, A. Safe futures for java. In: ACM. ACM SIGPLAN Notices . [S.l.], 2005. v. 40, n. 10, p. 439–453. Citado na página 83.
WITT, D. J. D. et al. Parallelizing oodbms traversals: a performance evaluation. the VLDB Journal , Springer, v. 5, n. 1, p. 3–18, 1996. Citado na página 83.
ZIAREK, L. et al. A uniform transactional execution environment for java. In: ECOOP
2008–Object-Oriented Programming . [S.l.]: Springer, 2008. p. 129–154. Citado na página83.
ZYL, P. V. Performance investigation into selected object persistence stores . Dissertação(Mestrado) — University of Pretoria, 2010. Citado 2 vezes nas páginas 83 e 92.
ZYL, P. V.; KOURIE, D. G.; BOAKE, A. Comparing the performance of objectdatabases and orm tools. In: SOUTH AFRICAN INSTITUTE FOR COMPUTERSCIENTISTS AND INFORMATION TECHNOLOGISTS. Proceedings of the 2006 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries . [S.l.], 2006. p. 1–11. Citado na
página 83.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 109/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 110/162
109
APÊNDICE A – Emeio
A.1 Classes
1 import jav a . u t i l . Date ;
2 import java . ut i l . Lis t ;
3
4 c l a s s Message {
5 p ri v at e i n t i d ;
6 private Date date ;
7 private S t r i n g s u b j e c t ;
8 private Str ing body ;
9 private User sender ;
10 private L i s t<U se r> r e c i p i e n ts ;
11 private List <File> attachments ;
12 private L ist<Message> re pl ie s ;
13 private List<Tag> tags ;
14
15 void s e t I d ( i n t i d ) {
16 t h i s . i d = i d ;
17 }
18
19 i nt g e t I d ( ) {
20 return i d ;
21 }
22
23 // Demais m ét od os s e t e g e t
24 }
25
26 c l a s s U s e r {
27 p ri v at e i n t i d ;
28 private Str ing name;
29 private F i l e p i c t u r e ;
30
31 // Mét odos s e t e g e t
32 }
33
34 c l a s s F i l e {
35 p ri v at e i n t i d ;
36 private Str ing name;
37 private MediaType mediaType ;
38
39 // Mét odos s e t e g e t
40 }
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 111/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 112/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 113/162
112
APÊNDICE B – OO7
B.1 Classes
1 import java . ut i l . Lis t ;
2
3 c l a s s CompositePart {
4 p riva te lo ng compositePartId ;
5 p riva te lo ng buildDate ;
6 p ri v at e i n t d e s i g n Id ;
7 private S t r i n g t y pe ;
8 private AtomicPart rootPart ;
9
10 // Mét odos s e t e g e t
11 }
12
13 c l a s s AtomicPart {
14 p riva te lo ng atomicPartId ;
15 p riva te lo ng buildDate ;
16 p ri v at e i n t d e s i g n Id ;
17 private S t r i n g t y pe ;
18 private List <Connection> toConnections ;
19
20 // Mét odos s e t e g e t
21 }
22
23 c l a s s Connection {
24 p riva te lo ng c o n n e c t i o n Id ;
25 p ri v at e i n t l engt h ;
26 private S t r i n g t y pe ;
27 private AtomicPart to ;
28
29 // Mét odos s e t e g e t
30 }
31
32 c l a s s Assembly {
33 p riva te lo ng assembl yId ;
34 p riva te lo ng buildDate ;
35 p ri v at e i n t d e s i g n Id ;
36 private S t r i n g t y pe ;
37
38 // Mét odos s e t e g e t
39 }
40
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 114/162
APÊNDICE B. OO7 113
41 c l a s s BaseAssembly extends Assembly {
42 private Lis t<CompositePart> componentsP rivate ;
43
44 // Mét odos s e t e g e t
45 }46
47 c l a s s ComplexAssembly extends Assembly {
48 private Lis t<JpaAssembly> subAs sembli es ;
49
50 // Mét odos s e t e g e t
51 }
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 115/162
APÊNDICE B. OO7 114
B.2 Tabelas
Figura 78 – Tabelas de OO7.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 116/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 117/162
APÊNDICE C. Demonstrações 116
18 Proof .
19 un fo ld nonDecNatSeq .
20 un fo ld nonDecNatSeq2 .
21 i n t r o s .
22 i n d u c t i o n n ’ .23 {
24 a s s er t ( n = 0 ) .
25 {
26 omega.
27 }
28 r e w r i t e H1 .
29 aut o .
30 }
31 {
32 a s s e r t ( n <= n ’ \ / n = S n ’ ) .33 {
34 omega.
35 }
36 d e s t r u c t H1 .
37 {
38 a s s e r t ( f n <= f n ’ ) .
39 {
40 aut o .
41 }
42 a s s e r t ( f n ’ <= f ( S n ’ ) ) .43 {
44 aut o .
45 }
46 omega.
47 }
48 {
49 r e w r i t e H1 . a ut o .
50 }
51 }
52 Qed .53
54 Theorem nonDecBndNatSeqConvSeq :
55 f o r a l l f , no nDecNa tS eq f −> bndNatSeq f −> convSeq f .
56 Proof .
57 unf old bndNatSeq .
58 unfo ld convSeq .
59 unfo ld consSeq .
60 u n f o l d s u f f S e q .
61 i n t r o s .
62 d e s t r u c t H0 a s [ L ] .63 i n d u ct i o n L .
64 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 118/162
APÊNDICE C. Demonstrações 117
65 e x i st s 0 .
66 i n t r o s .
67 a s s e r t ( f ( 0 + n ) <= 0 ) .
68 {
69 auto .70 }
71 a s s e r t ( f ( 0 + S n ) <= 0 ) .
72 {
73 auto .
74 }
75 omega.
76 }
77 {
78 d es t ru ct ( c l a s s i c ( f o r a l l n : nat , f n <= L ) ) .
79 {80 auto .
81 }
82 {
83 a s s e r t ( e x i s t s N, ~ f N <= L ) .
84 {
85 apply not_all_ex_not .
86 aut o .
87 }
88 d e s t r u c t H2 a s [ N ] .
89 e x i s t s N.90 i n t r o s .
91 a s s e r t ( f N <= f (N + n ) ) .
92 {
93 app ly nonDecNatSeqNonDecNatSeq2 in H.
94 unf old nonDecNatSeq2 in H.
95 a s s e r t (N <= N + n −> f N <= f (N + n ) ) .
96 {
97 aut o .
98 }
99 apply H.100 omega.
101 }
102 a s s e r t ( f (N + n ) <= f (N + S n ) ) .
103 {
104 unf old nonDecNatSeq in H.
105 a s s e r t ( f (N + n ) <= f ( S (N + n ) ) ) .
106 {
107 aut o .
108 }
109 a s s e r t ( S (N + n ) = N + S n ) .110 {
111 omega.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 119/162
APÊNDICE C. Demonstrações 118
112 }
113 r e w r i t e <− H5 .
114 aut o .
115 }
116 a s s e r t ( f (N + S n ) <= S L ) .117 {
118 aut o .
119 }
120 omega.
121 }
122 }
123 Qed .
C.3 ListSeq1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import L i s t . Import L i s tN o ta t i o n s .
4
5 Require Import NatSeq .
6 Require Import Seq .
7
8 Definition L i s tS e q E := S eq ( l i s t E) .
9
10 Definition s u f f E q L i s t E ( l l ’ : l i s t E) := e x i s t s l ’ ’ , l ’ = l ’ ’ ++ l .
11
12 Definition n o nD ec Li st Se q E ( f : L i s t S e q E ) :=
13 f o r a l l n , s u ff E qL i st ( f n ) ( f ( S n ) ) .
14
15 Definition l en gt hS eq E ( f : L i st S eq E) n := l e ng t h ( f n ) .
16
17 Definition l e n g th Bn d L i stS e q E ( f : L i s tS e q E) : = b n dN atSe q ( l e n g th S e q f ) .
18
19
Theorem nonDecListSeqNonDecLengthSeq :20 f o r a l l E ( f : L i s tS e q E) , n on De cL is tS eq f −> nonDecNatSeq ( lengthSeq f ) .
21 Proof .
22 unfo ld nonDecListSeq .
23 un fo ld nonDecNatSeq .
24 u n fo l d s u f f E q L i s t .
25 u n f o l d l e n g th S e q .
26 i n t r o s .
27 a s s e r t ( e x i s t s l ’ ’ , f ( S n ) = l ’ ’ ++ f n ) .
28 {
29
aut o .30 }
31 d e s t r u c t H0 .
32 r e w r i t e H0 .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 120/162
APÊNDICE C. Demonstrações 119
33 a s s e r t ( l e n gt h ( x ++ f n ) = l e ng t h x + l e n gt h ( f n ) ) .
34 {
35 apply app_length .
36 }
37 omega.38 Qed .
39
40 Theorem l en gt hZ er oE mp ty Li st : f o r a l l E ( l : l i s t E ) , l e n gt h l = 0 −> l = [ ] .
41 Proof .
42 i n t r o s .
43 u n f o l d l e n g t h in H.
44 d e s t r u ct l .
45 {
46 aut o .
47 }48 {
49 congruen ce .
50 }
51 Qed .
52
53 Theorem nonDecLengthBndListSeqConv :
54 f o r a l l E ( f : L is tS eq E) ,
55 nonDecListSeq f −> l e n gth Bn d L i stS e q f −> convSeq f .
56 Proof .
57 unfo ld convSeq .58 unfo ld consSeq .
59 u n f o l d s u f f S e q .
60 i n t r o s .
61 a s s e r t ( c o nv Se q ( l e n gt h S e q f ) ) .
62 {
63 app ly nonDecBndNatSeqConvSeq .
64 apply nonDecListSeqNonDecLengthSeq .
65 aut o .
66 aut o .
67 }68 u n f o l d c on vS eq in H1 .
69 u n f o l d c o ns S e q in H1 .
70 u n fo l d s u f f S e q in H1 .
71 u n f o l d l e n gt h S e q in H1 .
72 d e s t r u c t H1 as [ N ] .
73 e x i s t s N.
74 i n t r o s .
75 a s s e r t ( e x i s t s l ’ ’ , f (N + S n ) = l ’ ’ ++ f (N + n ) ) .
76 {
77 a s s e r t ( e x i s t s l ’ ’ , f ( S (N + n ) ) = l ’ ’ ++ f (N + n ) ) .78 {
79 unfo ld nonDecListSeq in H.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 121/162
APÊNDICE C. Demonstrações 120
80 u n fo l d s u f f E q L i s t in H.
81 auto .
82 }
83 a s s e r t ( S (N + n ) = N + S n ) .
84 omega.85 r e w r i t e <− H3 .
86 aut o .
87 }
88 d e s tr u c t H2 a s [ l ’ ’ ] .
89 a s s e r t ( l ’ ’ = [ ] ) .
90 {
91 a s s e r t ( l e n gt h l ’ ’ = 0 ) .
92 {
93 a s s e r t ( l e ng t h ( f (N + n ) ) = l e ng t h ( f (N + S n ) ) ) .
94 {95 aut o .
96 }
97 r e w r i t e H2 in H3 .
98 r e wr i te a p p_ le ng th in H3 .
99 omega.
100 }
101 apply lengthZeroEmptyList .
102 aut o .
103 }
104 r e w r i t e H3 in H2 .105 auto .
106 Qed .
C.4 Lim
1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import Omega.
4
5 Require Import Seq .
6
7 Definition l im Y ( f : Seq Y) L : = e x i s t s N, f o r a l l n , s u ff S eq f N n = L .
8
9 Theorem s uf f S eq L im :
10 f o r a l l Y ( f : Seq Y) N L , l im ( s u ff S eq f N) L −> lim f L .
11 Proof .
12 u n f o l d l i m .
13 u n f o l d s u f f S e q .
14
i n t r o s .15 d e s t r u c t H a s [ N ’ ] .
16 e x i s t s (N + N ’ ) .
17 i n t r o s .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 122/162
APÊNDICE C. Demonstrações 121
18 a s s e r t (N + N ’ + n = N + ( N’ + n ) ) .
19 {
20 omega.
21 }
22 r e w r i t e H0 .23 auto .
24 Qed .
C.5 ListOptionSeq
1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import C l a s s i c a l .
4
Require Import L i s t . Import L i s tN o ta t i o n s .5
6 Require Import Lim.
7 Require Import ListS eq .
8 Require Import Seq .
9
10 Definition L i s tO p t io n S e q E := S eq ( o p t i o n ( l i s t E) ) .
11
12 Definition s u f f L i s t O p t i on E ( l o l o ’ : o p ti o n ( l i s t E ) ) :=
13 match lo ’ with
14
| None => lo = None15 | Some [ ] => lo = Some [ ]
16 | Some l ’ => e x i s t s l e , l o = Some l /\ l ’ = e : : l
17 end .
18
19 Definition d e c L i st O p ti o nS e q E ( f : L i s tO p ti o n Se q E ) :=
20 f o r a l l n , s u ff L is t Op t io n ( f ( S n ) ) ( f n ) .
21
22 Theorem decOptionListSeqLim :
23 f o r a l l E ( f : L i st Op t io nS eq E ) ,
24
d e c L i s tOp t i o n S e q f −> l i m f None \ / l i m f ( Some [ ] ) .25 Proof .
26 i n t r o s .
27 d e s t r u ct ( c l a s s i c ( e x i s t s N , f N = None ) ) .
28 {
29 l e f t .
30 u n f o l d l i m .
31 u n f o l d s u f f S e q .
32 d e s t r u c t H0 a s [ N ] .
33 e x i s t s N.
34
i n d u ct i o n n .35 {
36 a s s e r t (N + 0 = N ) .
37 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 123/162
APÊNDICE C. Demonstrações 122
38 aut o .
39 }
40 r e w r i t e H1 .
41 auto .
42 }43 {
44 a s s e r t (N + S n = S (N + n ) ) .
45 {
46 omega.
47 }
48 r e w r i t e H1 .
49 u n f o l d d e c L i s tOp t i o n S e q in H.
50 u n fo l d s u f f L i s t O p t i on in H.
51 s p e c i a l i z e H with (N + n ) .
52 r e w r i t e IHn in H.53 auto .
54 }
55 }
56 {
57 a s s e r t ( f o r a l l n , f n <> None ) .
58 {
59 i n t r o s .
60 d e s t r u c t ( f n ) e qn : E1 .
61 {
62 congruen ce .63 }
64 {
65 u n f o l d n ot in H0 .
66 a s s e r t ( e x i s t s N : n at , f N = None ) .
67 {
68 e x i st s n .
69 aut o .
70 }
71 c o n t r a d i c t i o n .
72 }73 }
74
75 d e s t r u c t ( f 0 ) e qn : E1 .
76 {
77 a ss e rt (
78 f o r a l l n , e x i s t s l ’ , f n = Some l ’ /\ l e ng th l ’ = l en gt h l − n
79 ) .
80 {
81 i n d u ct i o n n .
82 {83 e x i s t s l .
84 a s s e r t ( l en g th l − 0 = l e ng t h l ) .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 124/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 125/162
APÊNDICE C. Demonstrações 124
132 d e s t r u c t IHn .
133 d e s t r u c t H6 .
134 i n j e c t i o n H6 .
135 i n t r o s .
136 r e w r i t e <− H4 .137 r e w r i t e <− H7 .
138 r e w r i t e <− H8 .
139 s impl .
140 omega.
141 }
142 }
143 }
144 {
145 congruenc e .
146 }147 }
148 }
149
150 {
151 r i g h t .
152 u n f o l d l i m .
153 e x i s t s ( l e ng t h l ) .
154 i n t r o s .
155 s p e c i a l i z e H2 with ( l en g th l + n ) .
156 d e s t r u c t H2 .157 d e s t r u c t H2 .
158 a s s e r t ( l e ng t h x = 0 ) .
159 {
160 omega.
161 }
162 apply lengthZeroEmptyList in H4 .
163 r e w r i t e H4 in H2 .
164 u n f o l d s u f f S e q .
165 aut o .
166 }167 }
168 {
169 congruen ce .
170 }
171 }
172 Qed .
173
174 Theorem d e cO p ti o n L is tS u f f S eq L i m :
175 f o r a l l E ( f : L i st Op t io nS eq E) N,
176 d e cL i s tO p t io n S eq ( s u f f S e q f N) −> l i m f None \ / l i m f ( Some [ ] ) .177 Proof .
178 i n t r o s .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 126/162
APÊNDICE C. Demonstrações 125
179 apply decOptionListSeqLim in H.
180 d e s t r u c t H .
181 {
182 l e f t .
183 a p pl y s u f f S eq L i m with N.184 aut o .
185 }
186 {
187 r i g h t .
188 a p pl y s u f f S eq L i m with N.
189 aut o .
190 }
191 Qed .
192
193 Theorem hasDecOptionListSuffSeqLim :194 f o r a l l E ( f : L i st Op t io nS eq E ) ,
195 ( e x i s t s N, d e cL i s tO p t io n S eq ( s u f f S e q f N) ) −> l i m f None \ /
196 l im f (Some [ ] ) .
197 Proof .
198 i n t r o s .
199 d e s t r u ct H a s [ N ] .
200 a p p ly d e c O p ti o n L i s tSu f f S e q L im with N.
201 auto .
202 Qed .
C.6 Sublist
1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import L i s t . Import L i s tN o ta t i o n s .
4 Require Import Omega.
5
6 Require Import ListS eq .
7
Require Import NatSeq .8 Require Import Seq .
9
10 Definition R e l E : = E −> E −> bool .
11
12 Definition r e f l E ( f : Rel E) := f o r a l l e , f e e = tr ue .
13
14 Definition symm E ( f : Rel E ) := f o r a l l e e ’ , f e e ’ = f e ’ e .
15
16 Definition t r an s E ( f : Rel E ) :=
17
f o r a l l e e ’ e ’ ’ , f e e ’ = t r ue −> f e ’ e ’ ’ = f e e ’ ’ .18
19 Definition e q ui E ( f : Rel E) := r e f l f /\ symm f /\ t r an s f .
20
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 127/162
APÊNDICE C. Demonstrações 126
21 Fixpoint c ou nt E ( r : Rel E ) l e :=
22 match l with
23 | [ ] => 0
24 | e ’ : : l ’ =>
25 l e t co un t ’ := c ou nt r l ’ e in
26 i f r e e ’ then S count ’ e l s e count ’
27 end .
28
29 Definition s u b l is t E ( r : Rel E) l l ’ :=
30 f o r a l l e , co un t r l e <= co un t r l ’ e .
31
32 Theorem t a i l S u bl i s t :
33 f o r a l l E ( r : Rel E) e l l ’ , s u b l is t r ( e : : l ) l ’ −> s u b l i s t r l l ’ .
34 Proof .
35 u nf ol d s u b l i s t .36 i n t r o s .
37 s p e c i a l i z e H with e0 .
38 s impl in H.
39 d e s t r u ct ( r e 0 e ) .
40 {
41 omega.
42 }
43 {
44 aut o .
45 }46 Qed .
47
48 Fixpoint remove E ( r : R el E ) l e :=
49 match l with
50 | [ ] => [ ]
51 | e ’ : : l ’ =>
52 l e t l ’ ’ := re mo ve r l ’ e in
53 i f r e e ’ then l ’ ’ e l s e e ’ : : l ’ ’
54 end .
55
56 Theorem lengthCountRemove :
57 f o r a l l E ( r : Rel E) l e , l en gt h l = count r l e + le ng th ( remove r l e ) .
58 Proof .
59 i n t r o s .
60 i n d u ct i o n l .
61 {
62 aut o .
63 }
64 {
65 s impl .66 d e s t r u ct ( r e a ) .
67 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 128/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 129/162
APÊNDICE C. Demonstrações 128
115 s impl .
116 d e s t r u ct ( r e a ) e qn : E1 .
117 {
118 s p l i t .
119 {120 i n t r o s .
121 d e s t r u ct H .
122 u n fo l d t r a ns in H1 .
123 s p e c i a l i z e H1 with e a e ’ .
124 a s s e r t ( r a e ’ = r e e ’ ) .
125 {
126 aut o .
127 }
128 r e w r i t e H0 in H2 .
129 un fo ld symm in H.130 s p e c i a l i z e H with e ’ a .
131 r e w r i t e H2 in H.
132 r e w r i t e H .
133 d e s t r u c t I H l .
134 aut o .
135 }
136 {
137 d e s t r u c t I H l .
138 aut o .
139 }140 }
141 {
142 s impl .
143 d e s t r u c t ( r e ’ a ) e qn : E2 .
144 {
145 s p l i t .
146 {
147 d e s t r u c t I H l .
148 aut o .
149 }150 {
151 i n t r o s .
152 d e s t r u c t H .
153 u n f ol d t r a ns in H1 .
154 s p e c i a l i z e H1 with e e ’ a .
155 a s s er t ( r e ’ a = r e a ) .
156 {
157 auto .
158 }
159 congruen ce .160 }
161 }
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 130/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 131/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 132/162
APÊNDICE C. Demonstrações 131
256 {
257 apply removeCount .
258 aut o .
259 aut o .
260 }261 omega.
262 }
263 {
264 a s s e r t ( c ou nt r ( remove r l e ) e0 = co un t r l e0 ) .
265 {
266 apply removeCount .
267 aut o .
268 aut o .
269 }
270 r e w r i t e H10 .271 a s s e r t ( c ou nt r ( remove r l ’ e ) e0 = c oun t r l ’ e0 ) .
272 {
273 apply removeCount .
274 aut o .
275 aut o .
276 }
277 r e w r i t e H11 .
278 u nf ol d s u b l i s t in H1’ .
279 s p e c i a l i z e H1 ’ with e0 .
280 omega.281 }
282 }
283
284 a s s e r t ( l e n gt h ( remove r l e ) <= l e n gt h ( remove r l ’ e ) ) .
285 aut o .
286 omega.
287 }
288 }
289 }
290 Qed .291
292 Theorem s u b l i s t L e ng t h L e :
293 f o r a l l E ( r : Rel E) l l ’ ,
294 e qu i r −> s u b l i s t r l l ’ −> l e n g t h l <= l e n g t h l ’ .
295 Proof .
296 i n t r o s .
297 a p p ly s u b l i s tL e n g th L e In d with ( n := l e ng t h l ) ( r := r ) .
298 auto .
299 auto .
300 auto .301 Qed .
302
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 133/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 134/162
APÊNDICE C. Demonstrações 133
350 aut o .
351 }
352 Qed .
353
354 Theorem appCount :355 f o r a l l E ( r : Rel E) l l ’ e ,
356 c ou nt r ( l ++ l ’ ) e = co un t r l e + co un t r l ’ e .
357 Proof .
358 i n d u ct i o n l .
359 {
360 i n t r o s .
361 aut o .
362 }
363 {
364 i n t r o s .365 s p e c i a l i z e I Hl with l ’ e .
366 r e w r i t e <− app_comm_cons .
367 u n f o l d c o un t .
368 f o l d c o un t .
369 d e s t r u ct ( r e a ) .
370 {
371 omega.
372 }
373 {
374 auto .375 }
376 }
377 Qed .
378
379 Theorem appCountZero :
380 f o r a l l E ( r : Rel E) l l ’ e ,
381 c ou nt r ( l ++ l ’ ) e = 0 −> count r l e = 0 /\ count r l ’ e = 0.
382 Proof .
383 i n t r o s .
384 rew rit e appCount in H.385 omega.
386 Qed .
387
388 Definition c on ta in s E ( r : Rel E) l e :=
389 match count r l e with
390 | 0 => f a l s e
391 | _ => true
392 end .
393
394 Theorem sameContains :395 f o r a l l E ( r : Rel E) l e e ’ ,
396 t r an s r −> r e e ’ = t r ue −> c o nt ai ns r l e = c on ta in s r l e ’ .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 135/162
APÊNDICE C. Demonstrações 134
397 Proof .
398 i n t r o s .
399 u n f o l d c o n t a i n s .
400 rew rit e sameCount with ( e ’ := e ’ ) .
401 auto .402 auto .
403 auto .
404 Qed .
405
406 Theorem c o n ta i n s Fa l s eCo u n tZ e r o :
407 f o r a l l E ( r : Rel E) l e ,
408 c on ta in s r l e = f a l s e −> count r l e = 0 .
409 Proof .
410 i n t r o s .
411 u n fo l d c o n t ai n s in H.412 d e st r u ct ( c ou nt r l e ) .
413 {
414 aut o .
415 }
416 {
417 congruen ce .
418 }
419 Qed .
420
421 Theorem containsTrueCountNotZero :422 f o r a l l E ( r : Rel E) l e ,
423 c on ta in s r l e = t ru e −> c ou nt r l e <> 0 .
424 Proof .
425 i n t r o s .
426 u n fo l d c o n t ai n s in H.
427 d e st r u ct ( c ou nt r l e ) .
428 {
429 congruen ce .
430 }
431 {432 aut o .
433 }
434 Qed .
435
436 Theorem a pp Co n ta in s Fa l se :
437 f o r a l l E ( r : Rel E) l l ’ e ,
438 t r an s r −> c o n t ai n s r ( l ++ l ’ ) e = f a l s e −>
439 c on ta in s r l e = f a l s e / \ c on ta in s r l ’ e = f a l s e .
440 Proof .
441 i n t r o s .442 u n f o l d c o n t a i n s .
443 a p p ly c o n ta i n s Fa l s eCo u n tZ e r o in H0 .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 136/162
APÊNDICE C. Demonstrações 135
444 apply appCountZero in H0 .
445 d e s t r u c t H0 .
446 r e w r i t e H0 .
447 r e w r i t e H1 .
448 auto .449 Qed .
450 (∗ Outros ∗)
C.7 LitoralFacts
1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import Peano_dec .
4
Require Import S tr i n g .5
6 Require Import L i t o r a l .
7 Require Import S u b l i s t .
8
9 Theorem s t rE qE q ui : e q u i s t rE q .
10 Proof .
11 u n f o l d e q ui .
12 s p l i t .
13 {
14
u n fo ld r e f l .15 i n t r o s .
16 u n f o l d s tr Eq .
17 d e s t r u c t ( s t r i ng _ d e c e e ) .
18 {
19 auto .
20 }
21 {
22 congruen ce .
23 }
24
}25 {
26 s p l i t .
27 {
28 un fo ld symm.
29 i n t r o s .
30 u n f o l d s tr Eq .
31 d e s tr u c t ( s t r i n g _ d e c e e ’ ) .
32 {
33 d e s t r u c t ( s t r i ng _ d e c e ’ e ) .
34
{35 aut o .
36 }
37 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 137/162
APÊNDICE C. Demonstrações 136
38 congruen ce .
39 }
40 }
41 {
42 d e s t r u c t ( s t r i ng _ d e c e ’ e ) .43 {
44 congruen ce .
45 }
46 {
47 aut o .
48 }
49 }
50 }
51 {
52 u n f o l d t r a n s .53 i n t r o s .
54 u n f o l d s tr Eq .
55 u n f o l d s t rE q in H.
56 d e s t r u c t ( s t r i ng _ d ec e ’ e ) .
57 {
58 r e w r i t e e 0 .
59 aut o .
60 }
61 {
62 d e s tr u c t ( s t r i n g _ d e c e e ’ ) .63 {
64 congruen ce .
65 }
66 {
67 congruen ce .
68 }
69 }
70 }
71 }
72 Qed .73
74 Theorem natEqEqui : equi natEq .
75 Proof .
76 u n f o l d e q ui .
77 s p l i t .
78 {
79 u n fo ld r e f l .
80 i n t r o s .
81 unfo l d natEq .
82 d e s tr u c t ( eq _n at_d ec e e ) .83 {
84 auto .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 138/162
APÊNDICE C. Demonstrações 137
85 }
86 {
87 congruen ce .
88 }
89 }90 {
91 s p l i t .
92 {
93 un fo ld symm.
94 i n t r o s .
95 unfo ld natEq .
96 des tru ct (eq_nat_dec e e ’ ) .
97 {
98 d e s tr u c t (e q_ na t_ de c e ’ e ) .
99 {100 aut o .
101 }
102 {
103 congruen ce .
104 }
105 }
106 {
107 d e s tr u c t (e q_ na t_ de c e ’ e ) .
108 {
109 congruen ce .110 }
111 {
112 aut o .
113 }
114 }
115 }
116 {
117 u n f o l d t r a n s .
118 i n t r o s .
119 unfo ld natEq .120 unfo ld natEq in H.
121 d e s tr u c t ( e q_ na t_ de c e ’ e ) .
122 {
123 r e w r i t e e 0 .
124 aut o .
125 }
126 {
127 des tru ct ( eq_nat_dec e e ’ ) .
128 {
129 congruen ce .130 }
131 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 139/162
APÊNDICE C. Demonstrações 138
132 congruen ce .
133 }
134 }
135 }
136 }137 Qed .
138
139 Theorem c la s s Eq E q ui : e q u i c l a s s E q .
140 Proof .
141 u n f o l d e q ui .
142 s p l i t .
143 {
144 u n fo ld r e f l .
145 i n t r o s .
146 u n f o l d c l a s s Eq .147 d e s t r u c t e .
148 p o s e p r o o f s tr Eq Eq ui .
149 u n f ol d e q ui in H.
150 d e s t r u c t H .
151 u nf ol d r e f l in H.
152 s p e c i a l i z e H with s .
153 aut o .
154 }
155 {
156 s p l i t .157 {
158 un fo ld symm.
159 i n t r o s .
160 u n f o l d c l a s s E q .
161 d e s t r u c t e .
162 d e s t r u c t e ’ .
163 p o s e p r o o f s tr Eq Eq ui .
164 u n f o l d e q u i in H.
165 d e s t r u c t H .
166 d e s t r u c t H0 .167 un fo ld symm in H0 .
168 s p e c i a l i z e H0 with s s 0 .
169 auto .
170 }
171 {
172 u n f o l d t r a n s .
173 i n t r o .
174 i n t r o .
175 i n t r o .
176 u n f o l d c l a s s E q .177 d e s t r u c t e .
178 d e s t r u c t e ’ .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 140/162
APÊNDICE C. Demonstrações 139
179 d e s t r u ct e ’ ’ .
180 p o s e p r o o f s tr Eq Eq ui .
181 u n f o l d e q u i in H.
182 d e s t r u c t H .
183 d e s t r u c t H0 .184 u n fo l d t r a ns in H1 .
185 s p e c i a l i z e H1 with s s 0 s 1 .
186 auto .
187 }
188 }
189 Qed .
190
191 Theorem pathEqEqui : equi pathEq .
192 Proof .
193 u n f o l d e q ui .194 s p l i t .
195 {
196 u n fo ld r e f l .
197 i n t r o s .
198 unf old pathEq .
199 d e s t r u c t e .
200 pose proof natEqEqui .
201 u n f ol d e q ui in H.
202 d e s t r u c t H .
203 u nf ol d r e f l in H.204 s p e c i a l i z e H with n .
205 aut o .
206 }
207 {
208 s p l i t .
209 {
210 un fo ld symm.
211 i n t r o s .
212 unf old pathEq .
213 d e s t r u c t e .214 d e s t r u c t e ’ .
215 pose proof natEqEqui .
216 u n f o l d e q u i in H.
217 d e s t r u c t H .
218 d e s t r u c t H0 .
219 un fo ld symm in H0 .
220 s p e c i a l i z e H0 with n n0 .
221 auto .
222 }
223 {224 u n f o l d t r a n s .
225 i n t r o .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 141/162
APÊNDICE C. Demonstrações 140
226 i n t r o .
227 i n t r o .
228 unf old pathEq .
229 d e s t r u c t e .
230 d e s t r u c t e ’ .231 d e s t r u ct e ’ ’ .
232 pose proof natEqEqui .
233 u n f o l d e q u i in H.
234 d e s t r u c t H .
235 d e s t r u c t H0 .
236 u n fo l d t r a ns in H1 .
237 s p e c i a l i z e H1 with n n0 n1 .
238 auto .
239 }
240 }241 Qed .
242
243 Theorem c l as s Path Eq Eq u i : e q u i c l a s sPa th Eq .
244 Proof .
245 u n f o l d e q ui .
246 s p l i t .
247 {
248 u n fo ld r e f l .
249 i n t r o s .
250 u n f o l d c l a s sPa th Eq .251 d e s t r u c t e .
252 p o s e p r o o f c l a s s Eq Equ i .
253 u n f ol d e q ui in H.
254 d e s t r u c t H .
255 u nf ol d r e f l in H.
256 s p e c i a l i z e H with c .
257 r e w r i t e H .
258 pose proof pathEqEqui .
259 u n f ol d e q ui in H1 .
260 d e s t r u c t H1 .261 u nf ol d r e f l in H1 .
262 s p e c i a l i z e H1 with p .
263 aut o .
264 }
265 {
266 s p l i t .
267 {
268 un fo ld symm.
269 i n t r o s .
270 u n f o l d c l a ss Pa th Eq .271 d e s t r u c t e .
272 d e s t r u c t e ’ .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 142/162
APÊNDICE C. Demonstrações 141
273 p o s e p r o o f c l a s s Eq Equ i .
274 u n f o l d e q u i in H.
275 d e s t r u c t H .
276 d e s t r u c t H0 .
277 un fo ld symm in H0 .278 s p e c i a l i z e H0 with c c 0 .
279 r e w r i t e H0 .
280 pose proof pathEqEqui .
281 u n f o l d e q u i in H2 .
282 d e s t r u c t H2 .
283 d e s t r u c t H3 .
284 un fo ld symm in H3 .
285 s p e c i a l i z e H3 with p p0 .
286 r e w r i t e H3 .
287 auto .288 }
289 {
290 u n f o l d t r a n s .
291 i n t r o s .
292 u n f o l d c l a ss Pa th Eq .
293 d e s t r u c t e .
294 d e s t r u c t e ’ .
295 d e s t r u ct e ’ ’ .
296 u n f o l d c l a ss Pa th Eq in H.
297 d e s t r u c t ( c l a s s E q c c 0 ) eq n : E1 .298 {
299 d e s tr u c t (p athEq p p0 ) e qn : E2 .
300 {
301 p o s e p r o o f c l a s s Eq Eq u i .
302 u n f o l d e q u i in H0 .
303 d e s t r u c t H0 .
304 d e s t r u c t H1 .
305 u n f ol d t r a ns in H2 .
306 a s s e r t ( c l as s Eq c 0 c 1 = c l as s E q c c 1 ) .
307 {308 auto .
309 }
310 r e w r i t e H3 .
311 pose proof pathEqEqui .
312 u n f o l d e q u i in H4 .
313 d e s t r u c t H4 .
314 d e s t r u c t H5 .
315 u n f ol d t r a ns in H6 .
316 a s s e r t ( p athEq p 0 p1 = p athEq p p1 ) .
317 {318 auto .
319 }
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 143/162
APÊNDICE C. Demonstrações 142
320 r e w r i t e H7 .
321 aut o .
322 }
323 {
324 congruen ce .325 }
326 }
327 {
328 congruen ce .
329 }
330 }
331 }
332 Qed .
333
334 Theorem o bj Eq Eq ui : e q u i o bj Eq .335 Proof .
336 u n f o l d e q ui .
337 s p l i t .
338 {
339 u n fo ld r e f l .
340 i n t r o s .
341 unfo l d objEq .
342 d e s t r u c t e .
343 p o s e p r o o f s tr Eq Eq ui .
344 u n f ol d e q ui in H.345 d e s t r u c t H .
346 u nf ol d r e f l in H.
347 s p e c i a l i z e H with s .
348 aut o .
349 }
350 {
351 s p l i t .
352 {
353 un fo ld symm.
354 i n t r o s .355 unfo ld objEq .
356 d e s t r u c t e .
357 d e s t r u c t e ’ .
358 p o s e p r o o f s tr Eq Eq ui .
359 u n f o l d e q u i in H.
360 d e s t r u c t H .
361 d e s t r u c t H0 .
362 un fo ld symm in H0 .
363 s p e c i a l i z e H0 with s s 0 .
364 auto .365 }
366 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 144/162
APÊNDICE C. Demonstrações 143
367 u n f o l d t r a n s .
368 i n t r o .
369 i n t r o .
370 i n t r o .
371 unfo ld objEq .372 d e s t r u c t e .
373 d e s t r u c t e ’ .
374 d e s t r u ct e ’ ’ .
375 p o s e p r o o f s tr Eq Eq ui .
376 u n f o l d e q u i in H.
377 d e s t r u c t H .
378 d e s t r u c t H0 .
379 u n fo l d t r a ns in H1 .
380 s p e c i a l i z e H1 with s s 0 s 1 .
381 auto .382 }
383 }
384 Qed .
C.8 AnalyzeSpecFacts
1 S e t Im p l i c i t A rg um en ts .
2
3
Require Import L i s t . Import L i s tN o ta t i o n s .4
5 Require Import Lim.
6 Require Import L i t o r a l .
7 Require Import L i t o r a l F a c t s .
8 Require Import ListOptionSeq .
9 Require Import ListS eq .
10 Require Import Seq .
11 Require Import S u b l i s t .
12
13
Definition a na ly ze Sp ec S c l a s s e s c l a s s s pe c n : =14 l e t ( s , _) := a na ly ze Sp ec c l a s s e s c l a s s s pe c n in s .
15
16 Theorem analyzeSpecS_t1 :
17 f o r a l l c l a ss e s c l a s s spec ,
18 n on De cL i st Se q ( a n al y ze S pe c S c l a s s e s c l a s s s p e c )
19 /\ s u b l i s tB n d L is t S eq ( a na ly ze Sp ec S c l a s s e s c l a s s s p ec ) .
20 Proof .
21 i n t r o s .
22 s p l i t .
23
{24 unfo l d nonDecListSeq .
25 i n t r o s .
26 u n f ol d s u f f E q L i s t .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 145/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 146/162
APÊNDICE C. Demonstrações 145
74 {
75 e x i s t s [ ] .
76 auto .
77 }
78 }79 {
80 u n f o l d s u b l i s t B n d L i s t S e q .
81 e x i s t s c l as s Pa t hE q .
82 u n f o l d a n a l y ze S p e cS .
83 u n f o l d a n a l y z e Sp e c .
84 d e s tr u c t ( i n d e xS p e c s pe c ) .
85 e x i s t s ( l i st _ pr o d c l a s s e s l ) .
86 s p l i t .
87 {
88 apply c lassPathEqEqui .89 }
90 {
91 u nf ol d s u b l i s t .
92 d e s tr u ct p .
93 d e s t r u ct s .
94 d e s t r u c t ( a n al y ze T ra v s l 0 ) .
95 {
96 i n d u c t i o n n 0 .
97 {
98 i n t r o s .99 u n f o l d a n a l y z e Cl a s s Pa th s .
100 s impl .
101 omega.
102 }
103 {
104 u n f o l d a n a l y z e Cl a s s Pa th s .
105 f o l d a n a l y ze C l a ss P a t h s .
106 d e s tr u c t ( a na ly ze C la ss Pa th s c l a s s e s l l 0 [ ] [ ( c l a ss , p ) ] n 0 ) .
107 d e s t r u c t o .
108 {109 d e s t r u ct l 2 .
110 {
111 aut o .
112 }
113 {
114 d e s t r u c t ( c o n t a in s C l a ss P a t h l 1 p0 ) e qn : E1 .
115 {
116 auto .
117 }
118 {119 d e s t r u c t ( c o n t a in s C l a ss P a t h ( l i s t _ p r o d c l a s s e s l ) p0 ) e qn : E2 .
120 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 147/162
APÊNDICE C. Demonstrações 146
121 i n t r o s .
122 a s se r t (
123 c ou nt c l as s Pa t hE q ( p 0 : : l 1 ) e <=
124 c ou nt c la ss Pa th Eq ( l i s t _p r o d c l a s s e s l ) e
125 ) .126 {
127 s impl .
128 d e s t r u c t ( c l as s Pa t hE q e p0 ) e qn : E3 .
129 {
130 u n f o l d c o n t ai n s C l a ss P a t h in E1 .
131 u n f o l d c o u ntCl a s sPa th in E1 .
132 d e s t r u c t ( c o u nt c l as s Pa t hE q l 1 p0 ) eq n : E4 .
133 {
134 p o s e p r o o f c l a ss Pa thEq Equ i .
135 u n f ol d e q ui in H.136 d e s t r u c t H .
137 d e s t r u c t H0 .
138 a s se r t (
139 c ou nt c l as s Pa t hE q l 1 e =
140 c ou nt c l as s Pa t hE q l 1 p0
141 ) .
142 {
143 apply sameCount .
144 auto .
145 auto .146 }
147 r e w r i t e H2 .
148 r e w r i t e E4 .
149 a s se r t (
150 c ou nt c la ss Pa th Eq ( l i s t _p r o d c l a s s e s l ) e =
151 c ou nt c l as s Pa t hE q ( l i s t _ p r o d c l a s s e s l ) p0
152 ) .
153 {
154 apply sameCount .
155 auto .156 auto .
157 }
158 r e w r i t e H3 .
159 u n f o l d c o n t a in s C l a ss P a t h in E2 .
160 u n f ol d c o n t ai n s in E2 .
161 d e s t r u c t ( c o u nt c l as s Pa t hE q
162 ( l i s t _p r o d c l a s s e s l ) p0 ) eqn : E5 .
163 {
164 congruenc e .
165 }166 {
167 omega.
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 148/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 149/162
APÊNDICE C. Demonstrações 148
215 f o r a l l c l a ss e s c l a s s spec ,
216 c on vS eq ( a n al y ze S pe c S c l a s s e s c l a s s s p e c ) .
217 Proof .
218 i n t r o s .
219 p o s e p r o o f a n a ly z eS p ec S _t1 .220 s p e c i a l i z e H with c l a s s e s c l a s s s pe c .
221 d e s t r u c t H .
222 apply nonDecSublistBndListSeqConv .
223 auto .
224 auto .
225 Qed .
226
227 Theorem consNotEqual :
228 f o r a l l E ( l : l i s t E) ( e : E ) , l <> e : : l .
229 Proof .230 i n t r o s .
231 i n d u ct i o n l .
232 {
233 d i s c r i m i n a t e .
234 }
235 {
236 i n j e c t i o n .
237 i n t r o s .
238 d e s t r u c t I H l .
239 r e w r i t e <− H1 .240 aut o .
241 }
242 Qed .
243
244 Definition an al yz eS pe cT c l a s s e s c l a s s s pe c n :=
245 l e t ( _, t ) := a na ly ze Sp ec c l a s s e s c l a s s s pe c n in t .
246
247 Theorem analyzeSpecT_t1 :
248 f o r a l l c l a ss e s c l a s s spec ,
249 e x i s t s N,250 d e cL i s tO p t io n Se q ( s u f f S e q ( a na ly ze Sp ec T c l a s s e s c l a s s s p e c ) N ) .
251 Proof .
252 i n t r o s .
253
254 p o s e p r o o f a n a ly z eS p ec S _t2 .
255 s p e c i a l i z e H with c l a s s e s c l a s s s pe c .
256 u n f o l d c on vS eq in H.
257 d e s t r u ct H a s [ N ] .
258 e x i s t s N.
259
260 u n f o l d d e c L i s tO p t i o n Se q .
261 u n f o l d s u f f L i s t O p t i o n .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 150/162
APÊNDICE C. Demonstrações 149
262 u n f o l d s u f f S e q .
263 unfo ld analyzeSpecT .
264 u n f o l d a n a l y z e S p e c .
265 u n f o l d c o ns S e q in H.
266 u n fo l d s u f f S e q in H.267 u n f o l d a n a l y ze S p e cS in H.
268 u n f o l d a n a l y z e Sp e c in H.
269
270 i n t r o s .
271 a s s e r t (N + ( S n ) = S (N + n ) ) .
272 {
273 omega.
274 }
275 r e w r i t e H0 .
276 s p e c i a l i z e H with n .277 r e w r i t e H0 in H.
278
279 u n f o l d a n a l y z e Cl a s s Pa th s .
280 f o l d a n a l yz e C l as s P a t hs .
281 u n f o l d a n a l yz e C l as s P a t hs in H.
282 f o l d a n a l yz e C l as s P a t hs in H.
283
284 d e s t r u c t ( i n de x Sp e c s p e c ) .
285 d e st r u ct p .
286 d e s t r u ct s .287 d e s t r u c t ( a n al y ze T ra v s l 0 ) .
288 {
289 d e st r u ct ( a na ly ze Cl as sP at hs c l a s s e s l l 0 [ ] [ ( c l a ss , p ) ] (N + n ) ) .
290 d e s t r u c t o .
291 {
292 d e s t r u ct l 2 .
293 {
294 aut o .
295 }
296 {297 d e s t r u c t ( c o n t a in s C l a s sP a t h l 1 p0 ) .
298 {
299 e x i s t s l 2 .
300 e x i s t s p0 .
301 aut o .
302 }
303 {
304 d e s t r u c t ( c o nt a in s Cl a ss P at h ( l i s t _p r o d c l a s s e s l ) ) .
305 {
306 d e s t r u c t p0 .307 d e s t r u ct ( a na ly ze Pa th c l a s s e s l 0 c p0 ) .
308 {
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 151/162
APÊNDICE C. Demonstrações 150
309 apply consNotEqual in H.
310 c o n t r a d i c t i o n .
311 }
312 {
313 apply consNotEqual in H.314 c o n t r a d i c t i o n .
315 }
316 }
317 {
318 e x i s t s l 2 .
319 e x i s t s p0 .
320 auto .
321 }
322 }
323 }324 }
325 {
326 auto .
327 }
328 }
329 {
330 aut o .
331 }
332 Qed .
333
334 Theorem analyzeSpecTLim :
335 f o r a l l c l a ss e s c l a s s spec ,
336 l i m ( a n al yz eS pe cT c l a s s e s c l a s s s p e c ) None \/
337 l i m ( a na ly ze Sp ec T c l a s s e s c l a s s s p e c ) ( Some [ ] ) .
338 Proof .
339 i n t r o s .
340 pose p roof analyzeSpecT_t1 .
341 s p e c i a l i z e H with c l a s s e s c l a s s s pe c .
342 apply hasDecOptionListSuffSeqLim .
343 auto .344 Qed .
345
346 Theorem analyzeSpecLim :
347 f o r a l l c l a ss e s c l a s s spec ,
348 e x i s t s N,
349 f o r a l l n ,
350 l e t ( _, t ) := a n al y ze Sp e c c l a s s e s c l a s s s p ec (N + n ) in
351 t = None \/ t = Some [ ] .
352 Proof .
353 i n t r o s .354 pose proof analyzeSpecTLim .
355 s p e c i a l i z e H with c l a s s e s c l a s s s pe c .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 152/162
APÊNDICE C. Demonstrações 151
356 u n fo l d l im in H.
357 u n fo l d s u f f S e q in H.
358 unfo ld analyzeSpecT in H.
359 d e s t r u c t H .
360 {361 d e s t r u ct H a s [N ] .
362 e x i s t s N.
363 i n t r o s .
364 s p e c i a l i z e H with n .
365 d e s t r u ct ( a na l yz eS p ec c l a s s e s c l a s s s p ec (N + n ) ) .
366 aut o .
367 }
368 {
369 d e s t r u ct H a s [N ] .
370 e x i s t s N.371 i n t r o s .
372 s p e c i a l i z e H with n .
373 d e s t r u ct ( a na l yz eS p ec c l a s s e s c l a s s s p ec (N + n ) ) .
374 aut o .
375 }
376 Qed .
C.9 InterpretSpecFacts
1 S e t Im p l i c i t A rg um en ts .
2
3 Require Import L i s t . Import L i s tN o ta t i o n s .
4
5 Require Import Lim.
6 Require Import L i t o r a l .
7 Require Import L i t o r a l F a c t s .
8 Require Import ListOptionSeq .
9 Require Import ListS eq .
10
Require Import Seq .11 Require Import S u b l i s t .
12
13 Definition f i l t e r 2 S ( p a ths : l i s t PATH) ( a l l O b j s : l i s t OBJ ) ( s : l i s t OBJ )
14 ( obj s : l i s t OBJ) ( path : PATH) :=
15 l e t ( s , _) := f i l t e r 2 p a th s a l l O b j s s o b j s p at h in s .
16
17 Definition f i l t er 2R ( paths : l i s t PATH) ( a l l Obj s : l i s t OBJ) ( s : l i s t OBJ)
18 ( obj s : l i s t OBJ) ( path : PATH) :=
19 l e t (_ , r ) := f i l t e r 2 p a th s a l l O b j s s o b j s p at h in r .
20
21 Theorem f i l t e r 2_ t 1 :
22 f o r a l l p at hs a l l O b j s ( s : l i s t OBJ) o b j s pat h ,
23 e x i s t s ( s ’ : l i s t OBJ ) ,
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 153/162
APÊNDICE C. Demonstrações 152
24 f i l t e r 2 S p at hs a l l O b js s o b js p at h = s ’ ++ s
25 /\ ( f o r a l l ob j ,
26 c ou nt o bj Eq s ’ o b j = 0 \ /
27 c ou nt o bj Eq s ’ o b j = 1 / \
28 c o n t ai n s ob jE q a l l O b j s o bj = t r u e /\29 c o n t ai n s ob jE q s o b j = f a l s e )
30 /\ l e n g th s ’ = l e ng t h ( f i l t e r 2 R p at hs a l l O b j s s o b j s p at h ) .
31 Proof .
32 i n t r o s .
33 i n d u c t i o n o b j s .
34 {
35 e x i s t s [ ] .
36 aut o .
37 }
38 {39 u n fo ld f i l t e r 2 S .
40 u n f ol d f i l t e r 2 R .
41 un fo ld f i l t e r 2 .
42 fo ld f i l t e r 2 .
43 d e s t r u c t I H ob j s .
44 u nf ol d f i l t e r 2 S in H.
45 u n fo ld f i l t e r 2 R in H.
46 d e s t r u c t ( f i l t e r 2 p a th s a l l O b j s s o b j s p at h ) .
47 d e s t r u c t ( c o nt a i ns O b j a l l O b j s a ) e qn : E1 .
48 {49 d e s t r u c t ( c o n ta i n sO b j l a ) eq n : E2 .
50 {
51 e x i st s x .
52 aut o .
53 }
54 {
55 d e s t r u ct H .
56 d e s t r u c t H0 .
57 r e w r i t e H .
58 e x i s t s ( a : : x ) .59 s p l i t .
60 {
61 aut o .
62 }
63 {
64 s p l i t .
65 {
66 s impl .
67 i n t r o s .
68 d e s t r u c t ( o bj Eq o b j a ) e qn : E3 .69 {
70 r i g h t .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 154/162
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 155/162
APÊNDICE C. Demonstrações 154
118 }
119 {
120 aut o .
121 }
122 }123 {
124 s impl .
125 omega.
126 }
127 }
128 }
129 }
130 {
131 e x i st s x .
132 auto .133 }
134 }
135 Qed .
136
137 Definition i n t e rp r e t Sp e c 2 S s p ec a l l O b j s o b j s n :=
138 l e t ’ ( _, s , _) := i n t e r p r et S p e c 2 s pe c a l l O b j s o b j s n in s .
139
140 Theorem i n t e rp r e t Sp e c 2 S_ t 1 :
141 f o r a l l s pe c a ll O b js o bj s ,
142 n on De cL i st Se q ( i n t e r p r e t S p e c 2 S s p e c a l l O b j s o b j s )143 /\ s u b l i s t Bn d L i st S e q ( i n t e rp r e t Sp e c 2S s pe c a l l O b j s o b j s ) .
144 Proof .
145 i n t r o s .
146 s p l i t .
147 {
148 unfo l d nonDecListSeq .
149 u n f o l d i n t e r p r e t S p e c 2 S .
150 u n f o l d i n t e r p r e t S p e c 2 .
151 u n f o l d i n t e r p r e t S p e c .
152 u n f o l d i n t e r p r e t Ob j s P a t h s .153 f o l d i n t e r p r e t Ob j s P a t h s .
154 d e s tr u c t ( i n d e xS p e c s pe c ) .
155 d e st r u ct p .
156 d e s t r u ct s .
157 i n t r o s .
158 d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] n0 ) .
159 d e s t r u c t p0 .
160 d e s t r u c t o .
161 {
162 d e s t r u ct l 3 .163 {
164 e x i s t s [ ] .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 156/162
APÊNDICE C. Demonstrações 155
165 aut o .
166 }
167 {
168 d e s t r u c t p0 .
169 d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) eq n : E1 .170 p os e p r o of f i l t e r 2 _ t 1 .
171 s p e c i a l i z e H with l a l l O bj s l 2 l 4 p0 .
172 d e s t r u ct H .
173 d e s t r u ct H .
174 u nf ol d f i l t e r 2 S in H.
175 r e w r i t e E1 in H.
176 d e s t r u ct ( i n t e rp r e t Pa t h l 0 al l O b j s l 6 p0 ) .
177 {
178 e x i st s x .
179 aut o .180 }
181 {
182 e x i st s x .
183 aut o .
184 }
185 }
186 }
187 {
188 e x i s t s [ ] .
189 auto .190 }
191 }
192 {
193 u n f o l d s u b l i s t B n d L i s t S e q .
194 e x i s t s o bj Eq .
195 e x i s t s a l l Ob j s .
196 s p l i t .
197 {
198 apply objEqEqui .
199 }200 {
201 i n d uc t i o n n .
202 {
203 u nf ol d s u b l i s t .
204 u n f o l d i n t e r p r e t S p e c 2 S .
205 u n f o l d i n t e r p r e t S p e c 2 .
206 u n f o l d i n t e r p r e t S p e c .
207 d e s tr u c t ( i n d e xS p e c s p e c ) .
208 d e st r u ct p .
209 d e s t r u ct s .210 u n f o l d i n t e r p r e t Ob j s P a t h s .
211 s impl .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 157/162
APÊNDICE C. Demonstrações 156
212 i n t r o s .
213 omega.
214 }
215 {
216 u n f o l d i n t e r p r e t S p e c 2 S in IHn.217 u n fo l d i n t e r p re t S p e c 2 in IHn.
218 u n fo l d i n t e r p r e t Sp e c in IHn.
219 u n f o l d i n t e r p r e t S p e c 2 S .
220 u n f o l d i n t e r p r e t S p e c 2 .
221 u n f o l d i n t e r p r e t S p e c .
222 d e s tr u c t ( i n d e xS p e c s p e c ) .
223 d e st r u ct p .
224 d e s t r u ct s .
225 u n f o l d i n t e r p r e t Ob j s P a t h s .
226 f o l d i n t e r p r e t O bj s P a t h s .227 d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] n ) .
228 d e s t r u c t p0 .
229 d e s t r u c t o .
230 d e s t r u ct l 3 .
231 {
232 aut o .
233 }
234 {
235 d e s t r u c t p0 .
236 d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) e qn : E1 .237 p os e p r oo f f i l t e r 2 _ t 1 .
238 s p e c i a l i z e H with l a l lO b js l 2 l 4 p0 .
239 d e s t r u c t H .
240 d e s t r u c t H .
241 u nf ol d f i l t e r 2 S in H.
242 r e w r i t e E1 in H.
243 a s s e r t ( s u b l i s t objEq l 5 a l l Ob j s ) .
244 {
245 u nf ol d s u b l i s t in IHn.
246 u nf ol d s u b l i s t .247 i n t r o s .
248 s p e c i a l i z e IHn with e .
249 r e w r i t e H .
250 re wr it e appCount .
251 d e s t r u c t H0 .
252 s p e c i a l i z e H0 with e .
253 d e s t r u c t H0 .
254 {
255 omega.
256 }257 {
258 d e s t r u c t H0 .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 158/162
APÊNDICE C. Demonstrações 157
259 d e s t r u c t H1 .
260 d e s t r u c t H2 .
261 apply containsTrueCountNotZero in H1 .
262 a p p ly c o n ta i n s Fa l se Co u n tZ e r o in H2 .
263 omega.264 }
265 }
266 d e s t r u c t ( i n t e rp r e t Pa t h l 0 a l l O b j s l 6 p0 ) .
267 {
268 d e s t r u ct l 6 .
269 {
270 aut o .
271 }
272 {
273 aut o .274 }
275 }
276 {
277 d e s t r u ct l 6 .
278 {
279 aut o .
280 }
281 {
282 aut o .
283 }284 }
285 }
286 {
287 aut o .
288 }
289 }
290 }
291 }
292 Qed .
293
294 Theorem i n t e rp r e t Sp e c 2 S_ t 2 :
295 f o r a l l s pe c a ll O b js o bj s ,
296 c on vS eq ( i n t e r p r e t S p e c 2 S s p e c a l l O b j s o b j s ) .
297 Proof .
298 i n t r o s .
299 p o s e p r o o f i n te r p r e tS p e c 2 S _ t1 .
300 s p e c i a l i z e H with s p e c a l l O b j s o b j s .
301 d e s t r u c t H .
302 apply nonDecSublistBndListSeqConv .
303 auto .304 auto .
305 Qed .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 159/162
APÊNDICE C. Demonstrações 158
306
307 Definition i n t er p re t S pe c 2T s p ec a l l O b j s o b j s n : =
308 l e t ’ (_, _, t ) := i n t er p re t S pe c 2 s pe c a l l Ob j s o b js n in t .
309
310 Theorem i nte r p r e tSp e c 2 T_ t1 :311 f o r a l l s pe c a ll O b js o bj s ,
312 e x i s t s N,
313 d e cL i s tO p t io n Se q ( s u f f S e q ( i n t e r pr e t S p ec 2 T s p e c a l l O b j s o b j s ) N ) .
314 Proof .
315 i n t r o s .
316
317 p o s e p r o o f i n te r p r e tS p e c 2 S _ t2 .
318 s p e c i a l i z e H with s p e c a l l O b j s o b j s .
319 d e s t r u ct H a s [ N ] .
320 e x i s t s N.321
322 u n f o l d d e c L i s tO p t i o n Se q .
323 u n f o l d s u f f L i s t O p t i o n .
324 u n f o l d s u f f S e q .
325 u n f o l d i n te r p r e tS p e c 2 T .
326 u n f o l d i n t e r p r e t S p e c 2 .
327 u n f o l d i n t e r p r e t S p e c .
328 u n f o l d c o ns S e q in H.
329 u n fo l d s u f f S e q in H.
330 u n f o l d i n t e r p r e t S p e c 2 S in H.331 u n fo l d i n t e r p r et S p e c 2 in H.
332 u n fo l d i n t e r p r e t S pe c in H.
333
334 i n t r o s .
335 a s s e r t (N + ( S n ) = S (N + n ) ) .
336 {
337 omega.
338 }
339 r e w r i t e H0 .
340 s p e c i a l i z e H with n .341 r e w r i t e H0 in H.
342
343 u n f o l d i n t e r p r e t Ob j s P a t h s .
344 f o l d i n t e r p r e t Ob j s P a t h s .
345 u n f o l d i n t e r p r e t Ob j s P a t h s in H.
346 f o l d i n t e r p r e t Ob j s P a t h s in H.
347
348 d e s t r u c t ( i n de x Sp e c s p e c ) .
349 d e st r u ct p .
350 d e s t r u ct s .351 d e s t r u ct ( i n t er p r et O b js P a t hs f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o bj s , p ) ] (N + n ) ) .
352 d e s t r u c t p 0 .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 160/162
APÊNDICE C. Demonstrações 159
353 d e s t r u c t o .
354 {
355 d e s t r u ct l 3 .
356 {
357 auto .358 }
359 {
360 d e s t r u c t p0 .
361
362 p os e p r oo f f i l t e r 2 _ t 1 .
363 s p e c i a l i z e H1 with l a l lO bj s l 2 l 4 p0 .
364 u nf ol d f i l t e r 2 S in H1 .
365 u nf ol d f i l t e r 2 R in H1 .
366 d e s t r u c t H1 .
367 d e s t r u c t H1 .368 d e s t r u c t H2 .
369
370 d e s t r u c t ( f i l t e r 2 l a l l O b j s l 2 l 4 p0 ) e qn : E1 .
371 d e s t r u ct ( i n t e rp r e t P at h l 0 a l l O b j s l 6 p0 ) eqn : E2 .
372 {
373 a s s e r t ( l 5 = [ ] ++ l 5 ) .
374 {
375 aut o .
376 }
377 r e w r i t e H4 in H1 .378 r e w r i t e H in H1 .
379 apply app_inv_tai l in H1 .
380 r e w r i t e <− H1 in H3 .
381 s impl in H3 .
382 symmetry in H3 .
383 apply lengthZeroEmptyList in H3 .
384 r e w r i t e H3 in E2 .
385 u n f o l d i n t e r p r e t P a t h in E2 .
386 i n j e c t i o n E2 .
387 i n t r o s .388 r e w r i t e <− H5 .
389 rew rit e app_nil_r .
390 e x i s t s l 3 .
391 e x i s t s ( l 4 , p0 ) .
392 aut o .
393 }
394 {
395 a s s e r t ( l 5 = [ ] ++ l 5 ) .
396 {
397 aut o .398 }
399 r e w r i t e H4 in H1 .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 161/162
APÊNDICE C. Demonstrações 160
400 r e w r i t e H in H1 .
401 apply app_inv_tai l in H1 .
402 r e w r i t e <− H1 in H3 .
403 s impl in H3 .
404 symmetry in H3 .405 apply lengthZeroEmptyList in H3 .
406 r e w r i t e H3 in E2 .
407 u n f o l d i n t e r p r e t P a t h in E2 .
408 congruen ce .
409 }
410 }
411 }
412 {
413 aut o .
414 }415 Qed .
416
417 Theorem i nte r p r e tSp e c 2 T_ t2 :
418 f o r a l l s pe c a ll O b js o bj s ,
419 l i m ( i n t e r pr e t S p ec 2 T s p ec a l l O b j s o b j s ) None \/
420 l i m ( i n te r p r e tS p e c 2 T s p e c a l l O b j s o b j s ) (Some [ ] ) .
421 Proof .
422 i n t r o s .
423 p o s e p r o o f i n te r p r e tS p e c2 T_ t1 .
424 s p e c i a l i z e H with s p e c a l l O b j s o b j s .425 apply hasDecOptionListSuffSeqLim .
426 auto .
427 Qed .
428
429 Theorem i n t e rp r e t Sp e c 2 Li m :
430 f o r a l l s pe c a ll O b js o bj s ,
431 e x i s t s N,
432 f o r a l l n ,
433 l e t ’ (_, _, t ) := i n t e r p re t S p e c 2 s p ec a l l O b j s o b j s (N + n ) in
434 t = None \/ t = Some [ ] .435 Proof .
436 i n t r o s .
437 p o s e p r o o f i n te r p r e tS p e c2 T_ t2 .
438 s p e c i a l i z e H with s p e c a l l O b j s o b j s .
439 u n fo l d l im in H.
440 u n fo l d s u f f S e q in H.
441 u n f o l d i n t e r pr e t S p ec 2 T in H.
442 d e s t r u c t H .
443 {
444 d e s t r u ct H a s [N ] .445 e x i s t s N.
446 i n t r o s .
7/23/2019 Otimizando Sistemas Intensivos em ES Através de Programação Concorrente
http://slidepdf.com/reader/full/otimizando-sistemas-intensivos-em-es-atraves-de-programacao-concorrente 162/162
APÊNDICE C. Demonstrações 161
447 s p e c i a l i z e H with n .
448 d e s t r u ct ( i n t e r p re t S p e c 2 s p e c a l l O b j s o b j s ( N + n ) ) .
449 d e st r u ct p .
450 aut o .
451 }452 {
453 d e s t r u ct H a s [N ] .
454 e x i s t s N.
455 i n t r o s .
456 s p e c i a l i z e H with n .
457 d e s t r u ct ( i n t e r p re t S p e c 2 s p e c a l l O b j s o b j s ( N + n ) ) .
458 d e st r u ct p .
459 aut o .
460 }
461 Qed .
top related