176

4.3.2.1 Componentes: Implementação

Para atingir o objetivo de ser distribuído e elástico, adotou-se o padrão

SOA e estilo REST na construção e comunicação entre os componentes, resul-

tando na divisão do sistema em três aplicações ou componentes principais da pla-

taforma CrystalWalk: CrystalWalk Design Pattern (CW4P), CrystalWalk Client

Application (CWAPP) e Encurtador de URL e API de persistência de dados

(CWLY). Este modelo é apresentado na FIG. 59, e cada um de seus componen-

tes é detalhado na sequência (seções 4.3.2.2 a 4.3.2.4).

FIGURA 59 – Interação entre componentes da plataforma CrystalWalk. Fonte: do autor.

177

4.3.2.2 CrystalWalk Design Pattern (CW4P)

Após uma avaliação das opções disponíveis, concluiu-se que não havia

nenhuma arquitetura adequada tanto ao problema como à plataforma escolhida

(WebGL). Considerando aplicativos gráficos tridimensionais interativos baseados

em web, nenhum dos padrões existentes proporcionava a responsividade nem a

escalabilidade e a resiliência adequadas. O paradigma da programação orientada

a eventos aborda esses requisitos (seção 3.5). Além dos aspectos de programa-

ção reativa, percebeu-se que a maioria das aplicações web não apresentavam

uma modularização adequada, definindo o código-fonte em um único arquivo.

Adotando-se boas práticas no desenvolvimento de interfaces em apli-

cação web, como os trabalhos de Osmani (2015) e Zakas (2012) e a especifica-

ção AMD, desenvolveu-se um padrão de estilo de arquitetura próprio para o

projeto, denominado CrystalWalk Design Pattern (CW4P), com o objetivo principal

de viabilizar o paradigma de programação orientada a eventos a aplicações que

utilizam tecnologia WebGL.

De modo sumário, no padrão CW4P: a especificação AMD é implemen-

tada por meio da biblioteca RequireJS (RequireJS, [s.d.]); o padrão publish-

subscribe é implementado por meio da biblioteca PubSubJS, que determina a

comunicação entre componentes em programação orientada a eventos (Pub-

SubJS, 2012); e a tecnologia WebGL é implementada por meio da biblioteca

three.js. Nesse contexto, o módulo roteador viabiliza o recebimento e difusão de

mensagens aos demais módulos e objetos 3D da aplicação. Na FIG. 60 é apre-

sentado um resumo do conceito deste modelo e na FIG. 61 são apresentados a

organização e o fluxo de comunicação entre seus componentes.

178

FIGURA 60 – Interação entre o módulo roteador e os outros módulos. Fonte: do autor.

FIGURA 61 – Fluxo de eventos determinado pelo padrão CW4P. Fonte: do autor.

179

A seguir, são detalhados a implementação do padrão CW4P na arqui-

tetura do sistema, seus componentes e os processos de comunicação.

4.3.2.3 CrystalWalk Client Application (CWAPP)

Principal componente da plataforma CrystalWalk, o CWAPP é uma

aplicação extensão do framework CW4P, responsável pela implementação de

todos os requisitos funcionais de interação com o usuário. Conforme ilustrado na

FIG. 62, o CWAPP é dividido em três componentes, o framework CW4P, os mó-

dulos adicionais da aplicação e uma interface com o servidor web para entrega

dos arquivos da aplicação cliente (deployable), desenvolvida em Ruby.

FIGURA 62 – Componentes da aplicação CWAPP. Fonte: do autor.

A arquitetura e a organização dos módulos da aplicação CWAPP são

definidas pelo framework CW4P e seguem o estilo model-view-controller (MVC). A

inicialização dos módulos e das estruturas de dados que definem a lógica deste

modelo, bem como suas respectivas dependências, é realizada pelo módulo prin-

cipal da aplicação (main.js).

Segundo a aplicação deste estilo de arquitetura, a janela de visualiza-

ção (view) gera eventos de entrada do mouse ou do teclado que são capturados

pelo controlador (controller). Com auxílio de um ou mais modelos (model), o con-

trolador interpreta os eventos de entrada e mapeia as ações do usuário em co-

mandos que geram novos eventos de estados. Mais uma vez, o controlador os

180

captura, gerando novos eventos para a janela de visualização, que finalmente

exibe as alterações.

O objeto modelo (model) é responsável pelo gerenciamento das estrutu-

ras de dados e atualização dos elementos principais de cena – o motivo, célula uni-

tária e cristal – por meio de alterações em suas entidades primitivas, os átomos,

células, direções e planos. Por fim, o objeto visão (view) renderiza os elementos de

