€¦ · resumo o objetivo deste trabalho ´e criar um mecanismo para mobilidade de objetos para a...

Pontifıcia Universidade Catolica do Parana – PUCPR

Programa de Pos-Graduacao em Informatica Aplicada

Mecanismo de Mobilidade

de Objetos para a Virtuosi

Juarez da Costa Cesar Filho

Dissertacao apresentada ao Programa de

Pos-Graducao em Informatica Aplicada da

Pontifıcia Universidade Catolica do Parana

como requisito parcial para obtencao do tıtulo de

Mestre em Informatica Aplicada

Julho de 2004

Agradecimentos

Ao amigo e orientador Alcides Calsavara, que transcendeu suas

funcoes de professor – e seus horarios – para possibilitar a con-

clusao deste trabalho. Ao colega, amigo e colaborador Kolb, que

percorreu comigo do primeiro ao ultimo dia – ultimo dia literal-

mente – os desafios do Mestrado. Aos meus Pais, e em especial

minha Mae, que da cartilha ate esta dissertacao corrige minha

escrita.

i

Resumo

O objetivo deste trabalho e criar um mecanismo para mobilidade de objetos para a Virtu-

osi. A Virtuosi e um sistema computacional distribuıdo orientado a objetos que atua sobre

maquinas virtuais cooperantes. A sua arquitetura e baseado no conceito de arvores de pro-

grama para representacao de classes e de referencias indiretas atraves de handle tables entre

suas entidades. Como outros sistemas distribuıdos tem em sua concepcao a mobilidade de

objetos. O mecanismo projetado deve ter como requisitos garantir a integridade do sistema,

possuir um desempenho adequado e tratar possıveis faltas no ambiente. Em complemento

a isto, o mecanismo deve disponibilizar funcionalidades – por interface de programacao –

para o controle da mobilidade dos objetos e, ser compatıvel com a definicao atual do kernel

e modulos ja implementados. Este trabalho de pesquisa define um mecanismo para mobi-

lidade de objetos baseado em diversos outros documentados na literatura e descreve uma

implementacao para o mesmo.

Palavras-chaves: mobilidade de objetos; migracao de objetos; maquina virtual; meta-

modelagem.

ii

Abstract

The main goal of this work is to define an Object Mobility Mechanism for Virtuosi. Vir-

tuosi is a distributed computing system based on collaborative virtual machines. Virtuosi

architecture uses program trees to represents object classes and indirect references using

handle tables among its entities. As some other distribuited environments, Virtuosi aims at

supporting object mobility. Such mechanism must preserve object integrity, with adequate

performance and fault tolerance. Additionaly, it should provide funcionality – through some

programming interface – to controle object mobility, and be compatible with Virtuosi’s

current core and already implemented modules. This research work defines an object mo-

bility mechanism based on several similar mechanisms documented in the literature and

describes an implementation for it.

Key-words: object mobility; object migration; virtual machines; metamodeling.

iii

iv

Sumario

Capıtulo 1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Problematica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Delimitacao de Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.5 Organizacao de Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Capıtulo 2 Mecanismos de Mobilidade 5

2.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Motivacao para a Movimentacao . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Requisitos de um Mecanismo de Mobilidade . . . . . . . . . . . . . . . . . . . . 6

2.4 Emerald . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.1 Estruturas da Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4.2 Primitivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.3 Parametros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.4 Tipos de objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4.5 Estrutura do Objeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4.6 Processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Sumario v

2.4.7 Movendo Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.4.8 Movendo Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.5 Distributed Oz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.1 Definicao de Termos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.2 Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5.3 Estruturas da Linguagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5.4 Comportamento Distribuıdo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.5.5 Grafico de Linguagem e Distribuicao . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.6 Mecanismo de Migracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.6 CORBA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

2.6.2 Transferencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

2.6.3 Consideracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

2.7 Aglet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.7.1 Introducao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.7.2 Implementacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

2.7.3 Ciclo de Vida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

2.7.4 Serializacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

2.7.5 Seguranca . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Capıtulo 3 Arquitetura da Virtuosi 42

3.1 Metamodelo da Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

Sumario vi

3.1.1 Literal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.2 Bloco de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.1.4 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.1.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1.6 Invocaveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

3.1.7 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.1.8 Chamadas de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2 Arvore de Programa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.1 Exemplos de arvores de programa . . . . . . . . . . . . . . . . . . . . . . . . . 54

3.2.2 Lista de Referencias a Classe . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

3.2.3 Lista de Referencias a Invocaveis . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3 Maquina Virtual Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3.1 Ciclo de Vida de Uma Aplicacao . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.3.2 Area de Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.3.3 Area de Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

3.3.4 Area de Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

3.3.5 Resumo da Arquitetura da Maquina Virtual Virtuosi . . . . . . . . . . . . . . 73

3.3.6 Funcionamento da Maquina Virtual Virtuosi . . . . . . . . . . . . . . . . . . . 73

Capıtulo 4 Mobilidade de Objetos na Virtuosi 78

4.1 Primitivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Sumario vii

4.2 Pre-requisitos para migracao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3 Mecanismo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3.1 Protocolo de Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

4.3.2 Mecanismo de Mobilidade de Atividades . . . . . . . . . . . . . . . . . . . . . 85

4.3.3 Fragmentacao de Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

4.3.4 Consideracoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.3.5 Tolerancia a Faltas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

4.3.6 Avaliacao Comparativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94

Capıtulo 5 Estudo de Cenarios 97

5.1 Cenario 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97

5.2 Cenario 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

5.3 Cenario 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

5.4 Cenario 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Capıtulo 6 Implementacao 106

6.1 Ambiente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.2 Limitacoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

6.3 Diagrama de Classes da MVV . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

6.4 Ciclo de Vida da MVV em Termos das Classes que a Compoem . . . . . . . . . 108

6.5 Tabela de Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

6.6 Programacao das Primitivas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Sumario viii

6.7 Cenarios de Testes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

Capıtulo 7 Conclusao e Trabalhos Futuros 113

7.1 Contribuicao Cientıfica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

7.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

Apendice A Metamodelo da Virtuosi . . . . . . . 115

A.1 Especificacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

A.1.1 Literais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116

A.1.2 Bloco de Dados e Indice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117

A.1.3 Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

A.1.4 Atributos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124

A.1.5 Referencias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

A.1.6 Invocaveis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.1.7 Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

A.1.8 Chamadas de Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158

Referencias Bibliograficas . . . . . . . . . . . . . 164

ix

Lista de Figuras

2.1 Tipos de enderecamento no Emerald . . . . . . . . . . . . . . . . . . . . . . 13

2.2 Representacao de um objeto do Emerald em memoria. . . . . . . . . . . . . 15

2.3 Representacao de uma pilha de execucao. . . . . . . . . . . . . . . . . . . . . 15

2.4 Representacao distribuıda de um processo atraves de suas pilhas de execucao. 16

2.5 Classificacao das entidades quanto a distribuicao. . . . . . . . . . . . . . . . 25

2.6 Representacao grafica das entities. . . . . . . . . . . . . . . . . . . . . . . . . 27

2.7 Grafico de linguagem versus grafico de distribuicao. . . . . . . . . . . . . . . 28

2.8 Visualizacao de um objeto com um atributo e dois metodos. . . . . . . . . . 28

2.9 Objeto local - sem referencias remotas. . . . . . . . . . . . . . . . . . . . . . 29

2.10 Objeto global com uma referencia remota. . . . . . . . . . . . . . . . . . . . 29

2.11 Invocacao remota sobre o objeto (1). . . . . . . . . . . . . . . . . . . . . . . 29



2.14 Visualizacao de um objeto com um atributo e dois metodos. . . . . . . . . . 31

2.15 Thread requisita a atualizacao do estado apontado por pe2. . . . . . . . . . . 32

2.16 (1)Mensagem de aquisicao do estado. (b)Redirecionamento da mensagem de

aquisicao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.17 (1)Repasse do ponteiro de estado. (2) Mensagem para prosseguimento de

transacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.18 Fim da movimentacao do estado do objeto para o site 2. . . . . . . . . . . . 33

Lista de Figuras x

2.19 Interconexao entre dois sistemas de agente. . . . . . . . . . . . . . . . . . . . 36

2.20 Ciclo de Vida de um aglet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.1 Codigo fonte em Aram mostrando os possıveis uso de um valor literal . . . . 44

3.2 Relacionamento da meta-classe que representa uma classe de aplicacao com

outros componentes do metamodelo da Virtuosi . . . . . . . . . . . . . . . . 45

3.3 Os tres tipos de atributos possıveis em uma classe segundo o metamodelo da

Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

3.4 Relacionamento da meta-classe que representa a referencia a objeto com ou-

tros componentes do metamodelo da Virtuosi . . . . . . . . . . . . . . . . . 48

3.5 Conjunto de arvores de programa que compoem uma aplicacao de software . 55

3.6 Fragmento de codigo fonte da classe Pessoa . . . . . . . . . . . . . . . . . . 56

3.7 Arvore de programa parcial referente a classe Pessoa . . . . . . . . . . . . . 56

3.8 Fragmento de codigo fonte da classe Pessoa . . . . . . . . . . . . . . . . . . 58

3.9 Arvore de programa parcial referente a classe Pessoa . . . . . . . . . . . . . 59

3.10 Referencias simbolicas entre arvores de programa . . . . . . . . . . . . . . . 61

3.11 Tabelas de classes com referencias locais e remotas . . . . . . . . . . . . . . . 64

3.12 Tabelas de invocaveis com referencias locais e remotas . . . . . . . . . . . . . 65

3.13 Ilustracao da carga de duas arvores de programa ligadas entre si . . . . . . . 66

3.14 Tabelas de objetos com referencias locais e remotas . . . . . . . . . . . . . . 68

3.15 Exemplo de uma pilha de execucao e o detalhe de uma atividade. . . . . . . 71

3.16 Uma atividade assıncrona remota . . . . . . . . . . . . . . . . . . . . . . . . 73

3.17 Arquitetura da Maquina Virtual Virtuosi . . . . . . . . . . . . . . . . . . . . 74

4.1 Objeto Y fixado por meio de primitiva e o objeto X disponıvel para movimen-

tacao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Lista de Figuras xi

4.2 Cenario inicial antes da migracao do objeto X para a MVV Beta. . . . . . . 81


4.4 Demonstracao das tabelas de referencia auxiliares para Classes e Invocaveis

pertinentes a classe X, geradas a partir das informacoes das listas de re-

ferencias, da Tabela de Classes e da Tabela de Invocaveis conforme Figura

4.2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

4.5 Cenario final apos a migracao da Classe X para a MVV Beta, baseado no

Cenario inicial da Figura 4.2. . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.6 Cenario final apos a migracao do objeto X para a MVV Beta, baseado no



4.8 Cenario final depois da migracao do objeto X para a MVV Beta, baseado no


4.9 Cenario onde duas pilhas de execucao possuem referencias entre suas ativi-

dades localmente. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

4.10 Cenario final apos resolucao das referencias locais entre atividades. . . . . . . 88

4.11 Demonstracao da area de objeto onde existem referencias fragmentadas e

otimizadas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.12 Demonstracao da sequencia de movimetacoes da classe Y . Cenario iniciado a

partir da conclusao da carga das classes pelo carregador de arvores. . . . . . 92

4.13 Demonstracao de referencias fragamentadas: as referencias b e c estao frag-

mentadas enquanto a a e d estao otimizadas (informacao baseada na Figura

4.11). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

4.14 Cenario onde todas as referencias estao otimizadas. . . . . . . . . . . . . . . 93

4.15 Cenario apos a migracao do objeto y para a MVV Gama tendo como base a

Figura 4.14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93

5.1 Cenario 1 (a): Disposicao inicial das entidades e sua referencias. . . . . . . . 98

Lista de Figuras xii

5.2 Cenario 1 (b): Objeto Y ja migrado para a MVV Beta. . . . . . . . . . . . . 99

5.3 Cenario 2 (a): Disposicao inicial das entidades e sua referencias. . . . . . . . 100

5.4 Cenario 2 (b): Objeto Y ja migrado para a VM Beta. . . . . . . . . . . . . . 101

5.5 Cenario 3: Disposicao das entidades ao final do codigo do metodo start(). . . 102

5.6 Cenario 4: Disposicao incial das atividades. . . . . . . . . . . . . . . . . . . . 105

5.7 Cenario 4: Disposicao das atividade apos a migracao do objeto x. . . . . . . 105

6.1 Diagrama das principais classes da Maquina Virtual Virtuosi . . . . . . . . . 108

A.1 Codigo fonte em Aram mostrando os possıveis usos de um valor literal . . . . 117

A.2 Relacionamento das meta-classes que representam valores literais e referencias

a literal com outros componentes do metamodelo da Virtuosi . . . . . . . . . 118

A.3 Referencia a literal-classe que representa a referencia a bloco de dado com


A.4 Relacao entre um ındice e uma referencia a bloco de dados . . . . . . . . . . 120

A.5 Relacionamento da meta-classe que representa a referencia a ındice com outros

componentes do metamodelo da Virtuosi . . . . . . . . . . . . . . . . . . . . 122

A.6 Relacionamento da meta-classe que representa uma classe de aplicacao com


A.7 Relacao de heranca entre classes segundo o metamodelo da Virtuosi . . . . . 125

A.8 Os tres tipos de atributos possıveis em uma classe segundo o metamodelo da

Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125

A.9 Relacionamento da meta-classe que representa a referencia a objeto com ou-

tros componentes do metamodelo da Virtuosi . . . . . . . . . . . . . . . . . 127

A.10 Atributos em uma classe segundo o metamodelo da Virtuosi . . . . . . . . . 128

A.11 Codigo fonte em Aram e diagrama de objeto de uma relacao de composicao

entre uma classe e um atributo . . . . . . . . . . . . . . . . . . . . . . . . . 129

Lista de Figuras xiii

A.12 Codigo fonte em Aram e diagrama de objeto de uma relacao de associacao

entre uma classe e um atributo . . . . . . . . . . . . . . . . . . . . . . . . . 129

A.13 As duas maneiras em que uma referencia a objeto representa o papel de atrib-

uto segundo o metamodelo da Virtuosi . . . . . . . . . . . . . . . . . . . . . 129

A.14 Um exemplo de atributo do tipo bloco de dados e uma representacao de um

objeto correspondente – codigo fonte em Aram . . . . . . . . . . . . . . . . . 130

A.15 Um exemplo de atributo do tipo enumerado e uma representacao de um objeto

correspondente – codigo fonte em Aram . . . . . . . . . . . . . . . . . . . . . 131

A.16 Relacionamento entre as meta-classes que definem os tipos de referencia na

Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

A.17 Relacao entre uma classe e as possıveis implementacoes de suas operacoes . . 133

A.18 Relacionamento da meta-classe Invocavel com outros componentes do meta-

modelo da Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133

A.19 Codigo fonte em Aram contendo um metodo sem parametros e um metodo

com parametros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135

A.20 Metodos com diferentes listas de exportacao – Codigo fonte em Aram . . . . 137

A.21 Relacao de um Invocavel e sua lista de exportacao . . . . . . . . . . . . . . . 137

A.22 Metodos com retorno e metodos sem retorno . . . . . . . . . . . . . . . . . . 138

A.23 Diferenciacao entre metodos com retorno e metodos sem retorno . . . . . . . 138

A.24 Codigo fonte em Aram contendo uma declaracao de uma acao . . . . . . . . 139

A.25 Relacionamento de heranca entre as meta-classes comando, comando simples

e comando composto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

A.26 Tipos de declaracoes para variaveis locais . . . . . . . . . . . . . . . . . . . . 141

A.27 Invocacao de metodo passando como parametro um valor literal e a declaracao

do metodo invocado – codigo fonte em Aram . . . . . . . . . . . . . . . . . . 142

A.28 Declaracao de uma variavel local do tipo referencia a objeto – codigo fonte

em Aram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142

Lista de Figuras xiv

A.29 Declaracao de uma variavel local do tipo referencia a bloco de dados – codigo

fonte em Aram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

A.30 Declaracao de uma variavel local do tipo referencia a ındice – codigo fonte em

Aram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

A.31 Relacionamento das meta-classes que representam os comandos de atribuicao

de referencia a objeto com outros componentes do metamodelo da Virtuosi . 145

A.32 Relacionamento das meta-classes que representam os dois comandos de atribuicao

de referencia a bloco de dados com outros componentes do metamodelo da

Virtuosi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

A.33 Relacionamento da meta-classe comando de atribuicao de referencia a ındice

com outros componentes do metamodelo da Virtuosi . . . . . . . . . . . . . 147

A.34 Relacionamento da meta-classe comando de atribuicao variavel enumerada

com outros componentes do metamodelo da Virtuosi . . . . . . . . . . . . . 148

A.35 Relacionamento entre um comando de retorno e uma referencia a objeto . . 149

A.36 Relacionamento da meta-classe que representa um comando de invocacao com

sua hierarquia e outros componentes do metamodelo da Virtuosi . . . . . . . 150

A.37 Relacao entre os comandos de invocacao e os invocaveis . . . . . . . . . . . . 151

A.38 Comandos de desvio e como se relacionam com as sequencias de comandos . 153

A.39 Relacao de um desvio condicional, um testavel, uma invocacao de acao e uma

acao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

A.40 Desvio condicional com um testavel que e uma invocacao de uma acao – codigo

fonte em Aram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

A.41 Desvio condicional com um testavel que e uma comparacao de valor entre

uma variavel enumerada e um valor literal – codigo fonte em Aram . . . . . 155

A.42 Definicao de uma acao padrao e seu respectivo uso por um comando de desvio 156

A.43 Relacao de um desvio condicional com todos os testaveis possıveis . . . . . . 157

A.44 Estrutura de repeticao realizada pela combinacao de um desvio condicional e

um desvio incondicional – codigo fonte em Aram . . . . . . . . . . . . . . . . 158

A.45 Comandos de sistema disponibilizados pelo sistema . . . . . . . . . . . . . . 159

A.46 Uso de dois comandos de sistema para facilitar a construcao de uma classe

pre-definida Integer – codigo fonte em Aram . . . . . . . . . . . . . . . . . . 161

A.47 Testaveis de sistema disponibilizados pelo sistema . . . . . . . . . . . . . . . 162

A.48 Uso de testaveis especiais nos comandos de desvio utilizados na construcao de

uma classe pre-definida Integer – codigo fonte em Aram . . . . . . . . . . . . 163

xv

Lista de Tabelas

4.1 Tabela de referencia auxiliar para Objetos, gerada a partir do cenarios descrito

na Figura 4.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

1

Capıtulo 1

Introducao

1.1 Motivacao

Diversos sistemas computacionais que fazem uso de processamento distribuıdo tem descrito

ou implementado mecanismos de mobilidade1 de objetos. Sistemas como o DCE[Tanenbaum, 1994],

CORBA[Crowcroft, 1996], Emerald[Jul et al., 1988], Chorus/COOL[Amaral et al., 1992] e

SOS[M. Shapiro, 1989] se beneficiam das varias vantagens que a mobilidade de objetos ofer-

ece [Nutttal., 1994]. Existem varias situacoes onde podemos verificar estas vantagens. A

movimentacao de um objeto para o mesmo local onde se encontram os recursos como ar-

quivos, perifericos ou mesmo outros objetos com os quais haja bastante interacao traz ganhos

pela reducao do trafego da rede. Nodos que estao sobrecarregados podem distribuir a car-

ga para outros nodos mais ociosos. Objetos podem necessitar de algum suporte especıfico,

como, por exemplo, um ambiente seguro, ou ainda em redes heterogeneas atividades de um

objeto podem necessitar de algum suporte especıfico fornecido somente por uma plataforma

disponıvel em algum nodo [Jul et al., 1988]. Aplicacoes onde a mobilidade de objeto e in-

trınseca como os dispositivos computacionais portateis, os quais estao sendo cada vez mais

utilizadas.

A Virtuosi e um sistema computacional distribuıdo orientado a objetos que atua sobre

maquinas virtuais cooperantes. Como outros sistemas distribuıdos, tem em sua concepcao

a mobilidade de objetos. A arquitetura da Virtuosi tem como caracterısticas a utilizacao

de arvores de programa para representacao de classes e o modo de referencias indiretas

atraves de handle tables [HU et al., 2003]. Visando estas caracterısticas e necessario uma

especificacao formal de um mecanismo de mobilidade de objetos que atenda os requisitos

Capıtulo 1. Introducao 2

propostos pela Virtuosi.

1.2 Objetivos

O objetivo deste trabalho e definir formal e precisamente o processo de mobilidade de objetos

na Virtuosi. Esta definicao deve se adaptar as suas caracterısticas de forma que utilize suas

peculiaridades da melhor forma possıvel em benefıcio do desempenho, seguranca e integri-

dade do sistema. Para uma melhor compreensao, por ser o tema abrangente, o separamos

em quatro objetos de estudo:

• Requisitos de mobilidade: Analise dos requisitos que um mecanismo de mobilidade

deve atender.

• Arquitetura: Estudo da arquitetura de sistemas distribuıdos orientados a objetos.

• Primitivas: Estudo das primitivas de mobilidade necessarias ao contexto distribuıdo.

• Protocolo da mobilidade: Definicao do protocolo a ser seguido durante a movimentacao

de um objeto. Tratamento das atividades em andamento, atualizacao de referencias,

sequencias possıveis e modelo transacional.

O trabalho utilizara a linguagem grafica representacional definida para Virtuosi, criando

uma extensao desta para os casos ainda nao concebidos pelo modelo [Calsavara, 2000]. O

estudo contribuira para a construcao da Virtuosi e servira de subsıdio para trabalhos futuros

correlatos a area de distribuicao e mobilidade de objetos para Sistemas Computacionais

Distribuıdos (SCD).

1.3 Problematica

Ao desenvolver este trabalho cientıfico pesquisou-se diversos SCDOO (Sistemas Computa-

cionais Distribuıdos Orientados a Objetos), de todos estes a arquitetura da Virtuosi se

1Mobilidade: Termo para a habilidade de movimentacao de um objeto ou processo por entre diferentesnodos de uma rede. Migracao foi comumente empregado com o mesmo sentido em artigos menos recentesque compoem este trabalho. Assim adotaremos ambos como sinonimos.


mostrou bastante diferente em importantes aspectos. O conceito de arvores de programa

e de handle tables [HU et al., 2003] para todas as referencias, tanto para as proprias arvores

como para os objetos instanciados, geram facilidades por serem projetados para prover uma

arquitetura totalmente voltada para a distribuicao. O enfoque pedagogico e experimental

da Virtuosi [Cal, 2004] tambem influenciou no peso dos requisitos a serem atendidos para o

mecanismo.

1.4 Delimitacao de Tema

Este trabalho se propoe ao estudo e desenvolvimento de um mecanismo de mobilidade que

atenda a arquitetura da Virtuosi, garantindo que o processo de mobilidade atenda os requi-

sitos estabelecido pelo sistema. Aqui nao sera contemplado o mecanismo de RPC2, e nem

a definicao de polıticas para a migracao, como balanceamento de carga, disponibilidade do

sistema, ou qualquer outro topico que possa se utilizar do mecanismo porem nao faca parte

dele.

1.5 Organizacao de Trabalho

O capıtulo 2 apresenta o contexto atual sobre mobilidade, apresentando as vantagens da

movimentacao de objetos, a conotacao dos termos utilizados e os requisitos que devem

ser atendidos pelos mecanismos. Citamos alguns Sistemas Computacionais Distribuıdos

e descrevemos com maior profundidade o Emerald, Distributed Oz e CORBA, os quais sao

parametros para este trabalho. O capıtulo 3 descreve o funcionamento da arquitetura da

Virtuosi em todos os aspectos importantes para a mobilidade: metamodelo, arvores de pro-

grama, modelo referencial, objetos, atividades, classes e Maquina Virtual. No capıtulo 4

detalhamos o mecanismo de mobilidade proposto, comecando pelas primitivas disponıveis,

as condicoes necessarias para que ocorra a migracao e a descricao do funcionamento do me-

canismo. O capıtulo 5 descreve alguns cenarios para a mobilidade. No capıtulo seguinte

2Remote Procedure Call: Protocolo que um programa pode utilizar para requisitar um servico a outroprograma localizado remotamente, sem que seja necessario o conhecimento de detalhes da rede.


e descrito a implementacao do mecanismo. O capıtulo 7 conclui este trabalho e apresenta

proposta de trabalhos futuros dentro do tema de Sistemas Distribuıdos Orientados a Objetos.

5

Capıtulo 2

Mecanismos de Mobilidade

2.1 Introducao

O mecanismo de mobilidade de objetos e algo poderoso, porem ainda pouco explorado nos

SCDOO (Sistemas Computacionais Distribuıdos Orientados a Objeto). O movimento que

um objeto faz de um nodo para outro pode ser motivado por alguma requisicao externa ou

por ele mesmo. Existem muitas implicacoes nesta acao, pois a total integridade e funciona-

lidade do objeto devem ser mantidas no novo local, incluindo o estado de suas atividades

no momento da movimentacao, as referencias a outros objetos, processos e demais recur-

sos que ele esteja usando. O inverso tambem e verdadeiro, pois todos os demais objetos

devem atualizar suas referencias para o novo local onde se encontra o objeto deslocado de

forma automatica e em nenhum momento do processo comprometer o sistema. Existem

diversas vantagens conseguidas atraves da mobilidade dos objetos como o controle de bal-

anceamento de carga, centralizacao de objetos com atividades com grande interacao entre

si, aumento da disponibilidade e outras que serao explicadas no topico seguinte. Dentre

todos os SCDOO definimos tres para um estudo mais aprofundado, sao eles o Distributed

Oz, Emerald e CORBA. O criterio usado para a selecao do Distributed Oz e Emerald foi que

estes sistemas, de forma semelhante a Virtuosi, nao implementam a distribuicao adicionando

uma camada sobre uma linguagem centralizada existente, o que ocorre em outros sistemas

como DCE [Tanenbaum, 1994],Java [Arnold and Gosling, 1996] e Erlang [Wikstrom, 1994]

[Haridi et al., 1997]. Embora CORBA implemente a distribuicao pela adicao de uma cama-

da sobre uma linguagem centralizada, o estudo da especificacao sobre agentes moveis trouxe

contribuicoes para elaboracao dos passos necessarios a serem seguidos por um mecanimos de

mobilidade.

Capıtulo 2. Mecanismos de Mobilidade 6

2.2 Motivacao para a Movimentacao

A motivacao para a mobilidade de objetos vem das vantagens que ela traz aos SCDOO. A

mobilidade e um mecanismo indispensavel para a solucao de varias situacoes encontradas

em ambientes distribuıdos como as citadas abaixo:

Balanceamento de carga: Nodos sobrecarregados podem ser desafogados pela mobilidade

de objetos com atividades para outros nodos mais ociosos.

Desempenho de comunicacao: Objetos que possuam grande interatividade de comuni-

cacao entre si podem ser dispostos em um mesmo nodo, reduzindo assim o tempo

gasto com a utilizacao da rede. O mesmo acontece com interatividade entre objetos

com arquivos, perifericos ou interfaces com outros aplicativos.

Disponibilidade: Objetos podem ser deslocados para nodos mais estaveis aumentando a

eficiencia de cobertura a falhas do sistema.

Utilizacao de capacidades especiais: Determinado objeto pode precisar de algum su-

porte especial existente somente em algum nodo. Por exemplo, efetuar suporte a

operacoes que exijam um ambiente seguro, ou privilegios de execucao para processa-

mento em tempo real, ou em redes heterogeneas algum servico especıfico prestado por

uma plataforma.

Movimentacao de dados: Encapsulando arquivos ou informacoes dentro de objetos, te-

mos uma maneira facil de movimentar estes dados sem a necessidade de tratar sepa-

radamente como uma transferencia de arquivo ou como um envio de mensagem.

Coletor de lixo: Mobilidade de objetos simplificam o trabalho do Coletor de Lixo por

mover os objetos para locais onde estes sejam referenciados [Hewitt, 1980] [Vestal, 1987].

Os casos citados acima justificam a motivacao para que haja mecanismos de mobilidade

de objetos para Sistemas Computacionais Distribuıdos.

2.3 Requisitos de um Mecanismo de Mobilidade

De toda a bibliografia estudada nao foram encontrados requisitos especıficos para um meca-

nismo de mobilidade. Logo, teve-se que aumentar a abrangencia partindo para os Sistemas


Distribuıdos. Primeiramente fez-se um estudo sobre os requisitos dos sistemas distribuıdos e

adotou-se a abordagem do Distributed Oz que preve quatro requisitos [Haridi et al., 1997]:

Transparencia de Rede: significa que os processos computacionais no sistema devem se

comportar da mesma forma, independente da estrutura distribuıda em que se encon-

tram [Cardelli, 1995]. A semantica da linguagem e inalterada independente de como

a computacao esta distribuıda entre os nodos. A distincao entre referencias locais

ou remotas deve parecer indiferente para o programador. A concorrencia entre ativi-

dades deve ser suportada de forma que possa ser executada de forma distribuıda ou

centralizada em um unico nodo.

Controle sobre a Comunicacao de Rede: significa que os padroes de comunicacao pela

rede devem ser programaveis e previsıveis. Estes padroes devem estar disponıveis para

a programacao de modo a tornar possıvel o controle sobre o comportamento da rede.

Isto se traduz no poder da programacao em definir momento e local de onde deva ou

nao ocorrer a movimentacao.

Tolerancia a Latencia: significa que a eficiencia da computacao deve ser minimamente

afetada por atrasos acarretados pela rede. A utilizacao da rede deve ser feita de forma

eficiente e racional.

Linguagem Segura: significa que a linguagem garante a integridade das atividades e da-

dos, desde que haja comunicacao segura1. Language security tem como objetivo

garantir ao programador meios para restringir o acesso a dados atraves do escopo

lexico da linguagem, ou seja, acessar dados somente onde exista uma referencia ex-

plıcita determinada por uma estrutura da linguagem.

Existem outros requisitos que poderiam ser avaliados, tais como: locatlizacao de recursos,

suporte para multiplas camadas, implementacao segura e tolerancia a falhas. Porem fogem

do escopo que o mecanismo da Virtuosi vai atender em primeira instancia. Alem disso mesmo

sendo a seguranca um requisito basico nao sera contemplado neste trabalho.

Seguinte ao estudo, identificamos os pontos onde o mecanismo de mobilidade pode con-

tribuir para os requisitos dos SCDOO. Entao definimos os seguintes requisitos de um meca-

nismo de mobilidade.

1Entende-se por comunicacao segura a protecao da integridade computacional contra possıveis intrusosque tenham acesso a implementacao do sistema [Roy et al., 1997]


Integridade: e a garantia da integridade dos dados, das atividades e referencias de tudo

que faz parte ou e afetado na mobilidade. Todas as atualizacoes executadas sobre

