Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

Ps-Graduao em Cincia da Computao
Otimizando Sistemas Intensivos em E/S Atravs de

Programao Concorrente
Por
Saulo Medeiros de Arajo
Dissertao de Mestrado
Universidade Federal de Pernambuco

posgraduacao@cin.ufpe.br
www.cin.ufpe.br/~posgraduacao
RECIFE/2015
SAULO MEDEIROS DE ARAJO
OTIMIZANDO SISTEMAS INTENSIVOS EM E/S ATRAVS DE

PROGRAMAO CONCORRENTE
Este trabalho foi apresentado Ps-Graduao em

Cincia da Computao do Centro de Informtica da
Universidade Federal de Pernambuco como
requisito parcial para obteno do grau de Mestre
em Cincia da Computao.
Orientador:
Silvio Romero de Lemos Meira
Recife
2015
Catalogao na fonte
Bibliotecria Joana DArc Leo Salvador CRB4-532
A663o
Arajo, Saulo Medeiros de.

Otimizando sistemas intensivos em E/S atravs de programao
concorrente / Saulo Medeiros de Arajo. Recife: O Autor, 2015.
161 f.: fig., tab.
Orientador: Silvio Romero de Lemos Meira.
Dissertao (Mestrado) Universidade Federal de Pernambuco. CIN,
Cincia da Computao, 2015.
Inclui referncias e apndices.
1. Engenharia de software. 2. Programao paralela (Computao). 3.
Programao orientada a objetos (Computao). 4. Banco de dados
relacionados. I. Meira, Silvio Romero de Lemos (Orientador). II. Titulo.
005.1
CDD (22. ed.)
UFPE-MEI 2015-107
Dissertao de Mestrado apresentada por Saulo Medeiros de Arajo Ps Graduao

em Cincia da Computao do Centro de Informtica da Universidade Federal de
Pernambuco, sob o ttulo Otimizando Sistemas Intensivos em E/S Atravs de
Programao Concorrente, orientada pelo Prof. Silvio Romero de Lemos Meira e
aprovada pela Banca Examinadora formada pelos professores:
______________________________________________
Prof. Augusto Czar Alves Sampaio
Centro de Informtica/UFPE
______________________________________________
Prof. Jones Oliveira de Albuquerque
Departamento de Estatstica e Informtica / UFRPE
_________________________________________________
Prof. Silvio Romero de Lemos Meira
Centro de Informtica / UFPE
Visto e permitida a impresso.

Recife, 6 de abril de 2015.
___________________________________________________
Profa. Edna Natividade da Silva Barros
Coordenadora da Ps-Graduao em Cincia da Computao do
Centro de Informtica da Universidade Federal de Pernambuco.
Para meus pais, Stelio e Henrriete.
Agradecimentos
Quero agradecer, em primeiro lugar, minha esposa, Karina. Sem o seu apoio
incondicional, no teria ido to longe. Agradeo tambm minha filha, Alice. Sua chegada,
no incio desta pesquisa, encheu-nos de alegria.
Diversos outros agradecimentos so devidos. Ao meu pai, Stelio, que me apresentou
ao computador e, ainda mais importante, ao violo, quando eu ainda era criana. minha
me, Henrriete, que foi minha primeira professora de Matemtica e, portanto, de Cincia
da Computao. minha irm Stella, que deu, por mim, o primeiro passo para que esta
pesquisa fosse possvel. minha sogra Tnia, que, assim como meus pais, nos ajudou a
cuidar de Alice.
Ao meu amigo e, agora, orientador, Silvio. Quase duas dcadas depois de nossa
primeira colaborao, seu entusiasmo continua sendo uma poderosa fora motriz para
mim. Aos professores Kiev e Nelson, cuja participao foi fundamental para a publicao
de alguns dos resultados alcanados nesta pesquisa. Ao professor Airton, que, com muita
pacincia, me ensinou Anlise Real.
Aos meus grandes amigos Fbio, Idevan, Celso e Humberto. Esta pesquisa ,
tambm, 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 funes durante
minha ausncia.
This is the springtime of my loving

The second season I am to know
(Page - Plant, The Rain Song)
Resumo
ORMs (Object-Relational Mappers) so bastante populares porque eles reduzem o esforo
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 so
carregados sob demanda, carregam os atributos de vrios objetos. Em muitos casos, estas
consultas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMs
executa consultas apenas sequencialmente.
Esta pesquisa visa aumentar o desempenho de sistemas baseados em ORMs. Para tanto,
ela define uma DSL (Domain-Specific Language) de especificao de navegaes por objetos
chamada Litoral. Tambm integra esta pesquisa o projeto e a implementao de um
interpretador de especificaes Litoral. O interpretador navega por objetos transientes
(aqueles que existem apenas na memria primria) e persistentes (aqueles que armazenados
em um banco de dados relacional) e pr-carrega os do segundo tipo executando consultas
sequencialmente ou concorrentemente.
A estratgia desta pesquisa foi avaliada com os benchmarks sintticos Emeio e OO7,
desenvolvidos, respectivamente, no contexto desta pesquisa e por terceiros. No primeiro,
pr-carregar objetos executando consultas concorrentemente aumentou a velocidade de
execuo em at 323,6%. No segundo, o aumento foi de at 245,7%. Os benchmarks
tambm foram implementados com os ORMs Hibernate e EcliseLink JPA, os quais
aderem especificao JPA (Java Persistence Architecture). O primeiro foi escolhido
por ser bastante popular. O segundo foi escolhido por ser a implementao de referncia
desta especificao. As implementaes baseadas no Hibernate e EclipseLink JPA foram
significativamente otimizadas. Entretanto, em todos os cenrios de Emeio e OO7 que
oferecem oportunidades para pr-carregar objetos executando consultas concorrentemente,
o desempenho delas foi inferior ao da implementao baseada no interpretador de Litoral.
Palavras-chaves: Mapeamento objeto-relacional. Pr-carregamento. Concorrncia.
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 this
end, 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 up
to 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.
Lista de ilustraes
Figura 1 Trecho de cdigo Java que navega por objetos. . . . . . . . . . . . . . .
Figura 2 Especificao Litoral que declara navegaes de mensagens para seus
remetentes e destinatrios. . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 3 Trecho de cdigo Java que pr-carrega objetos com o interpretador de
Litoral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 4 Trecho de cdigo Java que requisita objetos especificando o predicado
que eles devem satisfazer. . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 5 Consultas SQL que ORMs executam para carregar sob demanda os
atributos de mensagens manipulados pelo trecho de cdigo da Figura 4.
Figura 6 Consulta SQL que pr-carrega todos os atributos do primeiro tipo de
uma mensagem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 7 Consulta SQL que pr-carrega todos os atributos do tipo I de uma
mensagem e, atravs de uma juno, tambm seu remetente. . . . . . .
Figura 8 Consulta SQL que pr-carrega todos os atributos de uma mensagem. .
Figura 9 Consultas que pr-carregam os destinatrios e os remetentes de vrias
mensagens atravs do operador in de SQL. . . . . . . . . . . . . . . . .
Figura 10 Trecho de cdigo Java que informa a ORMs compatveis com a especificao JPA quais objetos eles devem pr-carregar. . . . . . . . . . . . .
Figura 11 Mtodo Java que carrega as mensagens enviadas por um usurio. . . .
Figura 12 Mtodo Java que carrega as mensagens enviadas por um usurio e
pr-carrega seus remetentes. . . . . . . . . . . . . . . . . . . . . . . . .
Figura 13 Gramtica de Litoral em notao EBNF e em diagramas de sintaxe.
Figura 14 Trecho de cdigo Java que navega por objetos. . . . . . . . . . . . . . .
Figura 15 Especificao Litoral que navega atravs de um nico atributo. . . .
Figura 16 Gerao da especificao da Figura 15 a partir da gramtica de Litoral.
Figura 17 Especificao Litoral que navega atravs de colees de objetos. . . .
Figura 18 Especificao Litoral que navega atravs de mais de um atributo. . .
Figura 20 Especificao Litoral que navega por um nico atributo. . . . . . . .
Figura 21 Especificao Litoral que navega indiretamente. . . . . . . . . . . . .
Figura 22 Especificao Litoral que encadeia navegaes indiretas. . . . . . . .
Figura 23 Especificao Litoral que replica uma navegao. . . . . . . . . . . .
Figura 24 Especificao Litoral que define uma travessia. . . . . . . . . . . . .
Figura 26 Especificao Litoral que define uma travessia recursiva. . . . . . . .
Figura 27 Representao de classes e objetos no interpretador definidor. . . . . .
17
18
18
26
26
27
27
29
29
30
33
33
34
35
36
36
36
37
37
37
38
38
39
39
40
41
42
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
28
29
30
31
31
31
31
32
33
33
33
34
35
36
37
38
39
Figura 40
Figura 41
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
42
43
44
45
46
47
48
49
50
51
52
53
Criao de classes no interpretador definidor. . . . . . . . . . . . . . .

Representao de especificaes Litoral no interpretador definidor. .
Criao de uma especificao Litoral no interpretador definidor. . . .
Analisador semntico. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analisador semntico - continuao . . . . . . . . . . . . . . . . . . . .
Analisador semntico - continuao. . . . . . . . . . . . . . . . . . . .
Analisador semntico - continuao. . . . . . . . . . . . . . . . . . . .
Teorema que assegura que o analisador semntico do interpretador
definidor sempre capaz de validar especificaes Litoral em um
nmero finito de recurses. . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretador definidor. . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretador definidor - continuao. . . . . . . . . . . . . . . . . . . .
Interpretador definidor - continuao. . . . . . . . . . . . . . . . . . . .
Funo filter que impede navegaes. . . . . . . . . . . . . . . . . . . .
Semntica 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Especificao Litoral que entra em recurso infinita na semntica 1. .
Mensagem que se auto-referencia. . . . . . . . . . . . . . . . . . . . . .
Semntica 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Teorema que assegura que, sob a semntica 2, especificaes Litoral
no entram em recurso infinita. . . . . . . . . . . . . . . . . . . . . .
Programa Litoral que especifica navegaes que no so realizadas
na semntica 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Especificao Litoral que permuta os passos de uma outra especificao e, na semntica 2, navega por objetos pelos quais a original no
navega. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semntica 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Clculo de b2 4ac compondo invocaes de mtodos. . . . . . . . . .
Clculo de b2 4ac com funes assncronas. . . . . . . . . . . . . . . .
Estratgia de Afluentes para combinar as vantagens de funes
sncronas e assncronas. . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces ISyncFn0, ISyncFn1 e ISyncFn2. . . . . . . . . . . . . . . . .
Clculo de b2 4ac compondo invocaes de funes sncronas. . . . .
Interface ICallback. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2. . . . . . . . . . . . . . .
Funes sub e mul definidas com as interfaces IAsyncFn2. . . . . . . .
Interface IEval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces IEval0 e IEval1. . . . . . . . . . . . . . . . . . . . . . . . . .
Clculo de b2 4ac compondo invocaes de funes sncronas. . . . .
43
43
44
45
46
47
48
50
51
52
53
54
55
55
55
56
57
57
58
59
63
64
65
66
66
67
67
67
68
68
69
Figura 54 Clculo de b2 4ac compondo invocaes de funes sncronas e assncronas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figura 55 Processo de avaliao de b2 4ac. . . . . . . . . . . . . . . . . . . . . .
Figura 56 Clculo do somatrio dos preos dos produtos de uma lista compondo
invocaes de funes sncronas. . . . . . . . . . . . . . . . . . . . . . .
Figura 57 Clculo do somatrio dos preos dos produtos de uma lista compondo
avaliadores de funes assncronas e de funes sobre listas. . . . . . .
Figura 58 Interface IEvalHolder. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 59 Proxy que implementa a interface IEvalHolder. . . . . . . . . . . . . .
Figura 60 Interface IPrefetcher. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 61 Trecho de cdigo Java que usa o interpretador de Litoral. . . . . . .
Figura 62 Gramtica de Litoral na metalinguagem do ANTLR. . . . . . . . . .
Figura 63 Especificao Litoral cuja rvore sinttica e AST so exibidas nas
figuras 64a e 64b, respectivamente. . . . . . . . . . . . . . . . . . . . .
Figura 64 rvore sinttica e AST da especificao da Figura 63 . . . . . . . . . .
Figura 65 Tabela de smbolos da especificao Litoral da Figura 63. . . . . . .
Figura 66 Interpretao de especificaes Litoral . . . . . . . . . . . . . . . . .
Figura 66 Interpretao de especificaes Litoral - Continuao . . . . . . . . .
Figura 66 Interpretao de especificaes Litoral - Continuao . . . . . . . . .
Figura 67 Especificaes Litoral que compem o benchmark Emeio. . . . . . .
Figura 68 Tabelas adicionadas ao banco de dados para otimizar a implementao
de Emeio baseada no Hibernate. . . . . . . . . . . . . . . . . . . . . .
Figura 69 ndices criados no banco de dados de Emeio. . . . . . . . . . . . . . .
Figura 70 Resultado das otimizaes da implementao de Emeio baseada no
Hibernate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 70 Resultado das otimizaes da implementao de Emeio baseada no
Hibernate - continuao. . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 71 Tempo total de execuo das implementaes de Emeio baseadas no
interpretador de Litoral, Hibernate e EclipseLink JPA. . . . . . . . .
Figura 72 ndices de OO7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 73 Especificaes Litoral que fazem parte de OO7. . . . . . . . . . . . .
Figura 74 Resultados da otimizao da implementao de OO7 baseada no Hibernate. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 75 Tempo total de execuo das implementaes de Emeio baseadas no
interpretador de Litoral, Hibernate e EclipseLink JPA. . . . . . . . .
Figura 76 Especificao Program Summary que declara navegaes das mensagens
enviadas por um usurio para seus remetentes e destinatrios. . . . . .
Figura 77 Tabelas de Emeio. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Figura 78 Tabelas de OO7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
69
71
72
72
73
73
74
75
76
77
78
80
81
82
86
87
87
88
89
91
93
93
94
95
96
111
114
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/Sada
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
Sumrio
1
1.1
1.2
1.3
1.4
1.4.1
1.4.2
1.5
1.6
INTRODUO
Objetivo . . . .
ORMs . . . . .
Hiptese . . . .
Estratgia . . .
Viabilidade . . .
Generalidade . .
Avaliao . . .
Organizao . .
2
2.1
2.2
2.2.1
2.2.2
2.2.3
.
.
.
.
.
.
.
.
.
16
16
16
17
18
19
19
20
20
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
em
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
22
22
23
23
23
23
2.3.1
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.4
CONCEITOS BSICOS . . . . . . . . . . . . . . . . . . . . . .
Sistemas Intensivos em Processamento e em E/S . . . . . . . .
Otimizao de Sistemas Intensivos em E/S . . . . . . . . . . .
Caching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Agregao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carregamento sob Demanda e Pr-carregamento . . . . . . . . . . .
Pr-carregamento Informado e Especulativo . . . . . . . . . . . . . . . . .
Compresso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Concorrncia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carregamento sob Demanda, Pr-carregamento e Agregao
ORMs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Tipos de Atributo . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Carregamento de Atributos do Tipo I . . . . . . . . . . . . . . . . .
Carregamento de Atributos do Tipo II que Referenciam Objetos . . .
Carregamento de Atributos do Tipo II que Referenciam Colees . . .
Pr-carregamento Informado . . . . . . . . . . . . . . . . . . . . . .
Pr-carregamento Especulativo . . . . . . . . . . . . . . . . . . . . .
Hiptese . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
3.1
3.2
3.3
3.3.1
3.3.2
3.3.3
LITORAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sintaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Semntica Informal . . . . . . . . . . . . . . . . . . . . . . . . .
Navegando Atravs de um nico Atributo . . . . . . . . . . . . . .
Navegando Atravs de mais de um Atributo . . . . . . . . . . . . .
Navegando Indiretamente . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
32
32
34
35
36
36
37
2.2.3.1
2.2.4
2.2.5
2.3
. .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
24
24
24
25
25
27
27
28
28
30
30
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
39
39
41
42
43
43
50
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
61
61
62
62
63
65
65
66
67
67
68
70
70
71
74
74
76
78
4.3.3.2
INTERPRETADOR . . . . . . . . . . . . . . . . . . . . . . .
Afluentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Modelo de Programao . . . . . . . . . . . . . . . . . . . . . . .
Funes Sncronas . . . . . . . . . . . . . . . . . . . . . . . . . .
Funes Assncronas . . . . . . . . . . . . . . . . . . . . . . . . .
Avaliadores, Avaliaes e Processo de Avaliao . . . . . . . . . . .
Representando Funes Sncronas . . . . . . . . . . . . . . . . . .
Callbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Representando Funes Assncronas . . . . . . . . . . . . . . . . .
Avaliaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Avaliadores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Funes sobre Listas . . . . . . . . . . . . . . . . . . . . . . . . .
Avaliadores de Funes sobre Listas . . . . . . . . . . . . . . . . .
Projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementao . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anlise Lxica e Sinttica . . . . . . . . . . . . . . . . . . . . . . .
Anlise Semntica . . . . . . . . . . . . . . . . . . . . . . . . . .
Interpretao . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ns que Atuam Sobre Objetos . . . . . . . . . . . . . . . . . . . . . .
Ns que Atuam Sobre Listas . . . . . . . . . . . . . . . . . . . . . . .
5
5.1
5.1.1
5.1.2
5.1.3
5.1.4
AVALIAO . . . . . . . . . . . . . . . . . . . . . . . . . . .
Emeio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementao Baseada no Hibernate . . . . . . . . . . . . . . . .
Implementao Baseada no EclipseLink JPA . . . . . . . . . . . . .
Implementao Baseada no Interpretador de Litoral . . . . . . .
Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
83
84
85
89
89
90
3.3.4
3.3.5
3.4
3.4.1
3.4.2
3.4.3
3.4.4
3.4.4.1
3.4.4.2
3.4.4.3
3.4.4.4
3.4.4.5
4
4.1
4.1.1
4.1.2
4.1.3
4.1.4
4.1.5
4.1.6
4.1.7
4.1.8
4.1.9
4.1.10
4.1.11
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.3.1
Travessias . . . . . . . . . . . . . . . . . .
Travessias Recursivas . . . . . . . . . . . .
Interpretador Definidor . . . . . . . . .
Representao de Classes e Objetos . . . .
Representao de Especificaes Litoral
Anlise Semntica . . . . . . . . . . . . .
Interpretao . . . . . . . . . . . . . . . .
Argumentos S, filter e s . . . . . . . . . . . .
Semntica 1 . . . . . . . . . . . . . . . . .
Semntica 2 . . . . . . . . . . . . . . . . .
Semntica 3 . . . . . . . . . . . . . . . . .
Escolha de uma Semntica . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
53
54
56
58
60
78
79
5.2
5.2.1
5.2.2
5.2.3
5.2.4
OO7 . . . . . . . . . . .
Implementao Baseada no
Resultados . . . . . . . .
. . . . . . . . .
Hibernate . . .
EclipseLink JPA
Interpretador de
. . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
Litoral
. . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
92
93
94
94
94
6
6.1
6.2
6.3
6.4
TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . .
Program Summaries . . . . . . . . . . . . . . . . . . . . . . . .
Scalpel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AutoFetch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Outros Trabalhos sobre Pr-carregamento Especulativo . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
96
96
98
99
100
7
7.1
7.2
CONCLUSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Contribuies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Referncias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
A.1
A.2
APNDICE A EMEIO . . . . . . . . . . . . . . . . . . . . . . . . 109

Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
B.1
B.2
APNDICE B OO7 . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
C.1
C.2
C.3
C.4
C.5
C.6
C.7
C.8
C.9
APNDICE C DEMONSTRAES . . . . . . . . . . . . .
Seq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NatSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ListSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Lim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ListOptionSeq . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sublist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LitoralFacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AnalyzeSpecFacts . . . . . . . . . . . . . . . . . . . . . . . . .
InterpretSpecFacts . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
115
115
118
120
121
125
135
143
151
16
1 Introduo
Sistemas computacionais so pervasivos em nossa sociedade. Em boa parte, isto se
deve maior eficcia e eficincia observadas quando a sociedade executa diferentes processos
de negcio apoiada por tais sistemas. No Brasil, por exemplo, o uso da computao permite
que eleitores conheam os resultados de eleies apenas algumas horas depois de encerradas
as votaes. Antes das urnas eletrnicas, a apurao de votos durava vrios dias. Alm disto,
como votos eram computados manualmente, esta etapa do processo eleitoral estava mais
sujeita a erros e fraudes. A otimizao de sistemas computacionais, portanto, contribui,
em ltima anlise, para uma sociedade mais eficaz e eficiente.
Muitos sistemas sobre os quais a sociedade se apia so construdos em linguagens
orientadas a objetos e manipulam dados armazenados em bancos de dados relacionais
atravs 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 atravs de ORMs. Esta diretriz se aplica no s aos
sistemas corporativos (utilizados por mais de um departamento do BCB) como tambm
aos departamentais (utilizados por um nico departamento), independentemente destes
sistemas serem desenvolvidos pelo prprio BCB ou contratados a terceiros.
1.1 Objetivo
Dada a sua importncia para a sociedade, esta pesquisa visa aumentar o desempenho
de sistemas baseados em ORMs.
1.2 ORMs
ORMs so populares porque eles reduzem o esforo 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 cdigo Java (GOSLING et al., 2014) da Figura 1 navega de mensagens para seus
remetentes (linha 4) e destinatrios (linha 5), no importando se estes objetos existem
apenas na memria primria (ou seja, so transientes) ou se um banco de dados relacional
os armazena (ou seja, so persistentes). Infelizmente, este trecho de cdigo muito mais
lento 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.
Captulo 1. Introduo
1
2
3
4
5
6
7
8
17
L i s t <Message> me ssa ge s = g e t M e s s a g e s ( ) ;
f o r ( Message message : m ess age s ) {
p r i n t M e s s a g e ( message ) ;
p r i n t U s e r ( message . g e t S e n d e r ( ) ) ;
f o r ( User r e c i p i e n t : message . g e t R e c i p i e n t s ( ) ) {
printUser ( recipient ) ;
}
}
Figura 1 Trecho de cdigo Java que navega por objetos.

ORMs atenuam este problema pr-carregando (prefetching) objetos, ou seja, carregando objetos antes de um sistema navegar por eles. O pr-carregamento propriamente
dito no reduz o tempo tc que ORMs levam para carregar objetos, mas d a ORMs a
chance de pr-carregarem vrios 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 incidncia das latncias
dos canais de comunicao 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 execuo das linhas 45. A primeira carrega o remetente de uma
mensagem sob demanda. A segunda carrega seus destinatrios sob demanda. Portanto, se o
mtodo g e t M e s s a g e s retorna n mensagens, ento ORMs executam 2n consultas. Por outro
lado, com pr-carregamento, ORMs podem pr-carregar remetentes e destinatrios de todas
as mensagens executando apenas 2 consultas quando a linha 1 executada, no importando
quantas mensagens g e t M e s s a g e s retorna, reduzindo assim tc significativamente.
Como as consultas que pr-carregam remetentes e destinatrios so independentes,
elas podem ser executadas concorrentemente. Entretanto, a maioria dos ORMs executa
consultas apenas sequencialmente.
1.3 Hiptese
Esta pesquisa parte da hiptese de que o pr-carregamento, em muitos casos,
tambm d a ORMs a chance de executar consultas concorrentemente e que, combinando
esta otimizao com consultas que carregam vrios objetos, ORMs podem reduzir tc ainda
mais.
Captulo 1. Introduo
18
[ sender r e c i p i e n t s ]
Figura 2 Especificao Litoral que declara navegaes de mensagens para seus remetentes e destinatrios.
1
L i s t <Message> me ssa ge s = g e t M e s s a g e s ( ) ;
2
3
4
5
6
String spec = " [ sender r e c i p i e n t s ] " ;

I P r e f e t c h e r <L i s t <Message>> p r e f e t c h e r =
new P r e f e t c h e r I m p l <L i s t <Message >>(s p e c ) { } ;
p r e f e t c h e r . p r e f e t c h ( m ess ag es ) ;
7
8
f o r ( Message message : m ess age s ) { / . . . / }
Figura 3 Trecho de cdigo Java que pr-carrega objetos com o interpretador de Litoral.
1.4 Estratgia
Esta pesquisa define uma DSL (Domain-Specific Language) (DEURSEN; KLINT;
VISSER, 2000) de especificao de navegaes por objetos chamada Litoral. A Figura
2, por exemplo, exibe uma especificao Litoral que declara navegaes de mensagens
para seus remetentes e destinatrios.
Tambm faz parte desta pesquisa o projeto e a implementao de um interpretador
que executa especificaes 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 questes relativas concorrncia,
delegando a ORMs questes relativas interao com bancos de dados. Graas a esta
diviso de responsabilidades, qualquer ORM pode embutir o interpretador e assim prcarregar objetos executando consultas concorrentemente. A Figura 3, por exemplo, exibe
o trecho de cdigo previamente exibido na Figura 1 modificado para usar o interpretador.
A linha 4 instancia o interpretador a partir da especificao Litoral contida na
linha 3. A linha 5 executa o interpretador passando-lhe como parmetro uma lista de
mensagens. Quando a execuo da linha 5 chega ao fim, o interpretador ter pr-carregado
os remetentes e destinatrios das mensagens. A grande diferena entre os trechos de cdigo
exibidos nas Figuras 1 e 3 que no primeiro, que no 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 estratgia que ela permite que programadores desenvolvam sistemas que pr-carregam objetos executando consultas concorrentemente sem,
contudo, lidar com programao concorrente, reconhecidamente difcil (NANZ; WEST;
SILVEIRA, 2013).
Captulo 1. Introduo
19
Outro aspecto que merece destaque nesta estratgia que ela pode ser adotada
pontualmente e tambm a posteriori. O trecho de cdigo da Figura 3, por exemplo,
funcionalmente idntico com ou sem o interpretador. A diferena nestes dois casos apenas
no-funcional. Com o interpretador, o trecho de cdigo executado mais rapidamente.
Portanto, pode-se identificar em cdigos 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 navegaes. De um lado do debate, (IBRAHIM; COOK, 2006) argumenta que difcil especificar
navegaes corretamente. Adicionalmente, manutenes evolutivas e corretivas podem
invalidar especificaes previamente vlidas. Estes trabalhos propem mtodos que permitam a ORMs especular quais navegaes sistemas executam, eliminando a necessidade de
programadores especificarem navegaes.
Do outro lado do debate, (GUHIS; GOASDOU-THION; RIGAUX, 2009) defende
que programadores especialistas podem especificar navegaes com relativa facilidade e
que o aumento de desempenho obtido a partir delas compensa seus custos. Uma evidncia
de que esta opinio no mnimo razovel que ORMs bastante populares (BLAKELEY et al., 2006; ADYA et al., 2007; CASTRO; MELNIK; ADYA, 2007; LINSKEY;
PRUDHOMMEAUX, 2007; ONEIL, 2008) oferecem mecanismos para que programadores
especifiquem navegaes. Alm disto, como os mtodos de especulao so falveis, eles
podem resultar no pr-carregamento de mais ou menos objetos do que o necessrio, prejudicando o desempenho dos sistemas que os adotam. Portanto, pelo menos nestes casos,
preciso um mecanismo que permita ao programador sobrepor as especulaes dos mtodos.
Apesar desta pesquisa se alinhar aos trabalhos que defendem que os benefcios
superam os custos, ela continuar vlida mesmo que esta hiptese no se confirme. Isto
acontece porque a otimizao que ela prope, ou seja, pr-carregar objetos executando
consultas concorrentemente, pode ser implementada a partir de navegaes especificadas
automaticamente ou manualmente.
1.4.2 Generalidade
O projeto do interpretador genrico o bastante para que ele possa delegar a
interao com o repositrio de objetos no s a um ORM (caso os objetos estejam
armazenados em um banco de dados relacional), mas tambm a qualquer outro mecanismo
de acesso a objetos, independentemente de qual o repositrio subjacente. possvel,
por exemplo, usar o interpretador para pr-carregar concorrentemente objetos que esto
Captulo 1. Introduo
20
armazenados em um outro sistema. Basta que o ltimo adote algum mecanismo de