cena e exibe a interface do usuário, comunicando seu estado ao controlador.

Os diferentes módulos que compõem a aplicação são ilustrados na

FIG. 63 e descritos na sequência.

FIGURA 63 – Implementação da arquitetura MVC na aplicação CWAPP. Fonte: do autor.

4.3.2.3.1 Objeto view (visão)

4.3.2.3.1.1 Módulo de interface do usuário (menu.js)

O módulo menu.js gerencia ações sobre todos os elementos da interfa-

ce, identificando e tratando adequadamente o fluxo e o funcionamento da aplica-

181

ção. Segundo o paradigma de programação orientada a eventos, este é um com-

ponente crítico da aplicação.

Utilizando-se da API PubSub, o módulo menu.js registra todos os ele-

mentos e parâmetros de interface (publisher), além de eventos associados (subs-

cribers). Assim, ao interagir com estes elementos, o usuário dispara uma

sequência de eventos e aciona um conjunto de módulos e/ou funcionalidades es-

pecíficas. A FIG. 64 ilustra de maneira simplificada o funcionamento da implemen-

tação Publish/Subscribe via módulo menu.js.

FIGURA 64 – Implementação Publish/Subscribe via módulo menu.js. Fonte: do autor.

4.3.2.3.1.2 Módulos de renderização (renderer.js) e cena (*Explorer.js)

Os módulos renderer.js e *Explorer.js são responsáveis pela constru-

ção da cena e renderização do motivo (motiffExplorer.js), da célula unitária

(unitCellExplorer.js) e da estrutura cristalina (crystalExplorer.js) – os objetos primi-

tivos da aplicação.

Cada cena possui um conjunto de parâmetros e atributos específicos e

independentes, tais como objetos a exibir, fontes de iluminação, câmeras, contro-

les de posição e ângulos, dentre outros. A seção 3.5.3.4 apresenta uma breve

revisão da literatura sobre computação gráfica e como estes conceitos são im-

plementados pelo WebGL e three.js. A TAB. 5 descreve os elementos de cena da

aplicação e a FIG. 65 ilustra a composição e organização destes.

182

TABELA 5 – Descrição dos principais elementos de cena e seus respectivos mó-dulos, parâmetros e atributos referente ao objeto visão da aplicação.

Fonte – do autor.

FIGURA 65 – Funcionamento dos principais módulos do objeto visão. Fonte: do autor.

183

4.3.2.3.2 Objeto model (modelo)

4.3.2.3.2.1 Módulos dos modelos primitivos da aplicação

Os módulos definidos no objeto modelo (model) gerenciam as estrutu-

ras de dados dos objetos primitivos em cena, o motivo, a célula unitária e o cristal.

A TAB. 6 descreve cada um destes módulos.

TABELA 6 – Descrição das estruturas de dados dos principais objetos primitivos em cena e seus respectivos módulos, parâmetros e atributos referentes ao objeto modelo da aplicação.

184

Fonte – do autor.

4.3.2.3.2.2 Módulo de persistência (storeProject.js)

O estado atual da aplicação é caracterizado pelos valores de atributos

dos módulos. Quando o usuário salva as configurações, o objeto view dispara um

evento, capturado pelo módulo controlador da estrutura cristalina, que, por sua

vez, envia os valores de atributos da aplicação ao módulo de persistência. Estes

atributos são convertidos pelo módulo de persistência em um documento no for-

mato JSON, enviado para a API da aplicação CWLY. Quando o usuário recupera

as configurações, o módulo de persistência recupera o documento JSON previa-

mente armazenado e dispara um evento de reconstrução da sessão, capturado

pelos demais módulos da aplicação. Cada módulo redefine os objetos a partir do

documento JSON e, como resultado, a aplicação retorna ao seu estado anterior.

4.3.2.3.3 Objeto controller (controlador)

4.3.2.3.3.1 Módulo de estrutura cristalina (lattice.js)

O módulo lattice.js define e gerencia o comportamento de todos os

elementos e parâmetros associados à estrutura cristalina. Segundo o paradigma

de programação orientada a eventos, este é um componente crítico da aplicação,

pois controla a maior parte do fluxo de eventos do objeto view (visão) do cristal.

Utilizando-se da API PubSub, o módulo lattice.js atua entre os elemen-

185

tos de cena da estrutura cristalina (objeto view) e sua estrutura de dados (objeto

model), mapeando as ações da interface (subscribers) para chamadas de modelo

que acionam um conjunto de funcionalidades específicas, permitindo ao usuário

visualizar e interagir com a estrutura cristalina e seus componentes. O módulo

lattice.js tem acesso aos outros módulos do modelo (pontos de rede, átomos, pla-

nos e direções) e suas estruturas de dados, aplicando as “regras de negócio” em