as referencias devem ser precisas. A movimentacao de dados deve ser segura e as

atividades preservarem a semantica e ordem processual.

Desempenho: o mecanismo deve ser otimizado e ter desempenho compatıvel com as ex-

pectativas. A eliminacao de redundancias e o uso criterioso da rede sao essencias para

o seu atingimento.

Confiabilidade: o protocolo de comunicacao deve tratar possıveis falhas do ambiente. Deve

ser preemptivo quanto a ocorrencias de indisponibilidade da rede.

Funcionalidade: o mecanismo deve dispor de controles que auxiliem na programacao do

comportamento da rede. Estes controles usualmente sao disponibilizados atraves de

primitvas.

A Transparencia da Rede so e possıvel se houver um ambiente que resolva todas as

questoes de distribuicao. Objetos locais ou remotos devem ser indiferentes a vista do pro-

gramador. Este ambiente dinamico e complexo so e possıvel se a integridade durante a

movimentacao dos objetos for garantida.

Para termos a Controle sobre a Comunicacao e necessario que haja confiabilidade, o que

somente e possıvel pela garantia de atomicidade do movimento. Outra relacao da Network

Awareness e com a funcionalidade, pois esta implica diretamente na facilidade de controle

sobre o comportamento da rede.

Tolerancia a Latencia esta relacionado diretamente aos requisitos de Desempenho e Fun-

cionalidade. Mecanismos de mobilidade otimizados auxiliam diretamente na reducao de

atrasos ocasionados pela rede contribuindo para o desempenho geral do sistema. Outra for-

ma de incrementar o desempenho e permitir ao programador, atraves de funcionalidades de

controle, interferir no comportamento da distribuicao.

O requisito de Linguagem Segura e suportado pela garantia de Integridade. A integridade

das atividades e dos dados so e possıvel se preservada a integridade dos mesmos durante sua

movimentacao.

Outras relacoes podem ser descritas, porem entendemos serem estas as mais importantes

ao nosso trabalho. Nosso objetivo com isso e que estes requisitos nos auxiliem a avaliar os


mecanismos existentes e nos sirva como guia em nosso trabalho com a Virtuosi.


2.4 Emerald

Emerald e uma linguagem baseada em objetos e um sistema projetado para a construcao de

sistemas distribuıdos [Amaral et al., 1992]. O Emerald nao tem por objetivo ser utilizado

em grandes redes, ele e concebido para ser utilizado em redes mais modestas, com nao mais

de cem nodos e com um ambiente homogeneo. Suporta fine-grainned mobility, ou seja,

tem como unidade de migracao estruturas que podem ser muito pequenas e assim estarem

muito mais dispersas. Possui uma operacao eficiente com referencias locais conseguidas

atraves das multiplas implementacoes de seus objetos. Embora seus objetos possuam diversas

implementacoes, estas se tornam invisıveis ao programador. A definicao semantica de objeto

e unica para qualquer implementacao do objeto independente se e local, objetos ativos ou

somente com atributos, moveis ou distribuıdos. O compilador e quem decide qual mecanismo

que o objeto deve adotar.

2.4.1 Estruturas da Linguagem

No Emerald, nao existem outras estruturas da linguagem que nao o objeto. Todo objeto no

Emerald possui quatro componentes: um nome global unico no contexto do sistema, atrib-

utos, metodos, e um processo opcional. Somente objetos que possuem processo sao ativos.

Os demais sao considerados meras estruturas de dados e de codigo. Emerald nao possui

hierarquia de classes. Objetos nao pertencem a uma classe conceitualmente, cada objeto

carrega seu proprio codigo. Porem, internamente objetos em um mesmo nodo compartil-

ham codigo. Este codigo e armazenado no que denomina-se de concrete type object. Estes

tipos concretos sao imutaveis, logo podem ser copiados livremente pelos nodos. Quando um

objeto e movimentado para um outro nodo seus dados sao enviados sem seu concrete type

object. Se existe um processo ativo para este objeto, a parte da pilha de execucao onde se

encontra o processo do objeto e enviada juntamente. Ao receber o objeto, o nodo verifica se

precisa ou nao do concrete type object, se precisar utiliza um algoritmo de procura que vai

localizar o tipo necessario nos demais nodos do sistema, fara uma copia dele, e o carregara

dinamicamente.


2.4.2 Primitivas

A mobilidade do objeto no Emerald e determinada pelo uso de quatro primitivas:

locate obj primitiva que retorna o nodo onde se encontra o objeto obj.

move obj to N move o objeto obj para o nodo N.

fix obj at N Fixa o objeto obj no nodo N.

unfix obj Torna movel o objeto obj.

refix obj Executa o Unfix, Move e o Fix para o objeto obj.

As primitivas fix e unfix determinam se o objeto pode ser movido ou nao. Depois de

fixado somente o unfix lhe devolve a mobilidade. A primitiva locate e encapsulada em

um objeto nodo, que e uma abstracao de uma maquina fısica. Esta primitiva e utilizada

para localizar o nodo onde se encontra o objeto. A primitiva move nao necessariamente

e executada, sendo somente uma sugestao. Caso o move seja encontrado na programacao,

o kernel nao obrigatoriamente a executa, e se executa, o objeto nao necessariamente vai

permanecer no nodo destino. Emerald tambem possui um mecanismo de agrupar objetos.

Isto e muito util para evitar a separacao de um objeto que tem grande interacao dentro de

um grupo. Caso nao seja evitada esta separacao, o custo de mante-lo longe dos demais seria

muito alto pela utilizacao de um grande numero de chamadas remotas.

2.4.3 Parametros

A passagem de parametros no Emerald e sempre por referencia (call-by-reference) inde-

pendentemente se local ou remota. Como os objetos sao moveis, nas chamadas remotas e

possıvel obter ganhos de desempenho movendo o objeto referenciado no parametro para o

nodo de onde ocorre a invocacao. A movimentacao do objeto e primeiramente determinada

em tempo de compilacao atraves dos criterios de otimizacao do compilador. Porem existe

a possibilidade de o programador determinar se objeto deve ser migrado baseado em seu

conhecimento do sistema. Para isto o programador deve utilizar-se do modo de passagem

de parametro denominado call-by-move.


Exemplo:

operation Deliver

Var aMailbox: Mailbox

if ToList.Length=1 then

aMailbox <- Tolist.getelement[ToList.lowerbound]

aMailbox.Deliver [move self]

else

var i: integer <- ToList.lowerbound

loop

exit when i > ToLista.upperbound

aMailbox <- ToList.getelement[i]

aMailBox.Deliver [self]

i <- i + 1

end loop

end if

end Deliver

No exemplo acima a operacao Deliver entrega as mensagens de todas as aMailboxes da

lista Tolist. No entando, o caso mais comum e onde existe somente um destinatario, entao

call − by −move e utilizado para movimentar a aMailbox para o local destino. Se houver

mais que um destinatario, somente a referencia e passada. Nao necessariamente o objeto

movimentado no parametro permanecera no nodo destino.

2.4.4 Tipos de objetos

Embora para a visao do programador exista somente uma definicao de objeto, internamente

isto nao se reflete. Baseado no conhecimento do comportamento do objeto que pode ser

deduzido durante a compilacao, Emerald pode gerar tres tipos de implementacoes para os

objetos:

Global: este objeto pode ser referenciado por qualquer outro objeto no sistema. Nao ne-

cessariamente o objeto que vai referencia-lo precisa conhece-lo durante a compilacao.


data

| G | R

tag | G | R

data

Object Data Area

address

address

tag | G | R

data

Object Data AreaX:

Object Descriptor

data pointer

Y:

Z:

tag

Figura 2.1 Tipos de enderecamento no Emerald

Local: sempre estara contido em outro objeto. Nunca podera ser movimentado indepen-

dente do objeto que o contenha.

Direct: e um objeto local o qual tem sua representacao de dados diretamente contida junto

a representacao de dados do objeto que o contenha. Este estilo de objeto e usado

principalmente para tipos primitivos como, por exemplo, o Integer.

Cada um destes objetos possui um tipo de enderecamento diferente como mostra a figura

2.1. A variavel X e o nome de um objeto global, e o conteudo de X e o endereco de um local

object descriptor. Cada nodo contem um object descriptor para cada objeto global para o

qual os objetos residentes neste nodo tem referencias.

As informacoes sobre o estado do objeto e a localizacao sao armazenadas no object

descriptor. O campo preenchido com a letra G indica se o objeto e Global ou Local. Se o

bit estiver com 1 e global senao local. O campo representado por R informa se o objeto e

residente naquele nodo ou nao. Se for o residente o object descriptor contem o endereco da

area de dados do objeto, senao tera um endereco de outro object descriptor que possivelmente

o tenha.

A variavel Y representa o nome de um objeto local, no conteudo desta variavel esta o

endereco da area de dados do objeto. Neste caso o, campo G que esta junto a area de dados

deve estar preenchido com 0 e o campo R com 1, pois objetos locais sao sempre residentes. A

variavel Z e uma variavel direct. Para este tipo de variavel a area de dados esta representada


diretamente no seu conteudo.

A localizacao de objetos no Emerald e baseada no conceito de fowarding addresses

[Fowler, 1985]. Existe um OID (Object Identifier) para cada objeto global do sistema. Cada

nodo possui uma tabela de acesso que mapeia o OID para o seu object descriptor correspon-

dente. Em cada tabela de acesso existe uma entrada para cada objeto local o qual exista uma

referencia remota para ele, e para cada objeto remoto o qual exista uma referencia local para

ele. Sempre que o object descriptor nao for residente, o endereco o qual ele apontara sera

um forwarding address. Este tipo de enderecamento e composto por um campo timestamp

e o nodo, onde o nodo e a ultima localizacao conhecida do objeto e o timestamp determina

a idade da localizacao. O forwarding address mais o OID sao suficientes para encontrar o

objeto.

2.4.5 Estrutura do Objeto

A estrutura do objeto no Emerald, como ja dito anteriormente, e composta pela area de

dados e o concrete type object. Toda a area de dados de um objeto contem um control

information, onde estao as informacoes sobre o tipo de implementacao do objeto e a loca-

lizacao, um ponteiro para o concrete type object e uma area a ser estruturada conforme um

template que esta contido no concrete type object. A Figura 2.2 mostra um exemplo de um

objeto com um monitor, um atributo de um tipo primitivo integer de quatro bytes e duas

referencias para objetos, uma para si mesmo e outra para uma string.

Exemplo:

const simpleobject == object simpleobject

monitor

var myself: Any <- simpleobject

var name: String <- "Emerald"

var i: Integer <- 17

operation GetMyName -> [n: String]

n <- name

end GetMyname

end monitor