computao distribuda 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/Sada Atravs de Programao
Concorrente.
1.5 Avaliao
A estratgia da Seo 1.4 foi avaliada com os benchmarks sintticos (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 execuo em at 323,6%.
No segundo, o aumento foi de at 245,7%.
Os benchmarks tambm foram implementados com os ORMs Hibernate (ONEIL,
2008) e EcliseLink JPA (KEITH; SCHINCARIOL, 2009), os quais aderem especificao
JPA (Java Persistence Architecture) (GROUP, 2013). O primeiro foi escolhido por ser
bastante popular. O segundo foi escolhido por ser a implementao de referncia desta
especificao (FOUNDATION, 2008). As implementaes baseadas no Hibernate e EclipseLink JPA foram significativamente otimizadas. Entretanto, em todos os cenrios de
Emeio e OO7 que oferecem oportunidades para pr-carregar objetos executando consultas concorrentemente, o desempenho delas foi inferior ao da implementao baseada no
interpretador de Litoral.
1.6 Organizao
O restante desta dissertao est organizado nos seguintes captulos:
o Captulo 2 discute conceitos bsicos para o entendimento desta pesquisa e, a partir
deles, justifica a hiptese da Seo 1.3;
o Captulo 3 apresenta a sintaxe de Litoral em notao EBNF (Extended BackusNaur Form) e sua semntica atravs de exemplos e de um interpretador definidor
(definitional interpreter) (REYNOLDS, 1972) desenvolvido com o assistente de provas
(GEUVERS, 2009) Coq (BERTOT; CASTRAN, 2004);
o Captulo 4 apresenta o projeto e a implementao do interpretador de Litoral, o qual foi construdo sobre o framework Afluentes (ARAUJO et al., 2014),
desenvolvido no contexto desta pesquisa e tambm apresentado neste captulo;
Captulo 1. Introduo
21
o Captulo 5 apresenta os bechmarks Emeio e OO7 e as implementaes destes

benchmarks baseadas no Hibernate, EclipseLink JPA e no interpretador de Litoral,
comparando o desempenho destas implementaes;
o Captulo 6 discute trabalhos relacionados a esta pesquisa;
o Captulo 7 conclui esta dissertao elencando suas contribuies e possveis trabalhos futuros.
22
2 Conceitos Bsicos
Este captulo discute conceitos bsicos para o entendimento da presente pesquisa e,
a partir deles, justifica a hiptese da Seo 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 operaes de E/S transfiram
dados para a memria primria e secundria, respectivamente. No caso de sistemas
baseados em ORMs, esta parcela incorpora o tempo de carregamento de objetos tc ,
discutido na seo 1.2;
2. o tempo tp que o processador est ocupado, processando os dados transferidos para
a memria primria.
A caracterizao de te/s apresentada acima a usualmente encontrada em livros de
sistemas operacionais (TANENBAUM, 2008). Provavelmente ela reminiscente de um
tempo em que operaes de E/S eram realizadas apenas para transferir dados entre a
memria primria e meios de armazenamento de massa tais como fitas e discos magnticos.
Atualmente, operaes de E/S so realizadas tambm para outros propsitos, tais como
comunicao entre processos e em redes de computadores. Portanto, parece mais adequado
chamar esta parcela de tempo de comunicao, seja esta comunicao com uma controladora
de fita, de disco, com outro processo ou com outro computador. Esta pesquisa atribui a
te/s esta ltima caracterizao, mais ampla.
Em muitos sistemas, uma destas parcelas domina tt . Os sistemas nos quais te/s
dominante, como os que processam dados comerciais, so chamados de intensivos em E/S.
J os sistemas nos quais tp dominante, como os que realizam clculos cientficos, so
chamados de intensivos em processamento.
Dada a natureza dos sistemas intensivos em processamento, s possvel aumentar
significativamente o seu desempenho reduzindo tp . Nestes sistemas, redues em te/s tm
baixo impacto sobre tt . Por exemplo, suponha que em um sistema te/s e tp respondam por
20% e 80% de tt , respectivamente. Neste caso, uma reduo de 50% em te/s reduzir tt em
apenas 10%. J uma reduo de tambm 50% em tp reduzir tt em 40%.
Captulo 2. Conceitos Bsicos
23
Nos sistemas intensivos em E/S, os papis se invertem. Redues em tp tm baixo

impacto sobre tt . Portanto, nestes sistemas, reduzir te/s a melhor estratgia quando se
deseja reduzir tt .
2.2 Otimizao de Sistemas Intensivos em E/S

Esta seo discute estratgias para aumentar o desempenho de sistemas intensivos
em E/S.
2.2.1 Caching
Caching consiste em armazenar na memria primria o resultado das operaes
de entrada que um sistema executa repetidas vezes. Desta forma, quando um sistema
precisa, pela primeira vez, de um dado que no est na memria primria, uma operao
de entrada executada. Quando o sistema precisar novamente do mesmo dado, ele j se
encontrar na memria primria, no sendo necessrio efetuar uma operao de entrada
novamente.
2.2.2 Agregao
Operaes de E/S exibem uma latncia significativa. Ou seja, o intervalo de tempo
transcorrido entre o incio e o fim de uma operao de E/S no desprezvel, mesmo
quando o volume de dados transferidos o menor possvel (um bloco de um disco, por
exemplo). Agregando diversas operaes de E/S em uma nica operao que produz os
mesmos efeitos das operaes agregadas, a latncia das operaes de E/S incide sobre um
sistema uma nica vez ao invs 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 so carregados imediatamente antes do instante t em que um sistema os manipula.
No segundo caso, eles so carregados com alguma antecedncia a t.
O pr-carregamento propriamente dito no uma otimizao. Entretanto, por ser
necessrio agregao de operaes de entrada, ele muitas vezes confundido com a
ltima, esta sim uma otimizao. Tal confuso lamentvel, pois, apesar de necessrio, o
pr-carregamento no suficiente para a agregao, j que possvel pr-carregar dados
executando operaes de entrada que no foram agregadas.
24
2.2.3.1 Pr-carregamento Informado e Especulativo

O pr-carregamento pode ser informado ou especulativo. No primeiro caso,
necessrio que programadores informem quais dados devem ser pr-carregados. O segundo
caso elimina esta necessidade empregando mtodos que especulam quais dados sistemas
manipulam. Os mtodos se baseiam em informaes coletadas esttica ou dinamicamente.
De maneira geral, quanto mais prximas do sistema forem as informaes coletadas, mais
corretas so as especulaes dos mtodos.
Como os mtodos de especulao so falveis, o pr-carregamento baseado neles
pode carregar menos ou mais dados do que o necessrio, reduzindo o desempenho de
sistemas. Um mtodo que costuma falhar por excesso, por exemplo, consiste em supor que
sistemas sempre manipulam todos os dados associados a um dado inicial. Graas a mtodos
imprecisos como este, o carregamento sob demanda visto como uma otimizao, pois ele
nunca carrega mais dados do que o necessrio. importante ressaltar, entretanto, que o
carregamento sob demanda nunca mais rpido do que o pr-carregamento executado a
partir de informaes ou especulaes corretas e costuma ser significativamente mais lento
do que este pr-carregamento combinado com a agregao de operaes de entrada.
2.2.4 Compresso
O tempo de execuo de operaes de E/S uma funo monotnica no-decrescente
do volume de dados transferidos. Portanto, comprimindo dados antes de transferi-los, reduzse potencialmente o tempo de execuo de operaes de E/S. necessrio descomprimir
os dados aps transferi-los, o que aumenta tp . Este aumento, entretanto, no costuma ser
significativo frente reduo no tempo de execuo das operaes de E/S, fazendo com
que o saldo final desta estratgia seja positivo.
2.2.5 Concorrncia
Caching, agregao e compresso reduzem te/s otimizando as operaes de E/S que
um sistema executa. Uma estratgia ortogonal s anteriores para reduzir te/s consiste em
executar estas operaes concorrentemente, sem atuar sobre seu desempenho. Por exemplo,
suponha que um sistema executa duas operaes independentes cujos tempos de execuo
so t1 e t2 , respectivamente. Se o sistema executa estas operaes sequencialmente, ento te/s
ser a soma de t1 e t2 . Entretanto, se o sistema executa estas operaes concorrentemente,
ento te/s vai variar do mximo entre t1 e t2 (melhor caso) soma de t1 e t2 (pior caso). O
melhor caso ocorrer se existirem os recursos necessrios execuo paralela das operaes.
No outro extremo, se s existirem recursos suficientes para executar uma operao de cada
vez, ocorrer o pior caso.
O exemplo anterior, apesar de bastante simples, ilustra as condies que um sistema
25
deve satisfazer para que a execuo concorrente de operaes de E/S seja uma otimizao
eficaz:
1. o sistema executa um nmero significativo de operaes independentes;
2. os tempos de execuo das operaes so similares;
3. existem recursos computacionais suficientes para executar as operaes em paralelo.
Se a primeira condio falsa, ento existem poucas oportunidades para executar
operaes de E/S em paralelo. Se a segunda condio no verdadeira, ento a diferena
entre o tempo que o processador espera pela execuo sequencial e paralela das operaes
no significativo. Por fim, se a terceira condio no satisfeita, ento as operaes so
executadas sequencialmente mesmo quando o sistema as requisita concorrentemente.
2.3 Carregamento sob Demanda, Pr-carregamento e Agregao

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 cdigo Java da Figura 4 exemplifica o segundo tipo de requisio. A linha 1 contm
uma consulta JPQL (Java Persistence Query Language) (GROUP, 2013) que especifica as
mensagens enviadas pelo usurio cujo identificador igual a 1 . As linhas 23 requisitam
estas mensagens a ORMs compatveis com a especificao JPA. As sees A.1 e A.2 contm
o cdigo das classes que este trecho de cdigo 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 informaes acerca do
objeto propriamente dito. O nome de um usurio e a data de envio de uma mensagem
so exemplos deste tipo. O tipo II representa associaes entre objetos. Exemplos deste
ltimo tipo so o remetente, os destinatrios 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, ento 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 cdigo da Figura 4.
1
2
3
26
S t r i n g j p q l = " s e l e c t m from Message m where m. s e n d e r . i d = 1 " ;

TypedQuery<Message> query = j p a . c r e a t e Q u e r y ( j p q l , Message . c l a s s ) ;
L i s t <Message> me ssa ge s = query . g e t R e s u l t L i s t ( ) ;
4
5
6
7
f o r ( Message message : m ess age s ) {

p r i n t l n ( message . getDate ( ) ) ;
p r i n t l n ( message . g e t S u b j e c t ( ) ) ;
User s e n d e r = message . g e t S e n d e r ( ) ;
p r i n t l n ( s e n d e r . getName ( ) ) ;
9
10
11
L i s t <User> r e c i p i e n t s = message . g e t R e c i p i e n t s ( ) ;
f o r ( User r e c i p i e n t : r e c i p i e n t s ) {
p r i n t l n ( r e c i p i e n t . name ) ;
}
12
13
14
15
16
L i s t <F i l e > f i l e = message . g e t F i l e s ( ) ;

println ( f i l e s . size () > 0);
17
18
19
Figura 4 Trecho de cdigo Java que requisita objetos especificando o predicado que eles
devem satisfazer.
s e l e c t sent_date from message where i d e n t i f i e r = / . . . /
2
3
s e l e c t s u b j e c t from message where i d e n t i f i e r = / . . . /
4
5
s e l e c t s e n d e r _ i d e n t i f i e r from message where i d e n t i f i e r = / . . . /
6
7
8
s e l e c t u s e r _ i d e n t i f i e r from m e s s a g e _ r e c i p i e n t s
where m e s s a g e _ i d e n t i f i e r = / . . . /
9
10
11
s e l e c t f i l e _ i d e n t i f i e r from m e s s a g e _ f i l e
where m e s s a g e _ i d e n t i f i e r = / . . . /
Figura 5 Consultas SQL que ORMs executam para carregar sob demanda os atributos
de mensagens manipulados pelo trecho de cdigo da Figura 4.
27
s e l e c t from message where i d e n t i f i e r = / . . . /
Figura 6 Consulta SQL que pr-carrega todos os atributos do primeiro tipo de uma
mensagem.
1
2
3
4
select
l e f t join
on
where
message . , s e n d e r . from message

user_table sender
s e n d e r . i d e n t i f i e r = message . s e n d e r _ i d e n t i f i e r
message . i d e n t i f i e r = / . . . /
Figura 7 Consulta SQL que pr-carrega todos os atributos do tipo I de uma mensagem
e, atravs de uma juno, tambm seu remetente.
Por outro lado, se ORMs pr-carregam especulativamente atributos do tipo I, ento
eles executam a consulta SQL exibida na Figura 6 ao invs das duas primeiras consultas
SQL da Figura 5.
2.3.2 Carregamento de Atributos do Tipo I

um tanto surpreendente, mas os tempos de execuo t1 , t2 e t3 das duas primeiras
consultas SQL da Figura 5 e da consulta SQL da Figura 6, respectivamente, so similares.
Isto acontece porque as latncias dos canais de comunicao entre ORMs e bancos de
dados dominam estes tempos. (BOWMAN; SALEM, 2007), por exemplo, relata que a
latncia corresponde a 95% ou mais do tempo de execuo de consultas SQL que, como
estas, selecionam uma nica linha e podem ser respondidas com ndices.
Portanto, no trecho de cdigo da Figura 4, se ORMs carregam atributos sob
demanda, ento o tempo de carregamento dos atributos do tipo I de cada mensagem ser
igual a t1 +t2 2t3 , enquanto que se eles pr-carregam atributos do tipo I especulativamente,
este tempo ser igual t3 , ou seja, aproximadamente metade do primeiro. por conta de
redues assim que ORMs pr-carregam atributos do tipo I especulativamente.
2.3.3 Carregamento de Atributos do Tipo II que Referenciam Objetos

ORMs precisam decidir como carregar os atributos tipo II. Uma estratgia consiste
em tambm pr-carreg-los. A Figura 7, por exemplo, exibe a consulta SQL que ORMs
executam para pr-carregar todos os atributos de uma mensagem do tipo I e, atravs
de uma juno (AHO; BEERI; ULLMAN, 1979), tambm um atributo do tipo II: seu
remetente.
Apesar de ser mais complexa do que a da Figura 6, a consulta SQL da Figura
7 tambm goza das propriedades que fazem com que sua execuo seja dominada pela
latncia: ela seleciona uma nica linha e pode ser respondida com ndices. O remetente de
28
uma mensagem um exemplo de atributo do tipo II que referencia um nico objeto. De

maneira geral, o tempo de execuo de consultas SQL que pr-carregam somente atributos
do tipo I apenas um pouco menor do que o daquelas que tambm pr-carregam atributos
do tipo II que referenciam objetos. por conta disto que alguns ORMs, em particular
aqueles compatveis com a especificao JPA, pr-carregam especulativamente atributos do
tipo II que referenciam objetos.
2.3.4 Carregamento de Atributos do Tipo II que Referenciam Colees

ORMs ainda precisam decidir como carregar os atributos do tipo II que referenciam
colees (listas, conjuntos, mapas, etc.) de objetos. Pr-carreg-los no uma boa idia
pois, diferentemente dos casos anteriores, as consultas SQL que tambm pr-carregam
estes atributos, na maioria dos casos, selecionam mais de uma linha e, quanto maior o
nmero de linhas selecionadas, menor a influncia da latncia no tempo de execuo de
consultas SQL. Colocando de outra forma: o tempo de execuo das consultas SQL que
pr-carregam atributos do tipo I e do tipo II que referenciam objetos costuma ser menor
que a latncia, enquanto que o tempo de execuo daquelas que tambm pr-carregam
atributos do tipo II que referenciam colees costuma ser maior.
A consulta SQL da Figura 8, por exemplo, pr-carrega todos os atributos de
uma mensagem. Sejam nr , na e nt o nmero de destinatrios, anexos e tags da mensagem,
respectivamente. Ento esta consulta seleciona max(1, nr )max(1, na )max(1, nt ) linhas.
ORMs carregam sob demanda atributos do tipo II que referenciam colees injetando
proxies (GAMMA et al., 1994) nos atributos. Cada proxy carrega e armazena a coleo
que ele representa quando um sistema executa qualquer mtodo dele pela primeira vez.
Em seguida, ele encaminha a execuo do mtodo coleo. Quando o sistema executa
qualquer mtodo do proxy novamente, ele apenas encaminha a execuo do mtodo para
a coleo. ORMs tambm usam proxies para carregar sob demanda atributos do tipo I ou
do tipo II que referenciam objetos.
2.3.5 Pr-carregamento Informado

Carregando sob demanda e pr-carregando atributos tal como descrito at aqui,
ORMs executam duas consultas a cada iterao do lao da Figura 4. A primeira carrega os
destinatrios de uma mensagem. A segunda seus anexos. Portanto, se o lao executado
n vezes, ento ORMs executam 2n consultas.
Entretanto, ORMs podem pr-carregar os remetentes e os anexos de todas as
mensagens que o lao da Figura 4 manipula executando apenas as duas consultas que
fazem uso do operador i n de SQL exibidas na Figura 9.
O pr-carregamento dos destinatrios e anexos pode ser informado ou especulativo.
1
2
3
29
s e l e c t message . , s e n d e r . , r e c i p i e n t . , f i l e . , t a g . from message

l e f t join user_table sender
on s e n d e r . i d e n t i f i e r = message . s e n d e r _ i d e n t i f i e r
4
5
6
7
8
l e f t join
on
l e f t join
on
message_recipient
m e s s a g e _ r e c i p i e n t . m e s s a g e _ i d e n t i f i e r = message . i d e n t i f i e r
user_table r e c i p i e n t
r e c i p i e n t . i d e n t i f i e r = message_recipient . r e c i p i e n t _ i d e n t i f i e r
l e f t join
on
l e f t join
on
message_file
m e s s a g e _ f i l e . m e s s a g e _ i d e n t i f i e r = message . i d e n t i f i e r
file
f i l e . i d e n t i f i e r = message_file . f i l e _ i d e n t i f i e r
l e f t join
on
l e f t join
on
where
message_tag
message_tag . m e s s a g e _ i d e n t i f i e r = message . i d e n t i f i e r
tag
t a g . i d e n t i f i e r = message_tag . t a g _ i d e n t i f i e r
message . i d e n t i f i e r = / . . . /
9
10
11
12
13
14
15
16
17
18
19
Figura 8 Consulta SQL que pr-carrega todos os atributos de uma mensagem.
1
2
3
4
5
6
select
l e f t join
on
l e f t join
on
where
r e c i p i e n t . from message
message_recipient
m e s s a g e _ r e c i p i e n t . m e s s a g e _ i d e n t i f i e r = message . i d e n t i f i e r
user_table r e c i p i e n t
r e c i p i e n t . i d e n t i f i e r = message_recipient . r e c i p i e n t _ i d e n t i f i e r
message . i d e n t i f i e r in ( / . . . / )
select
l e f t join
on
l e f t join
on
where
f i l e . from message
message_file
m e s s a g e _ f i l e . m e s s a g e _ i d e n t i f i e r = message . i d e n t i f i e r
file
f i l e . i d e n t i f i e r = message_file . f i l e _ i d e n t i f i e r
message . i d e n t i f i e r in ( / . . . / )
7
8
9
10
11
12
13
Figura 9 Consultas que pr-carregam os destinatrios e os remetentes de vrias mensagens

atravs do operador in de SQL.
1
2
30
S t r i n g j p q l = " s e l e c t m from Message m where m. s e n d e r . i d = 1 " ;

TypedQuery<Message> query = j p a . c r e a t e Q u e r y ( j p q l , Message . c l a s s ) ;
3
4
5
6
7
EntityGraph<Message> s p e c = manager . c r e a t e E n t i t y G r a p h ( Message . c l a s s ) ;

s p e c . addSubgraph ( " r e c i p i e n t s " ) ;
s p e c . addSubgraph ( " f i l e s " ) ;
query . s e t H i n t ( " j a v a x . p e r s i s t e n c e . l o a d g r a p h " , s p e c ) ;
8
9
10
11
Figura 10 Trecho de cdigo Java que informa a ORMs compatveis com a especificao
JPA quais objetos eles devem pr-carregar.
A Figura 10 exemplifica o primeiro. Ela adiciona ao trecho de cdigo da Figura 4 as linhas
47. Elas requisitam a ORMs compatveis com a especificao JPA o pr-carregamento
dos destinatrios e anexos das mensagens resultantes da consulta JPQL da linha 1.
2.3.6 Pr-carregamento Especulativo

O lao da Figura 4 bastante regular. Ele sempre navega de cada mensagem para seu
remetente, destinatrios e anexos. Regularidades como esta motivaram (BERNSTEIN; PAL;
SHUTT, 2000) a propor um mtodo de especulao 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 prcarregado pela operao (consulta, navegao, etc.) que carregou ou pr-carregou A.
Quando um sistema navega de A para outro objeto B atravs de um atributo b, ORMs
pr-carregam todos os objetos referenciados pelos objetos do contexto de A atravs do
atributo b.
Aplicando este mtodo no trecho de cdigo da Figura 4, ORMs pr-carregam os
destinatrios e os anexos de todas as mensagens quando as linhas 12 e 17 so executadas,
respectivamente, pela primeira vez.
2.4 Hiptese
A partir das discusses e exemplos das sees anteriores, esta seo justifica a
hiptese 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 programao exibido na Figura 4
(IBRAHIM; WIEDERMANN; COOK, 2009). Neste estilo, comum que sistemas, exceto os
31
mais simples, naveguem atravs de dois ou mais atributos do tipo II. Nestes casos, tal como
exemplificado na Subseo 2.3.5, as consultas que pr-carregam os objetos referenciados
pelos atributos so independentes.
As consultas que ORMs executam para pr-carregar objetos referenciados por
atributos do tipo II so bastante simples. Como elas so compostas apenas por restries
sobre chaves primrias e estrangeiras, seus tempos de execuo costumam ser dominados
pelas latncias dos canais de comunicao 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 so executados com frequncia em
instalaes que possuem os recursos necessrios para a execuo paralela de diversas
consultas. O surgimento e a popularizao da computao em nuvem (ARMBRUST et al.,
2010) tm contribudo para que isto ocorra cada vez mais.
Como ORMs executam consultas atravs de operaes de E/S, as ltimas gozam
das propriedades das primeiras. Por exemplo, se duas consultas so independentes, ento
as operaes de E/S atravs das quais elas so executadas tambm so independentes.
Conclui-se, portanto, que, em muitos casos, ORMs pr-carregam objetos executando
operaes de E/S independentes, cujos tempos de execuo so similares e existem recursos
computacionais suficientes para executar estas operaes em paralelo. Ou seja, o prcarregamento de objetos executado por ORMs satisfaz as condies discutidas na seo
2.2.5 para que a execuo concorrente de operaes de E/S seja uma otimizao eficaz.
32
3 Litoral
Este captulo apresenta Litoral, uma DSL para especificao de navegaes por
objetos.
3.1 Requisitos
A fase de anlise (MERNIK; HEERING; SLOANE, 2005) do desenvolvimento de
Litoral, determinou que a linguagem deveria atender os requisitos a seguir.
Embarque: deve ser possvel embutir Litoral em linguagens orientadas a objetos
que suportam reflexo. Mais especificamente, que permitem a sistemas, em tempo de
execuo, descobrir a classe de um objeto e obter o valor de um atributo a partir do seu
nome.
Independncia: Litoral deve ser independente de mecanismos de acesso a dados,
ou seja, ela deve ser capaz de especificar navegaes por objetos armazenados em bancos
de dados (relacionais ou no), sistemas de arquivos, outros sistemas, etc.
Agregao: tal como ocorre em linguagens orientadas a colees (SIPELSTEIN;
BLELLOCH, 1991), as construes de Litoral devem operar sobre agregaes de outros
tipos de dados. Litoral satisfaz este requisito tratando objetos como colees unitrias e
oferecendo construes que operam apenas sobre colees.
Recurso: Litoral deve ser capaz de especificar navegaes iterativas e recursivas.
O conceito de travessia, apresentado nas sees 3.3.4 e 3.3.5, cumpre esta demanda.
Conciso: especificaes Litoral sero tipicamente armazenadas em variveis
ou passadas como parmetros em linguagens orientadas a objetos, da a importncia delas
ocuparem poucas linhas de cdigo.
Segurana: erros do tipo null pointer (HOVEMEYER; SPACCO; PUGH, 2005)
no devem ocorrer. Para atender este requisito, Litoral verifica se possvel navegar
atravs de um atributo, ou seja, se ele referencia algum objeto. Em caso positivo, a
navegao executada, caso contrrio ela interrompida.
Declarao: Litoral deve ser uma linguagem declarativa, ou seja, ela deve
oferecer construes que permitem especificar navegaes sem entrar nos detalhes de como
elas devem ser executadas.
Concorrncia: especificaes Litoral devem codificar tanto dependncias entre
navegaes, ou seja, quando uma segunda navegao s pode ser executada aps uma
primeira, quanto as oportunidades para que elas sejam executadas concorrentemente.
Captulo 3. Litoral
1
2
3
4
5
33
L i s t <Message> g e t M e s s a g e s ( int u s e r I d ) {
S t r i n g j p q l = " s e l e c t m from Message m where m. s e n d e r . i d = " + u s e r I d ;
TypedQuery<Message> query = orm . c r e a t e Q u e r y ( j p q l , Message . c l a s s ) ;
return query . g e t R e s u l t L i s t ( ) ;
}
Figura 11 Mtodo Java que carrega as mensagens enviadas por um usurio.

1
2
L i s t <Message> g e t M e s s a g e s ( int u s e r I d ) {
S t r i n g j p q l = " s e l e c t m from Message m where m. s e n d e r . i d = " + u s e r I d ;
EntityGraph<Message> s p e c = manager . c r e a t e E n t i t y G r a p h ( Message . c l a s s ) ;

s p e c . addSubgraph ( " r e c i p i e n t s " ) ;
4
5
6
TypedQuery<Message> query = orm . c r e a t e Q u e r y ( j p q l , Message . c l a s s ) ;

query . s e t H i n t ( " j a v a x . p e r s i s t e n c e . l o a d g r a p h " , s p e c ) ;
return query . g e t R e s u l t L i s t ( ) ;
7
8
9
10
Figura 12 Mtodo Java que carrega as mensagens enviadas por um usurio e pr-carrega
seus remetentes.
Por independerem de mecanismos de acesso a dados, especificaes Litoral podem
ser facilmente incorporadas a qualquer camada (apresentao, negcio, acesso a dados,
etc.) de um sistema. Para perceber porque isto importante, suponha que o mtodo
g e t M e s s a g e s exibido na Figura 11 pertena camada de acesso a dados de um sistema.
Suponha tambm que um desenvolvedor identificou que, aps invocar g e t M e s s a g e s , uma
parte do sistema navega das mensagens retornadas por este mtodo para seus remetentes.
A partir desta constatao, o desenvolvedor decide modificar o mtodo g e t M e s s a g e s para
que ele, alm de carregar as mensagens enviadas por um usurio, tambm pr-carregue
seus remetentes. Esta modificao pode ser vista nas linhas 45 e 8 da segunda verso do
mtodo g e t M e s s a g e s exibida na Figura 12.
A segunda verso de g e t M e s s a g e s aumenta o desempenho da parte do sistema que
o desenvolvedor analisou. Isto acontece porque o ORM, fazendo uso de junes, carrega
as mensagens e seus remetentes executando uma nica consulta SQL enquanto que na
primeira verso de g e t M e s s a g e s , o ORM executa no mnimo duas consultas, uma para
carregar as mensagens e outra para carregar seus remetentes. A primeira executada
imediatamente. A segunda executada apenas quando o sistema navega para os remetentes.
Infelizmente, a segunda verso de g e t M e s s a g e s reduz o desempenho de outras
partes do sistema que tambm utilizam este mtodo mas que no navegam das mensagens
para seus remetentes. Nestes casos, a segunda verso de g e t M e s s a g e s pr-carrega os remetentes desnecessariamente. Para evitar esta perda de desempenho, resta ao desenvolvedor
Captulo 3. Litoral
34
(a)
(b)
Figura 13 Gramtica de Litoral em notao EBNF e em diagramas de sintaxe.

uma nica alternativa, manter as duas verses de g e t M e s s a g e s no sistema, utilizando
cada uma delas quando for mais apropriado.
fcil ver que existe uma forte tenso entre desempenho e reuso de cdigo
(IBRAHIM; COOK, 2006). O problema aqui que a especificao 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 cdigo. Especificaes Litoral, por outro lado,
podem ser incorporadas aos pontos mais externos de sistemas (por exemplo, nas camadas
de apresentao), tendo, portanto, efeitos mais localizados.
3.2 Sintaxe
A figura 13 apresenta a gramtica de Litoral em notao EBNF (Extended
BackusNaur Form) e tambm atravs de diagramas de sintaxe. Os smbolos 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 t e p so no-terminais. ID e os smbolos entre aspas simples so
terminais. s p e c i f i c a t i o n o smbolo inicial. A expresso regular [ azAZ ] [ azAZ0 9]
gera ID, ou seja, um ID formado por uma letra seguida de outras letras ou nmeros.
Captulo 3. Litoral
1
2
3
4
35
void p r i n t M e s s a g e ( Message message ) {

p r i n t l n ( message . getDate ( ) ) ;
p r i n t l n ( message . g e t S u b j e c t ( ) ) ;
p r i n t l n ( message . getBody ( ) ) ;
p r i n t U s e r ( message . g e t S e n d e r ( ) ) ;
6
7
f o r ( User r e c i p i e n t : message . g e t R e c i p i e n t s ( ) ) {
printUser ( recipient ) ;
}
8
9
10
11
f o r ( F i l e attachment : message . getAttachments ( ) ) {

p r i n t l n ( attachment . getName ( ) ) ;
12
13
14
printMediaType ( attachment . getMediaType ( ) ) ;
15
16
17
f o r ( Message r e p l y : message . g e t R e p l i e s ( ) ) {
printMessage ( reply ) ;
}
18
19
20
21
22
23
24
void p r i n t U s e r ( User u s e r ) {
p r i n t l n ( u s e r . getName ( ) ) ;
25
printFile ( user . getPicture ( ) ) ;
26
27
28
29
30
void p r i n t F i l e ( F i l e f i l e ) {
p r i n t l n ( f i l e . getName ( ) ) ;
31
printMediaType ( f i l e . getMediaType ( ) ) ;
32
33
34
35
36
37
38
void printMediaType ( MediaType mediaType ) {

p r i n t l n ( mediaType . getType ( ) ) ;
p r i n t l n ( mediaType . getSubtype ( ) ) ;
}
Figura 14 Trecho de cdigo Java que navega por objetos.
3.3 Semntica Informal

Esta seo se inspira em (MEYEROVICH et al., 2009) e apresenta a semntica de
Litoral informalmente atravs de vrios exemplos que, progressivamente, especificam as
navegaes que o trecho de cdigo Java exibido na Figura 14 executa.
Captulo 3. Litoral
1
36
sender
Figura 15 Especificao Litoral que navega atravs de um nico atributo.

1
2
3
4
5
6
7
8
specification
t r a v e r s a l path
path
s t e p | [ s t e p +]
step
ID | ID . path | ID ( )
ID
sender
//
//
//
//
//
//
//
//
smbolo i n i c i a l
s u b s t i t u i o de s p e c i f i c a t i o n
traversal opcional
s u b s t i t u i o de p a t h
e s c o l h a do p r i m e i r o ramo
s u b s t i t u i o de s t e p
e s c o l h a do p r i m e i r o ramo
ID g e r a s e n d e r

1
recipients
Figura 17 Especificao Litoral que navega atravs de colees de objetos.
3.3.1 Navegando Atravs de um nico Atributo

O mtodo p r i n t M e s s a g e da Figura 14 recebe uma mensagem como parmetro e,
na linha 6, navega para seu remetente atravs do atributo s e n d e r . A Figura 15 exibe
a especificao Litoral que declara esta navegao. Ela no faz nenhuma referncia
mensagem, pois o objeto que d incio a navegaes fica implcito nas especificaes
Litoral. Por um lado, esta caracterstica dificulta a compreenso de especificaes
Litoral quando lidas independentemente do cdigo onde elas sero embutidas. Por outro
lado, entretanto, ela torna as especificaes Litoral mais concisas.
A Figura 16 mostra como gerar esta especificao a partir da gramtica de Litoral.
Para Litoral irrelevante se atributos referenciam objetos ou colees de objetos.
A sintaxe que especifica navegaes atravs de atributos a mesma em ambos os casos.
A especificao Litoral da Figura 17, por exemplo, declara uma navegao atravs
do atributo r e c i p i e n t s , que referencia uma coleo de objetos. Ela possui a mesma
estrutura sinttica que a especificao da Figura 15, a qual declara uma navegao atravs
do atributo s e n d e r , que referencia um nico objeto.
3.3.2 Navegando Atravs de mais de um Atributo

Nas linha 8 e 12, o mtodo p r i n t M e s s a g e da Figura 14 tambm navega para
destinatrios e anexos de mensagens atravs dos atributos r e c i p i e n t s e a t t a c h m e n t s ,
respectivamente. A Figura 18 exibe a especificao Litoral que declara navegaes de
mensagens para seus remetentes, destinatrios e anexos. Os caracteres [ (abre colchetes) e
Captulo 3. Litoral
1
[
sender
recipients
attachments
2
3
4
5
37
Figura 18 Especificao Litoral que navega atravs de mais de um atributo.

1
2
3
4
path
s t e p | [ s t e p +]
[ s t e p +]
[ step step step ]
//
//
//
//
traversal opcional
s u b s t i t u i o de p a t h
e s c o l h a do segundo ramo
s u b s t i t u i o de s t e p+
// e s p a o s em branco e c a r a c t e r e s
// de nova l i n h a so i g n o r a d o s
5
6
step
step
step
7
8
9
10
11
12
[
sender
recipients
attachments
13
14
15
16
// s t e p g e r a sender , r e c i p i e n t s
// e a t t a c h m e n t s

1
[ sender ]
Figura 20 Especificao Litoral que navega por um nico atributo.

(fecha colchetes) delimitam lista de atributos de um objeto atravs dos quais navegaes
so executadas. Estes atributos so separados por espaos em branco ou caracteres de
nova linha.
]
A Figura 19 mostra como gerar esta especificao a partir do smbolo no terminal

path .
Pode-se omitir os delimitadores de listas formadas por um nico atributo. Portanto,

a especificao Litoral exibida na Figura 20 semanticamente equivalente exibida na
Figura 15
3.3.3 Navegando Indiretamente

At aqui, as especificaes Litoral declararam navegaes apenas para objetos
referenciados diretamente por um objeto inicial. Litoral, entretanto, expressiva o
Captulo 3. Litoral
1
[
sender
recipients
a t t a c h m e n t s . mediaType
2
3
4
5
38
Figura 21 Especificao Litoral que navega indiretamente.

1
[
s e n d e r . p i c t u r e . mediaType
recipients
2
3
4
5
Figura 22 Especificao Litoral que encadeia navegaes indiretas.

bastante para especificar navegaes indiretas, ou seja, navegaes de um objeto inicial
para um objeto intermedirio e, deste ltimo, para um objeto final, e assim por diante. Por
exemplo, na linha 15 da Figura 14, o mtodo p r i n t M e s s a g e 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, intermedirio e final, respectivamente. A linha 4 da especificaoLitoral
exibida na Figura 21 incorpora esta navegao indireta atravs do operador . (ponto).
Em navegaes indiretas, comum que um objeto intermedirio funcione como o
objeto inicial de uma nova navegao indireta. Navegaes deste tipo so especificadas
em Litoral encadeando aplicaes do operador . (ponto). O mtodo p r i n t M e s s a g e
da Figura 14, por exemplo, navega de uma mensagem para seu remetente atravs do
atributo s e n d e r , deste remetente para sua fotografia atravs do atributo p i c t u r e e desta
fotografia para o tipo do arquivo que a armazena atravs do atributo mediaType . A linha
2 da especificao Litoral exibida na Figura 22 incorpora esta navegao encadeando o
operador . (ponto).
Em navegaes indiretas, possvel que o atributo que leva ao objeto intermedirio
no referencie nenhum objeto ou referencie uma coleo vazia. Isto aconteceria, por exemplo,
se as navegaes que a especificao da Figura 22 declara fossem realizadas a partir de
uma mensagem sem remetente ou sem anexos. No primeiro caso, no seria possvel navegar
para a foto do remetente. No segundo caso, no seria possvel navegar para o tipo dos
arquivos anexados mensagem. Na maioria das linguagens de programao, navegaes
indiretas atravs de atributos que no referenciam nenhum objeto provocam um erro em
tempo de execuo. Estes erros no acontecem em Litoral pois as navegaes indiretas
declaradas por uma especificao Litoral s sero realizadas quando possvel, ou seja,
quando existir o objeto intermedirio e, caso ele seja uma coleo de objetos, apenas se
no for uma coleo vazia.
Captulo 3. Litoral
1
[
s e n d e r . p i c t u r e . mediaType
r e c i p i e n t s . p i c t u r e . mediaType
2
3
4
5
39
Figura 23 Especificao Litoral que replica uma navegao.

1
2
3
4
5
6
v i s i t U s e r = p i c t u r e . mediaType
[
sender . v i s i t U s e r ()
recipients . visitUser ()
]
Figura 24 Especificao Litoral que define uma travessia.
3.3.4 Travessias
O mtodo p r i n t M e s s a g e da Figura 14 navega no s de uma mensagem at o
tipo da fotografia do seu remetente, mas tambm at o tipo da fotografia de cada um dos
destinatrios desta mensagem. A linha 3 da especificao Litoral exibida na Figura 23
incorpora esta ltima navegao.
Apesar de correta, a especificao da Figura 23 possui uma replicao indesejvel,
pois mudanas no mtodo p r i n t U s e r da Figura 14 precisaro ser refletidas nela duas
vezes. Litoral permite que replicaes deste tipo sejam eliminadas com travessias, que
nada mais so 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 necessrio. A linha 1 da Figura 24, por exemplo, define uma travessia chamada
v i s i t U s e r cujo caminho p i c t u r e . mediaType . As linhas 4 e 5 iniciam esta travessia a
partir do remetente e dos destinatrios de uma mensagem, respectivamente.
A Figura 25 mostra como gerar esta especificao a partir da gramtica de Litoral.
3.3.5 Travessias Recursivas

Travessias podem iniciar outras travessias e, em particular, a si mesmas. Isto nos
permite escrever a verso final da especificao Litoral que declara os objetos pelos
quais o mtodo p r i n t M e s s a g e da Figura 14 navega. Esta ltima verso, 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 , alm de iniciar a travessia v i s i t U s e r nas linhas 4 e 5, inicia a
si mesma na linha 8.
A linha 8 da especificao da Figura 26 sugere uma recurso infinita. Entretanto,
Captulo 3. Litoral
1
2
3
4
40
specification
ID=path path
//
//
//
//
smbolo i n i c i a l
s u b s t i t u i o de program
s u b s t i t u i o de t r a v e r s a l
s u b s t i t u i o de t r a v e r s a l
ID=path
path
// e s p a o s em branco so i g n o r a d o s
v i s i t U s e r=path
path
// ID g e r a v i s i t U s e r
v i s i t U s e r=p i c t u r e . mediaType
[
sender . step
r e c i p i e n t s . step
]
// p a t h g e r a p i c t u r e . mediaType
// p a t h g e r a [
//
sender . step
//
recipients . step
//
]
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[
s e n d e r . ( ID | ID . path | ID ( ) )
// s u b s t i t u i o de s t e p
r e c i p i e n t s . ( ID | ID . path | ID ( ) ) // s u b s t i t u i o de s t e p
]
23
24
25
26
27
28
[
s e n d e r . ID ( )
r e c i p i e n t s . ID ( )
]
// e s c o l h a do t e r c e i r o ramo
// e s c o l h a do t e r c e i r o ramo
29
30
31
32
33
34
[
]
Captulo 3. Litoral
1
41
v i s i t U s e r = p i c t u r e . mediaType
2
3
4
5
6
visitMessage = [
r e p l i e s . visitMessage ()
8
9
10
11
visitMessage ()
Figura 26 Especificao Litoral que define uma travessia recursiva.

similarmente ao que ocorre em navegaes indiretas, travessias s so iniciadas quando
possvel, ou seja, quando o objeto a partir do qual elas so iniciadas existe e, caso ele seja
uma coleo de objetos, apenas se no for uma coleo vazia. graas a este comportamento
que a especificao da Figura 26 no contm uma recurso infinita, pois, eventualmente,
ele navegar at uma mensagem que no possui rplicas, ou seja, seu atributo r e p l i e s
referencia uma coleo vazia. Quando isto ocorrer, a travessia v i s i t M e s s a g e no ser
iniciada, encerrando a recurso.
Por outro lado, mesmo iniciando travessias apenas quando possvel, especificaes
Litoral ainda podem entrar em recurso infinita se elas declararem navegaes recursivas
por objetos que se auto-referenciam direta ou indiretamente. Por exemplo, se as navegaes
que a especificao da Figura 26 declara fossem realizadas a partir de uma mensagem que
rplica de si mesma, ocorreria uma recurso infinita.
possvel definir uma semntica para Litoral que evita recursses infinitas
mesmo na presena de estruturas circulares de objetos. Pode-se, por exemplo, registrar
para quais objetos j se navegou, evitando navegar para eles novamente. A prxima sesso
detalha esta e outras abordagens.
3.4 Interpretador Definidor

Esta seo torna mais precisa a semntica de Litoral atravs de um interpretador
definidor (REYNOLDS, 1972). O interpretador foi desenvolvido com o assistente de provas
(GEUVERS, 2009) Coq (BERTOT; CASTRAN, 2004). Usurios de Coq definem objetos
matemticos (conjuntos, funes, etc.) em uma linguagem similar a Standard ML (Meta
Language) (MILNER, 1997) chamada Gallina. Entretanto, enquanto Standard ML suporta
os paradigmas de programao funcional e imperativo (ROY et al., 2009), Gallina suporta
Captulo 3. Litoral
1
42
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 Representao de classes e objetos no interpretador definidor.

apenas o primeiro. Outra diferena importante que apenas funes totais1 so definveis
em Gallina. Standard ML, por outro lado, suporta tanto funes totais quanto parciais.
3.4.1 Representao de Classes e Objetos

Litoral foi concebida para ser embarcada em linguagens orientadas a objetos que
suportam reflexo. Infelizmente, classes, objetos e reflexo no esto 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 so apenas entidades que associam nomes
a valores. Conceitos como herana e polimorfismo, por exemplo, no so relevantes.
Adicionalmente, no importa para Litoral se um atributo referencia um nico objeto ou
uma coleo de objetos. Por fim, a distino entre objetos e valores de tipos primitivos
presentes em algumas linguagens orientadas a objetos como Java tambm no relevante.
Estas observaes, acrescidas da necessidade de reflexo, motivam a representao de
classes e objetos com os tipos exibidos na Figura 27.
Um valor do tipo CLASS representa uma classe e construdo 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 so, 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 construdo a partir
do identificador ( s t r i n g ) e dos atributos ( l i s t ) deste objeto. Cada atributo representado 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 so,
respectivamente, o nome ( s t r i n g ) e o valor do atributo ( l i s t s t r i n g ) .
O valor de um atributo representado por uma lista de identificadores de objetos.
Esta representao simplifica a implementao do interpretador, pois permite que ele lide
uniformemente com atributos que referenciam um nico objeto ou colees de objetos.
Valores do tipo CLASS referenciam-se indiretamente atravs de seus nomes. De
maneira similar, valores do tipo OBJ referenciam-se indiretamente atravs de seus identificadores. Por um lado, estas indirees dificultam a implementao do interpretador. Por
outro lado, elas tornam possvel a definio e a instanciao de classes e objetos que se
1
Uma funo f chamada de total quando para todo elemento x de seu domnio existe um elemento y
de seu contradomnio tal que f (x) = y, caso contrrio, f chamada de parcial.
Captulo 3. Litoral
1
2
3
4
5
6
7
43
Definition c l a s s e s := [
C l a s s " MediaType " [ ] ;
C l a s s " F i l e " [ ( " mediaType " , " MediaType " ) ]
C l a s s " User " [ ( " p i c t u r e " , " F i l e " ) ] ;
C l a s s " Message " [ ( " s e n d e r " , " User " ) ; ( " r e c i p i e n t s " , " User " ) ;
( " r e p l i e s " , " Message " ) ] ;
].
Figura 28 Criao de classes no interpretador definidor.

1
Definition ID := s t r i n g .
2
3
4
Inductive STEP :=
L a s t S t e p : ID > STEP | Step : 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 Representao de especificaes Litoral no interpretador definidor.

auto-referenciam direta ou indiretamente. O cdigo 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 Representao de Especificaes Litoral

Especificaes Litoral so representadas atravs de tipos que mimetizam a
gramtica da linguagem, tal como exibido na Figura 29. O trecho de cdigo Gallina exibido
na Figura 30, por exemplo, mostra como instanciar a especificao Litoral da Figura 26
a partir destes tipos.
Um valor do tipo PATH criado, tal como especificado pela gramtica de Litoral,
a partir de uma lista de passos ( l i s t STEP) e tambm de um nmero natural ( nat )
cuja funo ser descrita na seo 3.4.3. Por hora, suficiente saber que valores do tipo
PATH podem ser criados a partir do nmero 0 , tal como exemplificado na Figura 30.
3.4.3 Anlise Semntica

Uma especificao Litoral semanticamente vlida quando ela:
1. no define travessias com nomes repetidos;
Captulo 3. Litoral
1
2
3
4
5
6
7
8
9
10
11
44
Definition s p e c := Spec [
Trav " v i s i t U s e r " ( Path 0 [
Step " p i c t u r e " ( Path 0 [ L a s t S t e p " mediaType " ] )
]);
Trav " v i s i t M e s s a g e " ( Path 0 [
Step " s e n d e r " ( Path 0 [ I n i t " v i s i t U s e r " ] ) ;
Step " r e c i p i e n t s " ( Path 0 [ I n i t " v i s i t U s e r " ] ) ;
Step " a t t a c h m e n t s " ( Path 0 [ L a s t S t e p " mediaType " ] ) ;
Step " r e p l i e s " ( Path 0 [ I n i t " v i s i t M e s s a g e " ] )
])
] ( Path 0 [ I n i t " v i s i t M e s s a g e " ] ) .
Figura 30 Criao de uma especificao Litoral no interpretador definidor.

2. no inicia travessias inexistentes;
3. no referencia atributos inexistentes.
A funo a n a l y z e S p e c da Figura 31d verifica se especificaes Litoral satisfazem
estas condies dividindo o trabalho entre as funes aninhadas i n d e x S p e c da Figura
31a, a n a l y z e T r a v s da Figura 31d, a n a l y z e P a t h da Figura 31c e a n a l y z e C l a s s P a t h s
da Figura 31d.
A funo i n d e x S p e c recebe uma especificao Litoral como argumento e retorna
uma tripla cujo primeiro elemento uma nova especificao s p e c 2 quase idntica
primeira. A nica diferena entre elas que os ndices (os nmeros naturais) dos caminhos
contidos em s p e c 2 so nicos. Portanto, possvel decidir se dois caminhos contidos em
s p e c 2 so iguais comparando seus ndices. O terceiro elemento da tripla retornada por
i n d e x S p e c uma lista formada pelos caminhos contidos em s p e c 2 . O segundo elemento,
por sua vez, o tamanho desta lista.
A funo a n a l y z e T r a v s verifica a primeira condio. Por ser trivial, esta subseo
no discute sua implementao.
Captulo 3. Litoral
1
2
3
4
5
6
7
8
45
Fixpoint i n d e x S t e p s t e p i d x :=
match s t e p with
| L a s t S t e p nm => ( L a s t S t e p nm, idx , [ ] )
| Step nm path =>
l e t ( path , idx , p a t h s ) := indexPath path i d x in
( Step nm path , idx , p a t h s )
| I n i t nm => ( I n i t nm, idx , [ ] )
end
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
with indexPath path i d x : PATH nat l i s t PATH :=

let
i n d e x S t e p s := f i x i n d e x S t e p s s t e p s i d x :=
match s t e p s with
| [ ] => ( [ ] , idx , [ ] )
| s t e p : : s t e p s =>
l e t ( s t e p s , idx , p a t h s ) := i n d e x S t e p s s t e p s i d x in
l e t ( s t e p , idx , paths ) := i n d e x S t e p s t e p idx in
( s t e p : : s t e p s , idx , paths ++ p a t h s )
end
in
l e t Path _ s t e p s := path in
l e t ( s t e p s , idx , p a t h s ) := i n d e x S t e p s s t e p s i d x in
l e t idx := 1 + idx in
l e t path := Path idx s t e p s in ( path , idx , path : : p a t h s ) .
25
26
27
28
29
Definition indexTrav t r a v i d x :=
l e t Trav i d path := t r a v in
l e t ( path , idx , p a t h s ) := indexPath path i d x in
( Trav i d path , idx , p a t h s ) .
30
31
32
33
34
35
36
37
38
Fixpoint i n d e x T r a v s t r a v s i d x :=
match t r a v s with
| [ ] => ( [ ] , idx , [ ] )
| t r a v : : t r a v s =>
l e t ( t r a v s , idx , p a t h s ) := i n d e x T r a v s t r a v s i d x in
l e t ( trav , idx , paths ) := indexTrav t r a v idx in
( trav : : t r a v s , idx , paths ++ p a t h s )
end .
39
40
41
42
43
44
Definition i n d e x S p e c s p e c :=
l e t Spec t r a v s path := s p e c in
l e t ( t r a v s , idx , p a t h s ) := i n d e x T r a v s t r a v s 0 in
l e t ( path , idx , paths ) := indexPath path i d x in
( Spec t r a v s path , idx , paths ++ p a t h s ) .
(a)
Figura 31 Analisador semntico.
Captulo 3. Litoral
1
46
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
4
5
6
7
8
9
10
Definition getPath t r a v s nm :=
let
f t r a v := l e t Trav nm _ := t r a v in s t r E q nm nm
in
match f i n d f t r a v s with
| None => None
| Some ( Trav _ path ) => Some path
end .
11
12
Definition emptyPath := Path 0 [ ] .
13
14
15
Definition g e t C l a s s c l a s s e s nm :=
f i n d ( fun c l a s s => l e t C l a s s nm _ := c l a s s in s t r E q nm nm) c l a s s e s .
16
17
18
19
20
21
Definition g e t C l a s s A t t r c l a s s nm :=
let
f ( a t t r : s t r i n g s t r i n g ) := l e t (nm , _) := a t t r in s t r E q nm nm
in
l e t C l a s s _ a t t r s := c l a s s in f i n d f a t t r s .
22
23
24
25
26
27
Definition g e t A t t r C l a s s c l a s s e s c l a s s nm :=
match g e t C l a s s A t t r c l a s s nm with
| None => None
| Some (_, nm ) => g e t C l a s s c l a s s e s nm
end .
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
Definition a n a l y z e S t e p c l a s s e s t r a v s c l a s s s t e p :=
l e t g e t A t t r C l a s s H e l p e r nm path :=
match g e t A t t r C l a s s c l a s s e s c l a s s nm with
| None => None
| Some c l a s s => Some ( c l a s s , path )
end
in
match s t e p with
| L a s t S t e p nm => g e t A t t r C l a s s H e l p e r nm emptyPath
| Step nm path => g e t A t t r C l a s s H e l p e r nm path
| I n i t nm =>
match getPath t r a v s nm with
| None => None
| Some path => Some ( c l a s s , path )
end
end .
(b)
Figura 31 Analisador semntico - continuao
Captulo 3. Litoral
1
2
3
4
5
6
7
8
9
10
11
12
13
47
Fixpoint a n a l y z e S t e p s c l a s s e s t r a v s c l a s s s t e p s :=
| [ ] => Some [ ]
| s t e p : : s t e p s =>
match a n a l y z e S t e p s c l a s s e s t r a v s c l a s s s t e p s with
| None => None
| Some c l a s s P a t h s =>
match a n a l y z e S t e p c l a s s e s t r a v s c l a s s s t e p with
| None => None
| Some c l a s s P a t h => Some ( c l a s s P a t h : : c l a s s P a t h s )
end
end
end .
14
15
16
Definition a n a l y z e P a t h c l a s s e s t r a v s c l a s s path :=
l e t Path _ s t e p s := path in a n a l y z e S t e p s c l a s s e s t r a v s c l a s s s t e p s .
17
18
Definition natEq x y := i f eq_nat_dec x y then t r u e e l s e f a l s e .
19
20
21
22
Definition pathEq path path :=

l e t Path n _ := path in
l e t Path n _ := path in natEq n n .
23
24
25
26
Definition c l a s s E q c l a s s c l a s s :=
l e t C l a s s nm _ := c l a s s in
l e t C l a s s nm _ := c l a s s in s t r E q nm nm .
27
28
29
30
31
Definition c l a s s P a t h E q ( c l a s s P a t h c l a s s P a t h : CLASS PATH) :=

l e t ( c l a s s , path ) := c l a s s P a t h in
i f c l a s s E q c l a s s c l a s s then pathEq path path e l s e f a l s e .
32
33
34
Definition c o u n t C l a s s P a t h c l a s s P a t h s c l a s s P a t h :=
count c l a s s P a t h E q c l a s s P a t h s c l a s s P a t h .
35
36
37
Definition c o n t a i n s C l a s s P a t h c l a s s P a t h s c l a s s P a t h :=
contains classPathEq classPaths classPath .
(c)
Figura 31 Analisador semntico - continuao.
Captulo 3. Litoral
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
48
Fixpoint a n a l y z e C l a s s P a t h s c l a s s e s p a t h s t r a v s s c l a s s P a t h s n :=
match n with
| 0 => ( s , Some c l a s s P a t h s )
| S n =>
match a n a l y z e C l a s s P a t h s c l a s s e s p a t h s t r a v s s c l a s s P a t h s n with
| ( s , None ) => ( s , None )
| ( s , Some [ ] ) => ( s , Some [ ] )
| ( s , Some ( c l a s s P a t h : : c l a s s P a t h s ) ) =>
i f c o n t a i n s C l a s s P a t h s c l a s s P a t h then ( s , Some c l a s s P a t h s )
else
if
containsClassPath ( l i s t _ p r o d c l a s s e s paths ) classPath
then
l e t s := c l a s s P a t h : : s in
match a n a l y z e P a t h c l a s s e s t r a v s c l a s s path with
| None => ( s , None )
| Some c l a s s P a t h s =>
( s , Some ( c l a s s P a t h s ++ c l a s s P a t h s ) )
end
else
( s , Some c l a s s P a t h s )
end
end .
25
26
Definition a n a l y z e T r a v s ( t r a v s : l i s t TRAV) := t r u e .
27
28
29
30
31
32
33
Definition a n a l y z e S p e c c l a s s e s c l a s s s p e c n :=
l e t ( spec2 , idx , p a t h s ) := i n d e x S p e c s p e c in
l e t Spec t r a v s path := s p e c 2 in
i f a n a l y z e T r a v s t r a v s then
a n a l y z e C l a s s P a t h s c l a s s e s p a t h s t r a v s [ ] [ ( c l a s s , path ) ] n
e l s e ( [ ] , None ) .
(d)
Figura 31 Analisador semntico - continuao.
Captulo 3. Litoral
49
A funo a n a l y z e P a t h verifica a segunda e a terceira condio navegando por um

caminho a partir de uma classe. Durante a navegao, a n a l y z e P a t h pode se deparar com o
incio de travessias. a n a l y z e P a t h verifica se as travessias iniciadas existem. Entretanto, no
lugar de verificar a terceira condio chamando a si mesma recursivamente, a n a l y z e P a t h
retorna o caminho destas travessias e a classe a partir das quais elas sero iniciadas em
uma lista. a n a l y z e P a t h seria mais simples se ela chamasse a si mesma recursivamente.
Infelizmente, esta estratgia torna a n a l y z e P a t h uma funo parcial, j que ela entraria
em recurso infinita ao verificar caminhos que iniciam travessias recursivas.
A funo a n a l y z e C l a s s P a t h s recebe os argumentos:
do tipo l i s t CLASS, uma lista contendo as classes pelas quais uma

especificao Litoral navega;
classes
p a t h s do tipo l i s t PATH, uma lista formada pelos caminhos contidos em uma

especificao Litoral;
t r a v s do tipo l i s t TRAV, uma lista formada pelas travessias que uma especificao
Litoral define;
s do tipo l i s t (CLASS PATH) , o estado inicial, ou seja, uma lista contendo pares
formados por uma classe c e um caminho p. Se um par ( c , p ) pertence lista s ,
ento navegar o caminho p a partir da classe c semanticamente vlido;
c l a s s P a t h s do tipo l i s t (CLASS PATH) , uma lista contendo pares formados por
uma classe e um caminho que devem ser validados semanticamente;
n do tipo nat , o nmero de vezes que a funo a n a l y z e C l a s s P a t h s invocar a si
mesma.
A funo
retorna um par formado pelo estado final

( l i s t (CLASS PATH) ) e por um valor opcional ( o p t i o n ( l i s t (CLASS PATH) ) . Se
este valor igual a None, ento a especificao semanticamente invlida. Se ele igual a
Some c l a s s P a t h s e c l a s s P a t h s uma lista vazia, ento a especificao semanticamente vlida. Caso contrrio, a lista c l a s s P a t h s contm pares formados por uma classe
e um caminho que ainda precisam ser validados. Isto quer dizer que preciso aumentar o
nmero de vezes que a funo a n a l y z e C l a s s P a t h s invoca a si mesma para determinar se
uma especificao Litoral ou no semanticamente vlida.
analyzeClassPaths
Uma pergunta importante : a funo a n a l y z e S p e c sempre capaz de validar

semanticamente especificaes Litoral em um nmero finito de recurses? O teorema
exibido na Figura 32 garante que sim. Ele afirma que para qualquer especificao s p e c
que navega a partir de uma classe c l a s s pelas classes contidas na lista c l a s s e s , existe
Captulo 3. Litoral
1
2
3
4
5
6
50
Theorem analyzeSpecLim :
f o r a l l c l a s s e s c l a s s spec ,
e x i s t s N,
forall n,
l e t (_, t ) := a n a l y z e S p e c c l a s s e s c l a s s s p e c (N + n ) in
t = None \/ t = Some [ ] .
Figura 32 Teorema que assegura que o analisador semntico do interpretador definidor

sempre capaz de validar especificaes Litoral em um nmero finito de
recurses.
um um nmero finito de recurses N suficiente para que a funo a n a l y z e S p e c conclua
se a especificao s p e c ou no semnticamente vlida. O teorema tambm afirma que a
concluso da funo a n a l y z e S p e c definitiva, pois permitir que a funo a n a l y z e S p e c
invoque a si mesma recursivamente um nmero de vezes maior do que N (ou seja, um
nmero da forma N + n, onde n um nmero natural qualquer), no modifica a concluso
da funo a n a l y z e S p e c . A Seo C.8 contm a demonstrao deste teorema verificada
por Coq. Ela se baseia no fato de que sequncias montonas e limitadas so convergentes
(THOMSON; BRUCKNER; BRUCKNER, 2008).
3.4.4 Interpretao
A funo 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 , s p e c , 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 seo discutir S, f i l t e r e s em breve. Os argumentos s p e c , o b j s ,
a l l O b j s e n, so, respectivamente, uma especificao Litoral, 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 nmero de vezes que a funo i n t e r p r e t O b j s P a t h 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. Ento i n t e r p r e t S p e c SVal f i l t e r V a l sVal uma funo que
associa especificaes Litoral a funes que recebem e retornam listas de objetos, ou
seja,
interpretSpec SVal filterVal sVal define uma semntica para Litoral
Mais especificamente, i n t e r p r e t S p e c SVal f i l t e r V a l sVal uma funo que associa
especificaes Litoral a funes que:
recebem os argumentos a l l O b j s , o b j s e n;
Captulo 3. Litoral
1
2
51
Definition getObj a l l i d :=
f i n d ( fun o b j => l e t Obj id _ := o b j in s t r E q id i d ) a l l .
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Fixpoint g e t O b j s a l l i d s :=
match i d s with
| [ ] => Some [ ]
| i d : : i d s =>
match g e t O b j s a l l i d s with
| None => None
| Some o b j s =>
match getObj a l l i d with
| None => None
| Some o b j => Some ( o b j : : o b j s )
end
end
end .
17
18
19
20
21
22
Definition g e t O b j A t t r a t t r s nm :=
let
f ( a t t r : s t r i n g l i s t s t r i n g ) := l e t (nm , _) := a t t r in s t r E q nm nm
in
find f attrs .
23
24
25
26
27
28
29
Definition g e t V a l a l l o b j nm :=
l e t Obj _ a t t r s := o b j in
match g e t O b j A t t r a t t r s nm with
| None => None
| Some (_, v a l ) => g e t O b j s a l l v a l
end .
30
31
32
33
34
35
36
37
38
39
40
41
42
43
Fixpoint g e t V a l s a l l o b j s nm :=
match o b j s with
| [ ] => Some [ ]
| o b j : : o b j s =>
match g e t V a l s a l l o b j s nm with
| None => None
| Some v a l s =>
match g e t V a l a l l o b j nm with
| None => None
| Some v a l => Some ( v a l ++ v a l s )
end
end
end .
(a)
Figura 33 Interpretador definidor.
Captulo 3. Litoral
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
52
Definition i n t e r p r e t S t e p t r a v s a l l o b j s s t e p :=
let
g e t V a l s H e l p e r nm path :=
match g e t V a l s a l l o b j s nm with
| None => None
| Some v a l s => Some ( v a l s , path )
end
in
match s t e p with
| L a s t S t e p nm => g e t V a l s H e l p e r nm emptyPath
| Step nm path => g e t V a l s H e l p e r nm path
| I n i t nm =>
match getPath t r a v s nm with
| None => None
| Some path => Some ( o b j s , path )
end
end .
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Fixpoint i n t e r p r e t S t e p s t r a v s a l l o b j s s t e p s :=
| [ ] => Some [ ]
| s t e p : : s t e p s =>
match i n t e r p r e t S t e p s t r a v s a l l o b j s s t e p s with
| None => None
| Some objsPath =>
match i n t e r p r e t S t e p t r a v s a l l o b j s s t e p with
| None => None
| Some o b j s P a t h => Some ( o b j s P a t h : : objsPath )
end
end
end .
32
33
34
Definition i n t e r p r e t P a t h t r a v s a l l o b j s path :=
l e t Path _ s t e p s := path in i n t e r p r e t S t e p s t r a v s a l l o b j s s t e p s .
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 - continuao.
Captulo 3. Litoral
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
53
Fixpoint i n t e r p r e t O b j s P a t h s S ( f i l t e r : F i l t e r S ) t r a v s a l l s o b j s P a t h s n :=
match n with
| 0 => ( [ ] , s , Some o b j s P a t h s )
| S n =>
match i n t e r p r e t O b j s P a t h s S f i l t e r t r a v s a l l s o b j s P a t h s n with
| ( o b j s , s , None ) => ( o b j s , s , None )
| ( o b j s , s , Some [ ] ) => ( o b j s , s , Some [ ] )
| ( o b j s , s , Some ( ( o b j s , path ) : : o b j s P a t h s ) ) =>
l e t ( s , o b j s ) := f i l t e r s o b j s path in
match i n t e r p r e t P a t h t r a v s a l l o b j s path with
| None => ( o b j s ++ o b j s , s , None )
| Some o b j s P a t h s =>
( o b j s ++ o b j s , s ,
Some ( o b j s P a t h s ++ o b j s P a t h s ) )
end
end
end .
18
19
20
21
Definition i n t e r p r e t S p e c S ( f i l t e r : F i l t e r S ) s s p e c a l l O b j s o b j s n :=
l e t Spec t r a v s path := s p e c in
i n t e r p r e t O b j s P a t h s S f i l t e r t r a v s a l l O b j s s [ ( o b j s , path ) ] n .
(c)
Figura 33 Interpretador definidor - continuao.

navegam a partir dos objetos contidos em o b j s de acordo com SVal , f i l t e r V a l ,
sVal e as funes i n t e r p r e t O b j s P a t h s , i n t e r p r e t P a t h , i n t e r p r e t S t e p s e
i n t e r p r e t S t e p das figuras 33b e 33c;
retornam uma tripla cujo primeiro elemento uma lista formada pelos objetos pelos
quais elas navegaram, o segundo elemento o estado final e o terceiro elemento um
valor opcional o p t i o n ( l i s t ( l i s t OBJ PATH) ) . Similarmente ao que acontece
com a funo a n a l y z e S p e c , se este valor igual a None ou Some [ ] , ento no h
mais navegaes a serem executadas. Caso contrrio, preciso aumentar o valor do
argumento n para que todas as navegaes sejam executadas.
3.4.4.1 Argumentos S, filter e s
A funo i n t e r p r e t S p e c delega para o argumento f i l t e r a deciso de para quais
objetos ela deve navegar. O tipo de f i l t e r
l i s t (PATH) > l i s t (OBJ) > S > l i s t OBJ > PATH > S l i s t OBJ
Captulo 3. Litoral
1
2
54
Definition f i l t e r 0 ( s : l i s t OBJ) ( o b j s : l i s t OBJ) ( path : PATH)

: l i s t OBJ l i s t OBJ := ( [ ] , [ ] ) .
Figura 34 Funo filter que impede navegaes.

ou seja, f i l t e r uma funo que recebe cinco argumentos e retorna um par. Os argumentos
de f i l t e r so, em ordem:
1. uma lista formada por todos os caminhos contidos em uma especificao Litoral;
2. uma lista contendo todos os objetos pelos quais uma especificao Litoral navega;
3. o estado inicial de f i l t e r cujo tipo determinado pela varivel de tipo S, ou seja,
este argumento pode ser de qualquer tipo;
4. uma lista contendo os objetos para os quais i n t e r p r e t S p e c deseja navegar;
5. o caminho pelo qual i n t e r p r e t S p e c navegar a partir dos objetos recebidos no
argumento anterior.
J os elementos do resultado de f i l t e r so, em ordem:
1. o estado final de f i l t e r cujo tipo tambm determinado pela varivel de tipo S;
2. os objetos da lista recebida como argumento para os quais i n t e r p r e t S p e c deve
navegar.
O argumento s de i n t e r p r e t S p e c o estado inicial da funo f i l t e r e, portanto,
seu tipo tambm determinado pela varivel de tipo S.
A funo f i l t e r desempenha um papel importante no interpretador definidor de
Litoral ao decidir para quais objetos i n t e r p r e t S p e c deve navegar. A funo f i l t e r 0
exibida na Figura 34, por exemplo, decide que i n t e r p r e t S p e c no deve navegar para
nenhum objeto, pois o segundo elemento do seu resultado sempre uma lista vazia.
Obviamente, f i l t e r 0 no um valor adequado para f i l t e r . Na verdade, o oposto
dela, ou seja, uma funo que permita a i n t e r p r e t S p e c navegar para qualquer objeto,
que parece definir uma semntica razovel para Litoral.
3.4.4.2 Semntica 1
A Figura 35 exibe as funes f i l t e r 1 e i n t e r p r e t S p e c 1 .
A funo f i l t e r 1 decide que a funo i n t e r p r e t S p e c deve navegar para todos
os objetos que ela desejar. Como a funo f i l t e r 1 no precisa de nenhuma informao
Captulo 3. Litoral
1
2
55
Definition f i l t e r 1 ( s : l i s t OBJ) ( o b j s : l i s t OBJ) ( path : PATH) :=

( s , objs ) .
3
4
5
Definition i n t e r p r e t S p e c 1 :=
i n t e r p r e t S p e c ( S := l i s t OBJ) f i l t e r 1
[].
Figura 35 Semntica 1.
1
2
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 ( )
visitMessage ()
Figura 36 Especificao Litoral que entra em recurso infinita na semntica 1.

1
Definition p i c t u r e := Obj " p1 " [ ] .
2
3
Definition u s e r := Obj " u1 " [ ( " p i c t u r e " , [ " p1 " ] ) ] .
4
5
6
7
Definition message := Obj "m1" [ ( " s e n d e r " , [ " u1 " ] ) ;

( " r e c i p i e n t s " , [ " u1 " ] ) ;
( " r e p l i e s " , [ " m1 " ] ) ] .
Figura 37 Mensagem que se auto-referencia.

do passado para tomar esta deciso, ela retorna o mesmo estado recebido como argumento,
ou seja, a funo f i l t e r 1 permanece sempre em seu estado inicial.
A funo i n t e r p r e t S p e c 1 construda a partir de i n t e r p r e t S p e c adotando como
filtro a funo f i l t e r 1 e como estado inicial uma lista vazia. A funo i n t e r p r e t S p e c 1 ,
portanto, define uma semntica para Litoral. Esta semntica ser denominada de
semntica 1.
A semntica 1 possui uma propriedade indesejvel: ela associa especificaes Litoral recursivas a funes que entram em recurso infinita ao navegar por objetos que se
auto-referenciam direta ou indiretamente. Isto acontece, por exemplo, com a especificao
Litoral s p e c 1 e o objeto message exibidos nas Figuras 36 e 37, respectivamente.
fcil ver por que s p e c 1 entra em recurso infinita neste caso. A primeira coisa
que s p e c 1 faz iniciar a travessia v i s i t M e s s a g e a partir de uma lista contendo message :
[ message ] . v i s i t M e s s a g e ( )
A substituio de v i s i t M e s s a g e por seu caminho resulta em

[ message ] . r e p l i e s . v i s i t M e s s a g e ( )
Captulo 3. Litoral
1
2
3
56
Definition objEq o b j obj :=

l e t Obj i d _ := o b j in
l e t Obj id _ := obj in s t r E q i d id .
4
5
6
Definition c o n t a i n s O b j o b j s o b j :=
c o n t a i n s objEq o b j s o b j .
7
8
9
10
11
12
13
14
15
16
17
18
Fixpoint f i l t e r 2 ( p a t h s : l i s t PATH) ( a l l O b j s : l i s t OBJ)

( s : l i s t OBJ) ( o b j s : l i s t OBJ) ( path : PATH) :=
match o b j s with
| [ ] => ( s , [ ] )
| o b j : : o b j s =>
l e t ( s , outObjs ) := f i l t e r 2 p a t h s a l l O b j s s o b j s path in
i f c o n t a i n s O b j a l l O b j s o b j then
i f c o n t a i n s O b j s o b j then ( s , outObjs )
e l s e ( o b j : : s , o b j : : outObjs )
e l s e ( s , outObjs )
end .
19
20
21
Definition i n t e r p r e t S p e c 2 :=
i n t e r p r e t S p e c ( S := l i s t OBJ) f i l t e r 2
[].
Como message uma rplica de si mesma e f i l t e r 1 autoriza a navegao para message
novamente, s p e c 1 retorna configurao inicial:
[ message ] . v i s i t M e s s a g e ( )
3.4.4.3 Semntica 2
A funo i n t e r p r e t S p e c 2 exibida na Figura 38 define uma segunda semntica
para Litoral. Diferentemente da anterior, esta semntica no associa especificaes
Litoral a funes que podem entrar em recurso infinita. Isto acontece porque a funo
f i l t e r 2 , utilizada por i n t e r p r e t S p e c 2 , registra em seu estado os objetos pelos quais
uma especificao Litoral j navegou, impedindo-a de navegar para eles novamente.
Voltando ao exemplo anterior, ao se deparar com
impede que s p e c 1 navegue novamente para message atravs do atributo

r e p l i e s , resultando na configurao final
filter2
[ ] . visitMessage ()
Captulo 3. Litoral
1
2
3
4
5
6
57
Theorem i n t e r p r e t S p e c 2 L i m :
f o r a l l spec allObjs objs ,
e x i s t s N,
forall n,
l e t (_, _, t ) := i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s (N + n ) in
t = None \/ t = Some [ ] .
Figura 39 Teorema que assegura que, sob a semntica 2, especificaes Litoral no

entram em recurso infinita.
1
[
sender ,
recipients . picture
2
3
4
Figura 40 Programa Litoral que especifica navegaes que no so realizadas na

semntica 2.
O Teorema exibido na Figura 39 formaliza a propriedade de que, sob a semntica 2,
especificaes Litoral no entram em recurso infinita. A sua demonstrao, verificada
por Coq, encontra-se na seo C.9. Ela tambm se baseia no fato de que sequncias
montonas e limitadas so convergentes (THOMSON; BRUCKNER; BRUCKNER, 2008).
Apesar da semntica 2 associar especificaes Litoral a funes que no entram
em recurso infinita, estas funes podem exibir outros comportamentos indesejveis,
tais como, ao partir de determinados objetos, no realizar todas as navegaes que uma
especificao Litoral declara. Isto acontece, por exemplo, com a especificao Litoral
s p e c 2 exibida na Figura 40 e com o objeto message da Figura 37.
Na semntica 1, s p e c 2 parte de message e realiza todas as navegaes especificadas,
resultando na lista
[ message , u s e r , u s e r , p i c t u r e ]
Por outro lado, na semntica 2, s p e c 2 parte de message e navega para u s e r atravs

do atributo s e n d e r . Em seguida, s p e c 2 tenta navegar novamente de message para
u s e r atravs do atributo r e c i p i e n t s . Como f i l t e r 2 probe esta navegao, s p e c 2 no
navega novamente para u s e r e nem deste ltimo para p i c t u r e , resultando na lista
[ message , u s e r ]
Como Litoral uma linguagem declarativa, desejvel que as permutaes dos

passos de um caminho (produo path da Figura 13) gerem especificaes Litoral que
navegam, ainda que em ordens diferentes, pelos mesmos objetos. Infelizmente, isto no
Captulo 3. Litoral
1
[
r e c i p i e n t s . picture ,
sender
2
3
4
58
Figura 41 Especificao Litoral que permuta os passos de uma outra especificao e,

na semntica 2, navega por objetos pelos quais a original no navega.
verdade na semntica 2. Por exemplo, a nica diferena entre as especificaes Litoral
das Figuras 40 e 41 a ordem dos passos s e n d e r e r e c i p i e n t s . p i c t u r e . Entretanto, na
semntica 2, ao navegar pelo objeto message , a primeira resulta, como visto antes, na
lista
[ message , u s e r ]
enquanto a segunda resulta na lista

[ message , u s e r , p i c t u r e ]
3.4.4.4 Semntica 3
A funo f i l t e r 3 , exibida na Figura 42, refina f i l t e r 2 de forma a eliminar
os problemas da semntica 2. A diferena entre f i l t e r 2 e f i l t e r 3 que a primeira
armazena apenas os objetos para os quais um programa Litoral j navegou, enquanto
f i l t e r 3 armazena tambm o caminho que foi percorrido a partir destes objetos. Com esta
informao adicional, f i l t e r 3 permite que um programa Litoral navegue novamente
para um mesmo objeto, desde que o caminho que ser percorrido a partir deste objeto
ainda no tenha sido percorrido. Este critrio no s preserva a vantagem da semntica 2
sobre a semntica 1, ou seja, no associa programas Litoral a funes que entram em
recurso infinita, como tambm elimina os problemas da semntica 2.
Voltando ao exemplo da seo 3.4.4.2, ao se deparar com
navegue novamente para message , pois o caminho

r e p l i e s . v i s i t M e s s a g e ( ) j foi percorrido a partir deste objeto, resultando na configurao final
filter3
impede que
spec1
[ ] . visitMessage ()
Captulo 3. Litoral
1
2
3
4
59
Definition objPathEq ( objPath objPath : OBJ PATH) :=

l e t ( obj , path ) := objPath in
l e t ( obj , path ) := objPath in
i f objEq o b j obj then pathEq path path e l s e f a l s e .
5
6
7
8
9
10
11
12
Fixpoint c o n t a i n s O b j P a t h o b j P a t h s objPath :=
match o b j P a t h s with
| [ ] => f a l s e
| objPath : : objPaths =>
i f c o n t a i n s O b j P a t h objPaths objPath then t r u e
e l s e objPathEq objPath objPath
end .
13
14
15
16
17
18
19
20
21
22
23
24
25
26
Fixpoint f i l t e r 3 ( p a t h s : l i s t PATH) ( a l l O b j s : l i s t OBJ)

( s : l i s t (OBJ PATH) ) ( o b j s : l i s t OBJ) ( path : PATH) :=
match o b j s with
| [ ] => ( s , [ ] )
| o b j : : o b j s =>
l e t ( s , outObjs ) := f i l t e r 3 p a t h s a l l O b j s s o b j s path in
l e t objPath := ( obj , path ) in
i f c o n t a i n s O b j P a t h ( l i s t _ p r o d a l l O b j s p a t h s ) objPath then
i f c o n t a i n s O b j P a t h s objPath then ( s , outObjs )
e l s e ( objPath : : s , o b j : : outObjs )
else
( s , outObjs )
end .
27
28
29
30
Definition i n t e r p r e t S p e c 3 s p e c a l l O b j s o b j s n :=
l e t ( spec , _, _) := i n d e x S p e c s p e c in
i n t e 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 O b j s o b j s n .
Portanto, na semntica 3 s p e c 1 no entra em recurso infinita ao navegar a partir de
message .
Voltando ao primeiro exemplo da seo 3.4.4.3, f i l t e r 3 permitir que s p e c 2
navegue novamente de message para u s e r atravs do atributo r e c i p i e n t s , pois s p e c 2
ainda no percorreu o caminho p i c t u r e a partir de u s e r , resultando na lista
[ message , u s e r , u s e r , p i c t u r e ]
ou seja, na semntica 3 s p e c 2 parte de message e realiza todas as navegaes especificadas.

Por fim, voltando ao segundo exemplo da seo 3.4.4.3, ao navegar a partir de
message , s p e c 3 resulta na lista
Captulo 3. Litoral
60
[ message , u s e r , p i c t u r e , u s e r ]
mostrando que na semntica 3 s p e c 2 e s p e c 3 partem de message e navegam pelos

mesmos objetos, ainda que em ordens diferentes.
3.4.4.5 Escolha de uma Semntica
Dentre as semnticas 1, 2 e 3, a ltima deve ser escolhida preferencialmente, pois ela
est livre dos problemas das anteriores. Entretanto, se h segurana de que as especificaes
Litoral que sero executadas no definem travessias recursivas a partir de objetos que se
auto-referenciam, ento a semntica 1 pode ser adotada. Especificamente nestes casos, a
semntica 1, assim como a semntica 3, tambm associa especificaes Litoral a funes
que no entram em recurso infinita e que esto livres dos problemas da semntica 2.
Adotar a semntica 1 vantajoso, pois, por permanecer sempre em seu estado inicial, ela
mais simples e demanda menos memria e processamento do que a semntica 3.
A discusso anterior pressupe que a escolha de uma semntica esttica, ou seja,
toda e qualquer especificao Litoral ser executada sob a mesma semntica. Entretanto,
tambm possvel escolher uma semntica dinamicamente, em funo da especificao
Litoral que ser executada. Pode-se, por exemplo, procurar por travessias recursivas
na especificao Litoral. Se elas forem encontradas, a semntica 3 adotada. Caso
contrrio, a escolha recai sobre a semntica 1.
61
4 Interpretador
A Seo 3.4 mostrou que especificaes Litoral podem ser vistas como funes
que recebem listas de objetos como argumento e tambm retornam listas de objetos. Estas
funes navegam (em um sentido tornado preciso pelo interpretador definidor da seo
3.4) a partir dos objetos da primeira lista, retornando os objetos encontrados durante a
navegao na segunda lista.
Este captulo apresenta um segundo interpretador para Litoral. Enquanto o
anterior navega apenas por objetos que se encontram na memria primria, este tambm
navega por objetos que se encontram em um repositrio (um banco de dados relacional,
por exemplo), carregando-os para a memria primria durante a navegao.
O interpretador1 confere a Litoral uma semntica similar semntica 3 apresentada na Seo 3.4.4.4. Entretanto, como ele carrega objetos executando operaes de E/S
concorrentemente, ele navega pelos mesmos objetos que o interpretador definidor, mas no
necessariamente na mesma ordem.
Para carregar objetos com operaes de E/S concorrentes, o interpretador delega
para algum mecanismo de carregamento de objetos (um ORM, por exemplo) a interao
com o repositrio e para o framework Afluentes (ARAUJO et al., 2014) o gerenciamento
da concorrncia.
O interpretador foi desenvolvido na plataforma Java SE (Standard Edition), pois
ela oferece diversas oportunidades para se avaliar se o objetivo desta pesquisa (Seo 1.1)
foi alcanado. Tais oportunidades so fruto da popularidade dos ORMs nesta plataforma.
Sistemas que executam operaes de E/S concorrentemente podem ser desenvolvidos na plataforma Java SE com diversas combinaes de primitivas de E/S (sncronas e
assncronas (HAROLD, 2006)) e modelos de programao (multithreading (PEIERLS et
al., 2006), fork/join (LEA, 2000) e futuros). Entretanto, todas as combinaes possveis
so de baixo nvel e/ou bastante diferentes da programao sequencial, o que dificulta a implementao destes sistemas e, em particular, do interpretador. O framework Afluentes,
desenvolvido no contexto desta pesquisa, uma soluo para este problema.
4.1 Afluentes
Afluentes um framework para a plataforma Java SE baseado no paradigma de
concorrncia declarativa (ROY et al., 2009). Neste paradigma, o desenvolvedor declara as
1
A partir deste ponto, interpretador se refere ao interpretador deste captulo, enquanto interpretador
definidor se refere ao interpretador da seo 3.4.
Captulo 4. Interpretador
62
dependncias entre tarefas, sejam elas de dados ou temporais, e tambm declara quais
tarefas devem ser executadas em um novo contexto de execuo2 , cabendo ao ambiente de
tempo de execuo gerenciar:
a sincronizao, ou seja, executar as tarefas em uma ordem que respeite suas
dependncias e, quando for o caso, em um novo contexto de execuo (SCOTT,
2006);
a comunicao, 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/S
assncronas, baseadas em callbacks ou multiplexadas, e tambm com primitivas sncronas.
4.1.1 Modelo de Programao

Esta subseo d uma viso geral do modelo de programao de Afluentes. Neste
modelo, tarefas so avaliaes de funes. Por exemplo, sejam as funes sub(x, y) = x y
e mul(x, y) = x y. Ento as avaliaes sub(0, 1) e mul(2, 3) so tarefas.
Dependncias entre tarefas so composies das avaliaes subjacentes. Por exemplo, dados a, b e c, podemos calcular o valor de b2 4ac com a composio de avaliaes
sub(mul(b, b), mul(4, mul(a, c))). Ao se deparar com esta composio, Afluentes identifica, 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 composies de avaliaes, Afluentes tambm identifica tarefas
independentes. Afluentes supe que a execuo de cada uma destas tarefas no tem
efeitos indesejveis sobre as demais, portanto elas podem ser executadas concorrentemente.
No exemplo anterior, Afluentes identificaria que as tarefas mul(b, b) e mul(a, c) so
independentes e, portanto, podem ser executadas concorrentemente.
A independncia de tarefas uma condio necessria, mas no suficiente, para que
elas sejam executadas concorrentemente. Isto acontecer apenas se uma destas tarefas for
a avaliao de uma funo assncrona. Funes sncronas e assncronas sero discutidas em
breve. Para os fins desta subseo, suficiente saber que funes assncronas so avaliadas
em um novo contexto de execuo.
4.1.2 Funes Sncronas

O cdigo da Figura 43 calcula o valor de b2 4ac compondo invocaes de mtodos.
2
O termo thread foi evitado pois normalmente ele interpretado como um processo leve.
1
2
3
63
double mul ( double x , double y ) {

return x y ;
}
4
5
6
7
double sub ( double x , double y ) {

return x y ;
}
8
9
10
11
double d e l t a ( double a , double b , double c ) {

return sub ( mul ( b , b ) , mul ( 4 , mul ( a , c ) ) ) ;
}
Figura 43 Clculo de b2 4ac compondo invocaes de mtodos.

Os mtodos mul, sub e d e l t a da Figura 43 so exemplos de funes sncronas, ou
seja, funes que s devolvem o controle quando suas avaliaes chegam ao fim. Funes
sncronas entregam o resultado de suas avaliaes atravs de valores de retorno.
4.1.3 Funes Assncronas

O cdigo da Figura 44 tambm calcula o valor de b2 4ac, mas desta vez com
funes assncronas, ou seja, funes que entregam o resultado de suas avaliaes atravs
de callbacks.
Para no tornar o cdigo da Figura 44 excessivamente longo, o tratamento de
erros (implementaes dos mtodos t da interface I C a l l b a c k ) foi omitido e as expresses
lambda (SUBRAMANIAM, 2014) introduzidas na verso 1.8 da plataforma Java SE foram
adotadas nos mtodos mul e sub .
Funes assncronas devolvem o controle quase que imediatamente. O mtodo mul
da Figura 44, por exemplo, retm o controle apenas o tempo necessrio para criar e iniciar
o contexto que ir execut-lo, devolvendo o controle logo em seguida.
No preciso entender os detalhes do cdigo da Figura 44 para perceber que mais
difcil calcular o valor de b2 4ac com funes assncronas do que com funes sncronas
(Figura 43). Isto acontece porque, no primeiro caso, como callbacks no so construes
nativas da linguagem, recai sobre o desenvolvedor o trabalho de gerenciar a comunicao
e a sincronizao. J no segundo caso, como composies de avaliaes so construes
nativas da linguagem, este trabalho recai sobre o ambiente de tempo de execuo.
Embora seja mais fcil, o cdigo que usa funes sncronas tem a grande desvantagem de ser executado sequencialmente. J o cdigo que usa funes assncronas, apesar
de mais difcil, calcula as subexpresses de b2 4ac concorrentemente. Estas observaes
levam naturalmente pergunta:
1
2
3
void mul ( double x , double y , I C a l l b a c k <Double> cb ) {

new Thread ( ( ) > cb . y ( x y ) ) . s t a r t ( ) ;
}
4
5
6
7
void sub ( double x , double y , I C a l l b a c k <Double> cb ) {

}
8
9
10
11
void d e l t a ( double a , double b , double c , I C a l l b a c k <Double> cb ) {

AtomicReference<Double> b2 = new AtomicReference < >();
AtomicReference<Double> _4ac = new AtomicReference < >();
12
mul ( b , b , new I C a l l b a c k <Double >() {

public void y ( Double y ) {
b2 . s e t ( y ) ;
d e l t a ( b2 , _4ac , cb ) ;
}
13
14
15
16
17
18
public void t ( Throwable t ) { / . . . / }

});
19
20
21
mul ( 4 , a , new I C a l l b a c k <Double >() {

mul ( y , c , new I C a l l b a c k <Double >() {
_4ac . s e t ( y ) ;
d e l t a ( b2 , _4ac , cb ) ;
}
22
23
24
25
26
27
28
29

});
30
31
32
33

});
34
35
36
37
38
39
40
41
42
43
void d e l t a ( AtomicReference<Double> b2 , AtomicReference<Double> _4ac ,

I C a l l b a c k <Double> cb ) {
i f ( b2 . g e t ( ) != null && _4ac . g e t ( ) != null ) {
sub ( b2 . g e t ( ) , _4ac . g e t ( ) , cb ) ;
}
}
Figura 44 Clculo de b2 4ac com funes assncronas.
64
65
Figura 45 Estratgia de Afluentes para combinar as vantagens de funes sncronas e

assncronas.
possvel conciliar as vantagens de funes sncronas e assncronas?
Afluentes responde positivamente pergunta anterior provendo adaptadores
que transformam funes assncronas em avaliadores, tal como ilustrado na Figura 45.
Avaliadores sero discutidos em breve. Por hora, o importante perceber que, como
avaliadores so eles prprios funes sncronas, esta transformao permite que avaliaes de
funes assncronas sejam compostas com a mesma facilidade do caso sncrono. Afluentes
tambm prov adaptadores que transformam funes sncronas em avaliadores. Isto permite
que os dois tipos de funes sejam misturados em uma mesma composio de avaliaes.
4.1.4 Avaliadores, Avaliaes e Processo de Avaliao

Avaliadores so funes sncronas que recebem avaliaes como argumentos e
tambm retornam avaliaes.
Avaliaes so objetos que representam a execuo sob demanda de uma funo
sncrona ou assncrona. Eles encapsulam a funo a ser executada e os argumentos, eles
prprios outras avaliaes, com os quais a funo ser executada.
A execuo de avaliadores cria um grafo dirigido acclico de avaliaes. Afluentes percorre este grafo quando um contexto de execuo c0 demanda o resultado de
uma avaliao a0 . O percurso identifica avaliaes que podem ser executadas, ou seja,
seus argumentos j foram avaliados. Estas avaliaes podem estar relacionadas a funes
sncronas ou assncronas. No primeiro caso, o contexto c0 executa as avaliaes sequencialmente. No segundo caso, os contextos de execuo criados pelas funes assncronas
executam as avaliaes concorrentemente. Quando uma funo entrega o resultado de
sua avaliao, Afluentes repete este processo, o qual concludo quando Afluentes
recebe o resultado da avaliao a0 .
4.1.5 Representando Funes Sncronas

A implementao de avaliaes requer que seja possvel armazenar funes em
atributos de objetos. Adicionalmente, a implementao do processo de avaliao delineado
1
2
3
66
public i n t e r f a c e ISyncFn0<Y> {
Y y();
}
4
5
6
7
public i n t e r f a c e ISyncFn1<X1 , Y> {

Y y (X1 x1 ) ;
}
8
9
10
11
public i n t e r f a c e ISyncFn2<X1 , X2 , Y> {

Y y (X1 x1 , X2 x2 ) ;
}
Figura 46 Interfaces ISyncFn0, ISyncFn1 e ISyncFn2.

1
ISyncFn2<Double , Double , Double> sub = ( x , y ) > x y ;
2
3
ISyncFn2<Double , Double , Double> mul = ( x , y ) > x y ;
4
5
6
ISyncFn3<Double , Double , Double , Double> d e l t a =

( a , b , c ) > sub . y ( mul . y ( b , b ) , mul . y ( 4 . 0 , mul . y ( a , c ) ) ) ;
Figura 47 Clculo de b2 4ac compondo invocaes de funes sncronas.

na seo 4.1.4 requer que um framework seja capaz de descobrir as dependncias entre
avaliaes de funes. Mtodos so candidatos naturais a funes. Porm, na plataforma
Java SE, eles no satisfazem nenhum destes requisitos.
Devido a estas limitaes, Afluentes trata como funes sncronas objetos que
implementam uma das interfaces ISyncFn0 , ..., ISyncFn16 . A Figura 46 exibe as trs
primeiras. Os parmetros de tipo que iniciam com X ( X1, ..., X16) e o parmetro de
tipo Y definem, respectivamente, o domnio e o contradomnio das funes. O mtodo
y define a funo. Os parmetros x1 , ..., x16 correspondem aos argumentos da funo.
Aqui supe-se que funes com mais de dezesseis argumentos so bastante incomuns. Em
todo caso, elas podem ser emuladas construindo-se um objeto que encapsule todos os seus
argumentos. Como a interface ISyncFn modela funes sncronas, o mtodo y entrega
seu resultado atravs de valores de retorno.
O cdigo da Figura 47 calcula b2 4ac, mas desta vez compondo invocaes de
funes sncronas definidas com as interfaces ISyncFn2 e ISyncFn3 .
4.1.6 Callbacks
Callbacks so objetos cujas classes implementam a interface I C a l l b a c k exibida na
Figura 48. Funes assncronas entregam o resultado de suas avaliaes atravs do mtodo
y e sinalizam a ocorrncia de erros durante suas avaliaes atravs do mtodo t .
1
2
3
4
67
public i n t e r f a c e I C a l l b a c k <Y> {
void y (Y y ) ;
void t ( Throwable t ) ;
}
Figura 48 Interface ICallback.

1
2
3
public i n t e r f a c e IAsyncFn0<Y> {
void y ( I C a l l b a c k <Y> cb ) ;
}
4
5
6
7
public i n t e r f a c e IAsyncFn1<X1 , Y> {

void y (X1 x1 , I C a l l b a c k <Y> cb ) ;
}
8
9
10
11
public i n t e r f a c e IAsyncFn2<X1 , X2 , Y> {

void y (X1 x1 , X2 x2 , I C a l l b a c k <Y> cb ) ;
}
Figura 49 Interfaces IAsyncFn0, IAsyncFn1 e IAsyncFn2.

1
2
3
IAsyncFn2<Double , Double , Double> sub = ( x , y , cb ) > {

};
4
5
6
7
IAsyncFn2<Double , Double , Double> mul = ( x , y , cb ) > {

};
Figura 50 Funes sub e mul definidas com as interfaces IAsyncFn2.
4.1.7 Representando Funes Assncronas

As interfaces IAsyncFn0 , ..., IAsyncFn16 exibidas na Figura 49 so verses
assncronas das interfaces ISyncFn0 , ..., ISyncFn16 . Como funes assncronas entregam
o resultado de suas avaliaes atravs de callbacks, os mtodos y das interfaces IAsyncFn0 ,
..., IAsyncFn16 tm tipo de retorno v o i d e recebem como ltimo parmetro um callback.
A Figura 50 exibe as funes assncronas mul e sub , mas desta vez definidas com
as interfaces IAsyncFn2 .
4.1.8 Avaliaes
Avaliaes so objetos cujas classes implementam a interface I E v a l exibida na
Figura 51. Ao ser invocado pela primeira vez, o mtodo y executa o processo de avaliao
descrito na seo 4.1.4. O resultado deste processo armazenado na avaliao de forma
1
2
3
68
public i n t e r f a c e IEval<Y> {
Y y();
}
Figura 51 Interface IEval.

1
2
3
public i n t e r f a c e IFnEval0<Y> {
IEval <? extends Y> y ( ) ;
}
4
5
6
7
8
public i n t e r f a c e IFnEval1<X1 , Y> {

IEval <? extends Y> y (X1 x1 ) ;
IEval <? extends Y> y ( IEval <? extends X1> x1 ) ;
}
Figura 52 Interfaces IEval0 e IEval1.

que invocaes subsequentes do mtodo y no precisam executar o processo de avaliao
novamente.
4.1.9 Avaliadores
Avaliadores so objetos cujas classes implementam uma das interfaces IFnEval0 ,
..., IFnEval16 . A Figura 52 exibe as duas primeiras.
As classes ISyncEval0 , ..., ISyncEval16 e IAsyncEval0 , ..., IAsyncEval16
so adaptadores que transformam funes sncronas e assncronas, respectivamente, em
avaliadores. Elas podem ser vistas em ao nos cdigos das figuras 53 e 54 que calculam
b2 4ac, mas desta vez compondo invocaes de avaliadores de funes sncronas e
assncronas. A comparao destes cdigos concorda com as afirmaes da seo 4.1.3:
a transformao de funes assncronas em avaliadores (linhas 1 a 3 da Figura 54)
permite que suas invocaes sejam compostas (linha 8 da Figura 54) com a mesma
facilidade do caso sncrono (linha 6 da Figura 53);
a transformao de funes sncronas em avaliadores (linhas 1 e 3 da Figura 53 e
linha 5 da Figura 54) permite que os dois tipos de funes sejam misturados em
uma mesma composio de avaliaes (linha 6 da Figura 53).
Apesar dos mtodos d e l t a das figuras 53 e 54 serem idnticos, suas execues so
bastante diferentes. O primeiro executado sequencialmente, pois envolve apenas funes
sncronas. O ltimo executado concorrentemente, pois envolve tanto funes sncronas
quanto assncronas.
69
IFnEval2<Double , Double , Double> sub = new SyncEval2 <>((x , y ) > x y ) ;
2
3
IFnEval2<Double , Double , Double> mul = new SyncEval2 <>((x , y ) > x y ) ;
4
5
6
7

return sub . y ( mul . y ( b , b ) , mul . y ( 4 . 0 , mul . y ( a , c ) ) ) . y ( ) ;
}
Figura 53 Clculo de b2 4ac compondo invocaes de funes sncronas.

1
2
3
IFnEval2<Double , Double , Double> sub = new AsyncEval2 <>((x , y , cb ) > {

});
4
5
IFnEval2<Double , Double , Double> mul = new SyncEval2 <>((x , y ) > x y ) ;
6
7
8
9

return sub . y ( mul . y ( b , b ) , mul . y ( 4 . 0 , mul . y ( a , c ) ) ) . y ( ) ;
}
Figura 54 Clculo de b2 4ac compondo invocaes de funes sncronas e assncronas.
(c)
(a)
(b)
(e)
(d)
Figura 55 Processo de avaliao de b2 4ac.

A composio sub . y ( mul . y ( b , b ) , mul . y ( 4 . 0 , mul . y ( a , c ) ) ) produz a rvore
de avaliaes da Figura 55a. Quando o mtodo y de sua raiz invocado, Afluentes
70
percorre esta rvore em busca de avaliaes que podem ser executadas. As avaliaes
mul ( b , b ) e mul ( a , c ) satisfazem este critrio. Elas so executadas concorrentemente,
pois esto relacionadas a funes assncronas.
Suponha que mul ( b , b ) seja concluda primeiro, levando a rvore de avaliaes
configurao da Figura 55b. Afluentes percorre esta configurao em busca, novamente,
de avaliaes que podem ser executadas, mas desta vez no encontrar nenhuma.
A Figura 55c exibe a configurao da rvore de avaliaes quando mul ( a , c )
concluda. Neste momento, Afluentes executa uma nova busca e descobre que
mul ( 4 . 0 , mul ( a , c ) ) j pode ser executada. Quando esta avaliao concluda, a rvore
de avaliaes evolui para a configurao da Figura 55d. Uma nova busca revela que a raz
da rvore de avaliaes pode, enfim, ser executada. Quando esta avaliao chega ao fim, a
rvore de avaliaes evolui para a configurao final exibida na Figura 55e.
4.1.10 Funes sobre Listas

Sejam X1 e Y tipos quaisquer. Funes sobre listas so objetos que implementam
a interface ISyncFn1<L i s t <X1>, Y>, ou seja, so funes sncronas cujo domnio e contradomnio so, respectivamente, listas de X1 e Y. O cdigo da Figura 56, por exemplo,
define as funes sobre listas sum e p r o d u c t s . A primeira associa uma lista de produtos
ao somatrio dos seus preos. A segunda associa uma lista de cdigos de produtos a uma
lista dos respectivos produtos.
4.1.11 Avaliadores de Funes sobre Listas

Existem casos em que necessrio aplicar uma funo sobre listas
ISyncFn1<L i s t <X1>, Y> a uma lista de avaliaes de X1 ( L i s t <IEval<X1>>). O Adaptador SyncEval1 no ajudar nestes casos, pois ele permite que a funo sobre listas seja
aplicada a avaliaes de listas de X1 ( IEval<L i s t <X1>>) mas no a listas de avaliaes
de X1. O adaptador L i s t E v a l , por outro lado, permite a ltima aplicao. L i s t E v a l
recebe uma lista de avaliaes de X1, espera que todas as avaliaes sejam concludas,
constri uma nova lista contendo o resultado das avaliaes ( L i s t <X1>) e, finalmente,
aplica a funo nova lista.
Voltando ao exemplo da Figura 56, o mtodo t o t a l recebe uma lista de cdigos de
produtos e calcula o somatrio dos preos dos respectivos produtos compondo invocaes
das funes sum e p r o d u c t s . Como p r o d u c t s carrega os produtos para a memria
primria invocando a funo p r o d u c t , podemos aumentar o desempenho de t o t a l
tornando p r o d u c t assncrona, pois assim os produtos sero carregados concorrentemente.
O cdigo da Figura 57 incorpora esta mudana. Como a funo p r o d u c t tornou-se
um avaliador, o contradomnio da funo p r o d u c t s passou de L i s t <Product> para
71
ISyncFn1<I n t e g e r , Product> p r o d u c t = i d > { / . . . / } ;
2
3
4
5
6
7
8
9
10
ISyncFn1<L i s t <I n t e g e r >, L i s t <Product>> p r o d u c t s = i d s > {

L i s t <Product> ps = new A r r a y L i s t < >();
for ( I n t e g e r id : i d s ) {
Product p = p r o d u c t . y ( i d ) ;
ps . add ( p ) ;
}
return ps ;
};
11
12
13
14
15
16
17
18
ISyncFn1<L i s t <Product >, Double> sum = ps > {

double s = 0 ;
f o r ( Product p : ps ) {
s += p . p r i c e ;
}
return s ;
};
19
20
21
22
double t o t a l ( L i s t <I n t e g e r > i d s ) {

return sum . y ( p r o d u c t s . y ( i d s ) ) ;
}
Figura 56 Clculo do somatrio dos preos dos produtos de uma lista compondo invocaes de funes sncronas.
L i s t <IEval <? e x t e n d s Product>>.
Portanto, para que possamos aplicar a funo sum

aos resultados de p r o d u c t s , precisamos transform-la em um avaliador com o adaptador
ListEval.
4.2 Projeto
A fase de implementao (MERNIK; HEERING; SLOANE, 2005) do desenvolvimento 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, ento as nicas mudanas no cdigo do sistema
necessrias ao uso do interpretador devem ser sua instanciao e execuo.
Transparncia: o uso do interpretador no deve modificar um sistema funcionalmente. Seu nico efeito deve ser a reduo do tempo de carregamento de objetos.
Independncia: o interpretador deve ser capaz de interagir com qualquer mecanismo de carregamento de objetos.
1
2
3
72
IFnEval1<I n t e g e r , Product> p r o d u c t = new AsyncEval1 <>(( id , cb ) > {

/ . . . /
});
4
5
6
7
8
9
10
11
12
ISyncFn1<L i s t <I n t e g e r >, L i s t <IEval <? extends Product>>> p r o d u c t s = i d s > {

L i s t <IEval <? extends Product>> ps = new A r r a y L i s t < >();
for ( I n t e g e r id : i d s ) {
IEval <? extends Product> p = p r o d u c t . y ( i d ) ;
ps . add ( p ) ;
}
return ps ;
};
13
14
I L i s t E v a l <Product , Double> sum = new L i s t E v a l <>(ps > { / . . . / } ) ;
15
16
17
18
double t o t a l ( L i s t <I n t e g e r > i d s ) {

return sum . y ( p r o d u c t s . y ( i d s ) ) . y ( ) ;
}
Figura 57 Clculo do somatrio dos preos dos produtos de uma lista compondo avaliadores de funes assncronas e de funes sobre listas.
1
2
3
public i n t e r f a c e I E v a l H o l d e r <Y> {
IEval <? extends Y> g e t E v a l ( ) ;
}
Figura 58 Interface IEvalHolder.

Baixa exigncia: o interpretador deve fazer poucas exigncias aos mecanismos
de carregamento de objetos que desejam se integrar com ele.
O interpretador atende ao ltimo requisito fazendo uma nica exigncia: os mecanismos devem carregar objetos sob demanda com proxies que implementam a interface
I E v a l H o l d e r exibida na Figura 58. O parmetro de tipo Y determina a classe do objeto
que ser carregado. O mtodo g e t E v a l retorna a avaliao que carrega este objeto.
Mecanismos de carregamento de objetos atendem facilmente exigncia do interpretador gerando proxies que, similarmente ao exibido na Figura 59, armazenam a avaliao
retornada pelo mtodo g e t E v a l no atributo e v a l e sobrepem todos os mtodos de suas
classes-alvo. Os novos mtodos obtm os objetos-alvo dos proxies executando o processo
de avaliao ( e v a l . y ( ) ) e repassam para eles suas invocaes.
A gerao de proxies similares ao da Figura 59 tambm responsvel pelo cumprimento do requisito de transparncia. Quando um mtodo do proxy invocado, no faz
diferena se o interpretador j carregou o objeto-alvo do proxy executando o processo de
avaliao. Em caso positivo, a invocao ser repassada para o objeto-alvo imediatamente.
1
2
73
c l a s s MessageProxy extends Message implements I E v a l H o l d e r <Message> {

private IEval <? extends Message> e v a l ;
public IEval <? extends Message> g e t E v a l ( ) {

return e v a l ;
}
4
5
6
7
void s e t I d ( int i d ) {
eval . y ( ) . setId ( id ) ;
}
8
9
10
11
int g e t I d ( ) {
return e v a l . y ( ) . g e t I d ( ) ;
}
12
13
14
15
// Demais mtodos s e t e g e t
16
17
Figura 59 Proxy que implementa a interface IEvalHolder.

1
2
3
4
public i n t e r f a c e I P r e f e t c h e r <S t a r t > {

void p r e f e t c h ( S t a r t s t a r t ) ;
void p r e f e t c h ( IEval <? extends S t a r t > s t a r t ) ;
}
Figura 60 Interface IPrefetcher.

Em caso negativo, o objeto-alvo ser carregado e depois a invocao ser repassada para
ele.
A interface I E v a l H o l d e r , por sua vez, tambm responsvel pelo cumprimento
do requisito de independncia, pois ela depende apenas da API de Afluentes e apenas
por ela que o interpretador interage com mecanismos de carregamento de objetos.
O interpretador implementa a interface I P r e f e t c h e r exibida na Figura 60. O
parmetro de tipo S t a r t define a classe do objeto a partir do qual o interpretador iniciar
a navegao. O mtodo p r e f e t c h que recebe um objeto do tipo S t a r t como parmetro
navega a partir deste objeto. J o mtodo p r e f e t c h , que recebe uma avaliao como
parmetro, navega a partir do objeto carregado por esta avaliao. O tipo de retorno de
ambos os mtodos v o i d , pois a funo do interpretador carregar para a memria
primria os objetos que ele encontra durante a navegao e que ainda no foram carregados.
A classe P r e f e t c h e r I m p l implementa a interface I P r e f e t c h e r e encapsula a
implementao do interpretador. Para instanci-la, necessrio informar a especificao
Litoral que ser interpretada e a classe do objeto a partir do qual esta especificao ir
1
2
3
74
S t r i n g j p q l S t m t = " s e l e c t m from Message m where m. s e n d e r . i d = 1 " ;

TypedQuery<Message> query = orm . c r e a t e Q u e r y ( jpqlStmt , Message . c l a s s ) ;
4
5
6
7
8
S t r i n g l i t o r a l S t m t = " [ sender r e c i p i e n t s attachments ] " ;

P r e f e t c h e r I m p l <L i s t <Message>> p r e f e t c h e r =
new P r e f e t c h e r I m p l <L i s t <Message >>( l i t o r a l S t m t ) { } ;
p r e f e t c h e r . p r e f e t c h ( m ess ag es ) ;
9
10
Figura 61 Trecho de cdigo Java que usa o interpretador de Litoral.

navegar. As linhas 6 e 7 do trecho de cdigo da Figura 61, por exemplo, instanciam o
interpretador informando que ele ir interpretar a especificao
[ sender r e c i p i e n t s attachments ]
e que esta especificao ir navegar a partir de um objeto da classe L i s t <Message>. A

linha 7 executa o interpretador.
O trecho de cdigo da Figura 61 mostra que o projeto do interpretador cumpre o
requisito de baixo acoplamento, pois a incluso do interpretador (linhas 5 a 8) no modifica
o trecho de cdigo funcionalmente. Seu nico efeito carregar para a memria primria os
objetos pelos quais o trecho de cdigo ir navegar a partir da linha 10, de forma que no
ser necessrio carregar nenhum objeto durante a navegao. A incluso do interpretador
aumenta o desempenho do trecho de cdigo pois ele carrega os objetos com operaes de
E/S concorrentes. Similarmente incluso, a excluso do interpretador no modifica o
trecho de cdigo funcionalmente. Ela apenas reduz o desempenho do trecho de cdigo,
pois sem o interpretador os objetos so carregados com operaes de E/S sequenciais.
4.3 Implementao
4.3.1 Anlise Lxica e Sinttica
Os analisadores lxico e sinttico do interpretador foram gerados com a verso 3 do
ANTLR (PARR; QUONG, 1995). Alm de possuir excelente documentao (PARR, 2007),
O ANTLR gera analisadores que constroem ASTs a partir de anotaes na gramtica de
uma linguagem, facilitando a implementao do interpretador.
A Figura 62 exibe a gramtica de Litoral na metalinguagem do ANTLR. O
operador ^ (acento circunflexo) promove um token raiz de uma subrvore da AST. O
operador ! (exclamao) exclui um token da AST. O operador > (hfen seguido de maior
75
tokens { SPECIFICATION ; TRAVERSALS; PATH; INIT ; }
2
3
4
s p e c i f i c a t i o n : t r a v e r s a l path >
^(SPECIFICATION^(TRAVERSALS t r a v e r s a l ) ^(PATH path ) ) ;
5
6
traversal
: ID^ = ! path ;
path
: step !
step
: ID^ ! ID^ . ! path ! ID (
ID
: ( a . . z ! A . . Z ) ( a . . z ! A . . Z !
7
8
[ ! s t e p+ ] ! ;
9
10
) > ^( INIT ID ) ;
11
12
0 .. 9 );
Figura 62 Gramtica de Litoral na metalinguagem do ANTLR.

que) associa a alternativa de uma produo que o antecede regra de reescrita que o
sucede. A linha 3 da Figura 62, por exemplo, associa a alternativa
regra de reescrita
^(PROGRAM ^(TRAVERSALS t r a v e r s a l ) ^(PATH path ) )
. Esta associao faz com que o smbolo no-terminal program seja mapeado para um
n da AST que contm o token PROGRAM e possui dois filhos. O primeiro um n que
contm o token TRAVERSALS e cujos filhos so as travessias de program ( t r a v e r s a l ). O
segundo um n que contm o token PATH e cujo filho o caminho de program ( path ).
J a linha 10 da Figura 62 associa a alternativa
ID (
regra de reescrita
^( INIT ID )
. Esta associao faz com que o smbolo no terminal s t e p , ao ser produzido pela
alternativa ID ( ) , seja mapeado para um n da AST que contm o token INIT e
cujo filho o identificador da travessia sendo iniciada ( ID).
O ANTLR chama tokens como SPECIFICATION, TRAVERSALS, PATH e INIT de
imaginrios, pois eles no fazem parte da gramtica de uma linguagem, existindo apenas nas
1
2
76
v i s i t M e s s a g e =[ s e n d e r . p i c t u r e r e p l i e s . v i s i t M e s s a g e ( ) ]
visitMessage ()
Figura 63 Especificao Litoral cuja rvore sinttica e AST so exibidas nas figuras
64a e 64b, respectivamente.
ASTs construdas pelo analisador sinttico gerado pelo ANTLR. Tal como exemplificado
na linha 1 da Figura 62, tokens imaginrios so declarados na metalinguagem do ANTLR
com a palavra chave token .
As figuras 64a e 64b exemplificam o funcionamento do analisador sinttico gerado
pelo ANTLR a partir da gramtica da Figura 62. A primeira mostra a rvore sinttica da
especificao Litoral da Figura 63, enquanto a ltima mostra a sua AST.
4.3.2 Anlise Semntica

Alm de verificar se especificaes Litoral so semanticamente vlidas (seo
3.4.3), o analisador semntico constri as tabelas de smbolos destas especificaes.
As tabelas associam chaves a valores. Cada chave um par (nt , c) formado, respectivamente, pelo nome de uma travessia t e a classe do objeto a partir do qual t ser iniciada.
O valor associado a uma chave (nt , c) uma cpia da subrvore da AST correspondente
travessia t.
Os ns da cpia so anotados com as classes dos objetos sobre os quais eles atuam.
A Figura 65, por exemplo, exibe as chaves e os respectivos valores da tabela da especificao
Litoral da Figura 63 navegando a partir de um objeto da classe Message .
O analisador semntico constri a tabela de uma especificao Litoral preenchendoa, inicialmente, com uma nica entrada. A chave desta entrada um par formado por
uma cadeia de caracteres vazia e pela classe do objeto a partir do qual a especificao
Litoral navega. A cadeia de caracteres vazia indica que esta entrada contm o caminho
da especificao Litoral.
Em seguida, o analisador semntico procura na tabela por cpias de subrvores
da AST que ainda no foram anotadas. Se nenhuma for encontrada, ento a execuo
do analisador semntico chega ao fim. Caso contrrio, o analisador semntico anota a
primeira cpia encontrada. possvel que um dos ns da cpia contenha o token INIT ,
o que indica que ele inicia uma travessia t. Seu n filho contm o nome nt de t. Seu n
pai j foi anotado com a classe c do objeto a partir do qual t ser iniciada. O analisador
semntico procura na tabela pela chave (nt , c). Se ela for encontrada, nada precisa ser feito.
Caso contrrio, o analisador semntico inclui na tabela uma nova entrada que associa
(nt , c) a uma cpia da subrvore da AST correspondente a t.
77
(a) rvore sinttica
(b) AST
Figura 64 rvore sinttica e AST da especificao da Figura 63
78
(, Message)
(visitMessage, Message)
(visitMessage, List<Message>)
Figura 65 Tabela de smbolos da especificao Litoral da Figura 63.
4.3.3 Interpretao
A idia principal por trs da interpretao de especificaes Litoral com Afluentes consiste em construir composies de avaliaes a partir de suas tabelas de smbolos.
As avaliaes navegam por objetos, carregando-os para a memria primria se necessrio.
As tabelas de smbolos contm cpias das subrvores das ASTs das especificaes
Litoral. As composies de avaliaes so construdas medida que os ns das subrvores
so percorridos. Os ns esto anotados com as classes dos objetos sobre os quais eles
atuam. Os objetos podem ser listas de outros objetos, ou seja, suas classes so subclasses
de L i s t .
4.3.3.1 Ns que Atuam Sobre Objetos
Se n um n que atua sobre um objeto, ento n d origem a uma composio de
avaliaes das funes head e e v a l u a t i o n s 1 .
A funo 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 avaliaes. A primeira avaliao da lista carrega o objeto. Se ele
implementa a interface I E v a l H o l d e r , ento a primeira avaliao a retornada pelo mtodo
g e t E v a l . Caso contrrio, a avaliao da funo identidade aplicada ao objeto. As demais
avaliaes da lista retornada por e v a l u a t i o n s 1 correspondem a avaliaes de funes
que, a partir do objeto recebido como argumento:
navegam atravs dos atributos cujos nomes esto contidos nos filhos de n; ou
iniciam as travessias cujos nomes esto contidos nos netos de n.
79
A funo head recebe uma lista de objetos como argumento e retorna o primeiro
objeto da lista.
Por exemplo, se a especificao Litoral da Figura 63 for aplicado mensagem
m1 , ento a composio de avaliaes exibida na Subfigura 66a ser construda. Nesta e
nas demais subfiguras da Figura 66, retngulos contornados por linhas slidas, tracejadas
e crculos representam, respectivamente, funes, listas e avaliaes. Por fim, setas representam composies de avaliaes. Para simplificar os diagramas, os ns que e v a l u a t i o n 1
recebe como argumento foram omitidos e uma mesma avaliao pode ter sido desenhada
mais de uma vez (por exemplo, a avaliao associada a m1 ).
As subfiguras 66b, 66d, 66f e 66h mostram o resultado de execues de e v a l u a t i o n s 1 ,
As subfiguras 66i e 66j, por sua vez, mostram o resultado de execues de head .
4.3.3.2 Ns que Atuam Sobre Listas
Ns que atuam sobre listas originam avaliaes da funo e v a l u a t i o n s 2 , a qual
recebe uma lista de objetos como argumento e retorna uma lista de avaliaes. Para produzir
as avaliaes, e v a l u a t i o n s 2 aplica a composio das funes head e e v a l u a t i o n s 1
descritas na seo anterior a cada um dos objetos recebidos como argumento.
Voltando ao exemplo da Figura 66, a Figura 66l mostra o resultado da aplicao
de e v a l u a t i o n s 2 lista [m2 ].
(a)
80
(b)
(c)
(e)
(d)
Figura 66 Interpretao de especificaes Litoral
81
(g)
(f)
(i)
(h)
Figura 66 Interpretao de especificaes Litoral - Continuao
82
(k)
(j)
(l)
(m)
Figura 66 Interpretao de especificaes Litoral - Continuao
83
5 Avaliao
A estratgia proposta por esta pesquisa para aumentar o desempenho de sistemas
baseados em ORMs consiste em executar concorrentemente consultas que pr-carregam
objetos. Esta estratgia foi avaliada com os benchmarks sintticos Emeio e OO7 (CAREY;
DEWITT; NAUGHTON, 1993) (CAREY et al., 1994). O primeiro foi desenvolvido no
contexto desta pesquisa e baseado em um sistema no qual o autor atuou como arquiteto de
software. O segundo foi criado para avaliar o desempenho de OODBMSs (Object-Oriented
Database Management Systems) e, alm de ser usado para este fim (BONCZ; KWAKKEL;
KERSTEN, 1995; WITT et al., 1996), tambm usado para avaliar o desempenho de
ORMs (BERNSTEIN; PAL; SHUTT, 2000; HAN; WHANG; MOON, 2005; IBRAHIM;
COOK, 2006; ZYL; KOURIE; BOAKE, 2006; ZYL et al., 2009; ZYL, 2010; GERSEN,
2013), processamento de dados XML (LI et al., 2001), programao paralela (WELC;
JAGANNATHAN; HOSKING, 2005; JR et al., 2011) e memria transacional em software
(GUERRAOUI; KAPALKA; VITEK, 2007; ZIAREK et al., 2008).
Os benchmarks foram implementados com o interpretador de Litoral. Como
ele depende de um mecanismo de carregamento de objetos para funcionar, um ORM
mnimo contendo apenas as funcionalidades requeridas pelos benchmarks foi desenvolvido
e integrado ao interpretador. Tambm foi adicionada ao interpretador a capacidade de
pr-carregar objetos executando consultas sequencialmente. Isto nos permitiu comparar
o tempo de execuo dos benchmarks quando objetos so pr-carregados com consultas
executadas sequencialmente versus concorrentemente.
Caso a avaliao fosse feita apenas com esta comparao, as implementaes
dos benchmarks baseadas no interpretador de Litoral poderiam no adotar outras
otimizaes, diferentes da proposta nesta pesquisa, que ORMs costumam adotar. Isto
faria com que os tempos de execuo dos benchmarks com o interpretador de Litoral
no modo sequencial fossem artificialmente elevados, o que superestimaria o benefcio de
pr-carregar objetos executando consultas concorrentemente, pondo em risco a validade
da avaliao.
Para minimizar este risco, os benchmarks tambm foram implementados com os
ORMs Hibernate e Eclipse Link JPA, os quais aderem especificao JPA. O primeiro
foi escolhido devido sua popularidade. O ltimo foi escolhido por ser a implementao
de referncia de JPA. As implementaes dos benchmarks baseadas no Hibernate e
no EclipseLink JPA adotam as otimizaes disponibilizadas por estes ORMs, as quais
tambm foram, em sua maioria, adotadas pelas implementaes baseadas no interpretador
de Litoral.
Captulo 5. Avaliao
84
Como as implementaes dos benchmarks adotam, em grande parte, as mesmas

otimizaes, os tempos de execuo daquelas baseadas no Hibernate e no EclipseLink JPA
so similares aos daquelas baseadas no interpretador de Litoral no modo sequencial.
Esta similaridade, alm de tornar a avaliao mais confivel, uma evidncia de que ORMs
industriais experimentariam ganhos de desempenho similares aos observados quando o
interpretador opera no modo concorrente.
Os benchmarks foram executados em um computador com um processador AMD
Phenom II X4 955, o qual possui 4 ncleos, 8Gb de memria RAM, sistema operacional
Ubuntu Desktop 14.04.1 LTS e o sistema de gerenciamento de banco de dados PostgreSQL
9.3.5. Ambos os sistemas foram mantidos em suas configuraes padro.
5.1 Emeio
Emeio um benchmark baseado em um sistema que permite a seus usurios
enviarem mensagens entre si. Ele avalia o desempenho de navegaes por objetos das
classes exibidas na Seo A.1:
MediaType representa tipos de arquivos (por exemplo, application/pdf, image/jpeg
e image/png);
F i l e representa arquivos. Um arquivo possui um tipo ( MediaType ) ;
User representa os usurios do sistema. Cada usurio possui uma foto ( F i l e ) ;
Tag representa marcaes que os usurios podem adicionar mensagens para
classific-las (por exemplo, famlia, universidade e trabalho);
Message representa as mensagens que os usurios enviam uns aos outros. Cada
mensagem possui um remetente ( User ) , destinatrios ( User ) , anexos ( F i l e ) ,
marcaes ( Tag ) e rplicas ( Message ) .
O mapeamento objeto-relacional foi feito da seguinte maneira:
cada classe mapeada para uma tabela;
os atributos que identificam objetos unicamente so mapeados para chaves primrias;
os demais atributos so mapeados para colunas;
associaes de cardinalidade um para muitos so mapeadas para chaves estrangeiras
nas tabelas das classes que esto no lado muitos das associaes. As chaves
estrangeiras referenciam as tabelas das classes que esto no lado um;
Captulo 5. Avaliao
85
associaes de cardinalidade muitos para muitos so mapeadas para tabelas cujas

chaves primrias so formadas por chaves estrangeiras que referenciam as tabelas
das classes associadas. Os atributos das associaes, quando existirem, so mapeados
para colunas de suas tabelas;
subclasses so mapeadas para tabelas que contm apenas seus atributos prprios
(aqueles que no foram herdados das superclasses). As tabelas das subclasses possuem
chaves estrangeiras que referenciam as tabelas das superclasses.
A Seo A.2 exibe as tabelas resultantes do mapeamento objeto-relacional. O banco
de dados populado com um tipo de arquivo, uma marcao e cem usurios. Cada usurio
possui uma imagem e iniciou (ou seja, enviou a primeira mensagem de) mil conversaes.
Cada uma das nove primeiras mensagens de uma conversao possui uma rplica, enquanto
a ltima no possui rplicas. Portanto, cada conversao possui dez mensagens. Cada
mensagem possui um anexo e est associada a uma marcao. Resumindo, o banco de
dados populado com 1 tipo de arquivo, 1 marcao, 100 usurios, 1.000.000 mensagens e
1.000.100 arquivos.
Emeio composto pelas especificaes Litoral exibidas na Figura 67. As especificaes C e G declaram navegaes executadas durante a exibio da lista de mensagens
enviadas e recebidas por um usurio, respectivamente. A especificao L declara navegaes
executadas durante a exibio de todas as mensagens que compem uma conversao.
As especificaes AB, DF e HK so verses simplificadas das especificaes C, G e L,
respectivamente.
As especificaes AC e DG so executadas, respectivamente, a partir das 50
ltimas mensagens enviadas e recebidas por um usurio escolhido aleatoriamente. As
especificaes HL so executados a partir de mensagens escolhidas tambm aleatoriamente.
Todas as especificaes so executadas 6.000 vezes. As 1.000 primeiras so ignoradas para
minimizar a interferncia de custos de inicializao (por exemplo, carregamento de classes
e compilao just in time).
5.1.1 Implementao Baseada no Hibernate

A implementao de Emeio baseada no Hibernate sofreu as seguintes otimizaes:
1. atributos do tipo II so carregados atravs de consultas que fazem uso do operador i n
de SQL para carregar vrios objetos, ou seja, a anotao @BatchSize foi adicionada
aos atributos anotados com @ManyToOne ou @ManyToMany;
2. atributos do tipo II que referenciam objetos so carregados sob demanda, ou seja, o
atributo f e t c h das anotaes @ManyToOne recebu o valor FetchType .LAZY;
Captulo 5. Avaliao
86
recipients
// A
r e c i p i e n t s tags
// B
r e c i p i e n t s tags f i l e s
// C
sender
// D
sender r e c i p i e n t s
// E
sender r e c i p i e n t s tags
// F
sender r e c i p i e n t s tags f i l e s
// G
visitMessage = [ r e p l i e s . visitMessage ( ) ]
visitMessage ()
// H
visitMessage = [ sender r e p l i e s . visitMessage ( ) ]

visitMessage ()
// I
visitMessage = [ sender r e c i p i e n t s r e p l i e s . visitMessage ( ) ]

visitMessage ()
// J
visitMessage = [ sender r e c i p i e n t s tags r e p l i e s . visitMessage ( ) ]

visitMessage ()
// K
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
v i s i t M e s s a g e = [ s e n d e r 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 M e s s a g e ( ) ] // L
visitMessage ()
Figura 67 Especificaes Litoral que compem o benchmark Emeio.

3. ndices foram criados para as chaves estrangeiras de todas as tabelas;
4. as tabelas message_sender_view e m e s s a g e _ r e c i p i e n t _ v i e w exibidas na Figura
68 foram adicionadas ao banco de dados. Elas armazenam, respectivamente, as 50
ltimas mensagens enviadas e recebidas por cada usurio do sistema;
5. ndices foram criados para os pares de colunas das tabelas message_sender_view e
m e s s a g e _ r e c i p i e n t _ v i e w com os comandos SQL exibidos na Figura 69.
As figuras 70a70e exibem o tempo total de execuo das especificaesLitoral
AL com diferentes verses da implementao de Emeio baseada no Hibernate. A Figura
70a exibe os tempos com as verses no otimizada e com a otimizao 1, a Figura 70b
exibe os tempos das verses com a otimizao 1 e com as otimizaes 1 e 2 combinadas,
e assim sucessivamente. Nas figuras 70a70d o tempo total corresponde a 10 execues
Captulo 5. Avaliao
87
Figura 68 Tabelas adicionadas ao banco de dados para otimizar a implementao de

Emeio baseada no Hibernate.
1
2
create index on m e s s a g e _ r e c i p i e n t _ v i e w ( r e c i p i e n t _ i d e n t i f i e r ,
m e s s a g e _ i d e n t i f i e r desc ) ;
3
4
5
create index on message_sender_view ( s e n d e r _ i d e n t i f i e r ,

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 especificao Litoral, enquanto que na Figura 70e ele corresponde a 5.000
execues. Foi necessrio aumentar o nmero de execues porque a reduo no tempo
total proporcionada pela otimizao 5 s se torna aparente com um nmero maior de
execues.
Os dados exibidos nas figuras 70a70e so sintetizados pelas seguintes observaes:
aplicar a otimizao 1 verso no otimizada reduz o tempo total de execuo das
especificaes Litoral AC e EG em 75,178,8%;
aplicar a otimizao 2 verso com a otimizao 1 reduz o tempo total de execuo
das especificaes Litoral AG em 15,552,0%;
aplicar a otimizao 3 verso com as otimizaes 12 reduz o tempo total de
execuo de todas especificaes Litoral em 67,599,7%;
execuo das especificaes Litoral AG em 68,189,6%;
execuo das especificaes Litoral AG em 10,625,3%.
Captulo 5. Avaliao
88
(a)
(b)
(c)
Figura 70 Resultado das otimizaes da implementao de Emeio baseada no Hibernate.
Captulo 5. Avaliao
89
(d)
(e)
Figura 70 Resultado das otimizaes da implementao de Emeio baseada no Hibernate

- continuao.
5.1.2 Implementao Baseada no EclipseLink JPA

A implementao de Emeio baseada no EclipseLink JPA sofreu as mesmas otimizaes que a baseada no Hibernate. A nica diferena entre elas que a otimizao 1 obtida
no EclipseLink JPA adicionando-se a anotao @BatchFetch ( v a l u e=BatchFetchType . IN )
aos atributos anotados com @ManyToOne ou @ManyToMany.
5.1.3 Implementao Baseada no Interpretador de Litoral

A implementao de Emeio baseada no interpretador de Litoral sofreu as mesmas
otimizaes que as baseadas no Hibernate e no EclipseLink JPA. Entretanto, uma diferena
importante entre elas que tanto o Hibernate quanto o EclipseLink JPA armazenam
os objetos que eles carregam do banco de dados em um cache, minimizando assim o
Captulo 5. Avaliao
90
recarregamento de objetos, enquanto a implementao baseada no interpretador no adota

esta otimizao.
5.1.4 Resultados
As figuras 71a71c exibem o tempo total de execuo das especificaes AL com
as implementaes de Emeio baseadas no Hibernate, EclipseLink JPA e no interpretador
de Litoral.
Em muitos casos, o tempo total de execuo com o interpretador no modo sequencial
menor do que o obtido com o Hibernate e o EclipseLink JPA. bastante provvel que
isto ocorra porque o ORM com o qual o interpretador foi integrado possui apenas as
funcionalidades necessrias implementao dos benchmarks, enquanto o Hibernate e
o EclipseLink JPA implementam uma srie de outras funcionalidades que ajudam o
desenvolvedor, mas, eventualmente, reduzem o desempenho.
O tempo total de execuo das especificaes A, D e H com o interpretador no
modo concorrente foi 0,99,9% maior do que no sequencial. Este aumento ocorre porque a
otimizao 1 da seo 5.1.1 elimina destas especificaes as oportunidades para concorrncia.
Em casos assim, o aumento no tempo de processamento oriundo do gerenciamento da
concorrncia no compensado por uma reduo no tempo de E/S, pois as consultas
so executadas sequencialmente. Esta observao sugere que o interpretador deveria ser
capaz de identificar se uma especificao oferece oportunidades para concorrncia. Em
caso negativo, o interpretador operaria no modo sequencial mesmo quando solicitado a
operar no modo concorrente.
Por outro lado, o tempo total de execuo das demais especificaes com o interpretador no modo concorrente foi 33,369,1% menor do que no sequencial. De maneira
geral, quanto maiores forem as oportunidades para concorrncia (especificaes C, G e L),
maior a reduo no tempo total de execuo.
Em algumas especificaes, o tempo total de execuo com o interpretador no modo
sequencial foi menor do que com as implementaes baseadas no Hibernate (especificaes
AD e GH) e EclipseLink JPA (especificaes AC e G). Em outras, foi maior. O pior
desempenho foi observado na especificao I, na qual o tempo total de execuo mais
que dobrou. Entretanto, em todas as especificaes que oferecem oportunidades para
pr-carregar objetos executando consultas concorrentemente, esta otimizao fez com que
o tempo total de execuo com o interpretador no modo concorrente fosse menor do que
com as implementaes baseadas no Hibernate (862,3%) e EclipseLink JPA (8,156,4%).
Captulo 5. Avaliao
91
(a)
(b)
(c)
Figura 71 Tempo total de execuo das implementaes de Emeio baseadas no interpretador de Litoral, Hibernate e EclipseLink JPA.
Captulo 5. Avaliao
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 navegaes, atualizaes e
consultas em OODBMs. Como o interpretador de Litoral influencia apenas o desempenho
de navegaes, a implementao de OO7 desenvolvida nesta pesquisa, tal como (IBRAHIM;
COOK, 2006), se limita a esta parte do benchmark.
Os principais conceitos modelados por OO7 so:
partes compostas ( CompositePart ) representam primitivas de projeto bsicas 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 atmica ( AtomicPart ) raiz;
partes atmicas ( AtomicPart ) representam as unidades que compem as partes
compostas. Em um sistema CASE, por exemplo, elas representariam variveis,
comandos, expresses, etc. Uma parte atmica possui conexes com outras partes
atmicas;
conexes ( Connection ) representam a conexo entre uma parte atmica de origem
e outra de destino;
montagens ( Assembly ) representam construes de projeto de alto nvel como, por
exemplo, uma unidade lgica e aritmtica em um sistema VLSI CAD. Montagens
podem ser formadas por partes compostas, caso em que so chamadas de montagens
base ( BaseAssembly ) , ou por outras montagens, caso em que so chamadas de
montagens complexas ( ComplexAssembly ) ;
mdulos ( Module ) representam hierarquias de montagens complexas. Um mdulo
possui um manual ( Manual ) e uma montagem complexa raiz;
manuais ( Manual ) representam a documentao de um mdulo.
A implementao de OO7 desenvolvida nesta pesquisa adota o banco de dados
(modelo, ndices e dados) da desenvolvida em (ZYL, 2010). A Seo B.2 exibe suas tabelas
principais. A Figura 72 exibe os comandos SQL que criam seus ndices.
OO7 especifica trs tamanhos de banco de dados: pequeno, mdio 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 atmicas, 30.000, 60.000 ou
90.000 conexes para cada parte atmica (esta pesquisa adotou 30.000), 729 montagens
bsicas, 365 montagens complexas e 1 mdulo.
Captulo 5. Avaliao
1
2
3
4
5
6
create
create
create
create
create
create
index
index
index
index
index
index
on
on
on
on
on
on
93
assembly ( d e s i g n i d ) ;
atomic_parts ( b u i l d d a t e ) ;
atomic_parts ( d e s i g n i d ) ;
composite_parts ( d e s i g n i d ) ;
document ( t i t l e ) ;
module ( b u i l d d a t e ) ;
Figura 72 ndices de OO7.

1
2
3
4
5
6
v i s i t A t o m i c P a r t=t o C o n n e c t i o n s . t o . v i s i t A t o m i c P a r t ( ) // T1
v i s i t A s s e m b l y =[
subAssemblies . visitAssembly ()
componentsPrivate . rootPart . visitAtomicPart ( )
]
designRoot . visitAssembly ( )
7
8
9
10
11
12
v i s i t A s s e m b l y =[
subAssemblies . visitAssembly ()
componentsPrivate . rootPart
]
designRoot . visitAssembly ( )
// T6
Figura 73 Especificaes Litoral que fazem parte de OO7.

OO7 composto por sete cenrios denominados T1, T2, T3, T6, T8, T9 e CU
(Cache Update). Os cenrios T2, T3 e CU realizam as mesmas navegaes que T1 e,
adicionalmente, atualizam objetos. Os cenrios T8 e T9 consistem em carregar um manual
e varrer o seu contedo (uma cadeia de caracteres). Como o interpretador de Litoral
influencia apenas o desempenho de navegaes, esta pesquisa, tal como (IBRAHIM; COOK,
2006), ignora T2, T3 e CU. Ela tambm ignora T8 e T9, j que estes cenrios no oferecem
opotunidades para concorrncia. A Figura 73 exibe as especificaes Litoral que declaram
as navegaes executadas em T1 e T6. As duas especificaes so executadas a partir
de um mdulo. A Seo B.1 exibe as classes dos objetos pelos quais estas especificaes
navegam.
5.2.1 Implementao Baseada no Hibernate

A implementao de OO7 baseada no Hibernate sofreu uma nica otimizao:
atributos do tipo II so carregados atravs de consultas que fazem uso do operador i n
de SQL para carregar vrios objetos, ou seja, a anotao @BatchSize foi adicionada aos
atributos anotados com @OneToMany, @ManyToOne e @ManyToMany. A Figura 74 exibe o
tempo total de 10 execues das especificaes T1 e T6 com as verses no otimizada e
otimizada. A ltima 91,591,8% mais rpida do que a primeira.
Captulo 5. Avaliao
94
Figura 74 Resultados da otimizao da implementao de OO7 baseada no Hibernate.
5.2.2 Implementao Baseada no EclipseLink JPA

A implementao de OO7 baseada no EclipseLink JPA sofreu a mesma otimizao
que a baseada no Hibernate. Entretanto, uma limitao do EclipseLink JPA impediu que
os objetos referenciados pelos atributos c o m p o n e n t s P r i v a t e da classe BaseAssembly e
s u b A s s e m b l i e s da classe ComplexAssembly fossem carregados atravs de consultas que
fazem uso do operador i n de SQL para carregar vrios objetos. Mais especificamente,
a exceo o r g . e c l i p s e . p e r s i s t e n c e . e x c e p t i o n s . QueryException levantada com
o cdigo de erro 6169 quando a anotao @BatchFetch ( v a l u e=BatchFetchType . IN )
adicionada a estes atributos.
5.2.3 Implementao Baseada no Interpretador de Litoral

A implementao de OO7 baseada no interpretador de Litoral sofreu a mesma
otimizao que a baseada no Hibernate. Entretanto, diferentemente do Hibernate e do
EclipseLink JPA, ela no armazena objetos em um cache.
5.2.4 Resultados
A Figura 75 exibe o tempo total de execuo das especificaes T1 e T6 com as
implementaes de OO7 baseadas no Hibernate, EclipseLink JPA e no interpretador de
Litoral. O tempo total de execuo das especificaes T1 e T6 com o interpretador no
modo concorrente foi 49,559,3% menor do que no sequencial.
O tempo total de execuo das especificaes T1 e T6 com o interpretador no
modo sequencial foi menor do que com as implementaes baseadas no Hibernate e
EclipseLink JPA. A nica exceo foi a especificao T6 com o Hibernate. Entretanto, o
tempo total de execuo com o interpretador no modo concorrente foi menor do que com as
implementaes baseadas no Hibernate (52,458,0%) e no EclipseLink JPA (95,296,5%).
Captulo 5. Avaliao
95
Figura 75 Tempo total de execuo das implementaes de Emeio baseadas no interpretador de Litoral, Hibernate e EclipseLink JPA.
No caso do Hibernate, a reduo no tempo total de execuo se deve majoritariamente
execuo concorrente de consultas. Entretanto, no caso do EclipseLink JPA, a contribuio
desta otimizao foi minoritria, pois o tempo total de execuo com o interpretador no
modo sequencial j muito menor (90,491,5%) do que com o EclipseLink JPA.
96
6 Trabalhos Relacionados
Este captulo 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 alcanam este objetivo produzindo consultas SQL que, quando
executadas sequencialmente, minimizam o tempo de pr-carregamento de objetos. Um
aspecto interessante, evidenciado no Captulo 5, que estas consultas, na maioria dos
casos, tambm podem ser executadas concorrentemente, reduzindo ainda mais o tempo de
pr-carregamento de objetos.
6.1 Program Summaries

(GUHIS; GOASDOU-THION; RIGAUX, 2009) aumenta o desempenho de
sistemas baseados em ORMs pr-carregando objetos com consultas que carregam vrios
objetos. Para isto, ele define uma linguagem chamada Program Summary, baseada na
linguagem XPath (CLARK; DEROSE et al., 1999), que permite especificar navegaes
por objetos. A Figura 76, por exemplo, exibe uma especificao Program Summary que
declara navegaes das mensagens enviadas pelo usurio cujo identificador igual a 1
para seus remetentes e destinatrios.
Sejam S uma especificao Program Summary, G um grafo de objetos e v um
vrtice deste grafo. (GUHIS; GOASDOU-THION; RIGAUX, 2009) define formalmente
o trao TS,v (G) de S sobre o vrtice v com respeito a G. Intuitivamente, o trao corresponde
aos vrtices de G pelos quais a especificao S, iniciando por v, navega.
(GUHIS; GOASDOU-THION; RIGAUX, 2009) apresenta trs estratgias para
transformar uma especificao Program Summary S em programas que, dados um grafo
de objetos G e um vrtice v deste grafo, carregam TS,v (G). Estes programas so formados
pelas operaes open, fetch e decode, consultas SQL e laos.
A primeira estratgia chamada de Lazy e corresponde ao carregamento sob
demanda dos vrtices de G. Esta estratgia, portanto, a que executa mais consultas SQL.
@db . Message [ s e n d e r . i d e n t i f i e r =1] {
2
@sender { } ;
3
@ r e c i p i e n t s {}
4 }
1
Figura 76 Especificao Program Summary que declara navegaes das mensagens enviadas por um usurio para seus remetentes e destinatrios.
Captulo 6. Trabalhos Relacionados
97
A segunda estratgia, chamada de Single, faz uso de junes (AHO; BEERI;

ULLMAN, 1979) e do operador union de SQL para carregar vrios objetos executando
uma nica consulta. A desvantagem desta estratgia que o resultado da consulta que ela
executa tende a ter um nmero muito grande de linhas e colunas.
A terceira estratgia chamada de Decorrelation e executa uma consulta SQL para
cada tabela que contm vrtices de TS,v (G). Ela uma estratgia intermediria 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 vrios objetos.
(GUHIS; GOASDOU-THION; RIGAUX, 2009) define o custo de execuo de
uma especificao Program Summary como sendo a combinao linear
Copen Nopen + Cnet Nf etch + Cdecode Ndecode
, onde Copen , Cnet e Cdecode , so os pesos relativos das operaes open, fetch e decode e
Nopen , Nnet e Ndecode so os nmeros de vezes que estas operaes so executadas.
Ele supe que os pesos Copen , Cnet e Cdecode so similares e prope um algoritmo
que transforma uma especificao Program Summary S em um programa que combina as
estratgias Lazy, Single e Decorrelation de forma a minimizar a soma Nopen +Nf etch +Ndecode
e, portanto, minizar o custo de execuo de S.
Para avaliar sua proposta, (GUHIS; GOASDOU-THION; RIGAUX, 2009)
implementa uma extenso do Hibernate que aplica o algoritmo de otimizao a uma
especificao Program Summary e pr-carrega seu trao. A partir desta extenso, ele
prope e implementa um benchmark que adota o banco de dados do benchmark TPC-H
(POESS; FLOYD, 2000).
Em comum com esta pesquisa, (GUHIS; GOASDOU-THION; RIGAUX, 2009)
define uma linguagem que permite especificar navegaes por objetos e projeta e implementa
um interpretador que executa especificaes desta linguagem, pr-carregando os objetos
pelos quais ele navega.
Entretanto, uma diferena fundamental entre (GUHIS; GOASDOU-THION;
RIGAUX, 2009) e esta pesquisa que o primeiro se prope a reduzir o tempo de prcarregamento tp de objetos encontrando as consultas que, quando executadas sequencialmente, minimizam tp , enquanto que esta pesquisa reduz tp executando consultas
concorrentemente.
Outras diferenas importantes so:
(GUHIS; 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;
98
apesar de (GUHIS; GOASDOU-THION; RIGAUX, 2009) definir formalmente a

semntica de Program Summary, esta definio depende da semntica do subconjunto
de XPath adotado. Esta pesquisa define a semntica de Litoral completamente,
ainda que de uma maneira que apenas se aproxima de uma definio formal;
dentro de algumas condies, o interpretador de Program Summary minimiza tp ,
enquanto o de Litoral pode at aumentar tp ;
(GUHIS; GOASDOU-THION; RIGAUX, 2009) avaliou sua proposta apenas com
um benchmark prprio enquanto que esta pesquisa avaliou sua proposta com um
benchmark prprio (Emeio) e com um benchmark de terceiros (OO7).
6.2 Scalpel
Scalpel (BOWMAN; SALEM, 2005) intercepta as consultas SQL que um sistema
executa visando identificar padres de aninhamento
Q1 , Q2 (r1 ), ..., Q2 (rn )
, onde Q1 uma consulta cujo resultado formado pelas tuplas r1 , ..., rn e Q2 (r1 ), ..., Q2 (rn )
so instncias da consulta parametrizada Q2 . Estes padres so bastante comuns em
sistemas baseados em ORMs que carregam objetos sob demanda e tambm em sistemas que
acessam bancos de dados relacionais diretamente, inclusive aqueles que so desenvolvidos
em linguagens imperativas.
Ele consegue carregar os mesmos dados que as consultas Q1 , Q2 (r1 ), ..., Q2 (rn )
carregam executando uma nica consulta Qopt e tambm consegue extrair do resultado de
Qo pt os resultados de Q1 , Q2 (r1 ), ..., Q2 (rn ).
Quando o sistema excuta a consulta Q1 , Scalpel especula se as consultas Q2 (r1 ), ...,
Q2 (rn ) sero executadas em seguida. Em caso negativo, ele simplesmente executa Q1 ,
retornando seu resultado para o sistema. Em caso positivo, ele executa a consulta
Qopt , extrai de seu resultado o resultado de Q1 , Q2 (r1 ), ..., Q2 (rn ), armazena o resultado
Q2 (r1 ), ..., Q2 (rn ) e, finalmente, retorna o resultado de Q1 para o sistema. Se Scalpel
especulou corretamente, ento o sistema ir executar as consultas Q2 (r1 ), ..., Q2 (rn ) aps
receber o resultado de Q1 . Neste caso, Scalpel simplesmente retorna os resultados de
Q2 (r1 ), ..., Q2 (rn ) que ele armazenou anteriormente. Caso contrrio, Scalpel executa a
consulta Q3 (Q3 6= Q2 (r1 ) ... Q3 6= Q2 (rn )) que o sistema executou e retorna para o
sistema o resultado de Q3 .
(BOWMAN; SALEM, 2007) amplia Scalpel para tratar lotes de consultas, ou seja,
padres
99
Q1 , ..., Qn
, onde Q1 , ..., Qn so consultas no-aninhadas relacionadas quaisquer.
Provavelmente, a caracterstica mais interessante de Scalpel a transparncia.
Scalpel pode ser implantado entre qualquer sistema e os banco de dados relacionais
que ele acessa. O sistema continuar executando as mesmas consultas e recebendo os
mesmos resultados, s que mais rapidamente. Outra caracterstica distintiva de Scalpel
a generalidade, j que ele aumenta o desempenho de sistemas independentemente deles
serem ou no baseados em ORMs.
Restrigindo ao contexto de ORMs, a principal diferena entre Scalpel e Program
Summaries que o primeiro pr-carrega dados (resultados de consultas) especulativamente,
enquanto que o segundo pr-carrega dados (objetos) a partir de informaes fornecidas
por programadores. Outra diferena importante que o modelo de custos do primeiro
mais sofisticado que o do segundo, fazendo uso, por exemplo, de estimativas de custos
de execuo de consultas fornecidas pelo SGBD (Sistema de Gerenciamento de Banco de
Dados) em tempo de execuo.
Em comum com Program Summaries, Scalpel aumenta o desempenho de sistemas
baseados em ORMs agrupando consultas que so executadas sequencialmente, explorando,
portanto, uma otimizao diferente da proposta nesta pesquisa.
6.3 AutoFetch
AutoFetch (IBRAHIM; COOK, 2006), assim como Scalpel, prope um mtodo para
especular por quais objetos sistemas baseados em ORMs navegam. Uma caracterstica
distintiva de AutoFetch classificar consultas em classes e executar o mtodo para cada
uma das classes. AutoFetch determina a classe de uma consulta Q a partir da prpria
consulta e de um subconjunto do estado da pilha de execuo no momento em que Q
executada. Isto permite que AutoFetch pr-carregue objetos diferentes quando uma mesma
consulta executada em pontos diferentes de um sistema.
Entretanto, diferentemente de Scalpel e tambm de Program Summaries, que
decidem qual estratgia minimiza o tempo de pr-carregamento de objetos e dados,
respectivamente, com modelos de custos, AutoFetch sempre adota uma variao da
estratgia Single da Seo 6.1.
A estratgia Single executa consultas cujo resultado tende a ter um nmero muito
grande de linhas e colunas. AutoFetch lida com esta desvantagem abrindo mo do operador
union , o que reduz o nmero de linhas, e fazendo no mximo uma juno com tabelas
que representam relacionamentos muitos para muitos, o que reduz o nmero de linhas e
colunas.
100
As restries que AutoFetch impe estratgia Single evitam, na maioria dos casos,
que ela execute consultas que aumentam o tempo de pr-carregamento ao invs de reduzilo. Entretanto, por adotar apenas uma variao da estratgia Single, o desempenho de
AutoFetch , provavelmente, pior que o de Program Summaries nos casos em que este ltimo
determina que a estratgia Single no 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 so executadas sequencialmente.
Trata-se, portanto, de um trabalho relacionado, mas que explora uma otimizao diferente
da proposta nesta pesquisa.
6.4 Outros Trabalhos sobre Pr-carregamento Especulativo

Esta seo relaciona outros trabalhos sobre pr-carregamento especulativo em
sistemas baseados em ORMs e similares que, assim como AutoFetch, focam em mtodos de
especulao. Diferentemente desta pesquisa, nenhum deles pr-carrega objetos executando
consultas concorrentemente.
(HAN; WHANG; MOON, 2005; IBRAHIM; COOK, 2006): classificam estes trabalhos nas categorias a seguir.
Baseados em pginas: so 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 esto armazenados em uma mesma pgina de memria;
Baseados em padres de acesso a objetos/pginas: so aqueles que, ao
carregarem um objeto/pgina, pr-carregam outros objetos/pginas cujos acessos esto
correlacionados com os do primeiro. (PALMER, 1991) um cache que implementa esta
tcnica. (CUREWITZ; KRISHNAN; VITTER, 1993; VITTER; KRISHNAN, 1996) empregam mtodos de compresso de dados para identificar correlaes. (GARBATOV;
CACHOPO, 2010; GARBATOV et al., 2011) empregam mtodos estocsticos;
Baseados em contexto: (BERNSTEIN; PAL; SHUTT, 2000) foi o primeiro
trabalho deste tipo. A seo 2.3 discute o mtodo de especulao que ele props, o qual
(HAN et al., 2001; HAN; MOON; WHANG, 2003; HAN; WHANG; MOON, 2005) refinaram
posteriormente.
101
7 Concluso
Esta pesquisa partiu da hiptese de que ORMs podem aumentar o desempenho de
sistemas executando concorrentemente consultas que pr-carregam objetos e se props a
desenvolver esta otimizao.
As avaliaes descritas no captulo 5 so evidncias de que a hiptese verdadeira e
de que o desenvolvimento da otimizao foi bem sucedido. De fato, no benchmark Emeio,
a execuo concorrente de consultas reduziu o tempo total de execuo em at 69,1%,
ou seja, aumentou a velocidade de execuo em at 323,6%. J no benchmark OO7, o
tempo total de execuo foi reduzido em at 59,3%, ou seja, a velocidade de execuo foi
aumentada em at 245,7%.
Nos dois benchmarks, em todos os cenrios que oferecem oportunidades para a
execuo concorrente de consultas que pr-carregam objetos, o tempo total de execuo com
esta otimizao foi menor do que com importantes ORMs industriais, os quais executam
estas consultas apenas sequencialmente. Este resultado mais uma evidncia de que o
desempenho de sistemas baseados em ORMs ser maior se estes ltimos adotarem a
otimizao proposta e desenvolvida nesta pesquisa.
7.1 Contribuies
As contribuies principais desta pesquisa foram:
1. identificar a oportunidade de pr-carregar objetos pelos quais sistemas baseados em
ORMs navegam executando consultas concorrentemente;
2. produzir evidncias de que, explorando esta oportunidade, pode-se aumentar significativamente o desempenho destes sistemas.
Adicionalmente, a forma como esta pesquisa explorou tal oportunidade produziu
as seguintes contribuies:
3. a DSL Litoral, a qual permite a especificao de navegaes iterativas e recursivas
por objetos;
4. o interpretador definidor de Litoral, o qual se aproxima de uma definio formal
desta DSL;
5. o projeto e a implementao do interpretador de Litoral, o qual pode ser facilmente
integrado a ORMs e outros mecanismos de carregamento de objetos;
Captulo 7. Concluso
102
6. o benchmark Emeio, voltado para a avaliao de desempenho de navegaes em

ORMs;
7. o projeto e a implementao do framework Afluentes (ARAUJO et al., 2014),
o qual permite que sistemas que executam operaes de E/S sequencialmente ou
concorrentemente atravs de primitivas de E/S sncronas ou assncronas sejam
desenvolvidos com um mesmo modelo de programao.
7.2 Trabalhos Futuros

Possveis desdobramentos desta pesquisa so:
1. identificar e explorar outras oportunidades de aumentar o desempenho de sistemas
baseados em ORMs atravs da execuo concorrente de consultas;
2. produzir mais evidncias de que sistemas baseados em ORMs oferecem oportunidades 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 (GUHIS;
GOASDOU-THION; RIGAUX, 2009) para levar em conta a concorrncia, pois as
consultas que minimizam o tempo de carregamento de objetos quando executadas
sequencialmente podem no gozar desta propriedade quando executadas concorrentemente.
O segundo desdobramento pode ser conduzido aplicando-se o mesmo mtodo desta
pesquisa, ou seja, implementando benchmarks sintticos com um ORM mnimo integrado
ao interpretador de Litoral e tambm com ORMs industriais e, em seguida, comparando
o desempenho das implementaes.
Uma alternativa consiste em integrar o interpretador de Litoral a um ORM
popular. Apesar desta alternativa demandar um esforo inicial maior, ela tem a grande
vantagem de permitir que a otimizao 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 execuo sequencial e concorrente das consultas. A
partir do tempo total de execuo de cada simulao possvel estimar os efeitos que a
otimizao desenvolvida nesta pesquisa ter sobre os sistemas.
103
Referncias
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.
877888. Citado na pgina 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. 297314, 1979.
Citado 2 vezes nas pginas 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. 279287. Citado 3 vezes nas pginas 20, 61
e 102.
ARMBRUST, M. et al. A view of cloud computing. Communications of the ACM, ACM,
v. 53, n. 4, p. 5058, 2010. Citado na pgina 31.
BERNSTEIN, P. A.; PAL, S.; SHUTT, D. Context-based prefetchan optimization for
implementing objects on relations. The VLDB Journal, Springer-Verlag, v. 9, n. 3, p.
177189, 2000. Citado 5 vezes nas pginas 17, 30, 31, 83 e 100.
BERTOT, Y.; CASTRAN, P. Interactive theorem proving and program development.
[S.l.]: Springer Science & Business Media, 2004. Citado 2 vezes nas pginas 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. 3239, 2006. Citado na pgina 19.
BONCZ, P. A.; KWAKKEL, F.; KERSTEN, M. L. High performance support for oo
traversals in monet. CWI (Centre for Mathematics and Computer Science), 1995. Citado
na pgina 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. 10561101, 2005.
Citado na pgina 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. 12841288. Citado 2 vezes nas pginas 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. 414426, 1994. Citado 2 vezes nas pginas 20
e 83.
CAREY, M. J.; DEWITT, D. J.; NAUGHTON, J. F. The 007 benchmark. [S.l.]: ACM,
1993. Citado 2 vezes nas pginas 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. 10701072. Citado na
pgina 19.
Referncias
104
CLARK, J.; DEROSE, S. et al. Xml path language (xpath). W3C recommendation, v. 16,
CUREWITZ, K. M.; KRISHNAN, P.; VITTER, J. S. Practical prefetching via data
compression. ACM SIGMOD Record, ACM, v. 22, n. 2, p. 257266, 1993. Citado na
pgina 100.
CURNOW, H. J.; WICHMANN, B. A. A synthetic benchmark. The Computer Journal,
Br Computer Soc, v. 19, n. 1, p. 4349, 1976. Citado na pgina 20.
DEURSEN, A. V.; KLINT, P.; VISSER, J. Domain-specific languages: An annotated
bibliography. Sigplan Notices, v. 35, n. 6, p. 2636, 2000. Citado na pgina 18.
EISENBERG, A. et al. Sql: 2003 has been published. ACM SIGMoD Record, ACM, v. 33,
n. 1, p. 119126, 2004. Citado na pgina 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. 115150, 2002.
Citado na pgina 20.
FOUNDATION, E. Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference
Implementation. 2008. Disponvel em: <http://www.eclipse.org/org/press-release/
20080317_Eclipselink.php>. Citado na pgina 20.
GAMMA, E. et al. Design Patterns: Elements of Reusable Object-Oriented
Software. Pearson Education, 1994. ISBN 9780321700698. Disponvel em: <http:
//books.google.com.br/books?id=6oHuKQe3TjQC>. Citado na pgina 28.
GARBATOV, S.; CACHOPO, J. Predicting data access patterns in object-oriented
applications based on markov chains. In: IEEE. Software Engineering Advances (ICSEA),
2010 Fifth International Conference on. [S.l.], 2010. p. 465470. Citado na pgina 100.
GARBATOV, S. et al. Data access pattern analysis and prediction for object-oriented
applications. INFOCOMP Journal of Computer Science, v. 10, n. 4, p. 114, 2011. Citado
na pgina 100.
GERSEN, C. M. ORM Optimization through Automatic Prefetching in WebDSL.
Dissertao (Mestrado) Delft University of Technology, 2013. Citado na pgina 83.
GEUVERS, H. Proof assistants: History, ideas and future. Sadhana, Springer, v. 34, n. 1,
p. 325, 2009. Citado 2 vezes nas pginas 20 e 41.
GOSLING, J. et al. The Java Language Specification, Java SE 8 Edition. Pearson
Education, 2014. ISBN 9780133900798. Disponvel em: <http://books.google.com.br/
books?id=1DaDAwAAQBAJ>. Citado na pgina 16.
GROUP, J. P. . E. JSR 338: JavaTM Persistence API, Version 2.1. 2013. Disponvel em:
<http://download.oracle.com/otndocs/jcp/persistence-2_1-fr-eval-spec/index.html>.
GUHIS, S.; GOASDOU-THION, V.; RIGAUX, P. Speeding-up data-driven applications
with program summaries. In: ACM. Proceedings of the 2009 International Database
Engineering & Applications Symposium. [S.l.], 2009. p. 6676. Citado 5 vezes nas pginas
19, 96, 97, 98 e 102.
Referncias
105
GUERRAOUI, R.; KAPALKA, M.; VITEK, J. Stmbench7: A benchmark for

software 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. 315324. ISBN 978-1-59593-636-3. Disponvel em:
<http://doi.acm.org/10.1145/1272996.1273029>. Citado na pgina 83.
HAN, W.-S.; MOON, Y.-S.; WHANG, K.-Y. Prefetchguide: capturing navigational
access patterns for prefetching in client/server object-oriented/object-relational dbmss.
Information Sciences, Elsevier, v. 152, p. 4761, 2003. Citado na pgina 100.
HAN, W.-S.; WHANG, K.-Y.; MOON, Y.-S. A formal framework for prefetching based on
the type-level access pattern in object-relational dbmss. Knowledge and Data Engineering,
IEEE Transactions on, IEEE, v. 17, n. 10, p. 14361448, 2005. Citado 2 vezes nas
pginas 83 e 100.
HAN, W.-S. et al. Prefetching based on the type-level access pattern in object-relational
dbmss. In: IEEE. Data Engineering, 2001. Proceedings. 17th International Conference on.
[S.l.], 2001. p. 651660. Citado na pgina 100.
HAROLD, E. Java I/O. OReilly Media, 2006. ISBN 9781449390884. Disponvel em:
<http://books.google.com.br/books?id=42etT\_9-\_9MC>. Citado na pgina 61.
HOVEMEYER, D.; SPACCO, J.; PUGH, W. Evaluating and tuning a static analysis to
find null pointer bugs. In: ACM. ACM SIGSOFT Software Engineering Notes. [S.l.], 2005.
v. 31, n. 1, p. 1319. Citado na pgina 32.
IBRAHIM, A.; COOK, W. R. Automatic prefetching by traversal profiling in object
persistence architectures. ECOOP 2006Object-Oriented Programming, Springer Berlin
Heidelberg, p. 5073, 2006. Citado 7 vezes nas pginas 19, 34, 83, 92, 93, 99 e 100.
IBRAHIM, A.; WIEDERMANN, B.; COOK, W. R. Coordinating database and
programming language research. In: CITESEER. ESSAY SUBMITTED TO CIDR 2009
MONTEREY, CALIFORNIA USA. [S.l.], 2009. Citado na pgina 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. 535548. Citado na pgina 83.
KEITH, M.; SCHINCARIOL, M. Pro jpa 2. Mastering the Java Persistence API, Springer,
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. 109124, 1990. Citado na
pgina 100.
LAMB, C. et al. The objectstore database system. Communications of the ACM, ACM,
v. 34, n. 10, p. 5063, 1991. Citado na pgina 100.
LEA, D. A java fork/join framework. In: ACM. Proceedings of the ACM 2000 conference
on Java Grande. [S.l.], 2000. p. 3643. Citado 2 vezes nas pginas 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. 167174. Citado na pgina 83.
Referncias
106
LINSKEY, P. C.; PRUDHOMMEAUX, M. An in-depth look at the architecture of an

object/relational mapper. In: ACM. Proceedings of the 2007 ACM SIGMOD international
conference on Management of data. [S.l.], 2007. p. 889894. Citado na pgina 19.
MERNIK, M.; HEERING, J.; SLOANE, A. M. When and how to develop domain-specific
languages. ACM computing surveys (CSUR), ACM, v. 37, n. 4, p. 316344, 2005. Citado
2 vezes nas pginas 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. 120. Citado na pgina 35.
MILNER, R. The definition of standard ML: revised. [S.l.]: MIT press, 1997. Citado na
pgina 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. 434445.
Citado na pgina 18.
ONEIL, 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. 13511356. Citado 2 vezes nas pginas 19 e 20.
PALMER, M. S. zdonik,fido: A cache that learns to fetch,. In: Proceedings of the 1991
International Conference on Very Large Databases. [S.l.: s.n.], 1991. Citado na pgina
100.
PARR, T. The definitive ANTLR reference: building domain-specific languages. [S.l.]:
Pragmatic Bookshelf, 2007. Citado na pgina 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. 789810, 1995. Citado na
pgina 74.
PEIERLS, T. et al. Java Concurrency in Practice. Pearson Education, 2006. ISBN
9780132702256. Disponvel em: <http://books.google.com.br/books?id=EK43StEVfJIC>.
Citado na pgina 61.
PINTER, C. A Book of Abstract Algebra: Second Edition. Dover Publications, 2012. ISBN
9780486134796. Disponvel em: <https://books.google.com.br/books?id=qviuEUavE4IC>.
Citado na pgina 115.
POESS, M.; FLOYD, C. New tpc benchmarks for decision support and web commerce.
ACM Sigmod Record, ACM, v. 29, n. 4, p. 6471, 2000. Citado na pgina 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. 717740.
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 pginas 41 e 61.
Referncias
107
RYMAN, A. Simple object access protocol (soap) and web services. In: IEEE COMPUTER
SOCIETY. Software Engineering, International Conference on. [S.l.], 2001. p. 06890689.
Citado na pgina 20.
SCOTT, M. Programming Language Pragmatics. Morgan Kaufmann, 2006.
(Programming Language Pragmatics, v. 1). ISBN 9780126339512. Disponvel em:
<http://books.google.com.br/books?id=TLbvODF1uIEC>. Citado na pgina 62.
SIPELSTEIN, J. M.; BLELLOCH, G. E. Collection-oriented languages. Proceedings of the
IEEE, IEEE, v. 79, n. 4, p. 504523, 1991. Citado na pgina 32.
SUBRAMANIAM, V. Functional Programming in Java: Harnessing the Power
of Java 8 Lambda Expressions. Pragmatic Programmers, LLC, 2014. (Pragmatic
programmers). ISBN 9781937785468. Disponvel em: <http://books.google.com.br/books?
id=4Y7TngEACAAJ>. Citado na pgina 63.
TANENBAUM, A. Modern Operating Systems. Pearson Prentice Hall, 2008. (GOAL
Series). ISBN 9780136006633. Disponvel em: <http://books.google.com.br/books?id=
DxNiQgAACAAJ>. Citado na pgina 22.
THOMSON, B.; BRUCKNER, J.; BRUCKNER, A. Elementary Real Analysis, Second
Edition. Createspace Independent Pub, 2008. ISBN 9781434843678. Disponvel em:
<http://books.google.com.br/books?id=vA9d57GxCKgC>. Citado 3 vezes nas pginas
50, 57 e 115.
VITTER, J. S.; KRISHNAN, P. Optimal prefetching via data compression. Journal of the
ACM (JACM), ACM, v. 43, n. 5, p. 771793, 1996. Citado na pgina 100.
WALDO, J. Remote procedure calls and java remote method invocation. Concurrency,
IEEE, IEEE, v. 6, n. 3, p. 57, 1998. Citado na pgina 20.
WELC, A.; JAGANNATHAN, S.; HOSKING, A. Safe futures for java. In: ACM. ACM
SIGPLAN Notices. [S.l.], 2005. v. 40, n. 10, p. 439453. Citado na pgina 83.
WITT, D. J. D. et al. Parallelizing oodbms traversals: a performance evaluation. the
VLDB Journal, Springer, v. 5, n. 1, p. 318, 1996. Citado na pgina 83.
ZIAREK, L. et al. A uniform transactional execution environment for java. In: ECOOP
2008Object-Oriented Programming. [S.l.]: Springer, 2008. p. 129154. Citado na pgina
83.
ZYL, P. V. Performance investigation into selected object persistence stores . Dissertao
(Mestrado) University of Pretoria, 2010. Citado 2 vezes nas pginas 83 e 92.
ZYL, P. V.; KOURIE, D. G.; BOAKE, A. Comparing the performance of object
databases and orm tools. In: SOUTH AFRICAN INSTITUTE FOR COMPUTER
SCIENTISTS 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. 111. Citado na
pgina 83.
Referncias
108
ZYL, P. V. et al. The influence of optimisations on the performance of an object relational

mapping tool. In: ACM. Proceedings of the 2009 Annual Research Conference of the South
African Institute of Computer Scientists and Information Technologists. [S.l.], 2009. p.
109
APNDICE A Emeio
A.1 Classes
1
2
import j a v a . u t i l . Date ;
import j a v a . u t i l . L i s t ;
3
4
5
6
7
8
9
10
11
12
13
c l a s s Message {
private int i d ;
private Date d a t e ;
private S t r i n g s u b j e c t ;
private S t r i n g body ;
private User s e n d e r ;
private L i s t <User> r e c i p i e n t s ;
private L i s t <F i l e > a t t a c h m e n t s ;
private L i s t <Message> r e p l i e s ;
private L i s t <Tag> t a g s ;
14
void s e t I d ( int i d ) {
this . id = id ;
}
15
16
17
18
int g e t I d ( ) {
return i d ;
}
19
20
21
22
// Demais mtodos s e t e g e t
23
24
25
26
27
28
29
c l a s s User {
private int i d ;
private S t r i n g name ;
private F i l e p i c t u r e ;
30
// Mtodos s e t e g e t
31
32
33
34
35
36
37
class File {
private int i d ;
private MediaType mediaType ;
38
39
40
APNDICE A. Emeio
41
42
43
44
45
c l a s s MediaType {
private int i d ;
private S t r i n g type ;
// a p p l i c a t i o n , image , e t c .
private S t r i n g subtype ; // j s o n , xml , j p e g , png , e t c .
46
47
48
49
50
51
52
c l a s s Tag {
private int i d ;
53
54
55
110
APNDICE A. Emeio
A.2 Tabelas
Figura 77 Tabelas de Emeio.

111
112
APNDICE B OO7
B.1 Classes
1
import j a v a . u t i l . L i s t ;
2
3
4
5
6
7
8
c l a s s CompositePart {
private long c o m p o s i t e P a r t I d ;
private long b u i l d D a t e ;
private int d e s i g n I d ;
private AtomicPart r o o t P a r t ;
10
11
12
13
14
15
16
17
18
c l a s s AtomicPart {
private long a t o m i c P a r t I d ;
private L i s t <Connection> t o C o n n e c t i o n s ;
19
20
21
22
23
24
25
26
27
c l a s s Connection {
private long c o n n e c t i o n I d ;
private int l e n g t h ;
private AtomicPart t o ;
28
29
30
31
32
33
34
35
36
c l a s s Assembly {
private long a s s e m b l y I d ;
37
38
39
40
APNDICE B. OO7
41
42
c l a s s BaseAssembly extends Assembly {

private L i s t <CompositePart> c o m p o n e n t s P r i v a t e ;
43
44
45
46
47
48
c l a s s ComplexAssembly extends Assembly {

private L i s t <JpaAssembly> s u b A s s e m b l i e s ;
49
50
51
113
APNDICE B. OO7
114
B.2 Tabelas
Figura 78 Tabelas de OO7.
115
APNDICE C Demonstraes
Este apndice contm as demonstraes verificadas por Coq dos teoremas enunciados
nas sees 3.4.3 e 3.4.4.2. Por serem bastante extensas, as demonstraes foram estruturadas em diversos mdulos. Os mdulos Seq , NatSeq , L i s t S e q , Lim e L i s t O p t i o n S e q
contm definies e teoremas bsicos, os quais foram adaptados da Anlise Real (THOMSON; BRUCKNER; BRUCKNER, 2008) para contextos mais simples tais como nmeros
naturais, listas, etc. O mdulo S u b l i s t contm algumas definies e teoremas bsicos
da lgebra Abstrata (PINTER, 2012). Os mdulos L i t o r a l F a c t s , A n a l y z e S p e c F a c t s e
I n t e r p r e t S p e c F a c t s contm as demonstraes propriamente ditas.
C.1 Seq
1
S e t I m p l i c i t Arguments .
2
3
Definition Seq Y := nat > Y.
4
5
Definition consSeq Y ( f : Seq Y) := f o r a l l n , f n = f ( S n ) .
6
7
Definition s u f f S e q Y ( f : Seq Y) N n := f (N + n ) .
8
9
Definition convSeq Y ( f : Seq Y) := e x i s t s N, consSeq ( s u f f S e q f N ) .
C.2 NatSeq
1
2
3
4
Require Import C l a s s i c a l .
Require Import Omega .
5
6
Require Import Seq .
7
8
Definition NatSeq := Seq nat .
9
10
Definition nonDecNatSeq f := f o r a l l n , f n <= f ( S n ) .
11
12
Definition nonDecNatSeq2 f := f o r a l l n n , n <= n > f n <= f n .
13
14
Definition bndNatSeq ( f : NatSeq ) := e x i s t s L , f o r a l l n , f n <= L .
15
Theorem nonDecNatSeqNonDecNatSeq2 :
17
f o r a l l ( f : NatSeq ) , nonDecNatSeq f > nonDecNatSeq2 f .
16
APNDICE C. Demonstraes
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
Proof .
u n f o l d nonDecNatSeq .
u n f o l d nonDecNatSeq2 .
intros .
induction n .
{
assert (n = 0).
{
omega .
}
r e w r i t e H1 .
auto .
}
{
a s s e r t ( n <= n \/ n = S n ) .
{
omega .
}
d e s t r u c t H1 .
{
a s s e r t ( f n <= f n ) .
{
auto .
}
a s s e r t ( f n <= f ( S n ) ) .
{
auto .
}
omega .
}
{
r e w r i t e H1 . auto .
}
}
Qed .
53
54
55
56
57
58
59
60
61
62
63
64
Theorem nonDecBndNatSeqConvSeq :
f o r a l l f , nonDecNatSeq f > bndNatSeq f > convSeq f .
Proof .
u n f o l d bndNatSeq .
u n f o l d convSeq .
u n f o l d consSeq .
unfold suffSeq .
intros .
d e s t r u c t H0 a s [ L ] .
induction L.
{
116
exists 0.
intros .
a s s e r t ( f ( 0 + n ) <= 0 ) .
{
auto .
}
a s s e r t ( f ( 0 + S n ) <= 0 ) .
{
auto .
}
omega .
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
}
{
d e s t r u c t ( c l a s s i c ( f o r a l l n : nat , f n <= L ) ) .
{
auto .
}
{
a s s e r t ( e x i s t s N, ~ f N <= L ) .
{
apply not_all_ex_not .
auto .
}
d e s t r u c t H2 a s [N ] .
e x i s t s N.
intros .
a s s e r t ( f N <= f (N + n ) ) .
{
apply nonDecNatSeqNonDecNatSeq2 in H.
u n f o l d nonDecNatSeq2 in H.
a s s e r t (N <= N + n > f N <= f (N + n ) ) .
{
auto .
}
apply H.
omega .
}
a s s e r t ( f (N + n ) <= f (N + S n ) ) .
{
u n f o l d nonDecNatSeq in H.
a s s e r t ( f (N + n ) <= f ( S (N + n ) ) ) .
{
auto .
}
a s s e r t ( S (N + n ) = N + S n ) .
{
omega .
117
118
}
r e w r i t e < H5 .
auto .
112
113
114
}
a s s e r t ( f (N + S n ) <= S L ) .
{
auto .
}
omega .
115
116
117
118
119
120
121
}
123 Qed .
122
C.3 ListSeq
1
2
3
Require Import L i s t . Import L i s t N o t a t i o n s .
4
5
6
Require Import NatSeq .

7
8
Definition L i s t S e q E := Seq ( 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
13
Definition nonDecListSeq E ( f : L i s t S e q E) :=
f o r a l l n , suffEqList ( f n) ( f (S n ) ) .
14
15
Definition l e n g t h S e q E ( f : L i s t S e q E) n := l e n g t h ( f n ) .
16
17
Definition l e n g t h B n d L i s t S e q E ( f : L i s t S e q E) := bndNatSeq ( l e n g t h S e q f ) .
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Theorem nonDecListSeqNonDecLengthSeq :
f o r a l l E ( f : L i s t S e q E) , nonDecListSeq f > nonDecNatSeq ( l e n g t h S e q f ) .
Proof .
u n f o l d nonDecListSeq .
u n f o l d nonDecNatSeq .
unfold suffEqList .
unfold lengthSeq .
intros .
a s s e r t ( e x i s t s l , f ( S n ) = l ++ f n ) .
{
auto .
}
r e w r i t e H0 .
33
34
35
36
37
38
119
a s s e r t ( l e n g t h ( x ++ f n ) = l e n g t h x + l e n g t h ( f n ) ) .
{
apply app_length .
}
omega .
Qed .
39
40
41
42
43
44
45
46
47
48
49
50
51
Theorem l e n g t h Z e r o E m p t y L i s t : f o r a l l E ( l : l i s t E) , l e n g t h l = 0 > l = [ ] .
Proof .
intros .
u n f o l d l e n g t h in H.
destruct l .
{
auto .
}
{
congruence .
}
Qed .
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
Theorem nonDecLengthBndListSeqConv :
f o r a l l E ( f : L i s t S e q E) ,
nonDecListSeq f > l e n g t h B n d L i s t S e q f > convSeq f .
Proof .
u n f o l d convSeq .
u n f o l d consSeq .
unfold suffSeq .
intros .
a s s e r t ( convSeq ( l e n g t h S e q f ) ) .
{
apply nonDecBndNatSeqConvSeq .
apply nonDecListSeqNonDecLengthSeq .
auto .
auto .
}
u n f o l d convSeq in H1 .
u n f o l d consSeq in H1 .
u n f o l d s u f f S e q in H1 .
u n f o l d l e n g t h S e q in H1 .
e x i s t s N.
intros .
a s s e r t ( e x i s t s l , f (N + S n ) = l ++ f (N + n ) ) .
{
a s s e r t ( e x i s t s l , f ( S (N + n ) ) = l ++ f (N + n ) ) .
{
u n f o l d nonDecListSeq in H.
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
u n f o l d s u f f E q L i s t in H.
auto .
}
a s s e r t ( S (N + n ) = N + S n ) .
omega .
auto .
}
d e s t r u c t H2 a s [ l ] .
assert ( l = [ ] ) .
{
assert ( length l = 0).
{
a s s e r t ( l e n g t h ( f (N + n ) ) = l e n g t h ( f (N + S n ) ) ) .
{
auto .
}
r e w r i t e H2 in H3 .
r e w r i t e app_length in H3 .
omega .
}
apply l e n g t h Z e r o E m p t y L i s t .
auto .
}
auto .
Qed .
C.4 Lim
1
2
3
4
5
6
7
Definition l i m Y ( f : Seq Y) L := e x i s t s N, f o r a l l n , s u f f S e q f N n = L .
8
9
10
11
12
13
14
15
16
17
Theorem s u f f S e q L i m :
f o r a l l Y ( f : Seq Y) N L , l i m ( s u f f S e q f N) L > l i m f L .
Proof .
unfold lim .
unfold suffSeq .
intros .
d e s t r u c t H as [N ] .
e x i s t s (N + N ) .
intros .
120
18
19
20
21
22
23
24
a s s e r t (N + N + n = N + (N + n ) ) .
{
omega .
}
r e w r i t e H0 .
auto .
Qed .
C.5 ListOptionSeq
1
2
3
4
Require Import C l a s s i c a l .
5
6
7
8
Require Import Lim .

Require Import L i s t S e q .
9
10
Definition L i s t O p t i o n S e q E := Seq ( o p t i o n ( l i s t E ) ) .
11
12
13
14
15
16
17
Definition s u f f L i s t O p t i o n E ( l o l o : o p t i o n ( l i s t E ) ) :=
match l o with
| None => l o = None
| Some [ ] => l o = Some [ ]
| Some l => e x i s t s l e , l o = Some l /\ l = e : : l
end .
18
19
20
Definition d e c L i s t O p t i o n S e q E ( f : L i s t O p t i o n S e q E) :=
f o r a l l n , suffListOption ( f (S n)) ( f n ) .
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Theorem decOptionListSeqLim :
f o r a l l E ( f : L i s t O p t i o n S e q E) ,
d e c L i s t O p t i o n S e q f > l i m f None \/ l i m f ( Some [ ] ) .
Proof .
intros .
d e s t r u c t ( c l a s s i c ( e x i s t s N, f N = None ) ) .
{
left .
unfold lim .
unfold suffSeq .
e x i s t s N.
induction n .
{
a s s e r t (N + 0 = N ) .
{
121
auto .
}
r e w r i t e H1 .
auto .
38
39
40
41
}
{
42
43
a s s e r t (N + S n = S (N + n ) ) .
{
omega .
}
r e w r i t e H1 .
u n f o l d d e c L i s t O p t i o n S e q in H.
u n f o l d s u f f L i s t O p t i o n in H.
s p e c i a l i z e H with (N + n ) .
r e w r i t e IHn in H.
auto .
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
}
{
a s s e r t ( f o r a l l n , f n <> None ) .
{
intros .
d e s t r u c t ( f n ) eqn : E1 .
{
congruence .
}
{
u n f o l d not in H0 .
a s s e r t ( e x i s t s N : nat , f N = None ) .
{
exists n.
auto .
}
contradiction .
}
}
74
75
76
77
78
79
80
81
82
83
84
d e s t r u c t ( f 0 ) eqn : E1 .
{
assert (
f o r a l l n , e x i s t s l , f n = Some l /\ l e n g t h l = l e n g t h l n
).
{
induction n .
{
exists l .
assert ( length l 0 = length l ) .
122
85
omega .
86
}
auto .
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
}
{
assert ( length l S n = length l n 1).
{
omega .
}
r e w r i t e H2 .
u n f o l d d e c L i s t O p t i o n S e q in H.
u n f o l d s u f f L i s t O p t i o n in H.
s p e c i a l i z e H with n .
destruct ( f n ).
{
destruct l0 .
{
r e w r i t e H.
exists [ ] .
split .
{
auto .
}
{
d e s t r u c t IHn .
i n j e c t i o n H3 .
intros .
auto .
}
}
{
d e s t r u c t H.
d e s t r u c t H.
d e s t r u c t H.
intros .
r e w r i t e H.
exists x.
split .
{
auto .
}
{
123
d e s t r u c t IHn .
intros .
simpl .
omega .
132
133
134
135
136
137
138
139
140
141
142
}
{
143
144
congruence .
145
146
147
148
149
150
right .
unfold lim .
e x i s t s ( length l ) .
intros .
s p e c i a l i z e H2 with ( l e n g t h l + n ) .
assert ( length x = 0).
{
omega .
}
apply l e n g t h Z e r o E m p t y L i s t in H4 .
unfold suffSeq .
auto .
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
}
{
congruence .
169
170
}
172 Qed .
171
173
Theorem d e c O p t i o n L i s t S u f f S e q L i m :
f o r a l l E ( f : L i s t O p t i o n S e q E) N,
176
d e c L i s t O p t i o n S e q ( s u f f S e q f N) > l i m f None \/ l i m f ( Some [ ] ) .
177 Proof .
178
intros .
174
175
124
179
180
181
182
183
184
185
186
187
188
189
190
191
apply decOptionListSeqLim in H.
d e s t r u c t H.
{
left .
apply s u f f S e q L i m with N.
auto .
}
{
right .
apply s u f f S e q L i m with N.
auto .
}
Qed .
192
Theorem h a s D e c O p t i o n L i s t S u f f S e q L i m :
f o r a l l E ( f : L i s t O p t i o n S e q E) ,
195
( e x i s t s N, d e c L i s t O p t i o n S e q ( s u f f S e q f N) ) > l i m f None \/
196
l i m f ( Some [ ] ) .
197 Proof .
198
intros .
199
d e s t r u c t H a s [N ] .
200
apply d e c O p t i o n L i s t S u f f S e q L i m with N.
201
auto .
202 Qed .
193
194
C.6 Sublist
1
2
3
4

5
6
7
8
Require Import L i s t S e q .
Require Import NatSeq .
9
10
Definition Rel E := E > E > b o o l .
11
12
Definition r e f l E ( f : Rel E) := f o r a l l e , f e e = t r u e .
13
14
Definition symm E ( f : Rel E) := f o r a l l e e , f e e = f e e .
15
16
17
Definition t r a n s E ( f : Rel E) :=
f o r a l l e e e , f e e = t r u e > f e e = f e e .
18
19
20
Definition e q u i E ( f : Rel E) := r e f l f /\ symm f /\ t r a n s f .
125
21
22
23
24
25
26
27
126
Fixpoint count E ( r : Rel E) l e :=

match l with
| [ ] => 0
| e : : l =>
l e t count := count r l e in
i f r e e then S count e l s e count
end .
28
29
30
Definition s u b l i s t E ( r : Rel E) l l :=
f o r a l l e , count r l e <= count r l e .
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
Theorem t a i l S u b l i s t :
f o r a l l E ( r : Rel E) e l l , s u b l i s t r ( e : : l ) l > s u b l i s t r l l .
Proof .
unfold s u b l i s t .
intros .
s p e c i a l i z e H with e0 .
s i m p l in H.
d e s t r u c t ( r e0 e ) .
{
omega .
}
{
auto .
}
Qed .
47
48
49
50
51
52
53
54
Fixpoint remove E ( r : Rel E) l e :=

match l with
| [ ] => [ ]
| e : : l =>
l e t l := remove r l e in
i f r e e then l e l s e e : : l
end .
55
56
57
58
59
60
61
62
63
64
65
66
67
Theorem lengthCountRemove :
f o r a l l E ( r : Rel E) l e , l e n g t h l = count r l e + l e n g t h ( remove r l e ) .
Proof .
intros .
induction l .
{
auto .
}
{
simpl .
destruct ( r e a ).
{
omega .
68
}
{
69
70
simpl .
omega .
71
72
73
}
75 Qed .
74
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
Theorem removeLengthLe :
f o r a l l E ( r : Rel E) l e , l e n g t h ( remove r l e ) <= l e n g t h l .
Proof .
intros .
induction l .
{
auto .
}
{
simpl .
destruct ( r e a ).
{
auto .
}
{
simpl .
omega .
}
}
Qed .
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
Theorem removeCount :
f o r a l l E ( r : Rel E) ,
symm r /\ t r a n s r >
forall l e e ,
( r e e = f a l s e > count r ( remove r l e ) e = count r l e ) /\
( r e e = t r u e > count r ( remove r l e ) e = 0 ) .
Proof .
intro .
intro .
intro .
induction l .
{
auto .
}
{
intros e e .
s p e c i a l i z e I H l with e e .
127
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
simpl .
d e s t r u c t ( r e a ) eqn : E1 .
{
split .
{
intros .
d e s t r u c t H.
u n f o l d t r a n s in H1 .
s p e c i a l i z e H1 with e a e .
assert ( r a e = r e e ) .
{
auto .
}
u n f o l d symm in H.
s p e c i a l i z e H with e a .
r e w r i t e H2 in H.
r e w r i t e H.
d e s t r u c t IHl .
auto .
}
{
auto .
}
}
{
simpl .
d e s t r u c t ( r e a ) eqn : E2 .
{
split .
{
auto .
}
{
intros .
d e s t r u c t H.
s p e c i a l i z e H1 with e e a .
assert ( r e a = r e a ).
{
auto .
}
congruence .
}
}
128
162
auto .
163
164
165
166
167
}
Qed .
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
Theorem s u b l i s t L e n g t h L e I n d :
f o r a l l n E ( r : Rel E) l l ,
l e n g t h l <= n > e q u 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 .
Proof .
induction n .
{
intros .
assert ( length l = 0).
{
omega .
}
r e w r i t e H2 .
omega .
}
{
intros .
a s s e r t ( l e n g t h l <= n \/ l e n g t h l = S n ) .
{
omega .
}
{
s p e c i a l i z e IHn with E r l l .
auto .
}
{
destruct l .
{
simpl .
omega .
}
{
a s s e r t ( IHn := IHn ) .
s p e c i a l i z e IHn with E r l l .
assert ( length l = n ) .
{
auto .
}
a s s e r t ( l e n g t h l <= n ) .
{
129
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
omega .
}
a s s e r t (H1 := H1 ) .
apply t a i l S u b l i s t in H1 .
a s s e r t ( l e n g t h l <= l e n g t h l ) .
{
auto .
}
p o s e p r o o f lengthCountRemove .
s p e c i a l i z e H6 with E r ( e : : l ) e .
r e w r i t e H6 .
p o s e p r o o f lengthCountRemove .
s p e c i a l i z e H7 with E r l e .
r e w r i t e H7 .
u n f o l d s u b l i s t in H1 .
s p e c i a l i z e H1 with e .
225
226
227
228
229
230
231
232
233
u n f o l d remove .
f o l d remove .
a s s e r t (H0 := H0 ) .
u n f o l d e q u i in H0 .
u n f o l d r e f l in H0 .
r e w r i t e H0 .
234
235
s p e c i a l i z e IHn with E r ( remove r l e ) ( remove r l e ) .
236
237
238
239
p o s e p r o o f removeLengthLe .
s p e c i a l i z e H9 with E r l e .
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
assert (
s u b l i s t r ( remove r l e ) ( remove r l e )
).
{
intros .
d e s t r u c t ( r e e0 ) eqn : E1 .
{
a s s e r t ( count r ( remove r l e ) e0 = 0 ) .
{
apply removeCount .
auto .
auto .
}
a s s e r t ( count r ( remove r l e ) e0 = 0 ) .
130
256
apply removeCount .
auto .
auto .
257
258
259
}
omega .
260
261
}
{
262
263
a s s e r t ( count r ( remove r l e ) e0 = count r l e0 ) .

{
apply removeCount .
auto .
auto .
}
r e w r i t e H10 .
a s s e r t ( count r ( remove r l e ) e0 = count r l e0 ) .
{
apply removeCount .
auto .
auto .
}
r e w r i t e H11 .
u n f o l d s u b l i s t in H1 .
s p e c i a l i z e H1 with e0 .
omega .
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
a s s e r t ( l e n g t h ( remove r l e ) <= l e n g t h ( remove r l e ) ) .

auto .
omega .
284
285
286
287
288
}
290 Qed .
289
291
292
293
294
295
296
297
298
299
300
301
302
Theorem s u b l i s t L e n g t h L e :
f o r a l l E ( r : Rel E) l l ,
e q u 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 .
Proof .
intros .
apply s u b l i s t L e n g t h L e I n d with ( n := l e n g t h l ) ( r := r ) .
auto .
auto .
auto .
Qed .
131
303
304
Definition s u b l i s t B n d L i s t S e q E ( f : L i s t S e q E) :=
e x i s t s r l , e q u i r /\ f o r a l l n , s u b l i s t r ( f n ) ( l ) .
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
Theorem nonDecSublistBndListSeqConv :
f o r a l l E ( f : L i s t S e q E) ,
nonDecListSeq f > s u b l i s t B n d L i s t S e q f > convSeq f .
Proof .
intros .
u n f o l d s u b l i s t B n d L i s t S e q in H0 .
d e s t r u c t H0 a s [ r ] .
d e s t r u c t H0 a s [ l ] .
a s s e r t ( lengthBndListSeq f ) .
{
unfold lengthBndListSeq .
u n f o l d bndNatSeq .
e x i s t s ( length l ) .
unfold lengthSeq .
intros .
apply s u b l i s t L e n g t h L e with ( r := r ) .
auto .
auto .
}
apply nonDecLengthBndListSeqConv .
auto .
auto .
Qed .
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
( Outros )
Theorem sameCount :
f o r a l l E ( r : Rel E) l e e ,
t r a n s r > r e e = t r u e > count r l e = count r l e .
Proof .
intros .
induction l .
{
auto .
}
{
simpl .
u n f o l d t r a n s in H.
assert ( r e a = r e a ).
{
auto .
}
r e w r i t e H1 .
r e w r i t e IHl .
132
auto .
350
}
352 Qed .
351
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
Theorem appCount :
f o r a l l E ( r : Rel E) l l e ,
count r ( l ++ l ) e = count r l e + count r l e .
Proof .
induction l .
{
intros .
auto .
}
{
intros .
s p e c i a l i z e I H l with l e .
r e w r i t e < app_comm_cons .
u n f o l d count .
f o l d count .
destruct ( r e a ).
{
omega .
}
{
auto .
}
}
Qed .
378
379
380
381
382
383
384
385
386
Theorem appCountZero :
count r ( l ++ l ) e = 0 > count r l e = 0 /\ count r l e = 0 .
Proof .
intros .
r e w r i t e appCount in H.
omega .
Qed .
387
388
389
390
391
392
Definition c o n t a i n s E ( r : Rel E) l e :=
match count r l e with
| 0 => f a l s e
| _ => t r u e
end .
393
Theorem sameContains :
395
f o r a l l E ( r : Rel E) l e e ,
396
t r a n s r > r e e = t r u e > c o n t a i n s r l e = c o n t a i n s r l e .
394
133
397
398
399
400
401
402
403
404
Proof .
intros .
unfold contains .
r e w r i t e sameCount with ( e := e ) .
auto .
auto .
auto .
Qed .
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
Theorem c o n t a i n s F a l s e C o u n t Z e r o :
f o r a l l E ( r : Rel E) l e ,
c o n t a i n s r l e = f a l s e > count r l e = 0 .
Proof .
intros .
u n f o l d c o n t a i n s in H.
d e s t r u c t ( count r l e ) .
{
auto .
}
{
congruence .
}
Qed .
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
Theorem containsTrueCountNotZero :
f o r a l l E ( r : Rel E) l e ,
c o n t a i n s r l e = t r u e > count r l e <> 0 .
Proof .
intros .
u n f o l d c o n t a i n s in H.
d e s t r u c t ( count r l e ) .
{
congruence .
}
{
auto .
}
Qed .
435
436
437
438
439
440
441
442
443
Theorem a p p C o n t a i n s F a l s e :
t r a n s r > c o n t a i n s r ( l ++ l ) e = f a l s e >
c o n t a i n s r l e = f a l s e /\ c o n t a i n s r l e = f a l s e .
Proof .
intros .
unfold contains .
apply c o n t a i n s F a l s e C o u n t Z e r o in H0 .
134
444
445
446
447
448
449
450
apply appCountZero in H0 .
r e w r i t e H0 .
r e w r i t e H1 .
auto .
Qed .
( Outros )
C.7 LitoralFacts
1
2
3
4
Require Import Peano_dec .

Require Import S t r i n g .
5
6
7
Require Import L i t o r a l .
Require Import S u b l i s t .
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
Theorem strEqEqui : e q u i s t r E q .
Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
unfold strEq .
destruct ( string_dec e e ) .
{
auto .
}
{
congruence .
}
}
{
split .
{
u n f o l d symm .
intros .
unfold strEq .
{
{
auto .
}
{
135
congruence .
38
39
}
{
40
41
{
congruence .
}
{
auto .
}
42
43
44
45
46
47
48
49
}
{
50
51
unfold trans .
intros .
unfold strEq .
u n f o l d s t r E q in H.
{
r e w r i t e e0 .
auto .
}
{
{
congruence .
}
{
congruence .
}
}
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
}
72 Qed .
71
73
74
75
76
77
78
79
80
81
82
83
84
Theorem natEqEqui : e q u i natEq .

Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
u n f o l d natEq .
d e s t r u c t ( eq_nat_dec e e ) .
{
auto .
136
}
{
85
86
congruence .
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
}
{
split .
{
u n f o l d symm .
intros .
u n f o l d natEq .
{
{
auto .
}
{
congruence .
}
}
{
{
congruence .
}
{
auto .
}
}
}
{
unfold trans .
intros .
u n f o l d natEq .
u n f o l d natEq in H.
{
r e w r i t e e0 .
auto .
}
{
{
congruence .
}
{
137
congruence .
132
133
134
135
136
137
}
Qed .
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
Theorem c l a s s E q E q u i : e q u i c l a s s E q .
Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
unfold classEq .
destruct e .
p o s e p r o o f strEqEqui .
u n f o l d e q u i in H.
d e s t r u c t H.
u n f o l d r e f l in H.
s p e c i a l i z e H with s .
auto .
}
{
split .
{
u n f o l d symm .
intros .
unfold classEq .
destruct e .
destruct e .
d e s t r u c t H.
u n f o l d symm in H0 .
s p e c i a l i z e H0 with s s 0 .
auto .
}
{
unfold trans .
intro .
intro .
intro .
unfold classEq .
destruct e .
destruct e .
138
destruct e .
d e s t r u c t H.
s p e c i a l i z e H1 with s s 0 s 1 .
auto .
179
180
181
182
183
184
185
186
187
}
189 Qed .
188
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
Theorem pathEqEqui : e q u i pathEq .

Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
u n f o l d pathEq .
destruct e .
p o s e p r o o f natEqEqui .
d e s t r u c t H.
auto .
}
{
split .
{
u n f o l d symm .
intros .
destruct e .
destruct e .
d e s t r u c t H.
s p e c i a l i z e H0 with n n0 .
auto .
}
{
unfold trans .
intro .
139
intro .
intro .
destruct e .
destruct e .
destruct e .
d e s t r u c t H.
s p e c i a l i z e H1 with n n0 n1 .
auto .
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
}
Qed .
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
Theorem c l a s s P a t h E q E q u i : e q u i c l a s s P a t h E q .
Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
unfold classPathEq .
destruct e .
pose proof classEqEqui .
d e s t r u c t H.
s p e c i a l i z e H with c .
r e w r i t e H.
p o s e p r o o f pathEqEqui .
u n f o l d r e f l in H1 .
s p e c i a l i z e H1 with p .
auto .
}
{
split .
{
u n f o l d symm .
intros .
destruct e .
destruct e .
140

d e s t r u c t H.
s p e c i a l i z e H0 with c c0 .
r e w r i t e H0 .
s p e c i a l i z e H3 with p p0 .
r e w r i t e H3 .
auto .
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
}
{
unfold trans .
intros .
destruct e .
destruct e .
destruct e .
u n f o l d c l a s s P a t h E q in H.
d e s t r u c t ( c l a s s E q c c0 ) eqn : E1 .
{
d e s t r u c t ( pathEq p p0 ) eqn : E2 .
{
a s s e r t ( c l a s s E q c0 c1 = c l a s s E q c c1 ) .
{
auto .
}
r e w r i t e H3 .
a s s e r t ( pathEq p0 p1 = pathEq p p1 ) .
{
auto .
}
141
r e w r i t e H7 .
auto .
320
321
}
{
322
323
congruence .
324
325
}
{
326
327
congruence .
328
329
330
331
332
}
Qed .
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
Theorem objEqEqui : e q u i objEq .

Proof .
unfold equi .
split .
{
unfold r e f l .
intros .
u n f o l d objEq .
destruct e .
d e s t r u c t H.
s p e c i a l i z e H with s .
auto .
}
{
split .
{
u n f o l d symm .
intros .
u n f o l d objEq .
destruct e .
destruct e .
d e s t r u c t H.
s p e c i a l i z e H0 with s s 0 .
auto .
}
{
142
unfold trans .
intro .
intro .
intro .
u n f o l d objEq .
destruct e .
destruct e .
destruct e .
d e s t r u c t H.
s p e c i a l i z e H1 with s s 0 s 1 .
auto .
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
}
384 Qed .
383
C.8 AnalyzeSpecFacts
1
2
3
4
5
6
7
8
9
10
11
Require
Require
Require
Require
Require
Require
Require
Import
Import
Import
Import
Import
Import
Import
Lim .
Litoral .
LitoralFacts .
ListOptionSeq .
ListSeq .
Seq .
Sublist .
12
13
14
Definition a n a l y z e S p e c S c l a s s e s c l a s s s p e c n :=
l e t ( s , _) := a n a l y z e S p e c c l a s s e s c l a s s s p e c n in s .
15
16
17
18
19
20
21
22
23
24
25
26
Theorem analyzeSpecS_t1 :
nonDecListSeq ( a n a l y z e S p e c S c l a s s e s c l a s s s p e c )
/\ s u b l i s t B n d L i s t S e q ( a n a l y z e S p e c S c l a s s e s c l a s s s p e c ) .
Proof .
intros .
split .
{
intros .
unfold suffEqList .
143
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
unfold analyzeSpecS .
unfold analyzeSpec .
d e s t r u c t ( indexSpec spec ) .
destruct p .
destruct s .
destruct ( analyzeTravs l 0 ) .
{
unfold analyzeClassPaths at 1 .
fold analyzeClassPaths .
destruct ( analyzeClassPaths c l a s s e s l l0 [ ] [ ( class , p ) ] n ) .
destruct o .
destruct l2 .
{
exists [ ] .
auto .
}
{
d e s t r u c t ( c o n t a i n s C l a s s P a t h l 1 p0 ) .
{
exists [ ] .
auto .
}
{
d e s t r u c t ( c o n t a i n s C l a s s P a t h ( l i s t _ p r o d c l a s s e s l ) p0 ) .
{
d e s t r u c t p0 .
d e s t r u c t ( a n a l y z e P a t h c l a s s e s l 0 c p0 ) .
{
e x i s t s [ ( c , p0 ) ] .
auto .
}
{
e x i s t s [ ( c , p0 ) ] .
auto .
}
}
{
exists [ ] .
auto .
}
}
}
{
exists [ ] .
auto .
}
}
144
74
exists
auto .
75
76
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
[].
77
78
145
}
{
unfold sublistBndListSeq .
e x i s t s classPathEq .
unfold analyzeSpecS .
unfold analyzeSpec .
exists ( list_prod classes l ) .
split .
{
apply c l a s s P a t h E q E q u i .
}
{
destruct p .
destruct s .
{
i n d u c t i o n n0 .
{
intros .
unfold analyzeClassPaths .
simpl .
omega .
}
{
d e s t r u c t ( a n a l y z e C l a s s P a t h s c l a s s e s l l 0 [ ] [ ( c l a s s , p ) ] n0 ) .
destruct o .
{
destruct l2 .
{
auto .
}
{
d e s t r u c t ( c o n t a i n s C l a s s P a t h l 1 p0 ) eqn : E1 .
{
auto .
}
{
d e s t r u c t ( c o n t a i n s C l a s s P a t h ( l i s t _ p r o d c l a s s e s l ) p0 ) eqn : E2 .
{
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
intros .
assert (
count c l a s s P a t h E q ( p0 : : l 1 ) e <=
count c l a s s P a t h E q ( l i s t _ p r o d c l a s s e s l ) e
).
{
simpl .
d e s t r u c t ( c l a s s P a t h E q e p0 ) eqn : E3 .
{
u n f o l d c o n t a i n s C l a s s P a t h in E1 .
u n f o l d c o u n t C l a s s P a t h in E1 .
d e s t r u c t ( count c l a s s P a t h E q l 1 p0 ) eqn : E4 .
{
pose proof classPathEqEqui .
d e s t r u c t H.
assert (
count c l a s s P a t h E q l 1 e =
count c l a s s P a t h E q l 1 p0
).
{
apply sameCount .
auto .
auto .
}
r e w r i t e H2 .
r e w r i t e E4 .
assert (
count c l a s s P a t h E q ( l i s t _ p r o d c l a s s e s l ) e =
count c l a s s P a t h E q ( l i s t _ p r o d c l a s s e s l ) p0
).
{
apply sameCount .
auto .
auto .
}
r e w r i t e H3 .
u n f o l d c o n t a i n s C l a s s P a t h in E2 .
u n f o l d c o n t a i n s in E2 .
d e s t r u c t ( count c l a s s P a t h E q
( l i s t _ p r o d c l a s s e s l ) p0 ) eqn : E5 .
{
congruence .
}
{
omega .
146
147
168
}
{
169
170
u n f o l d c o n t a i n s in E1 .
d e s t r u c t ( count c l a s s P a t h E q l 1 p0 ) eqn : E6 .
{
congruence .
}
{
congruence .
}
171
172
173
174
175
176
177
178
179
}
{
180
181
auto .
182
183
}
{
auto .
}
{
auto .
}
184
185
186
187
188
189
190
191
192
}
{
193
194
auto .
195
196
197
198
}
{
199
200
auto .
201
202
203
}
{
204
205
intros .
simpl .
omega .
206
207
208
209
210
}
212 Qed .
211
213
214
Theorem analyzeSpecS_t2 :
215
216
217
218
219
220
221
222
223
224
225
convSeq ( a n a l y z e S p e c S c l a s s e s c l a s s s p e c ) .
Proof .
intros .
p o s e p r o o f analyzeSpecS_t1 .
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 p e c .
d e s t r u c t H.
apply nonDecSublistBndListSeqConv .
auto .
auto .
Qed .
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
Theorem consNotEqual :
f o r a l l E ( l : l i s t E) ( e : E) , l <> e : : l .
Proof .
intros .
induction l .
{
discriminate .
}
{
injection .
intros .
auto .
}
Qed .
243
244
245
Definition analyzeSpecT c l a s s e s c l a s s s p e c n :=
l e t (_, t ) := a n a l y z e S p e c c l a s s e s c l a s s s p e c n in t .
246
247
248
249
250
251
252
Theorem analyzeSpecT_t1 :
e x i s t s N,
d e c L i s t O p t i o n S e q ( s u f f S e q ( analyzeSpecT c l a s s e s c l a s s s p e c ) N ) .
Proof .
intros .
253
254
255
256
257
258
p o s e p r o o f analyzeSpecS_t2 .
u n f o l d convSeq in H.
e x i s t s N.
259
260
261
unfold decListOptionSeq .
unfold suffListOption .
148
262
263
264
265
266
267
268
unfold
unfold
unfold
unfold
unfold
unfold
unfold
suffSeq .
analyzeSpecT .
analyzeSpec .
consSeq in H.
s u f f S e q in H.
a n a l y z e S p e c S in H.
a n a l y z e S p e c in H.
269
270
271
272
273
274
275
276
277
intros .
a s s e r t (N + ( S n ) = S (N + n ) ) .
{
omega .
}
r e w r i t e H0 .
278
279
280
281
282
u n f o l d a n a l y z e C l a s s P a t h s in H.
f o l d a n a l y z e C l a s s P a t h s in H.
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
destruct p .
destruct s .
{
d e s t r u c t ( a n a l y z e C l a s s P a t h s c l a s s e s l l 0 [ ] [ ( c l a s s , p ) ] (N + n ) ) .
destruct o .
{
destruct l2 .
{
auto .
}
{
d e s t r u c t ( c o n t a i n s C l a s s P a t h l 1 p0 ) .
{
exists l2 .
e x i s t s p0 .
auto .
}
{
destruct ( containsClassPath ( list_prod c l a s s e s l ) ) .
{
{
149
apply consNotEqual in H.
contradiction .
309
310
}
{
311
312
apply consNotEqual in H.
contradiction .
313
314
315
}
{
316
317
exists l2 .
e x i s t s p0 .
auto .
318
319
320
321
322
323
}
{
324
325
auto .
326
327
328
329
}
{
auto .
330
}
332 Qed .
331
333
334
335
336
337
338
339
340
341
342
343
344
Theorem analyzeSpecTLim :
l i m ( analyzeSpecT c l a s s e s c l a s s s p e c ) None \/
l i m ( analyzeSpecT c l a s s e s c l a s s s p e c ) ( Some [ ] ) .
Proof .
intros .
p o s e p r o o f analyzeSpecT_t1 .
apply h a s D e c O p t i o n L i s t S u f f S e q L i m .
auto .
Qed .
345
346
347
348
349
350
351
352
353
354
355
Theorem analyzeSpecLim :
e x i s t s N,
forall n,
l e t (_, t ) := a n a l y z e S p e c c l a s s e s c l a s s s p e c (N + n ) in
t = None \/ t = Some [ ] .
Proof .
intros .
p o s e p r o o f analyzeSpecTLim .
150
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
151
u n f o l d l i m in H.
u n f o l d s u f f S e q in H.
u n f o l d analyzeSpecT in H.
d e s t r u c t H.
{
e x i s t s N.
intros .
d e s t r u c t ( a n a l y z e S p e c c l a s s e s c l a s s s p e c (N + n ) ) .
auto .
}
{
e x i s t s N.
intros .
d e s t r u c t ( a n a l y z e S p e c c l a s s e s c l a s s s p e c (N + n ) ) .
auto .
}
Qed .
C.9 InterpretSpecFacts
1
2
3
4
5
6
7
8
9
10
11
Require
Require
Require
Require
Require
Require
Require
Import
Import
Import
Import
Import
Import
Import
Lim .
Litoral .
LitoralFacts .
ListOptionSeq .
ListSeq .
Seq .
Sublist .
12
13
14
15
Definition f i l t e r 2 S ( p a t h s : l i s t PATH) ( a l l O b j s : l i s t OBJ) ( s : l i s t OBJ)

( o b j s : l i s t OBJ) ( path : PATH) :=
l e t ( s , _) := f i l t e r 2 p a t h s a l l O b j s s o b j s path in s .
16
17
18
19
Definition f i l t e r 2 R ( p a t h s : l i s t PATH) ( a l l O b j s : l i s t OBJ) ( s : l i s t OBJ)

( o b j s : l i s t OBJ) ( path : PATH) :=
l e t (_, r ) := f i l t e r 2 p a t h s a l l O b j s s o b j s path in r .
20
Theorem f i l t e r 2 _ t 1 :
f o r a l l p a t h s a l l O b j s ( s : l i s t OBJ) o b j s path ,
23
e x i s t s ( s : l i s t OBJ) ,
21
22
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
f i l t e r 2 S p a t h s a l l O b j s s o b j s path = s ++ s
/\ ( f o r a l l obj ,
count objEq s o b j = 0 \/
count objEq s o b j = 1 /\
c o n t a i n s objEq a l l O b j s o b j = t r u e /\
c o n t a i n s objEq s o b j = f a l s e )
/\ l e n g t h s = l e n g t h ( f i l t e r 2 R p a t h s a l l O b j s s o b j s path ) .
Proof .
intros .
induction objs .
{
exists [ ] .
auto .
}
{
unfold f i l t e r 2 S .
unfold f i l t e r 2 R .
unfold f i l t e r 2 .
fold f i l t e r 2 .
d e s t r u c t IHobjs .
u n f o l d f i l t e r 2 S in H.
u n f o l d f i l t e r 2 R in H.
d e s t r u c t ( f i l t e r 2 p a t h s a l l O b j s s o b j s path ) .
d e s t r u c t ( c o n t a i n s O b j a l l O b j s a ) eqn : E1 .
{
d e s t r u c t ( c o n t a i n s O b j l a ) eqn : E2 .
{
exists x.
auto .
}
{
d e s t r u c t H.
r e w r i t e H.
exists (a : : x ).
split .
{
auto .
}
{
split .
{
simpl .
intros .
d e s t r u c t ( objEq o b j a ) eqn : E3 .
{
right .
152
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
s p e c i a l i z e H0 with o b j .
a s s e r t ( c o n t a i n s objEq a l l O b j s o b j = t r u e /\
c o n t a i n s objEq s o b j = f a l s e ) .
{
intros .
split .
{
r e w r i t e sameContains with ( e := a ) .
auto .
apply objEqEqui .
auto .
}
{
r e w r i t e H in E2 .
apply a p p C o n t a i n s F a l s e in E2 .
d e s t r u c t E2 .
r e w r i t e sameContains with ( e := a ) .
auto .
apply objEqEqui .
auto .
apply objEqEqui .
}
}
{
{
auto .
}
{
r e w r i t e H in E2 .
apply a p p C o n t a i n s F a l s e in E2 .
d e s t r u c t E2 .
r e w r i t e sameContains with ( e := o b j ) in H3 .
congruence .
apply objEqEqui .
p o s e p r o o f objEqEqui .
s p e c i a l i z e H6 with a o b j .
r e w r i t e E3 in H6 .
auto .
apply objEqEqui .
}
}
153
}
{
118
119
auto .
120
121
}
{
122
123
simpl .
omega .
124
125
126
127
128
}
{
129
130
exists x.
auto .
131
132
133
}
135 Qed .
134
136
137
138
Definition 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 n :=
l e t (_, s , _) := i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s n in s .
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
Theorem i n t e r p r e t S p e c 2 S _ t 1 :
nonDecListSeq ( 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 )
/\ s u b l i s t B n d L i s t S e 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 ) .
Proof .
intros .
split .
{
unfold interpretSpec2S .
unfold interpretSpec2 .
unfold interpretSpec .
unfold interpretObjsPaths .
fold interpretObjsPaths .
destruct p .
destruct s .
intros .
d e s t r u c t ( i n t e r p r e t O b j s P a t h s f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o b j s , p ) ] n0 ) .
destruct o .
{
destruct l3 .
{
exists [ ] .
154
auto .
165
}
{
166
167
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 ) eqn : E1 .
pose proof f i l t e r 2 _ t 1 .
s p e c i a l i z e H with l a l l O b j s l 2 l 4 p0 .
d e s t r u c t H.
d e s t r u c t H.
r e w r i t e E1 in H.
d e s t r u c t ( i n t e r p r e t P a t h l 0 a l l O b j s l 6 p0 ) .
{
exists x.
auto .
}
{
exists x.
auto .
}
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
}
{
186
187
exists
auto .
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
[].
}
{
unfold sublistBndListSeq .
e x i s t s objEq .
exists allObjs .
split .
{
apply objEqEqui .
}
{
induction n .
{
destruct p .
destruct s .
simpl .
155
intros .
omega .
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
156
}
{
u n f o l d i n t e r p r e t S p e c 2 S in IHn .
u n f o l d i n t e r p r e t S p e c 2 in IHn .
u n f o l d i n t e r p r e t S p e c in IHn .
destruct p .
destruct s .
destruct ( interpretObjsPaths f i l t e r 2 l l 0 allObjs [ ] [ ( objs , p ) ] n ) .
destruct o .
destruct l3 .
{
auto .
}
{
s p e c i a l i z e H with l a l l O b j s l 2 l 4 p0 .
d e s t r u c t H.
d e s t r u c t H.
r e w r i t e E1 in H.
a s s e r t ( s u b l i s t objEq l 5 a l l O b j s ) .
{
u n f o l d s u b l i s t in IHn .
intros .
s p e c i a l i z e IHn with e .
r e w r i t e H.
r e w r i t e appCount .
{
omega .
}
{
apply containsTrueCountNotZero in H1 .
omega .
259
260
261
262
263
264
}
d e s t r u c t ( i n t e r p r e t P a t h l 0 a l l O b j s l 6 p0 ) .
{
destruct l6 .
{
auto .
}
{
auto .
}
}
{
destruct l6 .
{
auto .
}
{
auto .
}
}
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
}
{
285
286
auto .
287
288
289
290
}
292 Qed .
291
293
294
295
296
297
298
299
300
301
302
303
304
305
Theorem i n t e r p r e t S p e c 2 S _ t 2 :
convSeq ( 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 ) .
Proof .
intros .
pose proof interpretSpec2S_t1 .
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 .
d e s t r u c t H.
apply nonDecSublistBndListSeqConv .
auto .
auto .
Qed .
157
158
306
307
308
Definition i n t e r p r e t S p e c 2 T s p e c a l l O b j s o b j s n :=
l e t (_, _, t ) := i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s n in t .
309
310
311
312
313
314
315
Theorem i n t e r p r e t S p e c 2 T _ t 1 :
e x i s t s N,
decListOptionSeq ( s u f f S e q ( interpretSpec2T spec a l l O b j s objs ) N) .
Proof .
intros .
316
317
318
319
320
pose proof interpretSpec2S_t2 .

e x i s t s N.
321
322
323
324
325
326
327
328
329
330
331
332
unfold
unfold
unfold
unfold
unfold
unfold
unfold
unfold
unfold
unfold
unfold
decListOptionSeq .
suffListOption .
suffSeq .
interpretSpec2T .
interpretSpec2 .
interpretSpec .
consSeq in H.
s u f f S e q in H.
i n t e r p r e t S p e c 2 S in H.
i n t e r p r e t S p e c 2 in H.
i n t e r p r e t S p e c in H.
333
334
335
336
337
338
339
340
341
intros .
a s s e r t (N + ( S n ) = S (N + n ) ) .
{
omega .
}
r e w r i t e H0 .
342
343
344
345
346
u n f o l d i n t e r p r e t O b j s P a t h s in H.
f o l d i n t e r p r e t O b j s P a t h s in H.
347
348
349
350
351
352
destruct
destruct
destruct
destruct
destruct
( indexSpec spec ) .
p.
s.
( i n t e r p r e t O b j s P a t h s f i l t e r 2 l l 0 a l l O b j s [ ] [ ( o b j s , p ) ] (N + n ) ) .
p0 .
353
354
355
356
357
358
359
360
destruct o .
{
destruct l3 .
{
auto .
}
{
361
362
363
364
365
366
367
368
s p e c i a l i z e H1 with l a l l O b j s l 2 l 4 p0 .
u n f o l d f i l t e r 2 S in H1 .
u n f o l d f i l t e r 2 R in H1 .
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
d e s t r u c t ( i n t e r p r e t P a t h l 0 a l l O b j s l 6 p0 ) eqn : E2 .
{
a s s e r t ( l 5 = [ ] ++ l 5 ) .
{
auto .
}
r e w r i t e H in H1 .
apply app_inv_tail in H1 .
r e w r i t e < H1 in H3 .
s i m p l in H3 .
symmetry in H3 .
r e w r i t e H3 in E2 .
u n f o l d i n t e r p r e t P a t h in E2 .
i n j e c t i o n E2 .
intros .
r e w r i t e app_nil_r .
exists l3 .
e x i s t s ( l 4 , p0 ) .
auto .
}
{
a s s e r t ( l 5 = [ ] ++ l 5 ) .
{
auto .
}
159
r e w r i t e H in H1 .
apply app_inv_tail in H1 .
r e w r i t e < H1 in H3 .
s i m p l in H3 .
symmetry in H3 .
r e w r i t e H3 in E2 .
u n f o l d i n t e r p r e t P a t h in E2 .
congruence .
400
401
402
403
404
405
406
407
408
409
410
411
412
}
{
auto .
413
414
415
}
Qed .
416
417
418
419
420
421
422
423
424
425
426
427
Theorem i n t e r p r e t S p e c 2 T _ t 2 :
l i m ( i n t e r p r e t S p e c 2 T s p e c a l l O b j s o b j s ) None \/
l i m ( i n t e r p r e t S p e c 2 T s p e c a l l O b j s o b j s ) ( Some [ ] ) .
Proof .
intros .
pose proof interpretSpec2T_t1 .
apply h a s D e c O p t i o n L i s t S u f f S e q L i m .
auto .
Qed .
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
Theorem i n t e r p r e t S p e c 2 L i m :
e x i s t s N,
forall n,
l e t (_, _, t ) := i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s (N + n ) in
t = None \/ t = Some [ ] .
Proof .
intros .
pose proof interpretSpec2T_t2 .
u n f o l d l i m in H.
u n f o l d s u f f S e q in H.
u n f o l d i n t e r p r e t S p e c 2 T in H.
d e s t r u c t H.
{
e x i s t s N.
intros .
160
d e s t r u c t ( i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s (N + n ) ) .
destruct p .
auto .
447
448
449
450
451
452
}
{
453
454
455
456
457
458
459
}
461 Qed .
460
e x i s t s N.
intros .
d e s t r u c t ( i n t e r p r e t S p e c 2 s p e c a l l O b j s o b j s (N + n ) ) .
destruct p .
auto .
161

Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Otimizando Sistemas Intensivos em ES Através de Programação Concorrente

Enviado por

Direitos autorais:

Formatos disponíveis

Ps-Graduao em Cincia da Computao

Otimizando Sistemas Intensivos em E/S Atravs de

Universidade Federal de Pernambuco

SAULO MEDEIROS DE ARAJO

OTIMIZANDO SISTEMAS INTENSIVOS EM E/S ATRAVS DE

Este trabalho foi apresentado Ps-Graduao em

Arajo, Saulo Medeiros de.

CDD (22. ed.)

Dissertao de Mestrado apresentada por Saulo Medeiros de Arajo Ps Graduao

Visto e permitida a impresso.

Para meus pais, Stelio e Henrriete.

This is the springtime of my loving

Keywords: Object-relational mapping. Prefetching. Concurrency.

Criao de classes no interpretador definidor. . . . . . . . . . . . . . .

Figura 54 Clculo de b2 4ac compondo invocaes de funes sncronas e assncronas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Lista de abreviaturas e siglas

Application Programming Interface

Abstract Syntax Tree

Banco Central do Brasil

Computer Aided Design

Computer Aided Manufacturing

Computer Aided Software Engineering

Extended Backus-Naur Form

Java Persistence Architecture

Java Persistence Query Language

Object-Oriented Database Management System

Representational State Transfer

Remote Method Invocation

Sistema de Gerenciamento de Banco de Dados

Simple Object Access Protocol

Structured Query Language

Very Large Scale Integration

XML Path Language

Extensible Markup Language

APNDICE A EMEIO . . . . . . . . . . . . . . . . . . . . . . . . 109

APNDICE B OO7 . . . . . . . . . . . . . . . . . . . . . . . . . . 112

Figura 1 Trecho de cdigo Java que navega por objetos.

String spec = " [ sender r e c i p i e n t s ] " ;

f o r ( Message message : m ess age s ) { / . . . / }

armazenados em um outro sistema. Basta que o ltimo adote algum mecanismo de

o Captulo 5 apresenta os bechmarks Emeio e OO7 e as implementaes destes

2.1 Sistemas Intensivos em Processamento e em E/S

Captulo 2. Conceitos Bsicos

Nos sistemas intensivos em E/S, os papis se invertem. Redues em tp tm baixo

2.2 Otimizao de Sistemas Intensivos em E/S

2.2.3 Carregamento sob Demanda e Pr-carregamento

Captulo 2. Conceitos Bsicos

2.2.3.1 Pr-carregamento Informado e Especulativo

Captulo 2. Conceitos Bsicos

2.3 Carregamento sob Demanda, Pr-carregamento e Agregao

2.3.1 Tipos de Atributo

Captulo 2. Conceitos Bsicos

S t r i n g j p q l = " s e l e c t m from Message m where m. s e n d e r . i d = 1 " ;

f o r ( Message message : m ess age s ) {

L i s t <F i l e > f i l e = message . g e t F i l e s ( ) ;

s e l e c t sent_date from message where i d e n t i f i e r = / . . . /

s e l e c t s u b j e c t from message where i d e n t i f i e r = / . . . /

s e l e c t s e n d e r _ i d e n t i f i e r from message where i d e n t i f i e r = / . . . /

Captulo 2. Conceitos Bsicos

s e l e c t from message where i d e n t i f i e r = / . . . /

message . , s e n d e r . from message

2.3.2 Carregamento de Atributos do Tipo I

2.3.3 Carregamento de Atributos do Tipo II que Referenciam Objetos

Captulo 2. Conceitos Bsicos