Post on 18-Oct-2020
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