Template{Control

Information

Data Area

Concrete Type

tag | G | R

code pointer

monitor queue

monitor lock

address

17

address

Operaton code

Object Descriptor for simpleobject

¨Emerald¨

1

4

2Pointer

Data

Monitor

Figura 2.2 Representacao de um objeto do Emerald em memoria.

object A

objetct C

object Dactivation record

object Bactivation record

activation recordobjetct C

Stack BaseProcess A

object B

Figura 2.3 Representacao de uma pilha de execucao.

end simpleobject

2.4.6 Processos

Cada processo em Emerald e implementado como uma thread. Somente objetos com um

processo podem iniciar um nova pilha de execucao. Um processo pode conter varias operacoes

de diversos objetos. Cada pilha de execucao pode ser representada com um conjunto de

activation records como demonstrado na Figura 2.3. O objeto A incia o processo e empilha

as operacoes de outros dois objetos B e C.

Em Emerald quando uma invocacao remota ocorre, o novo activation record e movido

para o local da execucao, e torna-se a base de uma nova pilha de execucao. Assim a pilha


activation recordobject B

activation recordobject B

object A

activation recordobjetct C

Stack Segment 3Process A

objetct C

Process AStack Segment 1

Nodo ANodo A

Process AStack Base

object A

Figura 2.4 Representacao distribuıda de um processo atraves de suas pilhas de execucao.

de execucao pode ser distribuıda entre os nodos.

Na figura 2.3 existe o caso onde o objeto B, que possui um activation record no meio

da pilha de execucao, e movido para outro nodo. Neste caso a pilha e particionada em tres

segmentos. A base e o activation record de A permanecem imoveis. Ja o objeto B leva

consigo seu activation record e forma a base de uma nova pilha do processo A em seu nodo

destino. O activation record de C forma localmente um nova pilha de execucao onde ele

proprio e a base (ver Figura 2.4).

2.4.7 Movendo Objetos

Para mover um objeto, Emerald envia uma mensagem ao nodo destino contendo toda a area

de dados do objeto e mais algumas informacoes que auxiliam o nodo destino a reorganizar as

referencias do objeto. Para ponteiros de objetos globais sao enviados o OID, o forwarding

address e o endereco do object descriptor. Para objetos locais, envia-se, junto a area de

dados, o seu endereco. Assim que o nodo destino recebe toda a informacao, o kernel aloca

espaco para o objeto, copia a area de dados e cria uma tabela de traducao que mapeia os

enderecos originais para enderecos do novo espaco alocado. OIDs sao utilizados para localizar


os object descriptors para objetos globais ja referenciados pelo nodo, ou para criar novos

object descriptors onde necessarios. Finalmente o kernel identifica o template dentro do

concrete type object correspondente ao objeto e identifica a estrutura da area de dados. Com

esta informacao pode-se atualizar os ponteiros do objeto com os ponteiros correspondentes

da tabela de traducao.

2.4.8 Movendo Atividades

Quando um objeto e movimentado, carrega consigo seus activation records, quebrando a

pilha de execucao em dois ou mais segmentos como demonstrado no subtopico sobre proces-

sos. Para isso e necessario criar uma lista de todas as atividades do objeto e atualiza-la em

toda a invocacao que iniciar ou finalizar, ou varrer as pilhas de execucao atras das atividades

do objeto em questao. O Emerald utiliza em parte as duas abordagens, porem de forma mais

otimizada. Existe uma lista das activation records em execucao em cada objeto. Porem na

invocacao o activation record nao esta ligado a esta estrutura. Ao inves disto, um espaco e

deixado para a ligacao e marcado como not linked, esta e uma operacao sem custo relevante.

Quando algum processo de movimentacao no Emerald e iniciado, a pilha e varrida a procura

somente dos not linked activation records. Estes sao entao ligados com os descritores dos

seus respectivos objetos. Se uma operacao que possui uma ligacao for concluıda, ela deve

se desvincular da lista de activation records em execucao do objeto referido. Os acivation

records sao movimentados de maneira similar as areas de dados do objeto.

Um problema adicional ao se mover activations recods e o gerenciamento dos regis-

tradores do processador. O compilador do Emerald otimiza o enderecamento de objetos

armazenando variaveis locais em registros ao inves de activation records. Isto causa de-

pendencia da arquitetura do computador. Para solucionar este problema o kernel envia

uma copia dos registradores usados em uma invocacao junto com o activation record movi-

mentado. Utilizando informacoes do seu tipo concreto e possıvel determinar o mapeamento

dos registradores e envia-los com a correta semantica [Jul et al., 1988].


2.5 Distributed Oz

Distributed Oz e um sistema de programacao distribuıdo que preserva o uso de uma semantica

de linguagem centralizada. O conceito de rede e abstraıdo do programador. Chamadas a

operacoes de rede podem ser executadas implicitamente pelo sistema com o uso de algum

construtor da linguagem de forma invisıvel ao programador. Porem o programador tem o

poder de controlar o fluxo da distribuicao, pelo fato de que operacoes de rede usualmente

tem um custo elevado [Haridi et al., 1997]. Diferentemente do Emerald, Oz nao deixa uma

trilha por onde os objetos passam (forwarding address). O comportamento da rede e melhor

previsıvel, pois a comunicacao segue diretamente para o endereco correto, sem a necessidade

de passar por varios nodos ate encontrar o objetivo [Roy et al., 1997].

2.5.1 Definicao de Termos

Para um melhor entendimento conceitual e para sermos fiel aos nomes definidos dentro do

universo de Distributed Oz, segue a definicao de alguns termos utilizados:

Language Entity : Ou somente entidade: E um item de dados basico da linguagem, como

um objeto, uma procedimento, uma thread ou um registro [Roy et al., 1997].

Statefull Entity : E uma entidade que pode ser alterada durante seu ciclo de vida. Em

um determinado momento uma entidade statefull esta localizada em um particular

nodo, chamado home site [Roy et al., 1997].

Stateless Entity : E uma entidade que nao pode ser alterada durante seu ciclo de vida.

Mobily Control : E a habilidade das entidades statefull de migrarem entre os nodos ou de

permanecerem estacionarias de acordo com a intencao do programador [HU et al., 2003].

2.5.2 Linguagem

A linguagem Distributed Oz e dinamicamente escrita, ou seja, seus tipos de estruturas sao

verificados em tempo de execucao [Roy et al., 1997]. A linguagem compreendida pelo kernel,


a qual o Distributed Oz e traduzido, e denominada OPM (Oz Programming Model). OPM e

um modelo de programacao concorrente o qual permite sincronizacao, orientacao a objetos,

e faz uma clara distincao entre referencias para entidades statefull e stateless.

2.5.3 Estruturas da Linguagem

Distributed Oz define uma semantica distribuıda para todas as entidades, significando que

cada operacao de cada entidade tem uma clara definicao de seu comportamento na rede.

As entities basicas compreendidas pelo OPM sao valores, variaveis logicas, procedimentos,

cells e threads. Um valor nunca e alterado e e o mais primitivo dos dados. Todas as

variaveis sao variaveis logicas (stateless), cujos conteudos nao podem ser alterados. Quando

sao necessarias variaveis que mudam o seu conteudo (statefull) utilizam-se cells. Threads

e cells sao as unicas entidade statefull. Para uma clara compreensao destas entidades e

necessario contextualiza-las dentro da linguagem, como faremos a seguir ao descrevermos

as sentencas do OPM. Um programa escrito em OPM consiste em uma composicao de sen-

tencas contendo descricao de valores, declaracao de variaveis, definicao de procedimentos e

chamadas, declaracao de estado e alteracao, condicionais, declaracao de threads, e trata-

mento de excecao.

Descricao de valores: Os valores sao empregados atraves de registros, numeros, literais

(nomes e atomos), e closures. Exceto por nomes e closures, os demais valores sao

definidos de forma usual. Closure e uma parte do procedimento e somente pode ser

referenciada atraves do nome do procedimento. Os outros valores podem ser direta-

mente escritos ou referenciados por variaveis [Roy et al., 1997]:

Exemplo:

local V W X Y Z H T in

V = queue(head:H tail:T) %Registro

W = H|T %Registro (representando uma lista)

X = 4324 %Numero

Y = foo %Literal (atom)

{NewName Z} %Literal (nome)

end


A chamada { NewName Z} cria um novo nome que e unico para todo o sistema. Nomes

sao utilizados para representar cells, procedimentos e threads.

Declaracao de variaveis: Todas as variaveis sao variaveis logicas. Elas precisam ser de-

claradas dentro de um escopo explıcito situado entre um local e um end. Toda variavel

inicia sem o conhecimento de seu valor. Somente apos uma operacao de atribuicao de

valor, a variavel passa a conhece-lo. Por exemplo, a operacao de atribuicao X = Y,

onde e atribuıdo o valor de Y para X. A sincronizacao entre threads pode ser executada

atraves de variaveis, desde de que qualquer tentativa de utilizar uma variavel a qual

ainda nao conheca seu valor ira paralisar as threads ate que este valor seja conhecido.

Exemplo:

local X in %Declarac~ao de X

thread {Consumer X} end % Cria a thread que utiliza X

{Producer X} % Calcula o valor de X

end

No codigo acima, a chamada do procedimento Consumer tendo como parametro X,

utiliza-se da variavel X como base de calculo para outras operacoes internas, porem

nao executa a operacao de atribuicao sobre ela. Ja a Producer efetua atribuicao sobre

X. Neste caso a thread de Consumer ira iniciar, porem no primeiro instante em que

fizer uso de X ficara bloqueada ate que Producer faca a atribuicao de um valor a X.

Neste exemplo ja demonstramos como e a sintaxe de criacao de threads.

Definicao de procedimento: A definicao e chamada de procedimentos se dao conforme o

exemplo abaixo:

Exemplo:

local

MakeAdder Add3 X Y

in

proc {MakeAdder N AddN} %Definic~ao da procedimento


proc {AddN X Y} Y=X+N end

end

{MakeAdder 3 Add3} %Chamada da procedimento

{ Add3 10 X} %X adquire o valor 13

{ Add3 1 Y} %Y adquire o valor 3

end

Executando a chamada {MakeAdder 3 Add3} define Add3 como um procedimento que

adiciona 3 ao seu primeiro parametro. A execucao da definicao do procedimento cria

um nome e um closure. Um closure e um valor que contem o codigo do procedimento

e suas referencias externas.

Declaracao de estado e atualizacao: Variaveis sempre se referem a valores que nao mu-

dam. Quando e necessaria a criacao de um dado statefull, e necessario faze-lo de

forma distinta atraves da criacao de uma cell. Uma cell e criada a partir da chamada

{NewCell X C} onde C e o nome da cell e X seu valor inicial. Existem outras duas

operacoes executadas sobre as cells: {Exchange C X Y} atualiza C com o conteudo de

Y e atribui a X o conteudo antigo de C, {Accesss C X} atualiza C com o conteudo de

X.

Exemplo:

local C X1 X2 X3

in

{NewCell bing C}

% Cria C com conteudo bing

{Exchange C X1 bang}

%bing e atribuıdo a X1 e bang atribuıdo a C

{Exchange C X2 bong (me:C was:X2) }

%bang e atribuıdo a X2 e bong(me:C was:X2) e atribuıdo a C

{Access C X3}

%bong(me:C was:X2) a atribuıdo a X3

end


Condicionais: Sao descritas em OPM como testes sobre valores de estruturas de dados,

conforme o exemplo:

Exemplo:

local X in

thread

if X=yes then Z=no else Z=yes end

end

X = no

end

Declaracao de Threads: cada thread executa seu codigo sequencialmente. A thread sera

bloqueada se algum valor que ela precise nao estiver disponıvel, e continuara seu pro-

cessamento assim que obte-lo. A concorrencia e introduzida explicitamente pela criacao

de uma nova thread:

Exemplo:

local Loop in

proc {Loop N} % Define aprocedimento

{Loop N+1}

end

thread %Define a thread

{Loop 0}

end

end


Cada thread e identificada por um nome unico que e obtido pela chamada {GetThreadIDT}dentro da propria thread. Cells e threads sao as unicas entidade statefull em OPM. As

entidades portas e objetos, que descreveremos na sequencia, sao definidas em termos

de cells.

Tratamento de Excecao: E um tratamento especial do fluxo sequencial de controle das

threads. Este tratamento permite um desvio no processamento caso ocorra uma

operacao ilegal no codigo.

Exemplo:

proc {AlwaysCalcX CalcX A X}

try

local Z in

{CalcX A Z}

Z = X %Atribui X se n~ao ocorrer excec~ao

CalcX

end

catch E then

{FailFix A X}

end

end

Distributed Oz fornece duas entidades adicionais elaboradas a partir das entities do

OPM que facilitam ao programador implementar o conceito de orientacao a objeto, atraves

de objetos e assincronismo atraves de portas. Objetos sao definidos em termos de OPM

como procedimentos e cells. O procedimento referencia uma cell a qual armazena o estado

interno do objeto. Operacoes de leitura e alteracao sobre o estado do objeto sao executadas

atraves do Access e Exchange. Metodos sao representados por procedimentos.

Exemplo:

class Counter %Define a classe

attr val:0 %Atributo com valor inicial 0


meth inc ( ) %Declarac~ao de metodo

val := @val + 1

end

meth get(X) %Method com um argumento

X = @val

end

meth reset

val := 0

end

end

A classe Counter definida acima tem um unico atributo val que e iniciado com zero.

Possui tres metodos inc(), get(X), reset. Os parenteses sao opcionais quando nao se tem

parametro. Atribuicao de valor ocorre atraves da notacao := e o acesso pelo sımbolo @. A

instanciacao do objeto e a chamada de metodos ocorre conforme mostra o exemplo abaixo:

C = {New Lcounter} %Cria a instancia

{C inc} %Incrementa @val

{C get(X)} %Pega o valor de @val para X

Porta e um canal assıncrono que suporta ordenacao de comunicacao de N para um e de

N para N [Roy et al., 1997]. Uma porta consiste de uma procedimento send e uma lista.

Ao final desta lista sempre esta uma variavel logica. send e acionado assincronamente por

diversas threads. Nao ha garantia de ordem nas mensagens recebidas entre as threads,

porem respeita-se a ordem interna do envio de mensagens individual de cada thread. Se

determinada thread T1 enviou duas mensagens T1M1 e T1M2 respectivamente, e outra

thread T1 paralelamente a esta enviou mais duas mensagens T2M1 e T2M2 tambem nesta

ordem, e garantido somente que T1M1 preceda T1M2 e T2M1 preceda T2M2. Sendo assim

poderıamos ter sequencias como T2M1, T1M1, T2M2, T1M2 ou T2M1, T2M2, T1M1, T1M2

por exemplo. Sempre que uma nova mensagem e recebida na porta, atribui-se ao final da

lista uma nova entrada e uma variavel logica. Caso o valor da variavel logica ainda nao

seja conhecido, varias threads podem estar aguardando o preenchimento desta informacao.

Assim que a atribuicao seja executada o valor estara disponıvel para todas elas. Desde que


stateless

value

cell

object

port

thread

logic variable

procedure

Oz 2 entity

stationary

mobile

stateful

lazy

eager

unknow

know

Figura 2.5 Classificacao das entidades quanto a distribuicao.

a lista seja stateless podera ser suportado qualquer numero de acessos de consulta a ela de

forma rapida.

2.5.4 Comportamento Distribuıdo

Cada entidade tem um comportamento distribuıdo bem definido pela Distributed Oz. A

distribuicao semantica de cada entidade esta resumida na Figura 2.5. Todas as entidades

stateless sao replicadas, pois nunca mudam durante seu ciclo de vida. Isto e feito objetivan-

do incrementar o desempenho por reduzir o trafego da rede evitando Chamadas Remotas

de Procedimentos (CRP). A forma como ocorrera a replicacao destas entidades pode ser

determinada conforme o desejo do programador. Ele pode escolher entre replicacao lazy

ou eager. Caso nao seja determinado pelo programa, o sistema replica records, numeros e

literais de forma eager, e procedimentos de forma lazy. Procedimentos e closures possuem

uma identidade global no sistema, garantindo que nao havera mais que uma copia de cada

localmente. Esta identidade global e utilizada para que blocos de codigos sejam transmitidos

somente onde eles ainda nao existam. O mesmo tratamento nao acontece com os numeros,

literais e records.

As Variaveis Logicas referenciam valores que ainda nao sao conhecidos. Uma vez que

este valor nao possa ser alterado indefinidamente a variavel logica e considerada stateless.

Ha duas operacoes sobre variaveis logicas: a atribuicao de valor ou no aguardo por um


valor[Roy et al., 1997]. Atribuindo-se um valor a variavel de forma eager, este sera repas-

sado a todos os nodos onde exista uma referencia. Este protocolo de atribuicao e chamado

protocolo de eliminacao de variavel. Quando e atribuıdo um registro para a variavel logica,

este – o registro – e replicado de forma eager, quando atribui-se um procedimento, o nome

desta tambem e replicado de forma eager . O closure utiliza o protocolo lazy.

Todas as entidades statefull (cell, objeto, port e thread) sao caracterizadas por sempre

possuırem seu home site. O controle de mobilidade define o que ira acontecer no home site

a cada operacao sobre a entidade statefull. Uma entidade statefull pode ser referenciada

como movel ou estacionaria dependendo de seu state − updating [Roy et al., 1997]. Ficou

definido como padrao que os states− updating da cell e do objeto sao moveis e da porta e

thread sao estacionarios.

Cells: A cell e movel. Todos os nodos que conhecem o nome da cell podem acessa-la. A

invocacao de um Exchance causa um movimento sıncrono do conteudo da variavel para

o seu nodo. E a invocacao de um cell − access somente replica o valor da cell, sem

que o home site seja alterado. A cell somente pode ser atualizada em seu home site.

Objects: O objeto e movel, e sua distribuicao obedece o comportamento distribuıdo do

OPM que o compoe. Quando um metodo e acionado remotamente, os procedimentos

correspondentes ao objeto e ao metodo sao replicados. O metodo e entao executado

no site acionador. Quando o estado do objeto e alterado, todo ele e enviado para o

site requisitante. De forma que o home site do objeto e alterado para que se possa

efetuar localmente a alteracao.

Portas: A porta e estacionaria. O envio de mensagens vindas de qualquer site causam

a aparicao de uma nova entrada na lista da porta. A operacao de send (envio de

mensagem) e definida como assıncrona e ordenada.

Threads Threads sao estacionarias. A computacao das atividades de uma thread e execu-

tada localmente em seu home site. A thread nunca muda de local desde sua criacao.

Comandos vindos de outros sites que nao o home site sao enviados sincronamente e

ordenados como um RPC.

Com as definicoes do comportamento distribuıdo de cada entidade pode-se prever o com-

portamento do sistema distribuıdo como um todo.


Thread (com referências)

Ponteiro para Estado (Cell) Record (com campos)

Variável

Procedure (com referências externas)

Lógica

Figura 2.6 Representacao grafica das entities.

2.5.5 Grafico de Linguagem e Distribuicao

Para facilitar o entendimento, demonstraremos as entidades do OPM atraves do grafico de

linguagem. Cada entidade do OPM e representada por um nodo, exceto as entidades com-

postas (portas e objetos) como mostrado na Figura 2.6. Cada nodo pode ser considerado

como uma entidade ativa com um estado interno, que tem o poder de enviar mensagens

assincronamente para outros nodos. Objetos sao entidades compostas e como tais sao repre-

sentadas com um conjunto de nomes.

Para representarmos o ambiente distribuıdo e necessario introduzir o conceito de site.

Os nodos sao dispostos em um conjunto finito de sites com referencias entre eles. Um

nodo referenciado por outro nodo em um site diferente do seu, necessariamente possui uma

estrutura de mapeamento para esta referencia. No exemplo da Figura 2.7, demosntra-se este

mapeamento. O nodo N2 e referenciado por outro dois nodos remotamente, N1 e N3 (Grafico

de Linguagem). No Grafico de Distribuicao e possıvel visualizar as estruras de referencias de

acesso criadas. No caso do exemplo citado, teremos para N2 o access struct {P1,P2,P3,M}.Definimos com access struct as entidades necessarias para este mapeamento. Para tanto

teremos um nodo proxy Pi para cada diferente site e um nodo manager M para toda a

estrutura. O grafico onde se demonstra o access struct e denominado Grafico de Distribuicao

[Roy et al., 1997] .

2.5.6 Mecanismo de Migracao

No grafico distribuıdo, o objeto e mostrado como uma entidade composta, formada a partir de

um registro de objeto, um registro de classe contendo procedimentos (metodos), um ponteiro


Gráfico de Linguagem

Sitio 2 Sitio 3Sitio 1Sitio 2Sitio 1 Sitio 3

P1 P2 P3

M

N1 N3

estrutura de acesso para N2

N3N2N1

Gráfico de Distribuição

Figura 2.7 Grafico de linguagem versus grafico de distribuicao.

A

endA={New Account trans(100)}

attr bal:0

meth getBal(B)

end

meth trans (Amt)bal<− @bal + Amt

B = @bal

e identificadordo objeto

Registro da Classe

100

Ponteiro deEstado

trans getBal

Classe

do EstadoRegistro

Nome

estado

bal

Registro do Objeto

pecl id

class Account

Figura 2.8 Visualizacao de um objeto com um atributo e dois metodos.

para estado e um registro para o estado do objeto. O comportamento do objeto e derivado

do comportamento de suas partes. Na Figura 2.8 e mostrada uma classe A contendo um

atributo bal e dois metodos trans e getBal. O campo pe contem o ponteiro para o ponteiro

do estado do objeto. O ponteiro de estado define o site em que operacoes de atualizacao

podem ser feitas sem operacoes de rede. O campo cl contem o registro da classe, onde estao

as procedimentos trans e getBal. O campo id contem o identificador unico do objeto Nome

[Roy et al., 1999].

Na Figura 2.9 um objeto A esta no site 1. Nao existe qualquer referencia remota a ele.

Em seguida na figura 2.10 ja existe um access struct formado por {Pa2, Ma}. O objeto A

agora e um objeto Global. Quando uma mensagem referenciando o objeto A deixa o site

1, um nodo de gerenciamento e criado, e quando a mensagem chega ao site 2 e criado um

nodo proxy Pa2 para o objeto.

Digamos que exista uma thread T referenciando o ponteiro Pa2, e que T executara uma

operacao de atualizacao sobre o estado do objeto A. Como descrito no topico anterior,


Classeponteirode estado

Site 1 Site 2

A

Estado 1

Figura 2.9 Objeto local - sem referencias remotas.

Ma

ponteirode estado

Site 1 Site 2

A

Estado 1

Classe

Pa2

Figura 2.10 Objeto global com uma referencia remota.

a thread e estacionaria e o objeto movel. Como todas as atualizacoes sao sempre feitas

localmente e necessaria a transferencia de A para o site 2. Para isto, o proxy Pa2 solicita

ao nodo de gerenciamento Ma uma copia do registro do objeto. A classe deve ser copiada

de imediato. O registro da classe e um ponteiro proxy para o estado e enviado para o site 2

(veja Figura 2.11).

Classeponteirode estado

Site 1 Site 2

A

Estado 1

Classe

Pa2MaMc Thread T

Pc

Figura 2.11 Invocacao remota sobre o objeto (1).


A

pe1

Site 1 Site 2

Estado 1

Classe

Thread T

Classe

A

pe2

Mc


Estado 2

pe1

Site 1 Site 2

Estado 1

Classe

Thread T

Classe

A

pe2

Mc

A


Com a chegada da mensagem, um segundo proxy pe2 e criado. A classe e copiada para

o site 2 e o proxy Pa2 torna-se o registro do objeto A. Entao o protocolo de mobilidade de

estado, que veremos na sequencia, transfere o ponteiro de estado para o site 2. O registro

do objeto tem um nome global. Isto implica que todas as mensagem direcionadas para A no

site 1, devem ser enviadas diretamente para o site 2.

A Figura 2.13 mostra a conclusao da operacao. O novo estado permanece no site 2. O

ponteiro de estado do site 1 e redirecionado para o Mc (nodo gerente).

Caso haja a invocacao de um metodo no site 1 que atualiza o estado do objeto A, o

ponteiro de estado e transferido novamente para o site 1. O novo estado 3 e criado no site

1. O estado antigo do objeto (estado 2) permanecera no site 2, mas o ponteiro Pc2 ja nao

apontara mais para ele (ver Figura 2.14) [Roy et al., 1999].

Temos algumas observacoes importantes a fazer sobre este mecanismo.

• O metodo do objeto e sempre executado localmente.


Estado 2

pe1

Sit 1 Site 2

Estado 3

Classe

Thread T

Classe

A

pe2

Mc

A

Figura 2.14 Visualizacao de um objeto com um atributo e dois metodos.

• A classe e enviada somente uma vez.

• Nas demais movimentacoes somente o ponteiro de estado e movimentado reduzindo o

custo da mobilidade.

• Todas as requisicoes sao direcionadas para o nodo gerenciador do ponteiro de estado.

Isto simplifica o protocolo mas cria a dependencia do site do nodo gerenciador.

• E possıvel tornar um objeto estacionario, atraves do encapsulamente do objeto por

uma porta, porem tornar o objeto estacionario implica na criacao de threads remotas,

sincronizacao entre diferentes sites, e passagens de excecoes entre estes. Conceitual-

mente e suficiente para sistemas distribuıdos termos threads moveis ou objetos moveis

[Roy et al., 1999].

O protocolo de mobilidade de estados deve garantir consistencia entre estados conse-

cutivos. Se estes estados estao em diferentes nodos, entao e necessaria uma transferencia

atomica do nodo gerenciador do ponteiro de estado entre os nodos. Quando um site solicita

o ponteiro de estado, este deve faze-lo para o gerenciador do ponteiro, e este envia uma

mensagem para o site que tem, ou tinha, o ponteiro para o estado. Consequentemente, o

gerenciador somente precisa armazenar o nome do site que eventualmente possui o ponteiro

de estado [Roy et al., 1997].

Na Figura 2.15 o ponteiro de estado pe1 e referenciado a partir de dois sites. Inicialmente

o estado esta localizado no site 1. A thread T executa localmente um metodo que atualizara

o estado do objeto. Neste momento T solicilita uma atualizacao no estado do objeto enviando

uma mensagem para pe2. A thread referencia o novo estado atraves da variavel Y. Quando

a atualizacao finalizar, T tambem referenciara o antigo estado atraves da variavel X. Como

o proxy pe2 nao possui o ponteiro de estado, ele deve solicita-lo ao seu nodo gerente.


T

pe1

Site 1 Site 2

Estado 1 Estado 2

Request

pe2

Mc

Y

X

Figura 2.15 Thread requisita a atualizacao do estado apontado por pe2.

(2) repassa

pe1

Site 1 Site 2

Estado 1 Estado 2

pe2

Mc

Y

X

T

(1) adquira

Figura 2.16 (1)Mensagem de aquisicao do estado. (b)Redirecionamento da mensagem de

aquisicao.

(2) continue

pe1

Site 1 Site 2

Estado 2

pe2

Mc

Y

X

T

Estado 1

Estado 1

(1) atribua

Figura 2.17 (1)Repasse do ponteiro de estado. (2) Mensagem para prosseguimento de transacao.


X

pe1

Site 1 Site 2

Estado 2

pe2

Mc

Y

T

Estado 1 Estado 1

Figura 2.18 Fim da movimentacao do estado do objeto para o site 2.

Na Figura 2.16(1) pe2 solicita o ponteiro de estado enviando um mensagem get para para

o gerenciador Mc, e (2) o gerenciador envia uma mensagem de forwarding para o proxy

que eventualmente vai ter o ponteiro de estado (pe1). O gerenciador pode aceitar outra

requisicao imediatamente, nao precisando esperar ate o ponteiro de estado ser transferido

completamente [Roy et al., 1999].

Na sequencia pe1 envia para pe2 uma mensagem put contendo o estado antigo, Estado 1

(Figura 2.17), e o pe2 envia para T uma mensagem proceed informando que a transferencia

esta completa. O estado antigo continua existindo no nodo para pe1. Mas pe1 nao mais o

referencia. A Figura 2.18 mostra a situacao final da transacao.

O protocolo descrito oferece um comportamento de rede previsıvel. Sao necessarios no

maximo tres pontos de rede para que o ponteiro de estado mude de site. Somente dois se o

gerenciador estiver no mesmo local que o estado e nenhum se o ponteiro de estado estiver

no mesmo site que o requisitante. A alteracao do estado do objeto e feita em uma ordem

consistente global.


2.6 CORBA

2.6.1 Introducao

CORBA (Common Object Resquest Broker Architecture) e uma arquitetura aberta para

computacao distribuıda orientada a objetos. E mantida e padronizada pela OMG2. CORBA

automatiza muitas atividades comuns na programacao em ambientes distribuıdos como reg-

istros de objetos, localizacao, parameter marshalling e RPC.

Nas especificacoes CORBA sobre Mobile Agent Facility(MAF) [OMG, 2000] e Life

Cycle Service [OMG, 2002] constam as definicoes sobre a mobilidade de objetos e agentes.

Desde de que um agente e em princıpio um objeto com atividades, focaremos no estudo da

mobilidade de agentes em CORBA por este ser mais complexo e interessante ao objetivo deste

trabalho. A especificacao MAF engloba os aspectos essencias que precisam ser padronizados

para que seja possıvel a operacionalizacao dos agentes:

Gerenciamento: Sistema administrador que, atraves de funcoes comuns, pode gerenciar

agentes de diferentes tipos.

Transferencia: O processo de mobilidade do agente.

Nomes: Atribuicao de nomes aos agentes.

Tipos: A identificacao do tipo do agente3, permite a verificacao se a plataforma do nodo

destino suporta o tipo a ser migrado.

Localizacao: A sintaxe da localizacao precisa ser comum para que seja compreendida por

todos os agentes.

Como o objetivo deste trabalho e a mobilidade de objetos, veremos somente os aspectos

que sao especıficos da transferencia de agentes moveis4, nao serao vistos os demais aspectos

como seguranca, autenticacao, escolha de protocolos de rede, sistema de regioes entre outros.

2Object Managment Group e um consorcio aberto sem fins lucrativos que produz e mantem especificacoespara a interoperabilidade de aplicacoes comerciais.

3Tipo do agente: E a identificacao do perfil do agente. Por exemplo um tipo Aglet, e implementado pelosistema de agente da IBM, implementa Java como linguagem e utiliza Java Object Serialization

4Um agente pode ser movel ou estacionario. Um agente movel e caracterizado pelo capacidade de mover


2.6.2 Transferencia

Quando um agente se transfere para outro sistema de agente5, inicia-se uma requisicao de

migracao. Junto a requisicao, o agente envia o nome e o endereco do destino. O agente

tambem especifica a qualidade do servico de comunicacao requerida para a transferencia do

agente. O MAF nao especifica como deve ser a comunicacao, deixando a criterio do sistema

implementador do agente.

Se o agente conseguir comunicar com o sistema de agente destino, este deve completar

a transferencia ou retornar um indicador de falha para o agente. Se o agente nao conseguir

comunicar com o sistema de agente destino, entao o indicador de falha deve ser retornado

ao sistema de agentes origem.

Se o sistema de agente destino concordar com a transferencia, as credenciais de seguranca,

o estado do agente, e se necessario o seu codigo sao transferidos. O sistema de agente destino

reativa o agente, e continua sua execucao. A Figura 2.19 mostra a relacao de encapsulamento

das estruturas da arquitetura CORBA e a conexao entre dois sistemas de agente.

Segue o detalhamento dos passos de inicializacao da transferencia, recepcao do agente e

transferencia de classes, necessarios a transferencia de um agente.

A inicializacao da transferencia ocorre pela identificacao do local do sistema de agente

destino. Se o local nao for especificado, o local default do sistema de agente destino sera

selecionado. Apos estabelecida a conexao, o agente solicita ao sistema de agente origem a

sua transferencia. Entao o sistema de agente executa as seguintes acoes:

(1) Suspende as atividades do agente.

(2) Identifica as partes do estado do agente que serao transferidas.

(3) Serializa a instancia da classe e do estado do agente

(4) Codifica o agente serializado conforme o protocolo de transporte.

a si proprio para outros locais. Um agente estacionario e executado somente no sistema em que foi criado.Utiliza basicamente servicos de comunicacao e transporte quando da necessidade de interacao remota comoutros agentes, servicos ou dados.

5sistema de agente: E uma plataforma que pode criar, interpretar, executar, transferir, e finalizar agentes.Um nodo pode conter um ou mais sistemas de agente


Sistema Operacional

Agente

Agente

Agente

Agente

Sistema de Agente

Rede

Local

Infraestrutura deComunicação

Sistema de Agente

Sistema Operacional

Local

Local

Infraestrutura deComunicação

Figura 2.19 Interconexao entre dois sistemas de agente.

(5) Autentica o cliente.

(6) Transfere o agente.

Antes da recepcao do agente pelo sistema de agente destino, este verifica se e possıvel in-

terpretar o agente recebido. Se a verificacao for positiva entao procede-se com as seguintes

acoes:

(1) Autentica o cliente.

(2) Decodifica o agente.

(3) Desserializa o estado e a classe do agente.

(4) Instancia o agente.

(5) Restaura o estado do agente.

(6) Da continuidade a execucao do agente.

A transferencia de classes e especıfica para agentes construıdos sobre a orientacao a

objetos – nao necessariamente os agentes em CORBA sao objetos – quando a classe nao


existe no sistema de agente destino. Existem quatro tipos possıveis de implementacoes para

a transferencia de classes:

Transferencia automatica de todas as classes: E o envio de todas as classes que o

agente ira precisar para sua criacao. Isto elimina a necessidade de solicitacoes posteri-

ores.

Transferencia automatica somente da classe do agente, outras classes sao envi-

adas conforme demanda: Somente a classe do agente e enviada, outras classes que

o agente precise sao requisitadas conforme demanda. Com isso a utilizacao da rede

e otimizada, uma vez que as classes que o agente usara no sistema de agente desti-

no podem existir localmente no destino eliminando o custo da transferencia. Porem,

se o sistema de agente destino posteriormente nao tiver acesso as classes necessarias,

ocorrera uma falha.

Transferencia da classe do agente e depois de todas das outras classes paralela-

mente a criacao do agente: Quando a criacao de um agente remota e ativada por

um cliente que nao esta conectado permanentemente, por exemplo um notebook ou

outro dispositivo portatil que nao permaneca conectado.

Transferencia de uma lista dos nomes das possıveis classes junto com requisicao

de transferencia: O sistema de agente origem envia uma lista das classes necessarias

para a criacao e a execucao de operacoes especıficas do agente. Entao o sistema de

agente destino solicita somente as classes que nao estao carregadas localmente. Esta

tecnica e eficiente, porem requer que o sistema de agente origem conheca as classes que

o agente utiliza.

2.6.3 Consideracoes

CORBA tem por objetivo definir padroes para interoperabilidade de sistemas distribuıdos

abertos. Nao e objetivo definir a implementacao dos sistemas que adotam a sua arquitetura.

Por esta razao nao encontraremos nas especificacoes de CORBA detalhes de mais baixo

nıvel sobre mecanismo de mobilidade de objetos. Estes detalhes podem ser encontrados na

descricao de implementacao dos sistemas que adotam a especificacao.


2.7 Aglet

2.7.1 Introducao

Aglets e uma solucao para a implementacao de agentes moveis desenvolvida sobre a platafor-

ma Java. Os Aglets tem o poder de encerrar sua execucao, movimentar-se de um nodo para

outro, e iniciar sua execucao novamente. Em sua movimentacao os Aglets levam consigo o

seu codigo e estado.

2.7.2 Implementacao

O Aglet Java estende o modelo de codigo de rede-movel conhecido pelos applets Java

[Venners, 1997]. Os arquivos de classe de um aglet podem migrar atraves da rede pelo

mesmo mecanismo que um applet. Mas diferentemente de um applet, quando um aglet mi-

gra ele tambem pode levar o seu estado. Um applet e codigo estatico que tem o poder de ser

movido pela rede de um servidor para um cliente. Um aglet e um programa Java em exe-

cucao que pode mover de um servidor para outro na rede mantendo seu estado interno antes

da movimentacao. Um aglet Java e similar a um applet na maneira que e executado, como

uma thread (ou multiplas threads) dentro do contexto de uma aplicacao Java. Para executar

applets, um navegador Web dispara uma aplicacao Java para abrigar quaisquer applets que

possam ser encontrados, como um usuario navega de pagina a pagina. Aquela aplicacao

instala um gerenciador de seguranca para reforcar restricoes nas atividades de quaisquer

applets nao confiaveis. Para baixar arquivos de classe applets, a aplicacao cria classes de

carregamento que ”sabem”como pedir arquivos de classes de um servidor HTTP. Da mesma

maneira, um aglet requer uma aplicacao Java servidor (um servidor aglet) para ser executado

no computador antes que ele possa visitar aquele computador. Quando aglets viajam atraves

de uma rede, eles migram de um servidor aglet para outro. Cada servidor aglet instala um

gerenciador de seguranca para reforcar restricoes nas atividades de aglets nao confiaveis. Os

servidores carregam aglets atraves de classes de carregamento que recuperam arquivos de

classes e o estado de um aglet de um servidor aglet remoto.


2.7.3 Ciclo de Vida

O ciclo de vida de um aglet pode ter varios eventos em sua vida, os quais podem ser:

Criar: Um aglet e criado pela inicializacao da execucao de uma thread e a criacao do seu

estado interno.

Copiar: Uma copia do aglets e criada.

Enviar: Um aglet viaja para um outro servidor.

Recuperar: Um aglet, previamente enviado, e trazido novamente para um servidor remoto.

Desativar: Um aglet tem suas atividades paralizadas. Seu estado e armazenado em algum

dispositivo de armazenamento, usualmente um arquivo.

Ativar: Um aglet desativado e trazido de volta para atividade.

Descartar/Eliminar: Um aglet e finalizado.

Cada atividade alem da criacao e eliminacao envolve tanto duplicacao, transmissao

atraves da rede, ou armazenagem persistente do estado do aglet. [Oshima et al., 1998] Cada

uma dessas atividades utiliza o mesmo processo de serializacao para obter o estado fora de

um aglet. Na figura 2.20 sao mostradas as fases do ciclo de vida de um aglet.

Dispositivo

Class

Aglet Aglet

Contexto ACopiar

Criar

Armazenador

Contexto BEnviar

Recuperar

Descartar/Eliminar

Desativar Ativar

Figura 2.20 Ciclo de Vida de um aglet


2.7.4 Serializacao

Os servidores aglets utilizam a serializacao de objetos, disponıvel em Java, para exportar o

estado de um objeto aglet para uma sequencia de bytes. Em um processo reverso, o estado

de um aglet pode ser reconstruıdo a partir desta sequencia. Serializacao permite que uma

imagem do heap (o estado de um heap) seja exportada para uma sequencia de bytes (tal

como um arquivo) e entao reconstruıda daquela sequencia de bytes. Porem, o estado da pilha

de execucao e contadores de programa das threads pertencentes ao aglet nao sao serializadas.

Serializacao de objetos diz respeito somente a dados no heap, e nao na pilha ou no contador

de programa. Assim, quando um aglet e enviado, clonado ou desativado, qualquer estado

relevante em qualquer pilha de um aglet em execucao, bem como o contador de programa

corrente de qualquer thread, e perdido. Na teoria, um agente de software deveria ser capaz

de migrar com todos os seus estados: heap, pilha de execucao, e registradores. Alguns

consideram a inabilidade de aglets para fazer isso um defeito na implementacao de aglet. Esta

caracterıstica de aglets originou-se da arquitetura do JVM, o qual nao permite um programa

acessar e manipular diretamente pilhas de execucao. Isto e parte do modelo de seguranca

construıdo no JVM. A menos que haja uma alteracao na JVM, aglets e qualquer outro agente

baseado em Java movel serao incapazes de levar o estado de suas pilhas de execucao com eles

quando os mesmos migram. Antes de ser serializado, um aglet deve colocar no heap todas

as informacoes necessarias para que ele possa ser ”ressucitado”corretamente como um aglet

ativado, enviado, ou entao um clone. Ele nao pode deixar qualquer informacao na pilha,

porque esta nao sera reproduzida na nova vida do aglet. Como resultado, o servidor aglet

informa um aglet que ele vai ser serializado para que o aglet possa preparar-se. Quando o

aglet e informado de uma possıvel serializacao, ele deve colocar na pilha qualquer informacao

que ele precisara para continuar sua execucao corretamente quando ele for ressucitado. Do

ponto de vista pratico, a inabilidade de um aglet migrar com sua pilha de execucao e uma

limitacao razoavel. Isso forca o programador a pensar de uma certa maneira quando o mesmo

escreve aglets. Ele deve entender o aglet como uma maquina de estado finito com o heap

como um unico repositorio de um estado de maquina. Se em qualquer ponto na vida de um

aglet pode-se saber seu estado apenas olhando no seu heap, entao ele pode ser serializado em

qualquer tempo. Caso contrario, deve-se ter uma maneira de gravar informacao suficiente

no heap antes da serializacao, de maneira tal a continuar corretamente quando o aglet e

”ressucitado”.


2.7.5 Seguranca

Sistemas de agentes moveis como aglets requerem nıveis de seguranca altos, pois eles repre-

sentam ainda outra forma de transmitir um programa malicioso. Antes de aglets poderem ser

utilizados na pratica, os servidores aglets devem possuir uma infraestrutura de prevencao

contra aglets nao confiaveis a fim de evitar danos no servidor. Seguranca e amplamene

fornecida na arquitetura intrınsica do Java e nas caracterısticas de seguranca extra do JDK,

mas alguns ataques sao ainda possıveis, como ocorre tambem nos applets. Atualmente, os

servidores aglets da IBM (Tahiti and Fiji) possuem restricoes de seguranca bastante severas

nas atividades de qualquer aglet que nao foi originado localmente.

42

Capıtulo 3

Arquitetura da Virtuosi

Esse Capıtulo especifica os conceitos de orientacao a objeto suportados pela Virtuosi atraves

da formalizacao do metamodelo da mesma. Em seguida especifica um novo formato de rep-

resentacao intermediaria na forma de arvore de programa interpretada pela maquina virtual

Virtuosi. Por ultimo, especifica a arquitetura da maquina virtual Virtuosi. Para auxiliar

o entendimento dos conceitos explicados ao longo desse Capıtulo, sao utilizados trechos de

codigo fonte de uma aplicacao de software orientado a objetos escritos na linguagem Aram1.

3.1 Metamodelo da Virtuosi

Os conceitos de orientacao a objeto suportados pela Virtuosi sao formalizados atraves de um

diagrama de classes da UML chamado de metamodelo da Virtuosi. O metamodelo da virtuosi

possui classes e associacoes que representam os elementos encontrados em uma linguagem

de programacao orientada a objeto que de suporte aos conceitos suportados pela Virtuosi.

Por isso, as classes do metamodelo podem ser chamadas de meta-classes. Por exemplo,

uma classe possui atributos; o metamodelo da Virtuosi, portanto, possui uma meta-classe

para representar uma classe de aplicacao, uma meta-classe para representar um atributo

e, atraves de uma associacao, explicita-se uma classe possui zero ou muitos atributos. O

metamodelo da Virtuosi pode ser entendido como um diagrama de classes que descreve

conceitos de orientacao a objeto e como tais conceitos se relacionam entre si. Na sequencia

segue uma descricao resumida de algumas meta-classes da Virtuosi (o detalhamento das

1Aram e uma linguagem de programacao que da suporte aos conceitos de orientacao a objeto definidospelo metamodelo da Virtuosi

Capıtulo 3. Arquitetura da Virtuosi 43

principais meta-classes e apresentado no Apendice A).

3.1.1 Literal

Valor Literal

Um valor literal e uma sequencia de caracteres sem semantica definida. A Figura 3.1 mostra

as situacoes possıves para o uso de valores literais.

Referencia a Literal

E a meta-classe que representa uma referencia a literal. Uma referencia a literal nao pode

sofrer atribuicao. Tambem nao e possıvel declarar uma variavel local do tipo referencia a

literal.

3.1.2 Bloco de Dados

Referencia a Bloco de dados

Uma referencia a bloco de dados consiste em uma referencia para uma sequencia contıgua

de dados binarios em memoria. Esse tipo de referencia e geralmente utilizado para a con-

strucao de classes pre-definidas (Integer, Real, Boolean, Character e String) utilizadas para

compor outras classes.

3.1.3 Classes

A meta-classe que representa uma classe se relaciona atraves de associacoes com outros

componentes do metamodelo da Virtuosi nas seguintes situacoes:

(1) como possuidora de atributos;

(2) como possuidora de atributos de variaveis enumeradas;


class Principal

{

constructor iniciar( ) exports all {

...

Integer massa = Integer.make( 70 );// 70 e um valor literal

}

...

}

...

class Boolean {

enum { true, false } value = false; // true e false s~ao literais

...

method void flip( ) exports all

{

if ( value == true )

value = false;

else

value = true;

}

...

}

Figura 3.1 Codigo fonte em Aram mostrando os possıveis uso de um valor literal

(3) como tipo de uma referencia a objeto;

(4) como possuidora de invocaveis2

A Figura 3.2 mostra o relacionamento da meta-classe que representa uma classe de apli-

cacao com outros componentes do metamodelo da Virtuosi, excetuando-se os relacionamentos

com meta-classes descendentes (ver secao .

2Do ingles invocable (o termo invocavel ainda nao esta registrado nos dicionarios da lıngua portuguesa).


invocable

DBRef

Class

ObjReftype

Association Attribute

Composition Attribute

0.n

attribute

0.n

0.n

EnumVar

ResultMethod

returnetype

0.n

client

Invocable

authorizer

Figura 3.2 Relacionamento da meta-classe que representa uma classe de aplicacao com outros

componentes do metamodelo da Virtuosi

Heranca

Duas classes podem estabelecer um relacionamento de heranca entre si, tal que os invocaveis

da classe herdeira podem acessar tanto o estado quanto o comportamento (metodos e acoes)

definidos pela classe ancestral, sem qualquer restricao. Em outras palavras, todas as defi-

nicoes de estado e comportamento existentes na classe ancestral sao validas para a classe

herdeira. Segundo o metamodelo da Virtuosi, uma classe pode ter apenas uma classe ances-

tral direta3, mas pode ter muitas classes herdeiras recursivamente. Entretanto, uma classe

nao pode ser direta ou indiretamente ancestral de si propria. Assim, um conjunto de clas-

3Essa propriedade e normalmente denominada heranca simples, em contra-partida a heranca multipla,quando uma classe pode ter muitas ancestrais diretas.


ses pode ser organizado como um grafo acıclico dirigido no qual a propriedade de heranca

e transitiva, isto e, uma classe herdeira assimila as definicoes de estado e de metodos de

ancestrais diretas ou indiretas.

Uma consequencia da transitividade da propriedade de heranca e que uma referencia de

uma certa classe pode ter como alvo instancias de distintas classes, desde que estas sejam

herdeiras (diretas ou indiretas) da classe que define o tipo da referencia, caracterizando assim

a propriedade de polimorfismo.

Existem dois tipos de classe, a classe de aplicacao e a classe raiz. Toda classe da

aplicacao possui uma classe ancestral, sendo que esta pode ser uma outra classe de aplicacao

ou a classe raiz. A classe raiz representa a classe ancestral – direta ou indireta – de todas as

classes de aplicacao, por este motivo nao possui ancestral. Ela e unica em toda a hierarquia

de classes.

3.1.4 Atributos

O ambiente Virtuosi disponibiliza uma biblioteca de classes pre-definidas (Integer, Real,

Boolean, Character e String) utilizadas para compor novas classes, as classes de aplicacao.

Os atributos de uma classe segundo o metamodelo da Virtuosi podem ser de tres tipos,

a saber:

• referencia a objeto;

• referencia a bloco de dados;

• variavel enumerada.

O metamodelo da Virtuosi formaliza os tres tipos de atributo de uma classe conforme

mostra a Figura 3.3.

Referencia a Objeto

A meta-classe que representa uma referencia a objeto se relaciona atraves de associacoes

com outros componentes do metamodelo da Virtuosi em situacoes como:


DBRef

attribute 0.n

ClassAssociation Attribute


EnumVar

ObjRef

Figura 3.3 Os tres tipos de atributos possıveis em uma classe segundo o metamodelo da Virtuosi

(1) como parametro;

(2) como atributo;

(3) como atributo em um acesso a atributo objeto;

(4) como objeto em um acesso a atributo bloco de dados;

(5) como referencia retornada por um invocavel;

(6) como variavel local;

(7) como alvo de invocacao de metodo;

(8) como alvo de invocacao de uma acao.

A Figura 3.4 mostra o relacionamento da meta-classe que representa a referencia a objeto

com outros componentes do metamodelo da Virtuosi.

Referencia a Bloco de Dados

Segundo o metamodelo da Virtuosi, um programador tem a possibilidade de criar novas

classes que nao dependam de nenhuma outra classe pre-existente. Para tanto, um atributo

pode referenciar um bloco de dados. Esse tipo de referencia e chamada referencia a bloco

de dados, e consiste em uma referencia para uma sequencia contıgua de dados binarios em


DBRef

Reference

LiteralRef

EnumAttributeAccess

ObjRefCompare

DBAttributeAccess

ObjDecl

ObjAttributeAccess

Testable<<interface>>

<<interface>>ObjBindSource

ObjBind

ActionInvocation

MethodInvocation

NullObjRefCompare

NullObjBind

This

ObjRef

<<interface>>Formal Parameter

<<interface>>

Class local variable

objectobject 2target

target

type

0..*

attribute

Actual Parameter

composition attribute

association attribute

Return

targettarget

0..*

target

IndexRef

Figura 3.4 Relacionamento da meta-classe que representa a referencia a objeto com outros


memoria. Um atributo do tipo referencia a bloco de dados obrigatoriamente tem uma relacao

de composicao exclusiva com a classe que o possui. Esse tipo de referencia e geralmente

utilizado para a construcao de classes pre-definidas. Cada classe pre-definida e responsavel

por dar o significado de sua sequencia de dados binarios atraves de suas operacoes. Por

exemplo, um objeto do tipo basico Integer pode armazenar um valor inteiro utilizando um

bloco de dados de qualquer tamanho, nesse caso uma operacao para adicionar um outro

valor inteiro (armazenado em outro objeto do tipo Integer tambem utilizando um bloco de

dados) ao valor inteiro deste objeto, deve conhecer a convencao utilizada na representacao

binaria de ambas as sequencias.


Variavel Enumerada

Uma classe implementada segundo o metamodelo da Virtuosi, pode ainda, ter um atributo

do tipo variavel enumerada. Um atributo do tipo variavel enumerada possui um conjunto

de valores possıveis definidos na construcao da classe. Os valores possıveis de uma variavel

enumerada nao sao objetos de nenhuma outra classe, sao simples valores literais. Esse con-

junto de valores possıveis de uma variavel enumerada chama-se enumerado. Um atributo

do tipo variavel enumerada recebe um valor inicial durante sua declaracao.

3.1.5 Referencias

Existem quatro tipos de referencia suportadas pelo metamodelo da Virtuosi, a saber:



• referencia a ındice;

• referencia a literal.

Um metodo sempre e invocado atraves de uma referencia a objeto sobre o objeto ao qual

ela aponta. Uma referencia do tipo This e utilizada quando dentro de um metodo deseja-se

invocar um metodo da propria classe e sobre o proprio objeto corrente.

3.1.6 Invocaveis

Segundo o metamodelo da Virtuosi, uma operacao de uma classe pode ser implementada de

duas maneiras, a saber:

• como um metodo;

• como uma acao;

Essas duas implementacoes descrevem o conjunto dos servicos que uma classe disponibi-

liza. Alem das operacoes, uma classe precisa implementar um metodo especial utilizado para

criar novas instancias da classe; esse tipo de metodo especial e chamado de construtor.


Um metodo, um construtor ou uma acao podem sofrer invocacao e, por isso, o metamo-

delo da Virtuosi os formaliza como invocaveis.

Construtor: Um construtor nao faz parte das operacoes definidas por um TAD (Tipo de

Dado Abstrato) pois nao interfere no comportamento dos objetos representados pelo TAD.

Porem, tem fundamental importancia na implementacao de uma classe, visto que, um objeto

sempre e criado atraves de sua interpretacao. O retorno da interpretacao de um construtor

e sempre um novo objeto, uma nova instancia de uma classe.

Metodo: Um metodo e a maneira mais comum de implementar uma operacao definida

por um TAD. Existem dois tipos de metodos, a saber: metodo sem retorno de valor –

muitas vezes chamado de procedimento – e metodo com retorno de valor – muitas vezes

chamado funcao.

A diferenciacao entre metodos com e sem retorno se da em parte pelo uso da palavra que

fica entre a palavra method e o nome do metodo. Caso essa palavra seja void trata-se de

um metodo sem retorno. Caso a palavra seja o nome de uma classe trata-se de um metodo

com retorno. Outra diferenca consiste no fato de um metodo com retorno sempre possuir ao

menos um comando retorno.

Acao: A segunda maneira de implementar uma operacao definida por um TAD e atraves

de uma acao. Uma acao pode ser vista como uma operacao cujo retorno e utilizado para a

tomada de decisao referente a um comando de desvio. Em outras palavras, o retorno de uma

acao permite ao comando de desvio decidir qual dentre duas sequencias de comandos deve

ser interpretada. Uma acao nao retorna uma referencia a objeto. Diferente de um metodo

com retorno ou um construtor – onde uma referencia e retornada – o retorno de uma acao

e um comando simples chamado: comando resultado de teste.

3.1.7 Comandos

No ambiente Virtuosi, toda computacao e realizada atraves da interpretacao dos comandos

que compoem um invocavel. Esses comandos podem ser invocacoes de outros invocaveis,


comandos responsaveis por controlar o fluxo da interpretacao, comandos para manipular

referencias a objetos ou ainda comandos de sistema para a manipulacao de referencia a

bloco de dados e manipulacao de referencia a ındice. Esses comandos sao interpretados a

partir do momento que um invocavel e invocado.

Composicao de Comandos

Um invocavel define uma sequencia de comandos. Comandos podem ser simples ou com-

postos. Um comando simples4 pode ser uma atribuicao, uma invocacao de operacao, um

desvio condicional, conforme detalhado no restante dessa Secao. Um comando composto5

e uma sequencia de comandos simples ou compostos, recursivamente.

Uma sequencia de comandos, simples ou compostos, pode ser agrupada em um comando

composto.

Declaracao de Variaveis

Para se invocar um invocavel e preciso possuir uma referencia para um objeto da classe que o

define(com excecao de construtores que sao invocados a partir do nome da classe). Segundo

o metamodelo da Virtuosi, uma referencia existe sob tres formas, a saber:

(1) atributo;

(2) parametro;

(3) variavel local.

Ao contrario dos atributos e parametros que sao definidos durante a construcao da classe

e seus respectivos invocaveis, uma variavel local nao existe ate que seja declarada. Portanto,

existem instrucoes para a declaracao de alguns tipos de referencia utilizadas como variaveis

locais.

4Do ingles simple statement.5Do ingles compound statement.


Atribuicao

Uma referencia nula nao permite uma invocacao a partir dela. Isso e verdade tanto para

variaveis locais quanto para atributos e parametros. Portanto, e preciso fazer com que uma

referencia aponte para um alvo, ou seja, uma referencia a objeto precisa apontar para um

objeto em memoria, uma referencia a bloco de dados precisa apontar para uma sequencia

de dados binarios em memoria e uma referencia a ındice precisa apontar para uma posicao

na sequencia de dados binarios em memoria. Isso ocorre atraves da interpretacao de um

comando de atribuicao. Esse comando e identificado no codigo fonte pelo uso do caracter

’=’ chamado de caracter de atribuicao. O que estiver a esquerda do caracter de atribuicao e

chamado alvo da atribuicao, e o que estiver a direita do caracter de atribuicao e chamado

origem da atribuicao.

Segundo o metamodelo da Virtuosi, os comandos de atribuicao existentes sao os seguintes:

• atribuicao de referencia a objeto;

• atribuicao de referencia nula a objeto;

• atribuicao de referencia a bloco de dados;

• atribuicao de referencia nula a bloco de dados;

• atribuicao de referencia a ındice;

• atribuicao de variavel enumerada.

Invocacao de Invocaveis

O metamodelo da Virtuosi define os comandos para realizar a invocacao de construtores,

metodos com retorno e metodos sem retorno. A invocacao de um construtor e realizada a

partir do nome da classe que o possui. Ja a invocacao de um metodo, com ou sem retorno,

e realizada a partir de uma referencia a objeto. Tanto o comando de invocacao de metodo

com retorno quanto o comando de invocacao de metodo sem retorno podem ser generalizados

como comandos de invocacoes de metodo. O comando de invocacao de metodo e o comando

de invocacao de construtor podem ser generalizados como comandos de invocacao.


3.1.8 Chamadas de Sistema

A Virtuosi disponibiliza diversos grupos de operacoes (comandos e testaveis) para a con-

strucao de classes de aplicacao. Entre eles o grupo de operacao de bloco de dados, o grupo

de operacoes de entrada e saıda, e o grupo de operacoes para a movimentacao de objetos

(secao 4.1).

3.2 Arvore de Programa

Desde o final da decada de 70, observam-se estudos preocupados em prover portabilidade para

aplicacoes computacionais atraves do uso de maquinas virtuais. Essa tendencia aumentou

com o avanco das tecnologias de rede e a necessidade de integracao entre computadores de

plataformas heterogeneas.

Uma maquina virtual prove uma camada de abstracao sobre o hardware e sistema opera-

cional de cada uma das plataformas onde e implementada. Essa estrategia permite que uma

mesma aplicacao seja interpretada em diferentes plataformas. Uma maquina virtual, como

o proprio nome diz, e um programa computacional capaz de interpretar outros programas.

Para tanto, os programas devem ser escritos em termos do conjunto de operacoes e dos tipos

de dados suportados pela maquina virtual.

Alem da portabilidade, outro benefıcio da utilizacao da estrategia de interpretacao de

software atraves de maquinas virtuais e a seguranca. Uma maquina virtual e geralmente um

simples processo – dentre os muitos – em um sistema operacional. Dessa forma, e possıvel

restringir um programa – que e interpretado em uma maquina virtual – de ter acesso de

forma direta aos recursos oferecidos pelo sistema operacional nativo.

A tecnologia Java e o principal exemplo de utilizacao da estrategia de maquinas virtu-

ais. Java tornou-se uma plataforma padrao de desenvolvimento e execucao de aplicacoes

portaveis, principalmente em sistemas embutidos6, em applets na Internet ou ainda em apli-

cacoes multi-plataforma. A portabilidade de Java e realizada atraves da compilacao de um

6Do ingles, embedded systems


programa fonte escrito em Java para uma sequencia de instrucoes da maquina virtual Java.

Essa sequencia de instrucoes e uma representacao intermediaria do programa fonte, e no

caso de Java, e chamada de bytecodes do Java. Os bytecodes do Java sao independentes da

arquitetura computacional onde o programa e interpretado.

Quando um compilador traduz o codigo fonte em Java para a representacao intermediaria

bytecode, as informacoes estruturais de alto nıvel presentes no codigo fonte de um programa

sao eliminadas. Isto nao impede, no entanto, a reconstrucao do codigo fonte de um programa

a partir de seus bytecodes.

Uma outra representacao intermediaria chamada de Slim Binaries e descrita em

[Kistler and Franz, 1997]. Ao inves de bytecodes, o codigo fonte e compilado para uma for-

ma de representacao intermediaria que preserva as informacoes estruturais de alto nıvel,

permitindo que otimizacoes sejam realizadas sem a reconstrucao do codigo fonte. Essa re-

presentacao intermediaria e baseada em arvores sintaticas abstratas, tambem chamadas de

arvores de programa.

No ambiente Virtuosi, utilizou-se a ideia de arvores sintaticas abstratas encontradas em

[Kistler and Franz, 1997] para criar uma representacao intermediaria propria no formato

de arvore de programa. Uma arvore de programa na Virtuosi pode ser vista com um

grafo cujos nos sao objetos que representam os elementos encontrados em uma linguagem de

programacao orientada a objeto, ou seja, uma arvore de programa e um grafo cujos nos sao

instancias das meta-classes definidas pelo metamodelo da Virtuosi e as ligacoes entre os nos

sao as relacoes entre tais meta-classes.

3.2.1 Exemplos de arvores de programa

Cada um dos objetos que compoem uma arvore de programa e uma instancia de uma das

meta-classes definidas pelo metamodelo da Virtuosi. Deve-se notar tambem que as asso-

ciacoes entre os objetos da arvore sao as associacoes definidas segundo o metamodelo da

Virtuosi.

No contexto desse trabalho, uma aplicacao Virtuosi pode ser vista como uma grande

arvore de programa formada por um conjunto de arvores de programa menores ligadas entre


si. Cada uma das classes de uma aplicacao e traduzida em uma arvore de programa.

A Figura 3.5 ilustra o relacionamento entre as arvores de programa que compoem uma

aplicacao. Neste caso as classes correspondentes sao chamadas A, B, C e D.

Tree D

��

��

��

��

��

��

Tree C

Tree A

Tree B

��

��

Figura 3.5 Conjunto de arvores de programa que compoem uma aplicacao de software

A seguir sao mostrados alguns exemplos de fragmentos de codigo fonte e os respectivos

fragmentos de arvore de programa.

Exemplo Basico

A Figura 3.6 apresenta o fragmento de codigo fonte da classe Pessoa.

A Figura 3.7 mostra a arvore de programa correspondente ao codigo fonte da Figura 3.6

atraves de um diagrama de colaboracao UML.

Com base na Figura 3.7, deve-se notar que:

(1) Existe um objeto chamado pessoa que e uma instancia da meta-classe utilizada para

representar uma classe de aplicacao. Este objeto representa a classe de aplicacao

Pessoa;

(2) Associado ao objeto chamado pessoa existe um objeto instancia da meta-classe uti-

lizada para representar uma referencia a objeto, chamado posicao. Este objeto esta

ligado ao objeto chamado pessoa por uma associacao e realiza o papel de atributo por

composicao;


class Pessoa

{

composition Integer posicao;

...

method void setPosicao(Integer p) exports all

{

posicao = p;

}

...

}

Figura 3.6 Fragmento de codigo fonte da classe Pessoa

target

pessoa: Class posicao: ObjRef integer: Class

setPosicao: VoidMethod

:CompoundStatement

: ObjBind

: RootClass

p: ObjRef

source

1

clientauthorizer

compositiontype

type

parameter

Figura 3.7 Arvore de programa parcial referente a classe Pessoa

(3) O objeto chamado pessoa tambem possui uma associacao com um objeto chamado

setPosicao que e instancia da meta-classe que representa um metodo sem retorno.

Esse objeto – que representa um metodo sem retorno da classe de aplicacao Pessoa

– por sua vez, possui uma associacao com um objeto instancia da meta-classe que

representa uma referencia a objeto chamado p que no caso e do tipo Integer e tem o


papel de parametro do metodo setPosicao;

(4) O objeto chamado setPosicao possui uma associacao com um objeto chamado raiz

que e instancia (unica em todo o sistema) da meta-classe que representa a classe raiz.

Essa associacao e responsavel por definir a lista de exportacao do metodo em questao,

ou seja, quais as outras classes de aplicacao que podem invocar o metodo em questao.

Neste caso especifico, qualquer classe podera invocar o construtor;

(5) Observa-se que o objeto chamado setPosicao possui uma associacao com um objeto

nao nomeado instancia da meta-classe que representa um comando composto, e este,

por sua vez, possui associacao com um objeto instancias da meta-classe que representa

um comando simples de atribuicao de referencia a objeto. O objeto que representa um

comando de atribuicao possui duas associacoes com objetos instancia da meta-classe

que representa referencia a objeto, um representando o alvo da atribuicao e o outro

representando a origem da atribuicao, neste caso especıfico o par: posicao – p.

Deve-se notar que os dois objetos instancia da meta-classe que representa uma referencia

a objeto – posicao e p – possuem uma associacao com um objeto instancia da meta-classe

que representa uma classe de aplicacao. Esta associacao indica a classe de aplicacao da

qual a referencia a objeto em questao e instancia, neste caso especıfico a classe pre-definida

Integer. Nota-se portanto, que a arvore de programa em questao nao esta completa, uma vez

que, a classe pre-definida Integer nao consta no diagrama. Isto ocorre porque cada classe de

aplicacao ou classe pre-definida define uma arvore de programa particular.

Exemplo Avancado

A Figura 3.8 apresenta o fragmento de codigo fonte da classe Pessoa.

A Figura 3.9 mostra a arvore de programa correspondente ao codigo fonte da Figura 3.8

atraves de um diagrama de colaboracao UML.

Com base na Figura 3.9, deve-se notar que:

(1) Existe um objeto chamado pessoa que e uma instancia da meta-classe utilizada para

representar uma classe de aplicacao. Este objeto representa a classe de aplicacao

Pessoa;


class Pessoa

{

composition String nome;

composition Integer massa;

...

enum {masculino, feminino } sexo = masculino;

constructor instanciar( String pNome, Integer pMassa, Integer pAltura,

literal pSexo) exports all

{

nome = pNome;

massa = pMassa;

...

sexo = pSexo;

...

}

...

}

Figura 3.8 Fragmento de codigo fonte da classe Pessoa

(2) Associado ao objeto chamado pessoa existem dois objetos instancias da meta-classe

utilizada para representar uma referencia a objeto, o primeiro deles e chamado nome

e o segundo e chamado massa. Ambos estao ligados ao objeto chamado pessoa por

uma associacao e realizam o papel de atributo por composicao;

(3) O objeto chamado pessoa possui uma associacao de atributo por composicao com um

objeto instancia da meta-classe que representa uma variavel enumerada chamado sexo

que, por sua vez, esta associado a um objeto instancia da meta-classe que representa

um enumerado, que, por sua vez, esta associado a dois objetos instancias da meta-classe

que representa valores literais, no caso masculino e feminino;

(4) O objeto chamado pessoa tambem possui uma associacao com um objeto chamado

instanciar que e instancia da meta-classe que representa um construtor. Esse objeto

– que representa um construtor da classe de aplicacao Pessoa – por sua vez, possui


type

pessoa: Class

pNome: ObjRef

pMassa: ObjRef

pAltura: ObjRef

pSexo: LiteralRef: ObjBind

: ObjBind

: ObjBind

:CompoundStatement

integer: Classnome: ObjRef

massa: ObjRefstring: Class

instanciar: Construtor

sexo: EnumVar

Enumerate

masculino: LiteralValue

feminino: LiteralValue

: RootClass

type

type

client

authorizer

composition

composition

composition

target

target

target

parameter

parameter

parameter

parameter

source

source

source

type

type

Figura 3.9 Arvore de programa parcial referente a classe Pessoa

tres associacoes com objetos instancias da meta-classe que representa uma referencia a

objeto (chamados respectivamente de pNome, pMassa e pAltura) e uma associacao com

um objeto instancia da meta-classe que representa uma referencia a literal chamado

pSexo. Estes quatro objetos compoem a lista de parametros do construtor;

(5) O objeto chamado instanciar possui uma associacao com um objeto chamado raiz

que e instancia (unica em todo o sistema) da meta-classe que representa a classe

raiz. Essa associacao e responsavel por definir a lista de exportacao do construtor em

questao, ou seja, quais as outras classes de aplicacao que podem invocar o construtor

em questao. Neste caso especificamente, qualquer classe podera invocar o construtor;

(6) Observa-se que o objeto chamado instanciar possui uma associacao com um objeto

nao nomeado instancia da meta-classe que representa um comando composto, e este,

por sua vez, possui associacao com tres objetos instancias da meta-classe que repre-


senta um comando simples de atribuicao de referencia a objeto. Cada um dos objetos

que representam os comandos de atribuicao possui duas associacoes com objetos in-

stancia da meta-classe que representa referencia a objeto, um representando o alvo da

atribuicao e o outro representando a origem da atribuicao (no caso os pares: nome –

pNome, massa – pMassa e sexo – pSexo).

Deve-se notar que todos os objetos instancias da meta-classe que representa uma re-

ferencia a objeto possuem uma associacao com um objeto instancia da meta-classe que

representa uma classe de aplicacao. Esta associacao indica a classe de aplicacao a qual a re-

ferencia a objeto em questao e instancia. Nota-se portanto, que a arvore em questao nao esta

completa, uma vez que, cada uma das outras classes de aplicacao mostradas no diagrama –

as classes pre-definidas String e Integer – nao constam no diagrama.

As arvores de programa de uma aplicacao geralmente sao armazenadas separadamente

em um meio fısico. Isso faz com que um objeto instancia da meta-classe que representa

referencia a objeto nao possa apontar diretamente para o objeto instancia da meta-classe

que representa a correspondente classe de aplicacao, caso esta pertenca a outra arvore de

programa. Dessa forma, uma arvore de programa isolada mantem em seus objetos instancias

da meta-classe referencia a objeto uma referencia simbolica para o objeto instancia da meta-

classe que representa a classe de aplicacao. O mesmo acontece com os objetos instancia

da meta-classe que representam uma invocacao de invocavel (construtor, metodo ou acao)

localizado em outra arvore de programa. A Figura 3.10 ilustra a ocorrencia de referencias

simbolicas entre arvores de programa.

Para facilitar o trabalho do carregador de arvores (detalhado na Secao 3.3.2) na tarefa de

resolver as referencias simbolicas entre arvores, cada arvore de programa possui duas listas,

a saber:

(1) lista de referencias a classes;

(2) lista de referencias a invocaveis.

3.2.2 Lista de Referencias a Classe

A lista de referencias a classes armazena um apontador para cada uma das classes as quais

referencia.


Referência Simbólica

pessoa: Class posicao: ObjRef integer: Class

setPosicao: VoidMethod : RootClass

p: ObjRef

clientauthorizer

compositiontype

type

parameter

Legenda:

Referência Normal

Figura 3.10 Referencias simbolicas entre arvores de programa

3.2.3 Lista de Referencias a Invocaveis

A lista de referencias a invocaveis armazena um apontador para cada um dos invocaveis aos

quais referencia.

3.3 Maquina Virtual Virtuosi

O ambiente Virtuosi tem como um de seus princıpios fundamentais o uso de maquinas virtu-

ais distribuıdas. O ambiente Virtuosi, portanto, define uma maquina virtual – a Maquina

Virtual Virtuosi (MVV).

A tarefa basica de uma instancia da MVV e interpretar os comandos definidos por in-

vocaveis pertencentes a uma arvore de programa. O restante dessa Secao tem como objetivo

definir os principais elementos da Maquina Virtual Virtuosi e como estes interagem.

3.3.1 Ciclo de Vida de Uma Aplicacao

Uma instancia da MVV pode interpretar mais de uma aplicacao Virtuosi ao mesmo tempo.


Para dar inıcio a interpretacao de uma aplicacao, deve-se informar a maquina virtual o

nome de uma classe de aplicacao – classe inicial – e o nome de um construtor desta classe

– construtor inicial. A partir dessas duas informacoes o ciclo de vida de uma aplicacao na

MVV segue uma sequencia de eventos bem definida:

(1) A maquina virtual utiliza o subsistema de carga de arvore para carregar as arvores de

programa que compoem a aplicacao para a area de classes;

(2) A maquina virtual cria um novo objeto instancia da classe inicial – objeto inicial – e

adiciona-o a area de objetos;

(3) A maquina virtual cria uma nova atividade (ver secao 3.3.4) – atividade inicial –

associada ao construtor inicial e ao objeto inicial;

(4) A maquina virtual empilha a atividade inicial na pilha de atividades, o que faz com

que a atividade inicial seja interpretada. Novas atividade sao empilhadas – recursiva-

mente – na pilha de atividades em resposta a interpretacao de comandos de invocacao

de metodo e construtor ou em resposta a um comando de desvio condicional cujo teste

seja uma acao;

(5) Apos o termino da interpretacao da atividade inicial a maquina virtual a retira do topo

da pilha de atividades e, caso nao hajam outras pilhas com atividades, a aplicacao e

encerrada. A existencia de outras pilhas de atividade e discutida na Secao 3.3.4.

3.3.2 Area de Classes

A area de classes e a regiao de memoria onde as arvores de programa de cada uma das classes

de aplicacao sao armazenadas.

Dentro da MVV as referencias entre arvores sempre sao feitas de forma indireta, ou

seja, os pontos de ligacao entre duas arvores de programa nunca apontam diretamente

para seus respectivos alvos. Essas duas ligacoes na perspectiva da aplicacao significam,

respectivamente, o tipo de um objeto e o metodo de uma invocacao.

No caso de uma referencia a objeto, a ligacao com o seu respectivo tipo e feita de forma

indireta atraves de uma tabela chamada tabela de classes. Essa estrategia e utilizada

devido a natureza distribuıda do ambiente Virtuosi, onde uma referencia a objeto pode ser


de um tipo (uma classe de aplicacao) cuja arvore pode estar localizada na propria instancia

da MVV ou localizada remotamente em outra instancia da MVV.

Tabela de Classes

Cada uma das classes de aplicacao carregadas na MVV tem uma entrada correspondente na

tabela de classes. Cada entrada possui o nome da classe de aplicacao para a qual aponta

e um apontador para a area de memoria onde a arvore esta localizada. Uma arvore pode

referenciar uma arvore localizada em outra maquina virtual. Portanto, existem dois tipos

de entrada na tabela de classes, a saber:

• Entrada de Referencia de Classe Local (ERCL);

• Entrada de Referencia de Classe Remota (ERCR) – neste caso a entrada tambem

armazena o nome da classe de aplicacao, mas ao inves de possuir um apontador para

uma area de memoria, a entrada possui a identificacao da MVV remota e a posicao da

entrada da tabela de arvores remota.

A Figura 3.11 ilustra a tabela de classes contendo entradas locais e entradas remotas.

No caso dos objetos instancias da meta-classe que representa uma invocacao de invocavel

a ligacao tambem e feita de forma indireta atraves de uma tabela chamada tabela de

invocaveis.

Tabela de Invocaveis

Cada um dos invocaveis de cada uma das classes de aplicacao carregadas na MVV tem uma

entrada correspondente na tabela de invocaveis. Cada entrada possui o nome do invocavel

apontado, o nome da classe de aplicacao que possui o invocavel e um apontador para a

area de memoria onde o invocavel esta localizado. Pode-se invocar um invocavel de um

objeto local ou de um objeto remoto. Portanto, existem dois tipos de entrada na tabela de

invocaveis, a saber:

• Entrada de Referencia de Invocavel Local (ERIL);


tabela de classes

��

��

��

��

��

��

��

��

��

��

... ... ... ...

......

VM Alpha VM Beta

Legenda:

Classe (Árvore de Programa)

Entrada de entidade local

Entrada de entidade remota

Referência de uma entrada para uma entidade local

Referência de uma entidade local para a entrada

Referência de uma entrada para uma entidade remota

área de classes

Figura 3.11 Tabelas de classes com referencias locais e remotas

• Entrada de Referencia de Invocavel Remoto (ERIR) – neste caso, a entrada armazena

a identificacao da MVV remota e a posicao da entrada da tabela de invocaveis remota.

A Figura 3.12 ilustra a tabela de invocaveis contendo entradas locais e entradas remotas.

Carregador de Arvores

Antes da MVV comecar a interpretar as arvores de programa que compoem a aplicacao, e

preciso carrega-las na area de classes da MVV.

O subsistema de carga de arvores de programa da MVV devera realizar a seguinte

sequencia de acoes:

(1) localizar e carregar uma arvore de programa.

(2) para cada objeto instancia da meta-classe que representa uma referencia a objeto,

transformar a referencia simbolica em uma referencia real que aponte para uma entrada

na tabela de classes;


área de classes

��

��

Legenda:

Classe (Árvore de Programa)

Entrada de entidade local

Entrada de entidade remota

Referência de uma entrada para uma entidade local

Referência de uma entidade local para a entrada

Referência de uma entrada para uma entidade remota

��

��

��

��

��

��

��

��

...

......

...

VM Alpha VM Beta

tabela de invocáveis

Figura 3.12 Tabelas de invocaveis com referencias locais e remotas

(3) para cada objeto instancia da meta-classe que representa uma invocacao de invocavel,

transformar a referencia simbolica em uma referencia real que aponte para uma entrada

na tabela de invocaveis.

(4) ligar a propria classe de aplicacao cuja arvore foi carregada a uma entrada da tabela

de classes; caso a entrada nao exista, deve-se criar uma nova.

(5) ligar os invocaveis da propria classe de aplicacao cuja arvore foi carregada as entradas

na tabela de invocaveis; caso a entrada para o invocavel nao exista, deve-se criar uma

nova.

(6) refazer essa sequencia de forma recursiva para todas as classes de aplicacao referencia-

das na arvore corrente.

A Figura 3.13 ilustra (de forma simplificada) a carga das arvores de programa de duas

classes de aplicacao situadas na mesma MVV. No caso, a classe Pessoa possui um atributo

(uma referencia a objeto) do tipo definido pela classe Integer e um metodo da classe Pessoa


invocable table

(c) (d)

(b)(a)

VM Alpha

pessoa: Class

i: ObjRef...

... ...

...

: resultMethodInvocation

soma: ResultMethod

integer : Class

tree table

invocable table

VM Alpha

pessoa: Class

i: ObjRef...

... ...

...


soma: ResultMethod

integer : Class

tree table

invocable table

VM Alpha

pessoa: Class

i: ObjRef...

... ...

...


soma: ResultMethod

integer : Class

tree table

invocable table

VM Alpha

pessoa: Class

i: ObjRef...

... ...

...


soma: ResultMethod

integer : Class

tree table

Figura 3.13 Ilustracao da carga de duas arvores de programa ligadas entre si

faz uma invocacao de um metodo sobre o atributo da classe Integer (soma, por exemplo).

Observa-se na Figura 3.13.a a situacao da classe Pessoa ainda nao carregada e com os pontos

de ligacao ainda como referencias simbolicas. A Figura 3.13.b ilustra a situacao da classe

Pessoa ainda nao carregada mas com os pontos de ligacao ja apontados para entradas na

tabela de arvore e tabela de invocavel. A Figura 3.13.c ilustra a situacao da classe Pessoa

ja carregada e com os pontos de ligacao ja apontados para entradas na tabela de arvore e

tabela de invocavel. E a Figura 3.13.d ilustra a situacao da classe Pessoa ja carregada e com

os pontos de ligacao ja apontados para entradas na tabela de arvore e tabela de invocavel e

alem disso, as entradas em ambas as tabelas ja apontando para a arvore da classe Integer.


3.3.3 Area de Objetos

A area de objetos e a regiao de memoria onde objetos instancias de classes de aplicacao sao

armazenados.

Dentro da MVV as referencias entre objetos sempre sao indiretas, ou seja, um objeto nun-

ca referencia diretamente um outro objeto. A ligacao entre os objetos e feita sempre atraves

da tabela de objetos. Essa estrategia e utilizada devido a natureza distribuıda do ambi-

ente Virtuosi, onde o objeto esta localizado na propria instancia da MVV ou remotamente

em outra instancia da MVV.

Tabela de Objetos

Para cada um dos objetos que a MVV instancia, ha uma entrada correspondente na tabela

de objetos. Cada entrada possui o nome do objeto para o qual aponta e um apontador para

a area de memoria onde o objeto esta localizado.

Um objeto pode referenciar um objeto localizado em outra maquina virtual. Portanto,

existem dois tipos de entrada na tabela de objeto, a saber:

• Entrada de Referencia de Objeto Local (EROL);

• Entrada de Referencia de Objeto Remoto (EROR) – ao inves de possuir um apontador

para uma area de memoria, a entrada possui a identificacao da MVV remota e a posicao

da entrada da tabela do objetos remota.

A Figura 3.14 ilustra a tabela de objetos contendo entradas locais e entradas remotas

entre duas MVV.

A Entrada de Referencia de Objeto Local, tem outra atribuicao alem de que somente

referenciar o objeto. Existe um campo de um bit denomidado freeze em sua estrutura.

Quando o campo freeze esta igual a zero indica que o objeto esta disponıvel para alteracao,

senao o objeto fica indisponıvel e as alteracoes devem aguardar ate que o objeto esteja

disponıvel novamente.

Para implementacao das primitivas foi necessario estender a estrutura da entrada de

referencia para objeto local (ver Capıtulo 4 - Estrutura do Objeto) incluindo um novo campo


Tabela de Objetos...

...

...

...

VM BetaVM Alpha

Área de Objetos

Figura 3.14 Tabelas de objetos com referencias locais e remotas

de um bit denominado fix. Este campo quando diferente de zero indica que o objeto esta

fixo. A execucao da primitiva fix atribui o valor 1 (um) para a campo, enquanto a unfix

atribui 0 (zero).

Estrutura de um Objeto

A estrutura interna de um objeto na MVV e composta por:

(1) um nome (identificador unico em todo o ambiente distribuıdo)7;

(2) um conjunto de atributos formado por apontadores para a Tabela de Objetos;

(3) um conjunto de blocos de dados;

(4) um conjunto de variaveis enumeradas;

(5) um apontador direto para a arvore de programa correspondente a classe de aplicacao

da qual o objeto e instancia.

O estado de um objeto e composto por seus conjuntos de bloco de dados, variaveis

enumeradas e atributos.

7O mecanismo gerenciador de nomes esta em desenvolvimento no contexto da pesquisa referente aomecanismo de RPC


3.3.4 Area de Atividades

Conforme descrito em [Calsavara, 2000], a Virtuosi tem como forma mais basica de comu-

nicacao entre objetos a invocacao de uma atividade de um objeto por outro objeto. Esse

mecanismo possibilita a concepcao de uma aplicacao baseada no encadeamento de atividades

de um conjunto de objetos.

A area de atividades e a regiao de memoria da MVV onde as pilhas de atividade sao ar-

mazenadas. Antes de definir uma pilha de atividades e preciso definir o que e uma atividade.

Atividade de Objeto

Uma atividade de um objeto corresponde a interpretacao de um de seus invocaveis (cons-

trutor, metodo ou acao), ou seja, cada invocacao de invocavel de um certo objeto da inıcio a

uma nova atividade deste objeto. Toda a computacao realizada pela MVV e obtida atraves

da interpretacao dos comandos definidos por um invocavel. Uma atividade termina quando

a interpretacao do invocavel termina, seja normal ou anormalmente (quando ocorre uma

excecao8). Duas invocacoes de dois metodos distintos dao inıcio a duas atividades indepen-

dentes. Da mesma forma, duas invocacoes do mesmo invocavel tambem dao inıcio a duas

atividades independentes. Assim, para cada instante no tempo, cada objeto na MVV pode

ter zero ou mais atividades, dependendo de como sao utilizados pelas aplicacoes. Um mesmo

objeto pode, inclusive, ter duas atividades simultaneas pertencentes a aplicacoes distintas.

Nesse modelo de execucao, uma aplicacao consiste em um encadeamento de atividades, en-

volvendo um conjunto de objetos relacionados. Cada aplicacao determina quais objetos

sao relacionados, que invocavel invoca qual invocavel, em que ordem e sob quais condicoes

ocorrem as invocacoes e ainda, para cada par de atividade invocadora e ativividade

invocada o modo de invocacao com relacao ao sincronismo.

Em relacao ao sincronismo, uma atividade invocada pode ser classificada como sıncrona

ou assıncrona.

8O mecanismo de tratamento de excecoes nao faz parte do escopo desse trabalho.


Atividade Sıncrona A atividade invocadora fica bloqueada ate que a atividade termine.

Necessariamente, entao, a atividade invocadora tem que ser notificada do termino da ativi-

dade invocada, seja ele normal (com um possıvel retorno) ou anormal (com geracao de

excecao).

Atividade Assıncrona A atividade invocadora nao fica bloqueada devido a invocacao e

nem recebe qualquer notificacao de termino. Assim, a atividade invocadora pode encerrar-se

independentemente do que aconteca com a atividade invocada. Nesse caso, se a atividade

tiver um retorno, este sera ignorado. Igualmente, se gerar alguma excecao, esta nao sera

notificada na atividade invocadora.

Deve-se observar que o modo de sincronismo para um certo invocavel nao precisa ser fixo,

isto e, pode ser escolhido em tempo de execucao pela atividade invocadora. Assim, e possıvel

que um mesmo invocavel seja interpretado como atividade sıncrona em uma situacao e como

atividade assıncrona em outra, dentro da mesma aplicacao ou nao.

No ambiente distribuıdo e possıvel que existam atividades sıncronas localizadas em nodos

diferentes. Para que seja possıvel a sincronia remota e necessario atribuir funcoes adicionais

para as atividades:

Invocadora Remota: A atividade com esta funcao permanece bloqueada ate que a men-

sagem de finalizacao da atividade remota sıncrona a ela retorne.

Invocada Remota: A atividade com esta funcao retorna uma mensagem de finalizacao

para a atividade remota subsequente a ela.

Em determinados casos uma atividade pode ter funcao invocada e invocadora remota ao

mesmo tempo.

Estrutura de uma Atividade Conforme supracitado, uma atividade e referente a um

objeto e a um dos invocaveis definidos pela classe de aplicacao da qual o objeto e instancia.

Portanto, a estrutura interna de uma atividade na MVV e composta por:


nulo

Start.start

X.makeZ

Z.make

X.makeZ

Pilha de Execução

origState

X.makeZ

stxz

invocáveltipo de sincronia

retorno

variáveis

parâmetrosvazio

void

==

&origState&stx

=

Figura 3.15 Exemplo de uma pilha de execucao e o detalhe de uma atividade.

(1) um apontador para o objeto dono da atividade localizado na area de objetos;

(2) um apontador para o invocavel sendo interpretado;

(3) um conjunto de parametros;

(4) um conjunto de variaveis locais.

Para atividades que assumem funcoes de invocadora ou invocada remota, e necessario

adicionar a sua estrutura uma referencia remota – identificador da MVV remota mais um

ponteiro para a atividade. No caso da atividade que assume as duas funcoes, adiciona-se

duas referencias remotas.

Deve-se observar que tanto o conjunto de parametros quanto o conjunto de variaveis

locais tem como seus elementos referencias a objeto, e cada uma dessas referencias a objeto

possui um apontador para uma entrada na tabela de objetos.

A Figura 3.15 mostra a notacao grafica para a representacao de uma atividade de objeto.

Pilha de Atividades

Quando uma atividade interpreta um comando de invocacao de construtor, metodo ou acao,

isto faz com que uma nova atividade seja criada para a interpretacao do invocavel em questao.

Quando a nova atividade – atividade invocada – e uma atividade sıncrona, ela e entao

empilhada sobre a atividade invocadora. Ao final da interpretacao da atividade invocada ela

e desempilhada e a atividade invocadora deve continuar a interpretar o proximo comando

apos o comando de invocacao que causou a criacao da atividade invocada. Esse processo e


recursivo, fazendo que todas as atividades sıncronas sejam empilhadas na mesma pilha de

atividades onde a atividade invocadora existe.

Quando a nova atividade – atividade invocada – e uma atividade assıncrona, uma nova

pilha de atividades e criada e a atividade invocada e empilhada como base da pilha.

Uma vez que a invocacao de uma atividade assıncrona cria uma nova pilha de ativi-

dades, a area de atividades pode ter mais de uma pilha de atividades sendo interpretada

simultaneamente.

Uma nova atividade sıncrona ou assıncrona pode ser criada em uma outra instancia da

MVV. No caso de uma atividade assıncrona uma nova pilha de atividades e criada remota-

mente e a nova atividade e empilhada como primeiro elemento da pilha. No caso de uma

atividade sıncrona a nova atividade tambem e colocada na base de uma nova pilha de ativi-

dades localizada na MVV remota, porem ao termino da atividade invocada remota, a

atividade invocadora local e desbloqueada e continua sua interpretacao normalmente.

A Figura 3.16 ilustra uma situacao de invocacao de atividade assıncrona remota.

Existem dois momentos onde pode haver comunicacao entre duas atividades em uma

pilha de atividades.

• na passagem de parametros;

• no retorno de construtores, metodos com retorno e acoes.

No caso dos construtores, apos o termino da atividade uma referencia para o novo objeto

criado e adicionado ao topo da pilha de atividades. No caso de um metodo com retorno

uma referencia a objeto e adicionada ao topo da pilha em resultado da interpretacao de um

comando de retorno. No caso de uma acao, o que e adicionado ao topo da pilha de atividades

e um dos comandos resultado de teste. Portanto, uma pilha de atividades pode empilhar

elementos que sao atividades, referencias a objeto ou ate mesmo comandos resultados de

teste.


Área de Atividades��

��

... ...

VM Alpha VM Beta

Thread

Key:

Atividade Assíncrona

Atividade Síncrona

Atividade Invocadora Remota

Atividade Invocada Remota

Referência bidirecional

Figura 3.16 Uma atividade assıncrona remota

3.3.5 Resumo da Arquitetura da Maquina Virtual Virtuosi

Uma visao geral de todas as areas que compoem a arquitetura da MVV e fornecida na Figura

3.17.

3.3.6 Funcionamento da Maquina Virtual Virtuosi

Alem das estruturas e areas de memoria da MVV, esse trabalho define as funcoes principais

realizadas pela MVV a fim de interpretar uma aplicacao ja carregada na area de classes. Em

suma, a MVV cria uma atividade relacionada a um determinado objeto e relacionada a um

determinado invocavel definido na arvore de programa da classe de aplicacao cujo objeto e

instancia. Em seguida a MVV interpreta os comandos definidos pelo invocavel definido pela

arvore de programa.


Área de Objetos

��

��

��

��

��

��

��

��

��

��

��

��

��

... ...

...

...

...

...

...

... ... ... ...

......

Legenda:

VM Alpha VM Beta

...

Pilha de Execução

Atividade Síncrona

Atividade Assíncrona

Atividade Chamadora

Atividade Chamada

Referência de uma Entrada de Referência

Entrada de Referência Remota

Entrada de Referência Local

Objeto

Classe

para uma Entidade Local

Referência de uma Entidade Local parauma Entrada de Referências

Referência de uma Entrada de Referênciapara uma Entrada de Referência Remota

Referência bidirecional entre AtividadeChamadora e Chamada

Tabela de Classes

Tabela de Invocáveis

Tabela de Objetos

Área de Classes

Área de Atividades

Figura 3.17 Arquitetura da Maquina Virtual Virtuosi


Criacao de um Objeto

Para a criar um objeto – uma instancia de uma classe de aplicacao – na MVV e preciso

primeiramente obter um nome unico para o objeto9. De posse do nome do objeto e um

apontador para a arvore de programa correspondente a classe de aplicacao do objeto, deve-

se realizar a seguinte sequencia de acoes:

(1) atribuir o nome ao objeto;

(2) atribuir ao apontador do objeto a referencia para a arvore de programa correspondente

a sua classe de aplicacao;

(3) para cada um dos atributos referencia a objeto definidos na arvore de programa cor-

respondente a classe de aplicacao a qual o objeto e instancia, criar uma entrada na

tabela de objetos com o apontador nulo;

(4) para cada um dos atributos blocos de dados definidos na arvore de programa corres-

pondente a classe de aplicacao da qual o objeto e instancia, declarar um apontador

para uma sequencia de dados binarios em memoria (area de objetos);

(5) para cada um dos atributos variavel enumerada definidos na arvore de programa cor-

respondente a classe de aplicacao que o objeto e instancia, declarar uma variavel enu-

merada e atribuir-lhe o valor inicial definido pelo enumerado associado.

Nota-se que o segundo passo supracitado somente cria entradas na tabela de objeto para

os atributos do objeto que sao outros objetos. Isto ocorre porque a alocacao de memoria

destes objetos e realizada atraves da interpretacao dos comandos apropriados (comandos de

sistema) durante a interpretacao da atividade criada pela invocacao do construtor do objeto.

Tambem nota-se que os atributos que sao referencias a bloco de dados sao somente

declarados; a alocacao de memoria se da atraves da interpretacao de um comando de sistema

apropriado durante a interpretacao da atividade criada pela invocacao do construtor do

objeto. Ja os atributos que sao variaveis enumeradas tem um espaco de memoria alocado

dentro do proprio objeto e um valor inicial atribuıdo, sendo que, este valor pode ser alterado

pela interpretacao de um comando de atribuicao de variavel enumerada.

9O mecanismo gerenciador de nomes nao faz parte do escopo deste trabalho.


Criacao de uma Atividade

A criacao de uma atividade e um processo simples. Para criar uma atividade na MVV e

necessario fornecer um apontador para o objeto sobre o qual a atividade sera criada, um

apontador para o invocavel em questao definido em uma arvore de programa e um conjunto

de parametros.

Interpretacao de uma Atividade

Um invocavel esta associado a um comando composto, e este por sua vez, esta associado a

uma serie de comandos (simples ou compostos, recursivamente) que quando interpretados

realizam a computacao desejada. Cada comando e um objeto instancia de uma meta-classe

do metamodelo da Virtuosi e portanto possui a informacao necessaria para ser interpretado.

Apos a criacao de uma atividade, a MVV a adiciona ao topo da pilha de atividades e

ordena a atividade que comece a se interpretar. A atividade entao e passada ao comando

composto definido pelo invocavel para que o comando seja interpretado. A interpretacao

do comando composto por sua vez, consiste em interpretar cada um dos comandos que ele

possui. A atividade e entao passada para cada um dos comandos na sequencia em que

sao interpretados, isto permite ao comando corrente ter acesso as variaveis locais e aos

parametros da atividade.

Cada comando “sabe” o que deve ser feito; por exemplo, um comando de atribuicao

de referencia a objeto tem associado a ele uma origem e um alvo, e o resultado de sua

interpretacao e que a referencia alvo passe a apontar para o mesmo objeto apontado pela

referencia origem. Quando um comando de invocacao e interpretado, isto faz com que uma

nova atividade seja criada e comece a ser interpretada em um processo recursivo. Quando

uma atividade termina de interpretar seu comando composto, isto faz com que a atividade

seja retirada da pilha de atividades.

Pode ocorrer tambem a interpretacao de um comando de retorno – no caso de uma

atividade criada para responder a invocacao de um metodo com retorno – o que faz com

que a atividade corrente seja retirada da pilha de atividades e uma referencia a objeto

apontando para o objeto resultado da atividade e adicionado no topo da pilha de atividades,


permitindo assim, que um comando de atribuicao pertencente a atividade invocadora utilize

a referencia a objeto no topo da pilha como a origem da atribuicao. No caso de uma

atividade de invocacao de construtor o processo e o mesmo, embora nao haja um comando

de retorno explıcito. Quando a atividade e criada em resposta a uma invocacao de acao,

a diferenca e que, neste caso, o que e adicionado a pilha de atividades apos a retirada da

atividade invocada e um comando resultado de teste que e utilizado pelo comando de desvio

pertencente a atividade invocadora.

78

Capıtulo 4

Mobilidade de Objetos na Virtuosi

Na Virtuosi e premissa que todos os objetos tenham a habilidade de se mover livremente.

Esta habilidade pode somente ser restringida por meio de primitivas. Este capıtulo forma-

liza os aspectos que tangem a mobilidade de objetos na Virtuosi. Primeiro sao descritas as

primitivas de mobilidade. Segundo, a definicao dos pre-requisitos necessarios para a movi-

mentacao de um objeto. Terceiro, o detalhamento do protocolo de migracao. Quarto, as

fragmentacoes referenciais. Quinto, algumas consideracoes sobre o protocolo. Por fim, uma

avaliacao comparativa.

4.1 Primitivas

Mobilidade dos Objetos na Virtuosi e suportada por cinco primitivas basicas da linguagem

que sao associadas atraves de invocaveis, a saber:

fix (): Fixa o objeto na MVV local.

unfix (): Torna o objeto movel.

refix (MVVNome): Move e fixa o objeto na MVV cujo identificador corresponde ao objeto

MVVNome.

locate (): MVVNome: Retorna o objeto MVVNome que identifica a MVV onde o objeto

se encontra.

move (MVVNome): Move o objeto para a MVV cuja identificacao e representada pelo

objeto MVVNome.

Capıtulo 4. Mobilidade de Objetos na Virtuosi 79

As primitivas sao semelhantes as adotadas pelo Emerald [Jul et al., 1988], porem a forma

com que sao implementadas sao diferentes, desde que o mecanismo de migracao e o modelo

de referencias sao outros. O fix e utilizado pelo programador para impedir que ocorra a

migracao do objeto. Esta primitiva deve ser utilizada de forma criteriosa, pois pode impedir

que outros aplicativos que gerenciam as polıticas administrativas do sistema percam o poder

de geri-las. Por exemplo, um balanceador de carga limita sua funcionalidade na medida que

nao pode movimentar objetos. Em uma manutencao preventiva de equipamento, o objeto

fixado nao poderia ser realocado.

O unfix permite que o objeto tenha mobilidade novamente. Para isto atualiza o mesmo

campo da estrutura da entrada que o fix. O refix e a composicao das primitivas unfix,

move e fix. O locate e util quando e relevante ao programador a informacao de onde se

encontra o objeto. O move efetiva a migracao do objeto da MVV local para a destino, desde

que o objeto nao esteja fixado. Exemplos da sintaxe das primitivas estao na secao .

A utilizacao do fix e importante por permitir ao programador a seguranca que o objeto

criado nao sera transposto para um local diferente ao qual ele foi projetado. Por exemplo, se o

objeto tem a necessidade de rodar em uma plataforma especıfica dentro da rede, ou o ganho

de desempenho e bastante significativo pela permanencia do objeto em um determinado

nodo. Para tanto, o objeto deve ser fixado. Uma medida de seguranca a mais e restringir a

licenca do uso da primitiva unfix e refix para outros objetos. Assim nao ha como o objeto

ser movimentado pela solicitacao de um objeto externo.

Para implementacao das primitivas foi necessario estender a estrutura da entrada de

referencia para objeto local (secao 3.3.3) incluindo um novo campo de um bit denominado

fix. Este campo quando diferente de zero indica que o objeto esta fixo. A execucao da

primitiva fix atribui o valor 1 (um) para a campo, enquanto a unfix atribui 0 (zero).

A informacao sobre a fixacao somente existe na entrada de referencia local para o objeto.

Referencias remotas nao contem o campo fix. (ver Figura 4.1).


Entrada de Referência para Objeto Local Fixada

VM BetaVM Alpha

.........yx y... ...

Legenda

Figura 4.1 Objeto Y fixado por meio de primitiva e o objeto X disponıvel para movimentacao.

4.2 Pre-requisitos para migracao

Na Virtuosi o unico pre-requisito existente para que um objeto possa ser migrado, e que ele

nao esteja fixado por forca de alguma primitiva. Caso a primitiva move seja invocada para

um objeto fixado, sera disparada uma excecao.

4.3 Mecanismo

Nesta secao e descrito passo a passo o mecanismo de migracao de objetos para a Virtuosi. A

questao da mobilidade de atividades sera descrita em seguida, fora da sequencia cronologica

do protocolo, para facilitar o entendimento. Algumas consideracoes sobre o protocolo fina-

lizam a secao.

4.3.1 Protocolo de Mobilidade

A movimentacao do objeto ocorre sempre quando a primitiva move e invocada. O protocolo

de mobilidade possui tres passos. O cenario inicial descrito pelas Figuras 4.2 e 4.3 sera

utilizado para demonstrar cada um dos passos.

PASSO 1: Verificacao da necessidade da classe. (a) O objeto a ser migrado envia


5

��

��

��

��

��

��

X ZY

VM Alpha VM Beta

8 9...

make(L

)

bigger(Y)

......m

ake() ...

... ...

make(Z

)

calc()

sum(Y

,Y)Y

4 5 10 11 6 712 13

...

...

...

sum(Y

,Y)Y

make(L

)

make()

YZ...4

Figura 4.2 Cenario inicial antes da migracao do objeto X para a MVV Beta.

...Objetos

Tabela deObjetos

MV Alpha MV Beta

... ... z

45 8 11

x z... ...y1 y2

4... Tabela de


uma mensagem informando o nome de sua classe para a MVV destino. (b) A partir do

nome recebido, a MVV destino identifica a existencia ou nao da classe. A identificacao

e feita pela busca na Tabela de Classes de uma entrada cujo o atributo nome seja igual

ao nome transmitido pela MVV origem. (c) Uma mensagem e retornada informando

o resultado da busca. (d) Caso se confirme a existencia da classe, o PASSO 2 do

protocolo nao sera executado, seguindo diretamente ao PASSO 3.

PASSO 2: Replicacao da classe. (a) Sao criadas duas tabelas auxiliares com as in-

formacoes das referencias externas da classe. Estas tabelas sao criadas a partir das

informacoes da Lista de Referencias a Classes e da Lista de Referencia a Invocaveis


Lista para Invocáveis

Refer &Y

Nome

&Z

Y Z

Nome ZY

Tabela Auxiliar para Classes

VM Alpha Beta

Id 8 4

Nome Y.bigger(Y) Y.make(L) Z.make() Z.sum(Y,Y)Y

Id

VM Alpha

4

Alpha BetaBeta

5 6 7

Tabela Auxiliar para Invocáveis

Lista para Classes

Refer

Nome

&(Y.bigger(Y))

Y.bigger(Y) Y.make(L)

&(Y.make(L)) &(Z.make()) &(Z.sum(Y,Y)Y)

Z.sum(Y,Y)YZ.make()

Figura 4.4 Demonstracao das tabelas de referencia auxiliares para Classes e Invocaveis perti-

nentes a classe X, geradas a partir das informacoes das listas de referencias, da Tabela de Classes

e da Tabela de Invocaveis conforme Figura 4.2.

(secao 3.2). Cada item destas listas e substituıdo por uma referencia composta pelo

identificador da MVV e o Id da respectiva entrada para a classe ou invocavel. No caso

da entrada ser uma referencia remota, a referencia apontada pela entrada e atribuıda

a tabela, senao e atribuıda a propria entrada (ver Figura 4.4). A arvore de programa

da Classe e as tabelas auxiliares sao serializadas e enviadas para a MVV destino. (b)

A arvore de programa e as tabelas sao restauradas na MVV destino. O carregamento

da classe e iniciado. No carregamento de uma classe replicada, o subsistema de carga

de arvores de programa (secao 3.3.2) realiza uma sequencia de acoes diferenciada:

(1) Carregar a arvore de programa na area de classes.

(2) Para cada referencia da classe, procurar pela entrada correspondente na Tabela

de Classes. Caso nao encontre, criar uma nova entrada remota e atribuir as

informacoes da linha da tabela auxiliar para a classe correspondente. Atualizar a

referencia para entrada.

(3) Para cada referencia a um invocavel, procurar pela entrada correspondente na

Tabela de Invocaveis. Caso nao encontre, criar uma nova entrada remota e atribuir

as informacoes da linha da tabela auxiliar para invocaveis correspondente. Atu-

alizar a referencia para entrada.

(4) Substituir a entrada remota, ou caso nao exista, criar uma nova entrada local na

Tabela de Classes para a propria classe cuja arvore foi carregada. Ligar a entrada

a classe.

(5) Substituir as entradas remotas, ou caso nao existam, criar novas entradas locais


Nome MV Id

y1 Alpha 4

y2 Alpha 5

z Beta 11

Tabela 4.1 Tabela de referencia auxiliar para Objetos, gerada a partir do cenarios descrito na

Figura 4.3

na Tabela de Invocaveis para os proprios invocaveis cuja arvore foi carregada.

Ligar as entradas aos invocaveis.

Ao fim das acoes, a classe estara carregada e todas as suas referencias atualizadas (ver

Figura 4.5). Nas Figuras 4.2 e 4.5 temos respectivamente o cenario inicial e final da

migracao da classe X.

PASSO 3: Migracao do objeto. (a) Pela alteracao da flag freeze (secao 3.3.3) o objeto

torna-se indisponıvel para alteracoes de estado. Somente acessos de leitura continuam

sendo possıveis. (b) E criada uma tabela auxiliar com as informacoes das referencias

do objeto. Para cada referencia do objeto, cria-se uma referencia composta pelo iden-

tificador da MVV e o Id da respectiva entrada (ver Tabela 4.1). No caso da entrada ser

uma referencia remota, o objeto apontado pela entrada e atribuıdo a tabela, senao a

propria entrada e atribuıda. O objeto mais a tabela auxiliar sao serializados e enviados

para a MVV destino. (c) Com o recebimento das estruturas, a MVV destino inicia o

processo de instanciacao do objeto conforme as seguintes acoes:

(1) Carregar o objeto na area de objetos.

(2) Para cada referencia do objeto, procurar pela entrada correspondente na Tabela

de Objetos. Caso nao encontre, criar uma nova entrada remota e atribuir as

informacoes da respectiva linha da tabela auxiliar.

(3) Criar uma nova estrutura de entrada local para o objeto sem adiciona-la na Tabela

de Objetos.

(4) Procurar por uma entrada correspondente ao objeto na Tabela de Objetos.

(5) Se encontrar, armazenar o Id (identificado da posicao). Se nao, reservar uma

entrada na Tabela de Objetos e armazenar o Id.


14

��

��

��

��

��

��

��

��

X ZY

VM Alpha VM Beta

8 9...

make(L

)

bigger(Y)

......m

ake() ...

... ...

make(Z

)

calc()

sum(Y

,Y)Y

4 5 10 11 6 712 13

...

...

sum(Y

,Y)Y

make(L

)

make()

YZ...4 5

...

calc()

make(Z

)

bigger(Y)

X

12

13 15

Figura 4.5 Cenario final apos a migracao da Classe X para a MVV Beta, baseado no Cenario

inicial da Figura 4.2.

...Tabela deObjetos

Tabela deObjetos

MV Alpha MV Beta

zz... ...y1 y2... ... y1y2x

4 7 8 911854

x...

Figura 4.6 Cenario final apos a migracao do objeto X para a MVV Beta, baseado no Cenario


Os blocos de dados e os enumerados que possam fazer parte do objeto nao sao alterados.

(d) Uma mensagem contendo o Id da posicao da tabela armazenada e retornada a MVV

origem. (e) Com o Id recebido mais a identificacao da MVV destino, a entrada local

do objeto migrado na MVV origem e substituıda por um entrada remota (ver Figura

4.6). (f) A MVV origem notifica o termino da transacao para a MVV destino. (g) A

MVV destino adiciona a entrada local para o objeto na posicao armazenada da Tabela

de Objetos. Nas Figuras 4.3 e 4.6 temos respectivamente o cenario inicial e final da

migracao do objeto x.


4.3.2 Mecanismo de Mobilidade de Atividades

Diferentemente do DistributedOz, a Virtuosi permite que objetos com atividades possam

ser movimentados. A implementacao deste mecanismo tem um custo caro para o sistema,

ja que e preciso relacionar as atividades com o objeto que as gerou. A abordagem escolhida

para a Virtuosi e semelhante a adotada pelo Emerald.

O processo de movimentacao das atividades pertence ao PASSO 3. Antes do congelamen-

to do objeto – PASSO 3(a) – o processo de movimentacao das atividade e iniciado. Todas

as atividade vinculadas ao objeto estao registradas na Tabela de Referencia para Atividades

conforme descrito na Arquitetura da Virtuosi (Capıtulo 4 - Estrutura do Objeto). (a) Para

cada atividade do objeto, as seguintes acoes sao efetuadas:

(1) Verificar se a atividade ja nao foi congelada.

(2) Identificar se ha 1atividades consecutivas pertencentes ao mesmo objeto.

(3) Congelar a atividade corrente mais todas as atividades identificadas.

(4) Se existir uma atividade imediatamente abaixo das atividades congeladas:

(a) Selecionar a atividade.

(b) Transformar a atividade selecionada em um atividade invocadora remota.

(c) Transformar a atividade da base das atividades congeladas em um atividade

invocada remota com referencia a atividade invocadora remota.

(d) Atualizar a referencia da atividade invocadora remota para a atividade invocada

remota.

(5) Se existir uma atividade imediatamente acima das atividades congeladas:

(a) Selecionar a atividade.

(b) Transformar a atividade do topo das atividades congeladas em um atividade

invocadora remota.

(c) Transformar a atividade selecionada em um atividade invocada remota com re-

ferencia para a atividade invocadora remota.

(d) Atualizar a referencia da atividade invocadora remota para a atividade invocada

remota.


Z

Lista de Atividades de x

{C,D,E,F,G}

��

��

x

x

x

x

x

Pilha P2

C

B

D

E

F

G

H

I

Pilha P1

VM BetaVM Alpha VM Gama

A

W


(6) Copiar e agrupar as atividade congeladas preservando a ordem em que se encontram

na pilha.

Caso a atividade a ser transformada ja for uma atividade invocada remota ou invocadora

remota esta assumira os dois papeis. (b) O objeto e congelado e a tabela auxiliar e criada

como no PASSO 3. Para cada variavel local e parametro da atividade deve ser incluso um

registro na tabela auxiliar de objetos da mesma forma como acontece para as referencias

do objeto. Juntamente com a tabela auxiliar e o objeto, as atividades sao serializadas e

enviadas. (c) Apos a instanciacao do objeto na MVV destino (PASSO 3(c)), procede-se com

a seguintes acoes:

(1) Para cada variavel local ou parametro de cada atividade, procurar pela entrada cor-

respondente na Tabela de Objetos. Caso nao encontre, criar uma nova entrada remota

e atribuir as informacoes da respectiva linha da tabela auxiliar. Ligar a entrada a

variavel ou parametro.

(2) Atualizar a referencia da atividade para o objeto e para o invocavel.

(3) Criar uma pilha de execucao para cada grupo de atividades e bloquear.

(d) Junto com a mensagem do Id da entrada do objeto (PASSO 3(d)), retorna-se a referencia

de cada atividade invocada ou invocadora remota que tenha sido transferida.(e) A MVV

1Atividades Consecutivas: Conjunto de atividades em uma mesma pilha de execucao que necessariamenteestao dispostas uma sobre a outra sem sofrer segmentacao por outras atividades que nao pertencem ao grupo.


D

Lista de Atividades de x

{C,D,E,F,G}

��W

Z

��

��

��

��

Pilha P1

A

B

VM Alpha

H

I

x

x

x

x

x

F

E

G

VM Beta VM Gama

Pilha P1

Pilha P2

Pilha P2

Pilha P1

C

Figura 4.8 Cenario final depois da migracao do objeto X para a MVV Beta, baseado no Cenario


origem atualiza as referencias das atividades locais que foram transformadas em atividades

invocadas e invocadoras remotas. Para as possıveis atividades remotas que referenciam as

atividades transferidas, uma mensagem e envidada para as respectivas MVVs informando

os novos enderecos. Aguarda-se a confirmacao de retorno de cada uma das atividades re-

motas. (f) Notifica-se a MVV destino do fim da transacao. As pilhas de execucao entao

sao desbloqueadas e o protocolo de mobilidade e concluıdo. Nas Figuras 4.7 e 4.8 temos

respectivamente o cenario inicial e final da migracao das atividade do objeto x.

No caso de alguma atividade migrada invocada ou invocadora remota possuir somente

referencias para atividades da MVV destino, a atividade migrada nao retornara sua referencia

para MVV origem (etapa (d)). A propria atividade, apos a notificacao de conclusao da

transacao, atualizara as referencias somando suas pilhas as das atividades ja existentes no

destino (ver Figuras 4.9 e 4.10).

No exemplo descrito na Figura 4.7, existem tres MVVs Alpha, Beta e Gama. O objeto

x situado na MVV Alpha (origem), sera migrado para a MVV Beta (destino). A atividade

remota W residente na MVV Gama relaciona-se com a atividade E do objeto x. Segue a


MVV Alpha

��

��A

B

Pilha P2

C

D

Pilha P1

Figura 4.9 Cenario onde duas pilhas de execucao possuem referencias entre suas atividades

localmente.

MVV Alpha

Pilha P1

A

B

C

D

Figura 4.10 Cenario final apos resolucao das referencias locais entre atividades.


descricao detalhada das principais etapas do protocolo para este exemplo: a) A primeira

atividade selecionada que consta na lista e a atividade C.

(1) A atividade C nao esta congelada.

(2) Identifica a atividade D como sendo consecutiva a C.

(3) A atividade C e D sao congeladas.

(4) Existe uma atividade imediatamente abaixo das atividades congeladas.

(a) A atividade B e selecionada.

(b) B e transformada em uma atividade invocadora remota

(c) A atividade C e transformada em uma atividade invocada remota com referencia

a atividade B.

(d) Atualizar a referencia da atividade B para C.

(5) Nao existem atividades imediatamente acima das atividades congeladas.

(6) As atividades congeladas C e D sao agrupadas e copiadas.

A proxima atividade da lista e a atividade D. Verifica-se que esta congelada. A proxima

atividade e a E.

(1) A atividade E nao esta congelada.

(2) Identifica as atividades F e G como sendo consecutivas a E.

(3) As atividades E, F e G sao congeladas.

(4) Nao existe uma atividade imediatamente abaixo das atividades congeladas.

(5) Existem atividades imediatamente acima das atividades congeladas.

(a) Seleciona a atividade H.

(b) Transforma a ativivade G em um atividade invocadora remota.

(c) Transformar a atividade H em um atividade invocada remota com referencia

para a atividade G.

(d) Atualizar a referencia da atividade G para H.

(6) As atividades congeladas E,F e G sao agrupadas e copiadas.


As proximas atividades da lista sao F e G as quais estao congeladas. Para cada variavel

local e parametro de cada atividade inclui-se um registro na tabela auxiliar de objetos. As

atividades copiadas sao serializadas e enviadas. (c) Na MVV destino cada parametro ou

variavel de cada atividade e tratado como uma referencia de objeto conforme descrito no

PASSO 3(c). Atualizam-se as referencias das atividades migradas para o objeto, e para os

respectivos invocaveis. Criam-se as pilhas P1 e P2. As pilhas criadas sao bloqueadas. (d)

As novas referencias das atividades invocadas remotas E e C, e da atividade invocadora

remota G sao retornadas.(e) A MVV origem atualiza as referencias da atividades invocadora

remota B e invocada remota H para C e G respectivamente. Para a atividade remota W

e enviada uma mensagem informando o novo endereco de E. A atividade W confirma a

alteracao. (f) Notifica-se a MVV destino do fim da transacao. As pilhas de execucao P1 e

P2 sao desbloqueadas e o protolocolo de mobilidade e concluıdo.

4.3.3 Fragmentacao de Referencias

A fragmentacao de referencias se da pela movimentacao dos objetos. Quanto mais dispersos

os objetos se encontram pela rede maior tende a ser a fragmentacao de suas referencias.

Uma referencia remota entre entidades que precise percorrer mais de duas 2 referencias

intermediarias e considerada uma referencia fragmentada. No caso das entidades estarem

situadas localmente, a referencia e considerada fragmentada quando existirem mais de uma

referencia intermediaria. Na cenario descrito pela Figura 4.11, exitem referencias otimizadas

e fragmentadas entre os objetos. Na Figura 4.13 os quatro caminhos das referencias da

Figura 4.11 sao separados. Observe que as referencias b) e d) estao fragmentadas enquanto

