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, resultando na divisão do sistema em três aplicações ou componentes principais da plataforma 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 componentes é 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 aplicaçã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 é implementada por meio da biblioteca RequireJS (RequireJS, [s.d.]); o padrão publishsubscribe é 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 é apresentado 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 arquitetura 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 principal 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 controlador interpreta os eventos de entrada e mapeia as ações do usuário em comandos 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 estruturas de dados e atualização dos elementos principais de cena o motivo, célula unitá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 interface, identificando e tratando adequadamente o fluxo e o funcionamento da aplica-
181 ção. Segundo o paradigma de programação orientada a eventos, este é um componente crítico da aplicação. Utilizando-se da API PubSub, o módulo menu.js registra todos os elementos e parâmetros de interface (publisher), além de eventos associados (subscribers). 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 específicas. A FIG. 64 ilustra de maneira simplificada o funcionamento da implementaçã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 primitivos 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, controles 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 implementados 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 estruturas 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 formato 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 previamente 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, planos 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 cristalina), 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 gerenciamento de todos os parâmetros associados ao motivo da estrutura cristalina. Complementar 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 simplificada a composição e organização do módulo, e a TAB. 8 descreve os seus principais 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 responsá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 utilizasse tecnologias capazes de suportar estes fundamentos, tais como a plataforma de desenvolvimento em nuvem Heroku, o framework Ruby on Rails, o uso de sistemas distribuídos (SOA), interfaces padronizadas para gerenciamento de recursos (REST) e uso de banco de dados híbrído (NoSQL/relacional) de alta escalabilidade. Esses conceitos e tecnologias são apresentados em maiores detalhes no capítulo 3. O CWLY é dividido em três componentes interdependentes, o Encurtador 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 (deployable), 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 armazenamento 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, referentes à 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, retornando 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 mecanismo. FIGURA 69 Diagrama do fluxo de eventos da aplicação CWLY. Fonte: do autor. Em concordância à arquitetura, padrões e tecnologias utilizados, optouse pelo uso de um esquema híbrido (NoSQL/relacional), adotando especificamente o PostgreSQL e o tipo de dados jsonb, devido à superioridade em termos de disponibilidade e elasticidade para a aplicação proposta (PostgreSQL Global Development Group, [s.d.]). O esquema híbrído (NoSQL/relacional) do banco de dados é especificado na TAB. 10. Por fim, o componente gerenciador de dados é uma interface restrita que permite a localização e o gerenciamento de documentos armazenados em banco de dados. TABELA 10 Descrição do esquema híbrido do banco de dados, referente à aplicação CWLY. Fonte do autor.