seus métodos. Tais regras visam controlar a criação de objetos e o acesso aos

dados, restringindo, por exemplo, valores máximos e mínimos aceitáveis. Na FIG.

66, é ilustrada de maneira simplificada a composição e organização do módulo, e,

na TAB. 7, são descritos os seus principais métodos e funções.

TABELA 7 – Descrição dos principais métodos do módulo lattice.js (estrutura cris-talina), referente ao objeto controlador.

Fonte – do autor.

186

FIGURA 66 – Funcionamento dos principais métodos e funções do módulo de estrutura cristalina, referente aos objetos modelo e controlador. Fonte: do autor.

4.3.2.3.3.2 Módulo de motivo (motifEditor.js)

O módulo motifEditor.js é responsável pela construção e gerenciamen-

to de todos os parâmetros associados ao motivo da estrutura cristalina. Comple-

mentar ao lattice.js, este módulo gerencia os parâmetros de inclusão, exclusão e

posição dos átomos do motivo, que são fornecidos interativamente pelo usuário

através da interface Edição (motifExplorer.js). A FIG. 67 ilustra de maneira simpli-

ficada a composição e organização do módulo, e a TAB. 8 descreve os seus prin-

cipais métodos e funções.

TABELA 8 – Descrição dos principais métodos do módulo motifEditor.js (motivo), referente ao objeto controlador.

Fonte – do autor.

187

FIGURA 67 – Funcionamento dos principais métodos e funções do módulo de motivo, referente aos objetos modelo e controlador. Fonte: do autor.

4.3.2.4 Encurtador de URL e API de persistência de dados (CWLY)

Componente da plataforma CrystalWalk, o CWLY é a aplicação res-

ponsável pelo armazenamento, gerenciamento e transferência de dados entre o

servidor e a aplicação cliente (CWAPP). Em concordância à arquitetura, padrões

e tecnologias utilizados, decidiu-se por uma estratégia de implementação que uti-

lizasse tecnologias capazes de suportar estes fundamentos, tais como a platafor-

ma de desenvolvimento em nuvem Heroku, o framework Ruby on Rails, o uso de

sistemas distribuídos (SOA), interfaces padronizadas para gerenciamento de re-

cursos (REST) e uso de banco de dados híbrído (NoSQL/relacional) de alta esca-

labilidade. Esses conceitos e tecnologias são apresentados em maiores detalhes

no capítulo 3.

O CWLY é dividido em três componentes interdependentes, o Encur-

tador de URL, a API de persistência e a interface de gerenciamento de dados. A

aplicação possui também uma interface para implementação no Heroku (deplo-

yable), desenvolvida em Ruby. A FIG. 68 ilustra esta arquitetura de maneira

simplificada.

188

FIGURA 68 – Componentes do CWLY. Fonte: do autor.

O componente de API de persistência da aplicação realiza o armaze-

namento e recupera documentos JSON no banco de dados. Esse componente

possui uma interface REST, cujas rotas são listadas e detalhadas na TAB. 9.

TABELA 9 – Descrição dos rotas, verbos e parâmetros da interface REST, refe-rentes à aplicação CWLY.

Fonte – do autor.

189

Ao receber uma solicitação de armazenamento, o componente de API

de persistência realiza o registro do documento JSON no banco de dados, retor-

nando um identificador único para cada transação. O componente encurtador de

URL utiliza este identificador para redirecionar um endereço de URL encurtada

para o endereço da aplicação principal, consultar o banco de dados e recuperar o

documento. A FIG. 69 ilustra de maneira simplificada o funcionamento deste me-

canismo.

FIGURA 69 – Diagrama do fluxo de eventos da aplicação CWLY. Fonte: do autor.

Em concordância à arquitetura, padrões e tecnologias utilizados, optou-

se pelo uso de um esquema híbrido (NoSQL/relacional), adotando especificamen-

te o PostgreSQL e o tipo de dados jsonb, devido à superioridade em termos de

disponibilidade e elasticidade para a aplicação proposta (PostgreSQL Global De-

velopment Group, [s.d.]). O esquema híbrído (NoSQL/relacional) do banco de da-

dos é especificado na TAB. 10. Por fim, o componente gerenciador de dados é

uma interface restrita que permite a localização e o gerenciamento de documen-

tos armazenados em banco de dados.

TABELA 10 – Descrição do esquema híbrido do banco de dados, referente à apli-cação CWLY.

Fonte – do autor.

[v1 16_set] Tese Bardella capa[v1 16_set] Tese Bardella capa e rosto

[v1 16_set] Tese Bardella miolo