a a) e c) estao otimizadas.

As tres entidades da Virtuosi tem comportamento diferenciado para com as referencias

durante a movimentacao. No caso da classe, sempre que o carregador de arvores (secao 3.3.2)

carrega uma classe, necessariamente todas as classes referenciadas sao carregadas localmente.

Seguindo o exemplo da Figura 4.12, a figura (a) monstra o estado inicial apos o carregamento

2Referencias Intermediarias: Estruturas que tem como objetivo redirecionar referencias, nao sendo oobjetivo final do acesso. Na Virtuosi todas as entradas das tabelas de referencias sao consideradas referenciasintermediarias.


... xt x y

VM Beta

y

VM Alpha

zyr ... ... ...

Figura 4.11 Demonstracao da area de objeto onde existem referencias fragmentadas e otimizadas.

das classes. Todas as classes referenciadas devem ser carregadas. Para o exemplo sao as

classes X e Y . Na figura (b), a classe Y e replicada para a MVV Beta passando a referenciar

remotamente a classe X. Na sequencia (c), Y e replicada da MVV Beta para a MVV Gama.

Observa-se que as referencias continuam otimizadas. Independente da replicacao das classes

X e Y para qualquer MVV nunca havera fragmentacao de referencias.

Atividades nao se utilizam de referencias intermediarias entre si, as referencias sempre

