Arquitetura de Interoperabilidade de Widgets

A necessidade de uma arquitetura para a integração de múltiplos(as) widgets/aplicações no mesmo dashboard e para a implementação da lógica de reconfiguração dinâmica de todo o dashboard, baseada no contexto atual, era evidente.

O sistema de widgets implementado opera como base de funcionamento de todo o frontend do protótipo. Com este sistema é possível modular um frontend à medida, com “aplicações” desejadas, integradas entre si e partilhadas com outros membros da rede. Nesta situação, os widgets/aplicações podem reagir de forma autónoma a “coisas” que acontecem no mesmo dashboard, adaptando-se ao contexto apresentado. Esta arquitetura, ao nível da camada de apresentação, oferece ao utilizador uma maior liberdade na definição do seu ambiente de trabalho.

Uma vez que a generalidade das frameworks de apoio à criação de dashboards não definem mecanismos de

interação entre os diferentes widgets que os compõem, é fundamental desenhar uma arquitetura de

implementação de múltiplos conceitos no mesmo dashboard, isto porque, além de permitir explorar canais

35 https://almsaeedstudio.com/themes/AdminLTE/index2.html

comunicacionais ao nível do dashboard, também permitiu aplicar conceitos e metodologias que possibilitam fazer de cada widget uma aplicação “consciente” do contexto (context-aware).

Para chegar a este conceito, algumas questões foram levantadas, nomeadamente:

1. Como construir (rapidamente) uma aplicação via arrastar/largar (drag and drop)?

2. Como ter aplicações diferentes no mesmo dashboard?

3. Como partilhar aplicações com outros membros da rede?

4. Como guardar o estado de cada aplicação?

5. Como é que uma aplicação poderá reagir a um evento que aconteceu numa outra aplicação?

6. Como é que uma aplicação poderá reagir em relação ao contexto atual?

7. Como poderemos garantir a independência de cada aplicação?

8. Como trataremos/enviaremos a informação entre aplicações partilhadas com vários utilizadores?

Todas estas questões levaram ao desenvolvimento de uma solução, tanto para a construção de widgets, como

para a troca de informações entre eles (usando tecnologias de comunicação em tempo-real). Essa solução suporta mecanismos para criar widgets, para partilhar widgets existentes e para reconfiguração dinâmica de widgets.

4.2.7.1. Criação de Widgets

Pretendia-se que a criação de um novo widget se baseasse no simples “arrastar e largar” (drag and drop) na área pretendida. Criou-se então um arquétipo de widget que contempla os seguintes requisitos:

⎯ A construção do widget tem que ser rápida, sendo isto entendido como uma ação que não apresente

muito tempo de espera para o utilizador. No caso de isso acontecer, deverá existir alguma interação que notifique o utilizador de tal situação e que não prejudique a experiência de utilização;

⎯ O método de construção deverá ser uniforme, isto é, comum a todos os widgets;

⎯ De forma automática, o widget passa a ter um ID único na rede;

⎯ Opcionalmente, o widget poderá apresentar um serviço (botão) como meio de partilha do próprio (Figura 32 – 1);

⎯ O widget deverá apresentar um serviço (botão) que permite a sua eliminação de forma simples e rápida (Figura 32 – 2);

⎯ O widget deverá apresentar uma nota gráfica que indica se o utilizador é proprietário do mesmo, ou se esse é proveniente de outro utilizador (Figura 32 – 3): barra de cor diferenciadora.

Figura 32 - Constituição de um Widget

O processo de construção (Figura 33) inicia-se quando, a partir do menu geral, se “arrasta e larga” um widget

na área de trabalho do dashboard. Como consequência, automaticamente, é realizado um registo no servidor

(método POST), onde é atribuído ao widget um ID único e um utilizador (proprietário). De seguida, no lado do cliente, ao receber resposta afirmativa, é feita a renderização do widget. A partir daqui, caso o widget necessite de dados para ficar devidamente configurado e poder “trabalhar”, o próprio será responsável por apresentar os meios adequados (ex.: formulário) para a recolha da informação necessária, assim como o envio dessa informação para o servidor. Na Figura 33, através da estrutura em JSON apresentada, é possível

visualizar um exemplo dos dados guardados em relação a um widget que necessitou de configuração após ser

“largado” no dashboard. Os dados apresentados no “bloco A” mostram os parâmetros de configuração (“setup”), assim como os “valores” atribuídos a esses parâmetros (“conf”).

Além do processo de construção apresentado na Figura 33, um widget também pode ser adicionado ao dashboard através de um link de partilha. Ou seja, também foi necessário desenvolver um método de partilha de qualquer widget entre os utilizadores. Aqui foram considerados os seguintes princípios:

⎯ O método de partilha deverá ser uniforme, isto é, comum a todos widgets;

⎯ O método de partilha deverá ser um processo simples para o utilizador;

⎯ O widget partilhado deverá apresentar o mesmo comportamento e estado em todos os dashboards em

que esteja presente, em qualquer momento.