sao diretas e bidirecionais. Logo nao existe fragmentacao referencial entre atividades.

O objeto tem por caracterısticas possuir referencias unidirecionais para com outros obje-

tos e sempre de forma indireta. Diferentemente da classe, o objeto nao poder ser replicado,

sendo uma entidade unica no sistema. A partir do objeto referenciado nao e possıvel saber

quais outros objeto o referenciam. Sem esta informacao, nao ha como notificar estes objetos

sobre a nova localizacao do objeto migrado, exceto pela utilizacao de um broadcast, o que

inviabilizaria o sistema para redes maiores. No caso (b) e (d) da Figura 4.13, o protocolo

consegue evitar a fragmentacao identificando previamente na tabela de objetos qualquer re-

ferencia ao nome do objeto recebido. Por esta razao e que se justifica idetificar os objetos com

um nome unico. Na Figura 4.14, o objeto z referencia y remotamente de forma otimizada.

Conforme mostra a Figura 4.15, o objeto y foi migrado para a MVV Gama e consequente-

mente a referencia de z para y tornou-se fragmentada. Quanto mais y prosseguir migrando

para diferentes MVVs, mais fragmentada a referencia se torna. Neste caso o protocolo de

mobilidade e inoperante.


��

��

��

��

XY

make()

bigger(Y)

make()

calc()...... ...

......

VM Alpha

(a) Estado inicial apos o carrega-mento das classes.

��

��

��

��

XY

make()

bigger(Y)

make()

calc()...... ...

......

VM Alpha

��

��

XY

make()

bigger(Y)

calc()...

VM Beta

... ...

......

(b) A classe Y e replicada para a MVV Beta.

...

��

��

XY

make()

bigger(Y)

calc()...

VM Beta

... ...

......

��

��

��

��

��

��

XY

make()

bigger(Y)

make()

calc()...... ...

......

VM Alpha

XY

make()

bigger(Y)

calc()...

VM Gama

... ...

...

(c) Da MVV Beta a classe Y e replicada para a MVV Gama.

Figura 4.12 Demonstracao da sequencia de movimetacoes da classe Y . Cenario iniciado a partir

da conclusao da carga das classes pelo carregador de arvores.

4.3.4 Consideracoes

Existem algumas consideracoes a se fazer sobre o protocolo. A criacao das tabelas auxiliares

para classes e invocaveis geram um custo que poderia ser evitado se subtituıdas pelas Listas

de Referencias a Classes e a Invocaveis. Neste caso, durante a carga do objeto (PASSO 2

- (c)), a MVV destino solicitaria a MVV origem somente as informacoes sobre as entradas


yx x

a) r t

b) t xx

x y

x x

c) x y

d) z y

y

y

t

Figura 4.13 Demonstracao de referencias fragamentadas: as referencias b e c estao fragmentadas

enquanto a a e d estao otimizadas (informacao baseada na Figura 4.11).

VM Beta

y z y ......

VM Alpha

x

Figura 4.14 Cenario onde todas as referencias estao otimizadas.

VM Gama

y...y z y ...... ...

VM Alpha VM Beta

x

Figura 4.15 Cenario apos a migracao do objeto y para a MVV Gama tendo como base a Figura

4.14.


de referencias as quais nao fossem encontradas equivalentes localmente. Como consequencia

terıamos mais dois acessos a rede, a solicitacao e o retorno. Para o protocolo da Virtuosi

sempre prevalece a minimizacao da utilizacao da rede em prol do maior uso de processamento

local.

Mesmo com o esforco despendido pelo mecanismo nao e possıvel manter todas as re-

ferencias atualizadas. Nestes casos a otimizacao das referencias fragmentadas serao deixadas

a cargo do mecanismo de RPC3 ainda a ser desenvolvido.

4.3.5 Tolerancia a Faltas

A seguranca do funcionamento mecanismo e garantida pelo fato de que somente apos a

notificacao de finalizacao da transacao a entrada para o objeto e disponibilizada na Tabela de

Objetos. No caso de uma falha de comunicacao entre as MVVs a integridade fica garantida.

Se ocorrer uma falha de comunicacao apos a conclusao do PASSO 2, nada que foi efetuado ate

o momento sera desfeito pois nenhuma referencia estaria invalida para as classes. No caso da

falha ocorrer durante o PASSO 3, as estruturas montadas na MVV destino sao desprezadas.

Em ambos os casos a MVV origem lanca uma excecao, restabelece as atividades congeladas

caso existam, e disponibiliza o objeto novamente para acesso.

4.3.6 Avaliacao Comparativa

Nesta secao descreve-se o Mecanismo de Migracao da Virtuosi conforme os requisitos de

Integridade, Performance, Confiabilidade e Funcionalidade definidos (secao 2.3) a priori.

Utilizaremos a comparacao com os sistemas Emerald e DistributedOz.

Integridade: O protocolo garante a ordem processual global e a integridade referencial

atraves da atomicidade do mecanismo. O protocolo somente disponibiliza alteracoes

no estado do objeto apos a finalizacao da transacao. Todos as sistemas atendem a este

requisito.

3Remote Procedure Call: Protocolo que um programa pode utilizar para requisitar um servico a outroprograma localizado remotamente, sem que seja necessario o conhecimento de detalhes da rede.


Desempenho: O DistributedOz e superior tanto ao Emerald quanto a Virtuosi por duas

caracterısticas:

(1) Liguagem: O modelo de programcao OPM (secao 2.5.2) permite a total frag-

mentacao do objeto. Com isso somente as partes do codigo da classe que serao

usadas sao replicadas, eliminando a necessidade de transferencia de toda a classe.

(2) Entidades Estacionarias: A definicao de que a atividade e uma entidade esta-

cionaria e de que o estado do objeto e uma entidade movel, elimina todo o custo

acarretado pela mobilidade de atividades.

O Emerald, por utilizar tres tipos de enderecamento para o objeto (secao 2.4.4), con-

segue obter um otimo desempenho nos processos que ocorrem localmente. A Virtuosi

utiliza o conceito de handle tables como padrao de enderecamento entre as entidades.

Embora reduza a complexidade, gera-se um custo maior que o Emerald para os pro-

cessamentos locais, ja que a referencias sao sempre indiretas. Porem o mecanismo de

handle table facilita e agiliza o processo de coleta de lixo [HU et al., 2003].

O desempenho do mecanismo de mobilidade da Virtuosi, ignorando-se a movimentacao

de atividades, e representado atraves das variaveis abaixo:

Custo = Numero total de entradas de referencias incluıdas e alteradas nas tabelas de

classes, invocaveis e objetos.

ro = Numero de referencias para outros objetos.

rc = Numero de referencias para outras classes.

ri = Numero de referencias para invocaveis de outras classes.

ni = Numero de invocaveis da classe.

n = Numero de movimentacoes do objeto.

Para um cenario onde, a migracao do objeto ocorra para nodos onde previamente nao

existam a classe do objeto e nem outros objetos que sejam referenciados por este,

utilizamos a seguinte equacao:

Custo = n(ro + 2) + n(rc + 1) + n(ri + ni)


Confiabilidade: Na Virtuosi e no Emerald, a fragmentacao de referencias causada pela

movimentacao dos objetos gera uma dependencia de um maior numero de pontos da

rede do que no caso que estas tivessem otimizadas. Isto fragiliza a confiabilidade do

mecanismo em caso de falha de um nodo o qual faz parte do caminho da referencia. No

DistributedOz, a referencia ao estado do objeto nunca passa de duas referencias inter-

mediarias, reduzindo o risco de uma falha romper o caminho de uma referencia. Por

outro lado, no caso de uma deteccao previa de uma futura falha ou uma manutencao

preventiva em algum nodo do sistema, o DistributedOz nao tem como mover as en-

tidades estacionarias para outro lugar, sendo inevitavel aguardar o fim de todas as

atividades daquele nodo antes do desligamento.

Funcionalidade: Embora o Emerald disponibilize primitivas de mobilidade para a progra-

macao, nao ha garantia que ela seja efetivamente executada. Isto porque o fluxo de

mobilidade dos objetos e determinado em tempo de compilacao. No DistributedOz, o

sistema pre-define quais objetos sao moveis ou estacionarios, tambem ja determinando

o fluxo de mobilidade. Na Virtuosi, a migracao so ocorre por forca de primitiva. Isto

permite que seja agregado ao sistema mecanismos de distribuicao de carga modulares

e viabiliza o suporte a agentes por permitir autonomia de mobilidade.

Com esta avaliacao comparativa demonstramos que o Mecanismo de Mobilidade de Ob-

jetos desenvolvido para a Virtuosi atinge os requisitos estabelecidos. Atendendo de forma

satisfatoria as necessidades do sistema.

97

Capıtulo 5

Estudo de Cenarios

Sera demonstrado atraves de estudo de cenarios o comportamento do protocolo de migracao

da Virtuosi. Os cenarios serao expressos pela notacao grafica da Vituosi e pela linguagem

ARAM. Todos os cenarios sempre iniciam pelo metodo start() da classe Start. Esta classe

somente sera utilizada para auxiliar a formacao do cenario e nao sera representada dentro

da MVV.

5.1 Cenario 1

O cenario 1 e a situacao mais simples de migracao. A transferencia do TAD nao e necessaria,

pelo fato do TAD do objeto a ser migrado ja existir na MVV destino. O objeto x referencia

y unidirecionalmente e y nao possui referencias para outros objetos. Nao sera demonstrada

a area de atividades.

Codigo em ARAM:

class y {

constructor make ( ) exports (all) { }

}

class X {

Y y;

constructor make ( ) exports (all) {

y = Y.make();

y.migrate("VMBeta");

}

}

Capıtulo 5. Estudo de Cenarios 98

move

��

��

��

��

��

��

...

VM Alpha VM Beta

X Y

make

...

...

...

...x y

Y

...

...

...

...

...

...

make...

...

...

...

make

move

Figura 5.1 Cenario 1 (a): Disposicao inicial das entidades e sua referencias.

class Start {

void method start ( ) exports (all) {

X x;

x = x.make();

}

}

Resolucao: O PASSO 1 do protocolo identifica que a classe ja existe na MVV destino,

consequentemente o PASSO 2 nao e executado. O PASSO 3 cria uma nova entrada local

na MVV destino para o objeto. A entrada de referencia local passa a ser remota na MVV

origem.

5.2 Cenario 2

Neste contexto teremos dois objetos sendo que existe uma referencia bidirecional entre eles.

O objeto migrado precisara referenciar o outro que permaneceu na VM origem remotamente.

A classe do objeto migrado nao existe na MVV destino. Tambem nao existem referencias a


move

��

��

��

��

��

��

VM Alpha VM Beta

X Y

make ...

...

...x

Y

... ...

...

...

make

.........

make

y y

...

...

... ...

...

......

move

Figura 5.2 Cenario 1 (b): Objeto Y ja migrado para a MVV Beta.

invocaveis de ambas as classes. Nao sera demonstrada a area de atividades.

Codigo em ARAM:

class Y {

X x;

constructor make () exports (all) { }

void method setX (X px) exports (all) {

x = px;

}

}

class X {

Y y;

constructor make () exports (all) {

y = Y.make();

}

Y method getY () exports (all) {

return y;

}

}

class Start {



getY

��

��

��

��

VM Alpha VM Beta

X Y

make

...

make

...

...

...

x y ......

...

...

...

...

......

... ...

setX

move

Figura 5.3 Cenario 2 (a): Disposicao inicial das entidades e sua referencias.

X x = X.make();

Y y = x.getY();

y.setX(x);

x.move(MVVBeta);

}

}

Resolucao: O PASSO 1 do protocolo identifica que a classe nao existe na MVV destino.

O PASSO 2 copia a classe e cria referencias remotas para classe Y e para o invocavel make

de Y . O PASSO 3 cria uma nova entrada local para x e uma entrada remota para y na MVV

destino. A entrada local de x na MVV origem e transformada em uma entrada remota.

Este cenario atende as restricoes para a aplicacao da formula de desempenho. Com isto

e obtido o custo de atualizacao das referencias (ver Secao 4.3.6):

Custo = n(ro + 2) + n(rc + 1) + n(ri + ni)

Custo = 1(1 + 2) + 1(1 + 1) + 1(1 + 3)

Custo = 9


make

��

��

��

��

��

��

VM Alpha VM Beta

X ......

x

Y

make

move

setYX ...

make

...

... x y ......

...

...

setX

Y

make

move

setY ...

...

... ...y

... ...

make

make

make

make

Figura 5.4 Cenario 2 (b): Objeto Y ja migrado para a VM Beta.

5.3 Cenario 3

Partindo do final do Cenario anterior (Figura 5.4), moveremos o objeto x para uma terceira

MVV Gama onde nao existe a classe X. O codigo das classes X,Y e Start e mantido conforme

Cenario 2, exceto pela adicao da primitiva x.move(MV V Gama) ao final do metodo start().

A configuracao final e demonstrada na Figura 5.5.

Codigo em ARAM:

class Start {


X x = X.make();

Y y = x.getY();

y.setX(x);

x.move(MVVBeta);

x.move(MVVGama); // Linha acionada

}

}


y

��

��

��

��

��

��

��

��

VM Alpha

X ...

make

...

...

...

setX

Y

make

move

setY

...

... x y ......

VM Gama

X ...... Y

make

move

setY ...

...

...

make

... ...x

VM Beta

X ...... Y

make

move

setY ...

...

...

make

x... ...y

Figura 5.5 Cenario 3: Disposicao das entidades ao final do codigo do metodo start().

Resolucao: O PASSO 1 do protocolo identifica que a classe X nao existe na MVV

Gama. O PASSO 2 copia a classe e cria referencias remotas para classe Y e para o invocavel

make de Y . Para as classes nao ha fragmentacao de referencias. O PASSO 3 cria uma nova

entrada local para x e uma entrada remota para y na MVV Gama. A entrada local de x na

MVV Beta e transformada em uma entrada remota. Observe que a referencia do objeto y

para o x torna-se fragmentada.

5.4 Cenario 4

Este Cenario e composto por tres classes X,Y e Calc. O objetivo destas classes e que atraves

de reducao ou incremento do objeto y declarado no metodo calc da classes Calc, este torne-se

igual ao numero interno de x, que no caso e 23. Antes da migracao ocorrer – conforme linha

11 da classe X – teremos a pilha de atividades descrita na Figura 5.6.

1 class X {

2 Y y;

3

4 constructor make () exports (all) {


5 y = Y.make(23); // Numero secreto

6 }

7

8 method void test(Y p) exports all {

9

10 if (y.equals(p)) // Encontrou o numero

11 move(MVVBeta); // Move para Beta

12 return;

13 else {

14 if (y.greater(p))

15 p.more();

16 else

17 p.less();

17 }

18 }

19 }

1 class Y {

2 datablock value1;

3 X x;

4

5 contructor make(Literal k) {

6 value2 = datablock.createDataBlock(32);

7 value2.storeInteger(k);

8 }

9 void setX(X p) {

10 x = p;

11 }

12 void method less(){

13 value.addInteger(-1);

14 x.test(this);

15 }

16 void method more(){

17 value.addInteger(1);

18 x.test(this);

19 }

20 action equals(Y y){ // Se o parametro for igual

21 if (value.equals(y.value)) // que o value, executa

22 execute;

23 else


24 skip;

25 }

26 action grater(Y y){ // Se o parametro for maior

27 if (value.greater(y.value)) // que o value, executa

28 execute;

29 else

30 skip;

31 }

32 }

1 class Calc {

2

3 constructor make() {

4 ...

5 calc();

6 }

7

8 void method calc() {

9 X x = X.make();

10 Y x = make(22);

11 Y.setX(x);

12 x.test(y)

13 }

14 }

1 class Start {

2

3 void method start() {

4 C c = C.make();

5 }

6 }

Resolucao: Na migracao das atividades do objeto x foi necessario transformar qua-

tro atividades da pilha P1 em uma atividade invocadora remota (c.calc), duas atividades

invocada invocadora remotas (x.test) e uma atividade invocada remota (y.more). Nao hou-

ve envio de mensagens a outras MVVs pois originalmente todas a atividades migradas eram

atividade normais.


c

VM Alpha VM Beta

c

x

y

x

calc

test

more

test

Pilha P1

make

Figura 5.6 Cenario 4: Disposicao incial das atividades.

calc

��Pilha P2

xtesttest

��

��

makec

��

VM Alpha VM Beta

Pilha P1x

testtesttest

Pilha P2y

moremore

Pilha P1c

calc

Figura 5.7 Cenario 4: Disposicao das atividade apos a migracao do objeto x.

106

Capıtulo 6

Implementacao

O mecanismo foi implementado sobre o prototipo da MVV desenvolvido no trabalho que

definiu o modelo de execucao das arvores de programa da Virtuosi [Kolb, 2004]. Este

prototipo foi implementado com o objetivo de validar o metamodelo da Virtuosi e o uso

de arvores de programa como representacao intermediaria para maquinas virtuais.

6.1 Ambiente

Para a construcao do prototipo foi utilizada a linguagem de programacao Java pelo fato

do prototipo original da MVV ja ter adotado esta linguagem. O ambiente distribuıdo foi

elaborado por um rede composta por dois computadores comunicando-se atraves do pro-

tocolo TCP/IP. Optou-se pela utlizacao de Sockets por ser um conceito fundamental sem

depedencia, diferente, por exemplo, de RMI. Durante os testes, cada instancia da MV Java

executou uma instancia da MVV, sendo possıvel abrir mais que uma MV Java em cada

computador. Sob a MV Java utilizamos o sistema operacional Windows 2000.

6.2 Limitacoes

A implementacao do mecanismo de mobilidade tem algumas limitacoes ao modelo proposto

no Capıtulo 4:

(1) nao consegue migrar objetos com atividades;

Capıtulo 6. Implementacao 107

(2) nao existe um servico de nomes para os nodos. Previamente no programa ja deveria

constar o nome e porta de comunicacao do nodo destino;

O prototipo MVV no qual o mecanismo foi implementado tambem possui algumas limi-

tacoes:

(1) da suporte somente a interpretacao de uma pilha de atividades por instancia da MVV,

de forma que somente invocacoes sıncronas podem ser interpretadas1;

(2) nao da suporte a heranca entre classes de aplicacao, embora o metamodelo da Virtuosi

de suporte a esta propriedade;

6.3 Diagrama de Classes da MVV

A Figura 6.1 mostra um diagrama de classes com as principais classes que compoem a

MVV. As classes VM, ObjectTable, ObjectTableEntry, InvocableTable e TreeTable foram

estendidas para atender a mobilidade.

As funcionalidades necessarias a distribuicao da MVV foram implementadas nas seguintes

classes:

VMD: E a extensao da classe VM. A partir desta classe foram implementados os servicos

de comunicacao de rede.

ObjectTableD: Gerada como extensao da classe ObjectTable, foi implementada com a

funcao de buscar entradas de referencias tendo como ındice o nome do objeto. A classe

representa a tabela de objetos.

ObjectTableEntryD: Foi adicionado o atributo fix e os respectivos metodos de atuali-

zacao. A classe representa a tabela de objetos.

InvocableTableD : Implementacao semelhante ao ObjetTableD. A classe representa a

tabela de invocaveis.

TreeTableD : Implementacao semelhante ao ObjetTableD. A classe representa a tabela de

classes.

1Concorrencia e objeto de estudo de outra dissertacao de mestrado.


ObjectTableEntryD

ObjectTable ObjectTableEntry Object

InvocableTableEntryInvocableTable

VM

ObjectArea

TreeTableEntry

ActivityStack Activity

TreeArea

0..*

0..*

0..*

0..*

VMD

ObjectTableD

0..*

TreeTable

TreeTableD

InvocableTableD

Figura 6.1 Diagrama das principais classes da Maquina Virtual Virtuosi

6.4 Ciclo de Vida da MVV em Termos das Classes que

a Compoem

No inıcio do ciclo de vida o metodo estatico start da classe VM e invocado. Este – o metodo

start – recebe dois parametros: o nome da classe de aplicacao inicial e o nome do construtor

que deve ser interpretado. Apos isso, os seguintes passos sao executados dentro do metodo

start.

(1) A tabela de arvores e inicializada;

(2) A tabela de invocaveis e inicializada;

(3) A tabela de objetos e inicializada;

(4) A area de arvores e inicializada;


(5) A area de objetos e inicializada;

(6) O controlador de nomes de objeto e inicializado;

(7) A area de atividades e inicializada;

(8) A MVV invoca o carregador de arvores passando como parametro o nome da classe

de aplicacao inicial. O carregador, atraves de um processo recursivo ja descrito na

Secao 3.3.2, carrega para a area de arvores todas as arvores correspondentes as classes

utilizadas pela aplicacao. Deve-se notar que o carregador de arvores cria todas as

entradas necessarias nas tabelas de arvore e tabela de invocaveis, alem de resolver

todas as referencias simbolicas entre arvores;

(9) A MVV cria um objeto na classe de aplicacao (um nome unico para o objeto e o nome

da classe de aplicacao sao fornecidos como parametros) inicial e recupera a respectiva

entrada na tabela de objetos;

(10) Com a entrada na tabela de objetos do objeto recem criado, a entrada na tabela de in-

vocaveis que aponta para o construtor inicial (para recuperar a entrada na tabela de in-

vocaveis deve-se invocar um metodo da tabela de invocaveis passando como parametro

o nome do construtor, o nome da classe que o possui e a concatenacao dos tipos de

seus parametros) e um conjunto de parametros (neste caso vazio), a MVV cria uma

nova atividade – a atividade inicial;

(11) A MVV entao adiciona a atividade inicial ao topo da pilha de atividades (neste mo-

mento vazia). A pilha de atividades entao e encarregada de dar inıcio a interpretacao

da atividade;

(12) Apos o final da interpretacao da atividade inicial, e por consequencia o final da inter-

pretacao da aplicacao, a MVV retira a atividade inicial do topo da pilha de atividades

e a MVV termina sua computacao;

6.5 Tabela de Referencias

As tabelas de referencias foram definidas como colecoes de objetos em Java. Nestas colecoes

existem entradas para refencias locais e remotas. As entradas locais sao compostas por

um nome, uma referencia a entidade a que se refere, um campo indicando se o objeto esta


fixado e outro campo indicando se esta congelado. Para a entrada remota a unica diferenca

seria que a referencia para a entidade e composta pelo endereco de rede mais a porta de

comunicacao da MVV destino e a posicao onde se encontra a entrada de referencia para o

objetivo alvo.

6.6 Programacao das Primitivas

As primitivas de mobilidade foram programadas no nıvel do metamodelo. Para isto ele

foi estendido com a criacao de uma chamada de sistema para cada primitiva. Com isto

atendemos o requisito de que o mecanismo e intrınseco ao sistema, ja que a mobilidade e

disponibilizada no mesmo nıvel das chamadas do sistema e nao adicionando-se uma camada

a uma linguagem centralizada existente.

6.7 Cenarios de Testes

Foram elaborados os seguintes cenarios para validar o mecanismo de mobilidade:

Cenario 1

MVV Alpha MVV Beta

Uma classe X sem referencia a outras Sem classes

Um objeto x sem referencia a outros Sem objetos

Execucao: O objeto x e movimentado para a MVV Beta.

O validacao dos resultados dos cenarios foram obtidas atraves de logs geradas pela im-

plementacao da MVV. Nestas logs constavam todo o conteudo das tabelas referencias e das

estruturas de todos os objetos instanciados. A cada etapa de cada passo as informacoes

eram colhidas e verificadas.


Cenario 2

MVV Alpha MVV Beta

Duas classes X e Y . Y referenciando X.

Dois objetos x e y. y referenciando x.

Sem classes e sem objetos

Execucao: O objeto x e movimentado para a MVV Beta.

Cenario 3

MVV Alpha MVV Beta

Duas classes X e Y . Y referenciando X e

Z. y referenciando x e z.

Uma classe Z e um objeto z

Execucao: O objeto y e movimentado para a MVV Beta.

Cenario 4

MVV Alpha MVV Beta


Z. Dois objetos x e y. y referenciando x e

z.

Uma classe Z e um objeto z

Execucao: O objeto z e movimentado para a MVV Alpha.

Cenario 5

MVV Alpha MVV Beta

Tres classes X, Y e Z. Y referenciando X,

e Z referenciando X. Tres objetos x, y e

z. y referenciando x, e z referenciando x.

Sem classe sem objetos

Execucao: O objeto z, x e y sao movimentado para a MVV Beta respectivamente.


Cenario 6

MVV Alpha MVV Beta MVV Gama

Tres classes X, Y e Z. To-

das se referenciam. Tres ob-

jetos x,y e z. Todos se ref-

erenciam.

Sem classe sem objetos Sem classe sem objetos

Execucao: Os objeto x e movimentado para a MVV Beta, e depois para a MVV

Gama. O mesmo ocorre com y e x respectivamente.

Cenario 7

MVV Alpha MVV Beta


Z, e Z referenciando Y . Dois objetos y e

x. y referenciando x e z.

Duas classes Y e Z. Um objeto z referen-

ciando y.

Execucao: O objeto z e movimentado para a MVV Alpha e depois retorna para a

MVV Beta.

113

Capıtulo 7

Conclusao e Trabalhos Futuros

O mecanismo de mobilidade de objetos para a Vituosi proposto neste trabalho atende os

requisitos de Integridade, Desempenho, Seguranca e Funcionalidade definidos (secao 2.3).

Na avaliacao comparativa com Emerald e Distributet Oz, o mecanismo de mobilidade da

Virtuosi obteve uma posicao satisfatoria nos aspectos mais relevantes aos objetivos da mesma

(pedagogico e experimental). Ja esta previsto no mecanismo, a mobilidade de objetos ativos,

o que e um requisito para atender a especificacao CORBA para agentes (MAF).

7.1 Contribuicao Cientıfica

O trabalho desenvolvido nesta dissertacao de mestrado traz uma contribuicao cientıfica nos

seguintes aspectos:

• Serve como base para o desenvolvimento de outros mecanismos de mobilidade de ob-

jetos.

• Formaliza o mecanismo de mobilidade para a Virtuosi.

• Valida o mecanismo de referencias indiretas atraves de handle tables

• Oferece suporte a mobilidade de objetos ativos, o que e um requisito importante para

o suporte a agentes.

7.2 Trabalhos Futuros

Atraves do desenvolvimento deste trabalho e possıvel prever os seguintes trabalhos futuros:

Capıtulo 7. Conclusao e Trabalhos Futuros 114