O processo de partilha (Figura 34) inicia-se com a receção de um link, através de um canal comunicacional, que corresponde a um widget já existente na rede e que é “propriedade” do utilizador que o fornece. A abertura do link provoca a construção do widget partilhado no dashboard, passando o utilizador a poder visualizar, colaborar e cooperar em tempo-real sobre o widget, em conjunto com todos os utilizadores que a ele têm acesso. Isto é possível porque cada utilizador está associado a um canal de comunicação e, cada vez que um widget é adicionado a um dashboard, é registada uma associação entre widget e canal. Esta filosofia de implementação permite que o comportamento e estado do widget seja igual em qualquer dashboard, porque cada atualização que exista em relação ao widget é imediatamente enviada para todos os canais associados.

Figura 34 - Processo de construção de um Widget Partilhado

4.2.7.2. Reconfiguração Dinâmica dos Widgets

Estando os widgets garantidamente integrados, eventuais alterações num poderá implicar a alteração de outros com os quais esteja “ligado”. Esta reconfiguração dinâmica dos widgets traduz a adaptabilidade ao contexto atual. Esta característica é baseada em eventos que podem ou não ser despoletados a partir de uma ação ou atualização sobre um widget. Para tal, foram definidos os seguintes princípios:

⎯ Existe um conjunto de eventos pré-definidos na rede para que os widgets possam ser programados a

despoletar e a reagir dentro dos mesmos padrões;

⎯ A capacitação de um widget em relação ao despoletar e ao reagir a um evento é opcional;

⎯ A reação de um widget (que também está habilitado a despoletar eventos) a um evento poderá desencadear novas atualizações/reconfigurações em widgets presentes no mesmo dashboard. Esta característica torna-se essencial num dashboard porque ajuda o utilizador a ter uma perceção rápida dos “acontecimentos”, apresentando-se como um meio facilitador da tomada de decisão. Observando a Figura 35

e considerando que os números apresentados indicam a ordem dos(as) processos/ações e que o widget “C” é uma instância do widget “A” (o widget “C” foi gerado através de uma partilha do widget “A” entre o user “1” e o user “2”), vejamos como se processa esta dinâmica:

1) Execução de uma ação sobre um widget, isto é, uma atualização/alteração de estado. Neste caso no

widget “A” ou no “C”;

2) Sendo “C” uma instância de “A”, automaticamente, qualquer atualização/alteração de estado que ocorra num deles será sincronizada;

3) A sincronização entre “A” e “C” poderá ainda desencadear eventos. Caso isso aconteça e o evento

enviado para o dashboard seja do mesmo tipo ao qual os widgets “B” e “D” reagem, logo “B” e “D” poderão também reconfigurar-se de forma automática a esse novo contexto.

Figura 35 - Reconfiguração Dinâmica do Dashboard

Na tentativa de elucidar melhor este processo, ainda na Figura 35, suponhamos que o user “1” tem um widget

“A”, onde agenda compromissos (data e localização), e um widget “B” que indica os dados meteorológicos

para a data e localização atuais e também reage a eventos “datetime”. Além disso, como o widget “C” é uma instância do widget “A” no dashboard do user “2”, a agenda de compromissos presente no dashboard do user

“1” também está presente no dashboard do user “2”. Por fim, como o widget “D” também reage a eventos

“datetime”, automaticamente indicará espetáculos de teatro para a data e localização atuais.

Resumindo, a sequência dos acontecimentos, tendo em conta a dinâmica apresentada anteriormente, será:

1) Agendamento de um compromisso através do widget “A” ou do widget “C”;

2) Sincronização entre o widget “A” e “C”, apresentando a mesma informação;

3) A sincronização entre “A” e “C” desencadeou para os seus dashboards um evento “datetime”, indicando a data e a localização registadas para o compromisso. Estando “B” e “D” capacitados a reagir a eventos “datetime”, logo, o widget “B” irá apresentar a previsão meteorológica para a data e localização recebidas, assim como o widget “D” irá apresentar uma lista de espetáculos para os mesmos parâmetros.

Toda esta dinâmica evolui numa regra de transitividade. Se imaginarmos no dashboard do user “2” a presença de um widget “E” com capacidade de reação a um evento igual ao que é “despoletado” através de uma alteração/atualização no widget “D”, i.e., com uma alteração/atualização no widget “A”, além de sincronizar

com “C”, iria provocar uma reação em “B”, “D” e “E” de forma automática e autónoma, provocando em todos uma adaptação ao contexto atual dos seus dashboards.

Posteriormente, estas dinâmicas terão de ser aprimoradas para controlar a complexidade destes processos (evitar ciclos de reconfigurações, regras para reconfigurações, etc.).

A jeito de conclusão, verifica-se que esta abordagem de integração de widgets demonstra que é possível usufruir de múltiplas aplicações de diferentes tipos e fornecedores no mesmo dashboard, com a capacidade de interoperarem entre elas e adaptando-se ao contexto global atual. Este dashboard apresenta assim

comportamentos de uma aplicação context-aware, onde existe “consciência” do que está a acontecer em cada

momento.

No capítulo seguinte são apresentados mais pormenores em torno da tecnologia utilizada para implementar esta dinâmica.