• Conclusao e melhorias na implementacao e modelo do mecanismo:

– Implementar a movimentacao de atividades.

– Elaborar uma avaliacao de desempenho do mecanismo.

– Permitir a mobilidade de grupos de objetos.

– Projetar modelo de seguranca (seguranca contra intrusos, autenticacao e per-

missoes de acesso).

– Criacao de um servico de nomes para as MVVS.

• Trabalhos que utilizarao como base o mecanismo:

– Mecanismo de RPC.

– Mecanismo de balanceamento de carga.

– Suporte a agentes.

Portanto, o trabalho atingiu um nıvel de robustez, tanto conceitual quanto operacional, a

ponto de permitir a sua propria evolucao de forma estruturada, alem de permitir a interacao

com outros modulos a ele relacionados na Arquitetura da Virtuosi.

115

Apendice A

Metamodelo da Virtuosi

Esse Capıtulo especifica os conceitos de orientacao a objeto suportados pela Virtuosi

atraves da formalizacao do metamodelo da Virtuosi.

Para auxiliar o entendimento dos conceitos explicados ao longo desse capıtulo, serao

utilizados trechos de codigo fonte de uma aplicacao de software orientado a objeto escritos

na linguagem Aram1.

A.1 Especificacao

Os conceitos de orientacao a objeto suportados pela Virtuosi sao formalizados atraves de um

diagrama de classes UML chamado de metamodelo da Virtuosi. O metamodelo da virtuosi

possui classes e associacoes que representam os elementos encontrados em uma linguagem

de programacao orientada a objeto que suporte aos conceitos suportados pela Virtuosi. Por

isso, as classes do metamodelo podem ser chamadas de meta-classes. Por exemplo, uma

classe possui atributos; o metamodelo da Virtuosi, portanto, possui uma meta-classe para

representar uma classe de aplicacao, uma meta-classe para representar um atributo e atraves

de uma associacao, explicita se uma classe possui zero ou muitos atributos. O metamodelo

da Virtuosi pode ser entendido como um diagrama de classes que descreve conceitos de

orientacao a objeto e a forma como tais conceitos se relacionam entre si.

1Aram e uma linguagem de programacao que da suporte aos conceitos de orientacao a objeto definidospelo metamodelo da Virtuosi

Apendice A. Metamodelo da Virtuosi 116

A.1.1 Literais

Valor Literal

Um valor literal e uma sequencia de caracteres sem semantica definida. Um valor literal

pode existir como:

(1) parametro real em comandos de invocacao;

(2) origem da atribuicao em comandos de atribuicao de variaveis enumeradas;

(3) segundo elemento em comandos de comparacao de valor em variaveis enumeradas.

A Figura A.1 mostra o uso de valores literais em cada uma das situacoes supracitadas.

Referencia a Literais

E uma meta-classe que representa uma referencia a literal se relaciona atraves de asso-

ciacoes com outros componentes do metamodelo da Virtuosi nas seguintes situacoes:

(1) como parametro formal;

(2) como parametro real;

(3) como origem de atribuicao em um comando de atribuicao de variavel enumerada;

(4) com uma das possibilidades para o segundo elemento de uma comparacao de valor de

variavel enumerada.

Deve-se notar que uma referencia a literal no papel de parametro real nao pode sofrer

atribuicao – uma vez que nao existe uma meta-classe que represente o comando de atribuicao

para referencia a literal. Tambem nao e possıvel declarar uma variavel local do tipo referencia

a literal, visto que nao existe uma meta-classe que represente o comando para declarar

variaveis do tipo referencia a literal.

A Figura A.2 mostra o relacionamento das meta-classes que representam valores literais

e referencias a literal com outros componentes do metamodelo da Virtuosi.

O uso de um valor literal e de uma referencia a literal e detalhado na Secao A.1.7,

especificamente na discussao sobre comandos de declaracao de variaveis.


class Principal

{

constructor iniciar( ) exports all {

...

Integer massa = Integer.make( 70 );// 70 e um valor literal

}

...

}

...

class Boolean {

enum { true, false } value = false;// True e False s~ao literais

...


{


value = false;

else

value = true;

}

...

}

Figura A.1 Codigo fonte em Aram mostrando os possıveis usos de um valor literal

A.1.2 Bloco de Dados e Indice

Referencia a Bloco de dados

Uma referencia a bloco de dados consiste em uma referencia a uma sequencia contıgua de

dados binarios em memoria. Esse tipo de referencia e geralmente utilizado para a construcao

de classes pre-definidas (Integer, Real, Boolean, Character e String) utilizadas para compor

outras classes. A referencia a bloco de dados e discutida em detalhes na Secao A.1.4.


LiteralValue Enumerate

<<Interface>>EnumBindSource

Reference

<<Interface>>ActualParameter

<<Interface>>FormalParameter

LiteralRef

Figura A.2 Relacionamento das meta-classes que representam valores literais e referencias a

literal com outros componentes do metamodelo da Virtuosi

A meta-classe que representa uma referencia a bloco de dados se relaciona atraves de

associacoes com outros componentes do metamodelo da Virtuosi nas seguintes situacoes:



(3) como atributo de uma classe;

(4) como atributo em um acesso a atributo bloco de dados (Este componente e explica-

do na Secao A.1.7, especificamente na discussao sobre o comando para atribuicao de

referencia a objeto);

(5) na comparacao entre duas referencias a bloco de dados;

(6) na comparacao entre uma referencia a bloco de dados e uma referencia nula;

(7) como alvo da atribuicao em um comando de atribuicao de referencia a bloco de dados;


(9) como alvo da atribuicao em um comando de atribuicao de referencia nula a bloco de

dados;

(10) como alvo de uma referencia a ındice;


(11) como alvo dos muitos comandos de sistema para manipulacao de blocos de dados de

classes pre-definidas. Os comandos de sistema sao detalhados na Secao A.1.8;

(12) como alvo dos muitos testaveis especiais para manipulacao de blocos de dados de classes

pre-definidas.

A Figura A.3 mostra o referencia a literal-classe que representa a referencia a bloco de

dado com outros componentes do metamodelo da Virtuosi, excetuando-se os comandos e

testaveis especiais.

localVariable

0.n

IndexRef

DBRef

ActualParameter

FormalParameter

DBAtributeAccess

NullBDRefCompare

NullBDBind

0.n

DBRefCompare

Class

DBDecl

<<interface>>

DBBindSource

2

Reference

attribute

DBBind0.n

attribute 0.n

target target

Figura A.3 Referencia a literal-classe que representa a referencia a bloco de dado com outros



Devido ao grande numero de situacoes em que uma referencia a bloco de dados existe, e

preferıvel analisa-la separadamente em cada caso durante esta Secao.

Referencia a Indice

Para a manipulacao de um bloco de dados existe uma referencia especial chamada referencia

a ındice, ou simplesmente ındice. Um ındice pode ser obtido a partir de uma referencia a

bloco de dados. Quando isso acontece o ındice passa a estar associado ao bloco de dados, ou

seja, o ındice passa a apontar para uma posicao da sequencia contıgua de dados binarios e, a

partir desse momento, seu valor pode ser entendido como um numero inteiro limitado entre

zero e o tamanho do bloco de dados menos um. Um ındice possui comandos tais como ir para

frente, ir para tras, ir para determinada posicao, etc. Tambem possui metodos de adicao,

subtracao, multiplicacao, etc. Estes metodos permitem ao ındice navegar na sequencia de

dados binarios.

O metamodelo da Virtuosi formaliza a relacao entre um ındice e uma referencia a bloco

de dados, conforme mostra a Figura A.4.

0.nDBRef IndexRef

Figura A.4 Relacao entre um ındice e uma referencia a bloco de dados

A meta-classe que representa uma referencia a ındice se relaciona atraves de associacoes

com outros componentes do metamodelo da Virtuosi nas seguintes situacoes:



(3) como ındice de uma referencia a bloco de dados;

(4) na comparacao de referencia a ındice;

(5) na comparacao de referencia a ındice nula;



(7) como alvo da atribuicao em um comando de atribuicao de referencia a ındice;

(8) com uma das possibilidades para a origem da atribuicao em um comando de atribuicao

de referencia a ındice;

(9) como parametro em alguns comandos de sistema para manipulacao de blocos de dados

de classes pre-definidas;

(10) como parametro em alguns testaveis especiais para manipulacao de blocos de dados de

classes pre-definidas.

A Figura A.5 mostra o relacionamento da meta-classe que representa a referencia a ındice

com outros componentes do metamodelo da Virtuosi, excetuando-se os comandos e testaveis

especiais.

Devido ao grande numero de situacoes em que uma referencia a ındice existe, e preferıvel

analisa-la separadamente em cada caso durante esta Secao.

A.1.3 Classes

A meta-classe que representa uma classe se relaciona atraves de associacoes com outros

componentes do metamodelo da Virtuosi nas seguintes situacoes:

(1) como possuidora de atributos referencia a objeto em um relacionamento associacao;

(2) como possuidora de atributos referencia a objeto em um relacionamento composicao

exclusiva;

(3) como possuidora de atributos referencia a bloco de dados em um relacionamento com-

posicao exclusiva;

(4) como possuidora de atributos de variaveis enumeradas em um relacionamento com-

posicao exclusiva;

(5) como tipo de uma referencia a objeto;

(6) como possuidora de invocaveis2.



target

DBRef

IndexDecl

NullIndexRefCompare

Index Ref.CompareIndexRefBindSource.

<<interface>>

IndexRefBind

IndexRef

ActualParameter

FormalParameter

Reference

0.n

0.n

2

local variable

Figura A.5 Relacionamento da meta-classe que representa a referencia a ındice com outros


(7) como cliente da lista de exportacao de um invocavel;

A Figura A.6 mostra o relacionamento da meta-classe que representa uma classe de apli-

cacao com outros componentes do metamodelo da Virtuosi, excetuando-se os relacionamentos

com meta-classes descendentes.


invocable

DBRef

Class

ObjReftype

Association Attribute


0.n

attribute

0.n

0.n

EnumVar

ResultMethod

returnetype

0.n

client

Invocable

authorizer

Figura A.6 Relacionamento da meta-classe que representa uma classe de aplicacao com outros


Heranca

Duas classes podem estabelecer um relacionamento de heranca entre si, tal que os invocaveis

da classe herdeira podem acessar tanto o estado quanto o comportamento (metodos e acoes)

definidos pela classe ancestral, sem qualquer restricao. Em outras palavras, todas as defi-

nicoes de estado e comportamento existentes na classe ancestral sao validas para a classe

herdeira. Segundo o metamodelo da Virtuosi, uma classe pode ter apenas uma classe ances-

tral direta3, mas pode ter muitas classes herdeiras recursivamente. Entretanto, uma classe

nao pode ser direta ou indiretamente ancestral de si propria. Assim, um conjunto de clas-

3Essa propriedade e normalmente denominada heranca simples, em contra-partida a heranca multipla,quando uma classe pode ter muitas ancestrais diretas.


ses pode ser organizado como um grafo acıclico dirigido no qual a propriedade de heranca

e transitiva, isto e, uma classe herdeira assimila as definicoes de estado e de metodos de

ancestrais diretas ou indiretas.

Uma consequencia da transitividade da propriedade de heranca e que uma referencia de

uma certa classe pode ter como alvo instancias de distintas classes, desde que estas sejam

herdeiras (diretas ou indiretas) da classe que define o tipo da referencia, caracterizando assim

a propriedade de polimorfismo.

O metamodelo da Virtuosi formaliza a relacao de heranca entre as classes, conforme

mostrado na Figura A.7.

Existem dois tipos de classe, a classe de aplicacao e a classe raiz. Toda classe da

aplicacao possui uma classe ancestral, sendo que esta pode ser uma outra classe de aplicacao

ou a classe raiz.

Classe Raiz

A classe raiz representa a classe ancestral – direta ou indireta – de todas as classes de

aplicacao, por este motivo nao possui ancestral. Ela e unica em toda a hierarquia de classes.

A.1.4 Atributos

O ambiente Virtuosi disponibiliza uma biblioteca de classes pre-definidas (Integer, Real,

Boolean, Character e String) utilizadas para compor novas classes, as classes de aplicacao.

Os atributos de uma classe segundo o metamodelo da Virtuosi podem ser de tres tipos,

a saber:



• variavel enumerada.

O metadomelo da Virtuosi formaliza os tres tipos de atributo para uma classe conforme

mostra a Figura A.8.


SuperClass

Class

<<interface>>

inheritance

ApplicationClass RootClass

Figura A.7 Relacao de heranca entre classes segundo o metamodelo da Virtuosi

DBRef

attribute 0.n

ClassAssociation Attribute


EnumVar

ObjRef

Figura A.8 Os tres tipos de atributos possıveis em uma classe segundo o metamodelo da Virtuosi

Referencia a Objeto

A meta-classe que representa uma referencia a objeto se relaciona atraves de associacoes

com outros componentes do metamodelo da Virtuosi nas seguintes situacoes:




(3) como atributo de uma classe por associacao;

(4) como atributo de uma classe por composicao;

(5) como sendo um tipo de classe;

(6) como objeto em um acesso a atributo variavel enumerada;

(7) como objeto em um acesso a atributo objeto (Este componente e explicado na Secao

A.1.7, especificamente na discussao sobre o comando para atribuicao de referencia a

objeto);

(8) como atributo em um acesso a atributo objeto (Este componente e explicado na Secao

A.1.7, especificamente na discussao sobre o comando para atribuicao de referencia a

objeto);

(9) como objeto em um acesso a atributo bloco de dados (Este componente e explica-

do na Secao A.1.7, especificamente na discussao sobre o comando para atribuicao de

referencia a bloco de dados);

(10) na comparacao entre duas referencias a objeto;

(11) na comparacao entre uma referencia a objeto e uma referencia nula;

(12) como alvo da atribuicao em um comando de atribuicao de referencia a objeto;

(13) como alvo da atribuicao em um comando de atribuicao de referencia nula a objeto;

(14) como uma das possibilidades para a origem da atribuicao em um comando de atribuicao

de referencia a objeto;

(15) como uma das possibilidades para o testavel associado a um comando de desvio condi-

cional (Tanto o componente testavel quanto o comando de desvio condicional sao ex-

plicados na Secao A.1.7, especificamente na discussao sobre o comando desvio condi-

cional);

(16) como referencia retornada por um invocavel;


(18) como alvo de invocacao de metodo;

(19) como alvo de invocacao de uma acao.


Devido ao grande numero de situacoes em que uma referencia a objeto existe, e preferıvel

analisa-la separadamente em cada caso durante esta Secao.

A Figura A.9 mostra o relacionamento da meta-classe que representa a referencia a objeto

com outros componentes do metamodelo da Virtuosi.

DBRef

Reference

LiteralRef

EnumAttributeAccess

ObjRefCompare

DBAttributeAccess

ObjDecl

ObjAttributeAccess

Testable<<interface>>

<<interface>>ObjBindSource

ObjBind

ActionInvocation

MethodInvocation

NullObjRefCompare

NullObjBind

This

ObjRef


<<interface>>

Class local variable

objectobject 2target

target

type

0..*

attribute

Actual Parameter



Return

targettarget

0..*

target

IndexRef

Figura A.9 Relacionamento da meta-classe que representa a referencia a objeto com outros


A Figura A.10 mostra uma classe implementada em Aram – segundo a definicao do

metamodelo da Virtuosi – com tres atributos do tipo referencia a objeto. O primeiro e o


segundo atributo sao instancias de uma classe pre-definida (String). O terceiro atributo e

instancia de uma classe de aplicacao, no caso Pessoa.

class Pessoa {

composition String nome; //classe pre-definida

association String endereco; //classe pre-definida

association Person esposa; //classe de aplicac~ao

}

Figura A.10 Atributos em uma classe segundo o metamodelo da Virtuosi

Um atributo do tipo referencia a objeto pode estar associado a classe por composicao

ou associacao.

Composicao Observando a Figura A.10 nota-se que o primeiro atributo – uma String de

nome name – possui como parte de sua declaracao a palavra composition. A existencia da

palavra composition indica um relacionamento de composicao exclusiva entre uma classe

e um atributo. A Figura A.11 mostra um codigo fonte com uma relacao de composicao

exclusiva entre classe e atributo e ilustra a semantica correspondente utilizando os objetos

envolvidos. Em uma relacao de composicao exclusiva o objeto representado pelo atributo

esta contido no objeto representado pela classe. Como consequencia do relacionamento de

composicao exclusiva um objeto contido somente pode ser referenciado por ele proprio, pelo

seu contentor direto ou por outro objeto que seja contido no mesmo objeto contentor.

Associacao Observando novamente a Figura A.10 nota-se que o segundo atributo – uma

String de nome address – possui como parte de sua declaracao a palavra association. A

palavra association indica um relacionamento de associacao entre uma classe e um atributo.

A Figura A.12 mostra um codigo fonte com uma relacao de associacao entre classe e atributo

e ilustra a semantica correspondente utilizando os objetos envolvidos. Em uma relacao

de associacao o objeto representado pelo atributo nao faz parte do objeto representado

pela classe, simplesmente esta associado a ele. Como consequencia do relacionamento de


nome

class Pessoa { composition String nome; //classe pre−definida

a: Pessoa

a.a1: String

Figura A.11 Codigo fonte em Aram e diagrama de objeto de uma relacao de composicao entre

uma classe e um atributo

associacao um objeto associado pode ser referenciado por qualquer outro objeto.

b: String

class Pessoa { association String endereco; //classe pre−definida

a: Pessoa

endereco

Figura A.12 Codigo fonte em Aram e diagrama de objeto de uma relacao de associacao entre

uma classe e um atributo

A Figura A.13 mostra como o metamodelo da Virtuosi formaliza as relacoes de com-

posicao e associacao entre uma classe e seus atributos.

ObjRef



Class

Figura A.13 As duas maneiras em que uma referencia a objeto representa o papel de atributo

segundo o metamodelo da Virtuosi


Referencia a Bloco de Dados

Segundo o metamodelo da Virtuosi, um programador tem a possibilidade de criar novas

classes que nao dependam de nenhuma outra classe pre-existente. Para tanto, um atributo

pode referenciar um bloco de dados. Esse tipo de referencia e chamada referencia a bloco

de dados. Uma referencia a bloco de dados consiste em uma referencia para uma sequencia

contıgua de dados binarios em memoria. Um atributo do tipo referencia a bloco de dados

obrigatoriamente tem uma relacao de composicao exclusiva com a classe que o possui. Esse

tipo de referencia e geralmente utilizado para a construcao de classes pre-definidas. Cada

classe pre-definida e responsavel por dar o significado de sua sequencia de dados binarios

atraves de suas operacoes. Por exemplo, um objeto do tipo basico Integer pode armazenar

um valor inteiro utilizando um bloco de dados de qualquer tamanho, nesse caso uma operacao

para adicionar um outro valor inteiro (armazenado em outro objeto do tipo Integer tambem

utilizando um bloco de dados) ao valor inteiro deste objeto, deve conhecer a convencao

utilizada na representacao binaria de ambas as sequencias. A Figura A.14 mostra o codigo

fonte de uma classe que possui um atributo do tipo bloco de dado e uma ilustracao de uma

instancia desta classe contendo o bloco de dados.

0

datablock value;

a: Integer

value

class Integer {

0 10 0

Figura A.14 Um exemplo de atributo do tipo bloco de dados e uma representacao de um objeto

correspondente – codigo fonte em Aram


Variavel Enumerada

Uma classe implementada segundo o metamodelo da Virtuosi, pode ainda ter um atributo

do tipo variavel enumerada. Um atributo do tipo variavel enumerada possui um conjunto

de valores possıveis definidos na construcao da classe. Os valores possıveis de uma variavel

enumerada nao sao objetos de nenhuma outra classe, sao simples valores literais. Esse con-

junto de valores possıveis de uma variavel enumerada chama-se enumerado. Um atributo

do tipo variavel enumerada recebe um valor inicial durante sua declaracao. A Figura A.15

mostra o codigo fonte de uma classe que possui um atributo de variavel enumerada e uma

ilustracao de uma instancia desta classe contendo um enumerado. O codigo fonte da Figura

abstrai um dado cuja face virada para cima sempre assume um dos valores definidos, no caso

um(1) a seis(6).

b: Boolean

false

enum { true, false value = false ;

value

class Boolean {

{

Figura A.15 Um exemplo de atributo do tipo enumerado e uma representacao de um objeto

correspondente – codigo fonte em Aram

A.1.5 Referencias

Existem quatro tipos de referencia no metamodelo da Virtuosi, a saber:



• referencia a ındice;

• referencia a literal.


A Figura A.16 mostra o relacionamento de heranca entre as referencias na Virtuosi e

mostra tambem que qualquer referencia pode ser passada como parametro real e fazer parte

dos parametros formais de um invocavel. Deve-se notar que a meta-classe referencia e ab-

strata, e e concretizada pelos quatro tipos de referencia.

ObjRef

Reference

LiteralRef


<<interface>>Actual Parameter

This

IndexRefDBRef

Figura A.16 Relacionamento entre as meta-classes que definem os tipos de referencia na Virtuosi

Observando-se a Figura A.16 nota-se que existe uma meta-classe chamada This herdeira

da meta-classe que representa uma referencia a objeto. Essa meta-classe representa uma

referencia para o objeto corrente durante a interpretacao de um metodo. Uma referencia do

tipo This e utilizada quando dentro de um metodo deseja-se invocar um metodo da propria

classe e sobre a propria instancia corrente.

A.1.6 Invocaveis

Segundo o metamodelo da Virtuosi, uma operacao de uma classe pode ser implementada de

duas maneiras, a saber:

• como um metodo;

• como uma acao;

Essas duas implementacoes descrevem o conjunto dos servicos que uma classe disponibi-

liza. Alem das operacoes, uma classe precisa implementar um metodo especial utilizado para

criar novas instancias da classe, esse tipo de metodo especial e chamado de construtor.


O metamodelo da Virtuosi formaliza a relacao entre uma classe e as possıveis implemen-

tacoes de suas operacoes e construtores, conforme mostra a Figura A.17.

invocable

Construtor Method

Invocable

VoidMethod

Action

Class0..*

ResultMethod

Figura A.17 Relacao entre uma classe e as possıveis implementacoes de suas operacoes

Um metodo, um construtor ou uma acao podem sofrer invocacao e, por isso, o metamo-

delo da Virtuosi os formaliza como invocaveis4.

A Figura A.18 mostra o relacionamento da meta-classe Invocavel com outros componentes

do metamodelo da Virtuosi.

statementInvocable

FormalParameter<<interface>>

CompoundStatement Class

invocable

clientauthorizer

0..*

0..* 0..*

0..*parameter

Figura A.18 Relacionamento da meta-classe Invocavel com outros componentes do metamodelo

da Virtuosi



A meta-classe que representa um invocavel – independente do seu tipo (construtor,

metodo ou acao) – se relaciona atraves de associacoes com outros componentes do meta-

modelo da Virtuosi nas seguintes situacoes:

(1) como possuidora de parametros formais;

(2) como possuidora de comandos;

(3) como pertencente a uma classe;

(4) como fornecedora para meta-classes que tem autorizacao para invoca-la;

Parametros Um invocavel pode receber parametros. Por isso um invocavel define uma

sequencia de parametros que deve ser provida durante sua invocacao (ou chamada).

Um parametro pode ser visto sob duas perspectivas diferentes. A primeira ocorre durante

a construcao de um invocavel onde o parametro tem o papel de parametro formal5, ou

seja, ele define o nome, o tipo e a posicao que determinado parametro possuira na sequencia

dos parametros formais daquela invocacao. A segunda ocorre no momento da chamada do

invocavel, onde um parametro e uma referencia a um objeto ja existente, tendo assim, o

papel de parametro real6.

O conjunto de parametros formais de um invocavel pode ser vazio ou composto de re-

ferencias. Qualquer tipo de referencia pode ser um parametro formal, inclusive uma re-

ferencia a literal7 utilizada para receber os parametros reais do tipo valor literal.

A Figura A.19 mostra um exemplo de uma classe de aplicacao Taxi com dois metodos,

um com uma lista de parametros vazia (sairPassageiro) e outro com uma lista contendo

um parametro formal do tipo referencia a objeto (entrarPassageiro). A Figura mostra

tambem a classe de aplicacao Principal, que invoca os dois metodos da classe de aplicacao

Taxi.

5Do ingles formal parameter.6Do ingles actual parameter.7Embora um parametro seja utilizado pelo invocavel da mesma forma que uma variavel local, no caso

de parametros do tipo referencia a literal, o parametro nao pode sofrer atribuicao, visto que, nao existe umcomando de atribuicao para referencia a literal. Portanto, uma referencia a literal sempre tem seu valorliteral atribuıdo por um comando de invocacao de invocavel


class Principal

{

constructor iniciar() exports { all }

{

Taxi corsa = Taxi.instanciar();

...

Boolean entrou = corsa.entrarPassageiro(andrea);

...

corsa.sairPassageiro();

...

}

...

}

class Taxi {

...

// metodo sem parametros

method void sairPassageiro( ) exports { Principal }

{

...

}

// metodo com parametros

method Boolean entrarPassageiro( Pessoa p ) exports { Principal }

{

...

}

}

Figura A.19 Codigo fonte em Aram contendo um metodo sem parametros e um metodo com

parametros

O metamodelo da Virtuosi formaliza a relacao entre um invocavel e seus parametros,

conforme mostra a Figura A.18.


Lista de Exportacao Um invocavel define explicitamente quais as outras classes cujos

invocaveis podem realizar invocacoes sobre o invocavel em questao. Para tanto, um invocavel

possui uma lista de exportacao, ou seja, uma lista das classes cujos invocaveis podem

invoca-lo.

Alguns exemplos do uso da lista de exportacao podem ser observados na Figura A.20. A

Figura mostra tres casos distintos: o metodo exportedToAllMethod – exportado para toda

e qualquer classe –, o metodo nonExportedMethod – nao exportado para nenhuma classe –

e o metodo exportedToBandC exportado para as classes B e C. Deve-se observar que nos

dois primeiros casos foram utilizadas palavras reservadas da linguagem ao inves de uma lista

de nomes de outras classes. Existem duas palavras reservadas que podem ser utilizadas no

lugar de uma lista de exportacao: all e none. A palavra all implica que o invocavel em

questao pode ser invocado a partir de invocaveis de toda e qualquer classe, enquanto que a

palavra none implica que o invocavel em questao somente pode ser invocado pelos invocaveis

pertencentes a mesma classe que o possui. O uso da palavra none permite que invocaveis

sejam acessados sem restricao por qualquer invocavel da propria classe.

O metamodelo da Virtuosi formaliza a relacao entre um invocavel e sua lista de expor-

tacao, conforme mostra a Figura A.21.

Construtor Um construtor nao faz parte das operacoes definidas por um TAD (Tipo

Abstrato de Dado) pois nao interfere no comportamento dos objetos representados pelo

TAD. Porem, tem fundamental importancia na implementacao de uma classe, visto que,

um objeto sempre e criado atraves de sua interpretacao. O retorno da interpretacao de um

construtor e sempre um novo objeto, uma nova instancia de uma classe.

Metodo Um metodo e a maneira mais comum de implementar uma operacao definida

por um TAD. Existem dois tipos de metodos, a saber: metodo sem retorno de valor –

muitas vezes chamado de procedimento – e metodo com retornode valor – muitas vezes

chamado funcao – conforme formalizado pelo metamodelo da Virtuosi e mostrado na Figura

A.22.

A diferenciacao entre metodos com e sem retorno se da em parte pelo uso da palavra que

fica entre a palavra method e o nome do metodo. Caso essa palavra seja void trata-se de


class A {

...

// metodo exportado para toda e qualquer classe

method void exportedToAllMethod() exports all

{

...

}

// metodo n~ao exportado para nenhuma classe

method void nonExportedMethod() exports none

{

...

}

method void exportedToBandC() exports { B, C }

}

Figura A.20 Metodos com diferentes listas de exportacao – Codigo fonte em Aram

0..*Invocable Class

clientauthorizer0..*

Figura A.21 Relacao de um Invocavel e sua lista de exportacao

um metodo sem retorno. Caso a palavra seja o nome de uma classe trata-se de um metodo

com retorno. Outra diferenca consiste no fato de um metodo com retorno sempre possuir ao

menos um comando retorno. A Figura A.23 mostra um exemplo de codigo fonte em Aram

contendo um metodo sem retorno e um metodo com retorno. O comando retorno e um

comando simples e e discutido na Secao A.1.7.

Acao A segunda maneira de implementar uma operacao definida por um TAD e atraves

de uma acao. Uma acao pode ser vista como uma operacao cujo retorno e utilizado para a


ResultMethod

Method

VoidMethod

Figura A.22 Metodos com retorno e metodos sem retorno

class Taxi {

...

// metodo sem retorno

method void sairPassageiro( ) exports { Principal }

{

...

}

// metodo com retorno

method Boolean entrarPassageiro( Pessoa p ) exports { Principal }

{

...

return resultado;

}

}

Figura A.23 Diferenciacao entre metodos com retorno e metodos sem retorno

tomada de decisao referente a um comando de desvio. Em outras palavras, o retorno de uma

acao permite ao comando de desvio decidir qual dentre duas sequencias de comandos deve

ser interpretada. Uma acao nao retorna uma referencia a objeto. Diferente de um metodo

com retorno ou um construtor – onde uma referencia e retornada – o retorno de uma acao e

um comando simples chamado: comando resultado de teste. Tanto o comando de desvio

quanto o comando resultado de teste sao detalhados na Secao A.1.7.

A Figura A.24 mostra um exemplo de codigo fonte com uma declaracao de uma acao,

segundo o metamodelo da Virtuosi.


class Pessoa {

...

// ac~ao

action casado() exports all

{

...

}

}

Figura A.24 Codigo fonte em Aram contendo uma declaracao de uma acao

A.1.7 Comandos

No ambiente Virtuosi, toda computacao e realizada atraves da interpretacao dos comandos

que compoem um invocavel. Esses comandos podem ser invocacoes de outros invocaveis,

comandos responsaveis por controlar o fluxo da interpretacao, comandos para manipular

referencias a objetos ou ainda comandos de sistema para a manipulacao de referencia a

bloco de dados e manipulacao de referencia a ındice. Esses comandos sao interpretados a

partir do momento que um invocavel e invocado.

Composicao de Comandos

Um invocavel define uma sequencia de comandos. Comandos podem ser simples ou com-

postos. Um comando simples8 pode ser uma atribuicao, uma invocacao de operacao, um

desvio condicional, conforme detalhado no restante dessa Secao. Um comando composto9

e uma sequencia de comandos simples ou compostos, recursivamente.

Uma sequencia de comandos, simples ou compostos, pode ser agrupada em um comando

composto. Esse relacionamento e mostrado na Figura A.25.

8Do ingles simple statement.9Do ingles compound statement.


0..*

InvocableCompoundStatement statement

Statement

SimpleStatement

0..*

Figura A.25 Relacionamento de heranca entre as meta-classes comando, comando simples e

comando composto

Declaracao de Variaveis

Para se invocar um invocavel e preciso possuir uma referencia para um objeto da classe que o

define(com excecao de construtores que sao invocados a partir do nome da classe). Segundo

o metamodelo da Virtuosi, uma referencia existe sob tres formas, a saber:

(1) atributo;

(2) parametro;

(3) variavel local.

Ao contrario dos atributos e parametros que sao definidos durante a construcao da classe

e seus respectivos invocaveis, uma variavel local nao existe ate que seja declarada. Portanto,

existem comandos para a declaracao de alguns tipos de referencia utilizadas como variaveis

locais. A Figura A.26 mostra a hierarquia de meta-classes que determina os comandos

simples disponıveis para a declaracao de variaveis locais, segundo o metamodelo da Virtuosi.

Conforme mostra a Figura A.26, e possıvel declarar variaveis locais do tipo:



• referencia a ındice.

Observando novamente a Figura A.26 nota-se que nao existe declaracao de variavel local

do tipo referencia a literal. Isto ocorre porque uma referencia a literal somente e permitida


VariableDeclaration

SimpleStatement

ObjDecl DBDecl IndexDecl

Figura A.26 Tipos de declaracoes para variaveis locais

como parametro de um invocavel, ou seja, no momento da invocacao o que e passado como

parametro e um valor literal, e nao uma referencia a literal. A Figura A.27 mostra uma

invocacao de um metodo passando um valor literal e a declaracao desse mesmo metodo

contendo um parametro formal do tipo referencia a literal.

Declaracao de Variaveis do Tipo Referencia a Objeto A Figura A.28 mostra a

declaracao de uma variavel local do tipo referencia a objeto. Apos a interpretacao desse

comando a referencia nao possui um alvo, ou seja, nao esta apontando para algum objeto

em memoria. Uma referencia sem alvo e chamada de referencia nula.

Declaracao de Variaveis do Tipo Referencia a Bloco de Dados A Figura A.29

mostra a declaracao de uma variavel local do tipo referencia a bloco de dados. Apos a

interpretacao desse comando a referencia nao possui um alvo, ou seja, nao esta apontando

para alguma sequencia de dados binarios em memoria. Da mesma forma que uma referencia

a objeto, uma referencia a bloco de dados sem alvo tambem e uma referencia nula.

Declaracao de Variaveis do Tipo Referencia a Indice Alem da declaracao de variavel

local do tipo referencia a objeto e do tipo referencia a bloco de dados existe a declaracao de

variavel local do tipo referencia a ındice. A Figura A.30 mostra a declaracao de uma variavel

local do tipo referencia a ındice. Apos a interpretacao desse comando a referencia nao possui


class Person {

...

constructor create()

{

Integer age;

age = Integer.make(26); // ’26’ e um valor literal

}

}

...

class Integer {

...

constructor make ( Literal charSequence){

...

}

}

Figura A.27 Invocacao de metodo passando como parametro um valor literal e a declaracao do

metodo invocado – codigo fonte em Aram

class Person {

constructor make() exports all

{

// declarac~ao de variavel local inicialmente nula.

String name;

...

}

...

}

Figura A.28 Declaracao de uma variavel local do tipo referencia a objeto – codigo fonte em

Aram

um alvo, ou seja, nao esta apontando alguma sequencia de dados binarios em memoria, ou

seja, e uma referencia nula.


class Integer {

method void add( Integer i ) exports all

{


datablock d;

...

}

...

}

Figura A.29 Declaracao de uma variavel local do tipo referencia a bloco de dados – codigo fonte

em Aram

class Integer {

method void add( Integer i ) exports all

{


index i;

...

}

...

}

Figura A.30 Declaracao de uma variavel local do tipo referencia a ındice – codigo fonte em Aram

Atribuicao

Uma referencia nula nao permite uma invocacao a partir dela. Isso e verdade tanto para

variaveis locais quanto para atributos e parametros. Portanto, e preciso fazer com que uma

referencia aponte para um alvo, ou seja, uma referencia a objeto precisa apontar para um

objeto em memoria, uma referencia a bloco de dados precisa apontar para uma sequencia

de dados binarios em memoria e uma referencia a ındice precisa apontar para uma posicao

na sequencia de dados binarios em memoria. Isso ocorre atraves da interpretacao de um


comando de atribuicao. Esse comando e identificado no codigo fonte pelo uso do caractere

‘=’ chamado de caractere de atribuicao. O que estiver a esquerda do caractere de atribuicao e

chamado alvo da atribuicao, e o que estiver a direita do caractere de atribuicao e chamado

origem da atribuicao.

Segundo o metamodelo da Virtuosi, os comandos de atribuicao existentes sao os seguintes:

• atribuicao de referencia a objeto;

• atribuicao de referencia nula a objeto;

• atribuicao de referencia a bloco de dados;

• atribuicao de referencia nula a bloco de dados;

• atribuicao de referencia a ındice;

• atribuicao de variavel enumerada.

Atribuicao de Referencia a Objeto No caso da atribuicao de referencia a objeto o alvo

da atribuicao sempre e uma referencia a objeto, enquanto que a origem da atribuicao pode

ser:

• uma referencia a objeto;

• um acesso a atributo objeto, ou seja, um acesso – somente de leitura – a um atributo

do tipo referencia a objeto, de outro objeto instancia da mesma classe que implementa

o invocavel onde a atribuicao ocorre;

• um comando de invocacao de construtor (Este componente e explicado nesta Secao,

especificamente na discussao sobre o comando de invocacao de construtor);

• um comando de invocacao de metodo com retorno (Este componente e explicado nesta

Secao, especificamente na discussao sobre o comando de invocacao de metodo com

retorno).

Atribuicao de Referencia Nula a Objeto Um comando de atribuicao de objeto nulo,

faz uma referencia a objeto voltar a ser uma referencia nula.


A Figura A.31 mostra o relacionamento das meta-classes que representam os dois co-

mandos de atribuicao de referencia a objeto com outros componentes do metamodelo da

Virtuosi.

source

ObjRef

ObjBindNullObjBind

target

SimpleStatement

0..*

ObjBindSource<<interface>>

ConstructorInvocation ResultMethodInvocation ObjAttributeAccess

Figura A.31 Relacionamento das meta-classes que representam os comandos de atribuicao de

referencia a objeto com outros componentes do metamodelo da Virtuosi

Atribuicao de Referencia a Bloco de Dados No caso da atribuicao de referencia a

bloco de dados o alvo da atribuicao sempre e uma referencia a bloco de dados, enquanto que

a origem da atribuicao pode ser:

• uma referencia a bloco de dados;

• um acesso a atributo bloco de dados, ou seja, um acesso – somente de leitura – a um

atributo do tipo referencia a bloco de dados, de outro objeto instancia da mesma classe

que implementa o invocavel onde a atribuicao ocorre.


Atribuicao de Referencia Nula a Bloco de Dados Um comando de atribuicao de

bloco de dados nulo, faz uma referencia a bloco de dados voltar a ser uma referencia nula.

A Figura A.32 mostra o relacionamento das meta-classes que representam os dois coman-

dos de atribuicao de referencia a bloco de dados com outros componentes do metamodelo

da Virtuosi.

DBAttributeAccess

DBBindNullDBBind

target

SimpleStatement

0..*

DBRef

target <<interface>>DBBindSource

Figura A.32 Relacionamento das meta-classes que representam os dois comandos de atribuicao

de referencia a bloco de dados com outros componentes do metamodelo da Virtuosi

Atribuicao de Referencia a Indice No caso da atribuicao de referencia a ındice o alvo

da atribuicao sempre e uma referencia a ındice, enquanto que a origem da atribuicao pode

ser:

• uma referencia a ındice;

• um comando especial para a manipulacao de referencia a bloco de dados.

• um comando de atribuicao de ındice nulo, faz uma referencia a ındice voltar a ser uma

referencia nula.


A Figura A.33 mostra o relacionamento da meta-classe comando de atribuicao de re-

ferencia a ındice com outros componentes do metamodelo da Virtuosi.

<<interface>>

SimpleStatement

IndexBind 0..*

IndexRef

target

sourceIndexRefBindSource

Figura A.33 Relacionamento da meta-classe comando de atribuicao de referencia a ındice com

outros componentes do metamodelo da Virtuosi

Atribuicao de Variavel Enumerada No caso da atribuicao de variavel enumerada o

alvo da atribuicao sempre e uma variavel enumerada, enquanto que a origem da atribuicao

pode ser:

• um valor literal;

• uma referencia a literal;

• um acesso a atributo variavel enumerada, ou seja, ou seja, um acesso – somente de

leitura – a um atributo do tipo variavel enumerada, de outro objeto instancia da mesma

classe que implementa o invocavel onde a atribuicao ocorre;

Um atributo do tipo variavel enumerada recebe um valor inicial durante sua declaracao

e somente e permitido atribuir-lhe um valor literal pertencente ao enumerado definido.

A Figura A.34 mostra o relacionamento da meta-classe comando de atribuicao variavel

enumerada com outros componentes do metamodelo da Virtuosi.


EnumAttributeAccess

EnumBind

SimpleStatement

0..*

EnumVar

target

EnumBindSource<<interface>>

source

LiteralValue LiteralRef

Figura A.34 Relacionamento da meta-classe comando de atribuicao variavel enumerada com

outros componentes do metamodelo da Virtuosi

Retorno de Metodo

O comando de retorno utilizado por um metodo e chamado simplesmente de retorno, sendo

que sempre retorna uma referencia a objeto do mesmo tipo definido pelo tipo de retorno do

metodo.

O metamodelo da Virtuosi formaliza o relacionamento entre um comando de retorno e

uma referencia a objeto, conforme mostra a Figura A.35.

Retorno de Acao

Conforme explicado na Secao A.1.6, uma acao nao retorna uma referencia, ao inves disso, tem

como retorno um comando desvie ou um comando execute. Um comando resultado de teste

e o comando retornado por todos os componentes do metamodelo que sao testaveis. Tanto

o comando resultado de teste quanto os comandos testaveis sao detalhados na discussao do


0..*

SimpleStatement

ObjRef

Return

Figura A.35 Relacionamento entre um comando de retorno e uma referencia a objeto

comando de desvio condicional nessa Secao.

Invocacao de Invocaveis

O metamodelo da Virtuosi define os comandos para realizar a invocacao de construtores,

metodos com retorno e metodos sem retorno. A invocacao de um construtor e realizada a

partir do nome da classe que o possui. Ja a invocacao de um metodo, com ou sem retorno,

e realizada a partir de uma referencia a objeto. Tanto o comando de invocacao de metodo

com retorno quanto o comando de invocacao de metodo sem retorno podem ser generalizados

como comandos de invocacoes de metodo. O comando de invocacao de metodo e o comando

de invocacao de construtor podem ser generalizados como comandos de invocacao.

A Figura A.36 mostra o relacionamento da meta-classe que representa um comando de

invocacao com sua hierarquia e outros componentes do metamodelo da Virtuosi.

O metamodelo da Virtuosi formaliza a relacao entre os comandos de invocacao e os

respectivos invocaveis, conforme mostra a Figura A.37.

Conforme a Figura A.37 mostra, um comando de invocacao de construtor causa a inter-

pretacao da sequencia de comandos definidos em um construtor; um comando de invocacao

de metodo sem retorno causa a interpretacao da sequencia de comandos definidos em um

metodo sem retorno; um comando de invocacao de metodo com retorno causa a interpretacao

da sequencia de comandos definidos em um metodo com retorno.


ObjRef

SimpleStatement

Invocation <<interface>>ActualParameter

ConstructorInvocation MethodInvocation

VoidMethodInvocation ResultMethodInvocation

target0..*

Figura A.36 Relacionamento da meta-classe que representa um comando de invocacao com sua

hierarquia e outros componentes do metamodelo da Virtuosi

Deve-se notar que uma acao, embora seja um componente invocavel, nao possui um

comando para invocacao correspondente. A invocacao de uma acao e abordada em detalhe

na discussao sobre componentes testaveis.

Desvios

Dois comandos simples sao responsaveis por controlar o fluxo de interpretacao dentro de

uma sequencia de comandos, a saber:

• desvio incondicional;

• desvio condicional.

Desvio Incondicional Um comando de desvio incondicional quando interpretado faz com

que uma sequencia de comandos especıfica seja interpretada. Nesse contexto essa sequencia

de comandos e chamada de caminho destino. Um desvio incondicional nao aparece ex-


Constructor

Invocable

Invocation

ConstructorInvocation MethodInvocation

VoidMethodInvocation ResultMethodInvocation

VoidMethod ResultMethod

Method

Figura A.37 Relacao entre os comandos de invocacao e os invocaveis

plicitamente no codigo fonte, ele sempre e utilizado em conjunto a um comando de desvio

condicional.

Desvio Condicional Um desvio condicional tem duas sequencias de comandos que podem

ser interpretados (exclusivamente). A primeira sequencia e chamada de caminho destino

e a segunda e chamada caminho alternativo.


Testavel Na Virtuosi, para se interpretar um comando de desvio, nao e necessario avaliar

o valor de um objeto da classe Boolean, embora isso possa ser feito.

Um comando de desvio condicional esta associado a algo que pode ser testado, um

testavel10. Um testavel, quando interpretado, retorna um dentre dois comandos possıveis,

a saber:

• comando execute ou ;

• comando desvie.

Caso o comando retornado seja o comando execute, isto faz com que o caminho destino

seja interpretado. Caso o comando retornado seja o comando desvie, o caminho alternativo

e interpretado.

Visto que ambos os comandos – execute e desvie – sao os dois resultados possıveis de um

testavel, diz-se que ambos sao comandos resultado de teste.

O metamodelo da Virtuosi formaliza os comandos de desvio e como estes se relacionam

com as sequencias de comandos, conforme mostra a Figura A.38.

Entre os componentes definidos como testaveis pelo metamodelo da Virtuosi, esta a

invocacao de uma acao. Uma acao, embora seja um componente invocavel, nao possui

um comando de invocacao correspondente. Uma acao tambem e invocada a partir de uma

referencia a objeto, contudo, sua utilizacao sempre esta associada a um comando de desvio

condicional, ou seja, a invocacao de uma acao e realizada a partir de uma referencia a objeto

somente quando esta invocacao for o elemento testavel de um comando de desvio condicional.

Deve-se notar a diferenca entre uma acao e uma invocacao de acao. Uma invocacao de

acao causa a interpretacao da sequencia de comandos definidos por uma acao. Um comando

de desvio condicional interpreta um testavel, para que este retorne um resultado de teste. O

testavel em questao, pode ser uma invocacao de acao. A invocacao de acao interpreta cada

um dos comandos definidos pela acao ate encontrar um comando resultado de teste. Esse

resultado de teste e utilizado pelo comando de desvio condicional.

10Do ingles testable (o termo testavel ainda nao esta registrado nos dicionarios da lıngua portuguesa).


Statement

<<interface>>Testable

Branch

SimpleStatement

ConditionalBranch UnconditionalBranch

Execute Skip

TestResult

destination

alternate

Figura A.38 Comandos de desvio e como se relacionam com as sequencias de comandos

O metamodelo da Virtuosi formaliza a relacao de um desvio condicional, um testavel,

uma invocacao de acao e uma acao, conforme mostra a Figura A.39.

A Figura A.40 mostra um exemplo de utilizacao de comando de desvio condicional cujo

testavel e uma invocacao de acao a partir de um objeto da classe pre-definida Integer.

A Figura A.41 mostra um exemplo de utilizacao de comando de desvio condicional cujo

testavel e uma comparacao de valor entre uma variavel enumerada e um valor literal.

Essa abordagem e bem diferente da abordagem normalmente utilizada por linguagens de

programacao, onde um desvio condicional sempre depende da avaliacao de uma expressao

que retorna um valor verdadeiro ou falso. Isto permite, por exemplo, que qualquer classe

defina uma ou mais acoes que podem ser utilizadas para a tomada de decisao em um desvio

condicional. Alem disso, toda classe pode definir uma acao chamada default ou acao


TestResult


ConditionalBranch

ActionInvocation

Action

Invocable

Execute Skip

Figura A.39 Relacao de um desvio condicional, um testavel, uma invocacao de acao e uma acao

class Pessoa

{

...

action obesa() exports all

{

...

if (massa_.gt(h))// gt significa greater than

execute;

else

skip;

}

...

}

Figura A.40 Desvio condicional com um testavel que e uma invocacao de uma acao – codigo

fonte em Aram


class Boolean

{

enum { true, false } value = false;

...


{


value = false;

else

value = true;

}

}

Figura A.41 Desvio condicional com um testavel que e uma comparacao de valor entre uma

variavel enumerada e um valor literal – codigo fonte em Aram

padrao. Esta acao padrao nao precisa ser explicitamente chamada, ou seja, se um comando

de invocacao tiver como teste simplesmente uma referencia a objeto, isto significa que a acao

invocada deve ser a padrao. A Figura A.42 mostra o exemplo da definicao de uma acao

padrao e seu respectivo uso por um comando de desvio. Portanto, embora o funcionamento

seja diferente, e possivel utilizar o valor de um objeto da classe Boolean como testavel de

um comando de desvio.

Alem de uma invocacao de acao, um testavel pode ser:

• uma comparacao entre duas referencias a objeto, chamada comparacao de referencia

a objeto – utilizada para verificar se ambas as referencias apontam para o mesmo ob-

jeto em memoria;

• uma comparacao entre duas referencias a bloco de dados, chamada comparacao de

referencia a bloco de dados – utilizada para verificar se ambas as referencias apon-

tam para a mesma sequencia de dados binarios em memoria;

• uma comparacao entre duas referencias a ındice, chamada comparacao de referencia

a ındice – utilizada para verificar se ambas as referencias apontam para a mesma


class Boolean

{

enum { true, false } value = false;

...

action default() exports all /ac~ao padr~ao da classe Boolean

{

if (value==true) {

execute;

}

else {

skip;

}

}

...

}

class Principal

{

constructor iniciar() exports all

{

...

Boolean entrou = corsa.entrarPassageiro(andrea);

if (entrou) {// uso da ac~ao padr~ao da classe Boolean

Integer distancia = Integer.make(10);

...

}

...

}

...

}

Figura A.42 Definicao de uma acao padrao e seu respectivo uso por um comando de desvio


posicao em uma mesma sequencia de dados binarios em memoria;

• uma comparacao entre uma referencia a objeto e uma referencia nula, chamada com-

paracao de referencia nula a objeto- utilizada para verificar se uma referencia e

nula;

• uma comparacao entre uma referencia a bloco de dados e uma referencia nula a bloco

de dados, chamada comparacao de referencia nula a bloco de dados – utilizada

para verificar se uma referencia e nula;

• uma comparacao entre uma referencia a ındice e uma referencia nula, chamada com-

paracao de referencia nula a ındice – utilizada para verificar se uma referencia e

nula;

• uma comparacao de valor entre uma variavel enumerada e um segundo elemento do

tipo variavel enumerada, valor literal, referencia a literal ou ainda um acesso a atributo

variavel enumerada, chamada comparacao de valor de variavel enumerada –

utilizada para comparar valores;

O metamodelo da Virtuosi formaliza todos elementos testaveis que podem ser utilizados

por um desvio condicional, conforme mostra a Figura A.43.

IndexRefCompare

ActionInvocation ObjRef EnumCompare


ObjRefCompare

ConditionalBranch

NullObjRefCompare DBRefCompare NullDBRefCompare

Figura A.43 Relacao de um desvio condicional com todos os testaveis possıveis


Repeticao

Utilizando um comando de desvio condicional associado a um comando de desvio incondi-

cional (nao visıvel no codigo fonte) e possıvel realizar o comportamento de uma estrutura

de repeticao no estilo enquanto–faca ou faca–enquanto conforme a Figura A.44 mostra.

class Principal

{

constructor iniciar() exports all

{

...

Integer t = Integer.make(2);

while (andrea.obesa()) {

andrea.emagreca(t);

}

}

}

Figura A.44 Estrutura de repeticao realizada pela combinacao de um desvio condicional e um

desvio incondicional – codigo fonte em Aram

Vazio

O metamodelo da Virtuosi define um comando que nao causa nenhum efeito, esse comando

e chamado de comando vazio.

A.1.8 Chamadas de Sistema

Conforme citado na Secao A.1.4, o ambiente Virtuosi disponibiliza uma biblioteca de classes

pre-definidas (Integer, Real, Boolean, Character e String) para a construcao de novas classes

chamadas de classes de aplicacao.


Contudo, o ambiente Virtuosi tambem disponibiliza comandos simples e testaveis de sis-

tema para a construcao de classes que utilizem referencias a bloco de dados. As proprias

classes pre-definidas disponibilizadas pelo ambiente Virtuosi sao construıdas com estes co-

mandos e testaveis de sistema.

Comandos de Sistema

Os comandos simples disponibilizados pelo ambiente Virtuosi sao chamados de comandos

de sistema. Com o intuito de organizar a hierarquia das meta-classes que representam

estes comandos, o metamodelo da Virtuosi define uma hierarquia de comandos de sistema,

conforme mostra a Figura A.45.

NativeSystemStatement

SimpleStatement

SystemStatement

IndexStatement

BitSetSystemStat CharSystemStat StringSystemStat RealSystemStat IntegerSystemStat

DataBlockStatement

IO

Figura A.45 Comandos de sistema disponibilizados pelo sistema

Observa-se que abaixo do comando de sistema, existem os comandos de entrada e saıda


e os comandos nativos.

Abaixo dos comandos nativos, existem dois tipos de comando:

• comandos para a manipulacao de bloco de dados;

• comandos para manipulacao de ındices.

Abaixo dos comandos para manipulacao de bloco de dados, existem cinco tipos de co-

mando:

• comandos de sistema para sequencia de dados binarios, que manipulam dados binarios

de forma neutra;

• comandos de sistema para valores inteiros;

• comandos de sistema para valores reais;

• comandos de sistema para valores caracter;

• comandos de sistema para valores conjunto de caracter;

A Figura A.46 mostra um exemplo de codigo fonte de uma classe pre-definida fornecida

pelo ambiente Virtuosi, no caso uma classe para manipulacao de valores inteiros, que utiliza

dois comandos de sistema: createDB – representado no codigo fonte pela invocacao do

construtor make e storeInteger – utilizado para armazenar uma sequencia de dados binarios

no formato apropriado para a representacao de numeros inteiros.

Observa-se que um comando sistema – disponibilizado pelo sistema – pode retornar uma

referencia para bloco de dados ou referencia para ındice. Nota-se tambem, que atraves da

utilizacao desses comandos de sistema, o programador pode, por exemplo, definir novas

classes que armazenem valores inteiros com bloco de dados de tamanho diferente. Isso e

possıvel porque os comandos de sistema que manipulam blocos de dados com a representacao

de valores inteiros podem receber como parametros um valor literal indicando o tamanho do

bloco de dados que deve ser criado.

Testaveis de Sistema

Os testaveis disponibilizados pelo ambiente Virtuosi sao chamados de testaveis de sistema.

Com o intuito de organizar a hierarquia das meta-classes que representam estes testaveis, o


class Integer

{

datablock value;

constructor make( literal k ) exports all

{

value = datablock.make( 32 );

// 32 e um valor literal utilizado para especificar

// o tamanho do bloco de dados.

value.storeInteger( k );

}

...

}

Figura A.46 Uso de dois comandos de sistema para facilitar a construcao de uma classe pre-

definida Integer – codigo fonte em Aram

metamodelo da Virtuosi define uma hierarquia de testaveis de sistema, conforme mostra a

Figura A.47.

Observa-se que abaixo da meta-classe representando os testaveis de sistema, existe so-

mente os testaveis nativos.

Abaixo dos testaveis nativos, existem dois tipos de testaveis:

• testaveis para a manipulacao de bloco de dados;

• testaveis para manipulacao de ındices.

Abaixo dos testaveis para manipulacao de bloco de dados, existem cinco tipos de testaveis:

• testaveis de sistema para sequencia de dados binarios, que manipulam dados binarios

de forma neutra;

• testaveis de sistema para valores inteiros;

• testaveis de sistema para valores reais;

• testaveis de sistema para valores caracter;


CharSystemTestBitSetSystemTest RealSystemTest IntegerSystemTest

SystemTest <<interface>>Testable

IndexTest DataBlockTest

NativeSystemTest

StringSystemTest

Figura A.47 Testaveis de sistema disponibilizados pelo sistema

• testaveis de sistema para valores de conjunto de caracter;

A Figura A.48 mostra um exemplo de codigo fonte de uma classe pre-definida fornecida

pelo ambiente Virtuosi, no caso uma classe para manipulacao de valores inteiros. O exemplo

mostra a implementacao de duas acoes da classe Integer. A acao chamada equals faz uso

de um testavel de sistema para sequencia de dados binarios chamado sameBits. A acao

chamada greaterOrEqual faz uso de um testavel de sistema para valores inteiros chamado

geq, que retorna um comando execute caso o valor inteiro armazenado no bloco de dados

seja maior ou igual ao passado como parametro.


class Integer

{

datablock value;

...

action equals( Integer i ) exports { all }

{

databalock k = i.value;

if ( value.sameBits( k ) )

execute;

else

skip;

}

action greaterOrEqual( Integer i ) exports { all } // greater or equal

{

databalock k = i.value;

if ( value.geqInteger( k ) )

execute;

else

skip;

}

}

Figura A.48 Uso de testaveis especiais nos comandos de desvio utilizados na construcao de uma

classe pre-definida Integer – codigo fonte em Aram

164

Referencias Bibliograficas

[Cal, 2004] (2004). Virtuosi Architecture Issues, volume 3061 of Lecture Notes in Computer

Science. Springer.

[Amaral et al., 1992] Amaral, P., Jacque, C., Jensen, P., Lea, R., and Mirowski, A. (1992).

Transparent object migration in cool-2. In ECOOP’92 European Conference on Object-

Oriented Programming.

[Arnold and Gosling, 1996] Arnold, K. and Gosling, J. (1996). The Java Programming Lan-

guage. Addison Wesley.

[Calsavara, 2000] Calsavara, A. (2000). Virtuosi: Maquinas virtuais para objetos dis-

tribuıdos. In Trabalho apresentado em concurso para professor titular da PUC-PR.

[Cardelli, 1995] Cardelli, L. (1995). A language with distributed scope. ACM Transactions

on Computer Systems, pages 286–297. Proceedings of the 22nd ACM SIGPLAN-SIGACT

symposium on Principles of programming languages.

[Crowcroft, 1996] Crowcroft, J. (1996). Open Distributed Systems. Artech House, Inc.

[Fowler, 1985] Fowler, R. J. (1985). Descentralized Object Finding Using Forwarding Ad-

dresses. PhD thesis, University of Washington.

[Franz and Kistler, 1997] Franz, M. and Kistler, T. (1997). Does java have alternatives? In

Proceedings of the California Software Symposium CSS ’97, pages 5–10.

[Franz and Thomas, 1999] Franz, M. and Thomas, K. (1999). A Tree-Based Alternative to

Java Byte-Codes. In International Journal of Parallel Programming.

[Haridi et al., 1997] Haridi, S., Roy, P. V., and Smolka, G. (1997). An overview of the

design of distributed oz. International Symposium on Parallel Symbolic Computation,

pages 176–187.

[Hewitt, 1980] Hewitt, C. (1980). Transparent object migration in cool-2. In Lisp Confer-

ence, pages 107–118, Palo Alto, California.

Referencias Bibliograficas 165

[HU et al., 2003] HU, Y. C., Cox, A., Wallach, D., and Zwaenepoel, W. (2003). Run-tim

support for distributed sharing in safe languages. ACM Transactions on Computer Sys-

tems, 21(1).

[Jul et al., 1988] Jul, E., Levy, H., Hutchinson, N., and Black, A. (1988). Fine-grained

mobility in the emerald system. ACM Transactions on Computer Systems, 6(1):109–133.

[Kistler and Franz, 1997] Kistler, T. and Franz, M. (1997). A tree-based alternative to ja-

va byte-codes. In Proceedings of the International Workshop on Security and Efficiency

Aspects of Java ’97. Also published as Technical Report No. 96-58, Department of Infor-

mation and Computer Science, University of California, Irvine, December 1996.

[Kolb, 2004] Kolb, C. (2004). Um sistema de execucao para software orientado a objeto

baseado em Arvores de programa. In Dissertacao apresentada na defesa de Mestrado da

PUC-PR.

[M. Shapiro, 1989] M. Shapiro, Y. G. (1989). Sos:an object-oriented operationg system –

assessment and perspectives. Computing Systems, 2:287–387.

[Nutttal., 1994] Nutttal., M. (1994). A brief survey of systems providing process or object

migration. ACM Operating Systems Review, 28:64–80.

[OMG, 2000] OMG (2000). Mobile agent facility specification.

[OMG, 2002] OMG (2002). Life cicle service specification.

[Oshima et al., 1998] Oshima, M., Karjoth, G., and Ono, K. (1998). Aglets specification.

www.trl.ibm.com/aglets.

[Otte et al., 1996] Otte, R., Patrik, P., and e Mark Roy (1996). Understanding CORBA:

The Common Object Request Broker Architecture. Prentice Hall PTR.

[Roy et al., 1999] Roy, P. V., Haridi, S., Brand, P., and Collet, R. (1999). A lightweight

reliable object migration protocol. Lecture Notes in Computer Science, 1686.

[Roy et al., 1997] Roy, P. V., Haridi, S., Brand, P., Smolka, G., Mehl, M., and Scheidhauer,

R. (1997). Mobile objects in distributed oz. ACM Transactions on Programming Languages

and Systems, 19:804–851.

[Stevens, 1990] Stevens, W. R. (1990). Unix Networking Programming. Prentice Hall soft-

ware Series. Remote Procedure Calls.

Referencias Bibliograficas 166

[Tanenbaum, 1994] Tanenbaum, A. S. (1994). Distributed operation systems. Prentice-Hall,

Englewood Cliffs, N. J.

[Venners, 1997] Venners, B. (1997). The architecture of aglets. JavaWorld.

[Vestal, 1987] Vestal, S. (1987). Garbage Collection: An Exercise in Distributed, Fault-

Tolerant Programming. PhD thesis, University of Washington.

[Wikstrom, 1994] Wikstrom, C. (1994). Distributed programming in erlang. In Primeiro

Simposio Internacional sobre Computacao Simbolica (PASCO ’94), pages 412–421. PAS-

CO ’94.

€¦ · resumo o objetivo deste trabalho ´e criar um mecanismo para mobilidade de objetos para a...

Documents