2.3.7. Dashboards
A comunicação tem apresentado grande evolução nos últimos tempos, promovendo cada vez mais a necessidade constante de partilha de informação. A aproximação das pessoas exige agora menos custos e menos tempo. Plataformas de colaboração, como Podio20, Trello e Asana21, são exemplos de fomentação dessa aproximação. Embora estejam assentes em linguagens e plataformas diferentes, existe já uma variedade de protocolos com o objetivo de garantir a necessária comunicação em tempo-real.
Estas plataformas implementam protocolos de comunicação ao nível do dashboard. Todas “reconhecem” que
é essencial uma atualização automática da informação. Por isso, tanto o Podio, como o Trello e o Asana têm implementações de sistemas baseados em protocolos que permitem a comunicação em tempo-real, como os
que foram apresentados previamente. O Podio apresenta-se como uma solução mais completa em relação à
gestão de projetos, enquanto que o Trello e o Asana são mais “orientados à tarefa”, mas o foco assenta-se na
implementação das tecnologias de comunicação ao nível do dashboard, assim como a construção/integração
de aplicações.
O Podio baseia-se numa implementação “completa” no que diz respeito à gestão dos processos que decorrem
numa empresa. Além de permitir estruturar projetos, também é possível organizar, por exemplo, a equipa comercial, de forma a transformar o funcionamento global da empresa (Podio, 2016a). Em relação à comunicação/atualização no dashboard, o Podio utiliza um sistema baseado na arquitetura publish/subscribe através do protocolo Bayeux22, designado de Faye23(Podio, 2016b). Bayeux baseia-se num protocolo de
20 https://podio.com/
21 https://asana.com/
22 https://docs.cometd.org/current/reference/index.html#_bayeux
transporte de mensagens assíncronas, com baixa latência entre o cliente e o servidor. Tal como o Pusher, o Bayeux faz um roteamento das mensagens através de canais (Russell, Wilkins, Davis, & Nesbitt, 2007). O Trello, também relacionado com a gestão de projetos, consiste numa plataforma cujo objetivo principal é a organização de tarefas. Inspirado na metodologia de trabalho Scrum, oferece total liberdade ao utilizador na definição do seu dashboard. As técnicas de comunicação implementadas são: pushing e polling. O pushing através de uma biblioteca baseada em Javascript, designada de Socket.IO24, que permite conexões WebSocket segundo o mesmo padrão (publish/subscribe) aplicado no Pusher e no Podio. O polling (através de pedidos
baseados em Asynchronous Javascript and XML – AJAX) foi implementado como alternativa ao pushing, caso
o web browser não suporte WebSockets (Kiefer, 2012).
Assim como o Trello, o Asana tem como objetivo principal a organização de tarefas. O seu dashboard é orientado a listas de tarefas, permitindo que estas sejam agrupadas formando um projeto, como também os
projetos podem ser agrupados formando um workspace. Quanto aos sistemas de comunicação implementados,
Asana usa uma framework desenvolvida pela própria equipa, designada de Luna (Asana, 2016), onde os processos que decorrem entre o cliente e o servidor apresentam um conceito diferente dos que foram apresentados até então. Luna permite o desenvolvimento de aplicações “isomórficas” em tempo-real. Este tipo de aplicações permite a execução de processos no servidor para cada sessão cliente. Luna tem a capacidade de simular o cliente no servidor, ou seja, de forma sincronizada, é capaz de executar no servidor o mesmo código que está a ser executado no cliente.
“This allows the server to look at the data that the application loads and proactively send data to the client, essentially simulating the UI on the server” (Strimpel & Najim, 2016).
Neste projeto, além da implementação de tecnologias/protocolos que permitam uma comunicação em
tempo-real, tanto a nível de dashboard como a nível de comunicação Humano-Humano (Human-to-Human – H2H),
os objetivos principais, em relação à comunicação, passam por: i) demonstrar que o funcionamento deste tipo de dashboards pode melhorar quanto à capacidade de reação das aplicações, tendo em conta o contexto apresentado e ii) apresentar proposta que garante a comunicação H2H sempre que necessária.
Da análise ao Podio, Trello e Asana, foi elaborada uma tabela (Tabela 4) onde se confrontam estas soluções
com o que é pretendido desenvolver (Extended Federated Social Network – EFSN) tendo em conta vários
aspetos que se consideram relevantes na apresentação e funcionamento de um dashboard eficaz: ser acessível via web (Web Based); incorporar tecnologias que permitam sincronização em tempo-real (Real-Time); estar disponível em várias plataformas web e mobile (Cross-Platform); ter um dashboard adaptável ao contexto atual, i.e., uns componentes – widgets – que reagem de forma autónoma a alterações de estado de outros, na sequência do que se “está a passar” no dashboard (Context-Aware); disponibilização de meios de comunicação síncrona (Canais Comunicacionais) e consequente abstração – ausência de consciência – em relação ao canal utilizado durante a comunicação (Abstração do Canal); permitir integrar múltiplas aplicações distintas (Orientado a Aplicações); partilhar widgets entre dashboards diferentes, com a capacidade de sincronização de estados (Sincronização de Widgets).
24 http://socket.io/
Tabela 4 - Podio vs Trello vs Asana vs EFSN Podio (Faye) Trello (Socket.IO) Asana (Luna) EFSN (Pusher) Web Based Real-Time Cross-Platform Context-Aware Canais Comunicacionais Abstração do canal Orientado a Aplicações Sincronização de Widgets
Apesar das múltiplas tecnologias/protocolos utilizados, assim como a interoperabilidade já suportada (com outras aplicações como Slack25, Toggl26, etc.), nenhuma destas soluções apresenta um dashboard que: i) seja capaz de reagir ao contexto apresentado; ii) permita integrar widgets correspondentes a aplicações externas à plataforma; iii) permita a sincronização de estado entre widgets partilhados.
Quanto à comunicação H2H, as plataformas atuais apresentam alguns meios para tal (nomeadamente chats),
mas nunca envolvendo utilizadores externos à plataforma.
Neste trabalho será explorada uma arquitetura para dashboards “conscientes do contexto”, que garante comunicação H2H através de uma camada de abstração em relação ao canal que está a ser usado, onde aplicações distintas podem ser integradas e cujos widgets podem ser partilhados entre dashboards diferentes.
2.4. Resumo
Ao longo deste capítulo foram analisados vários tópicos inerentes à construção e funcionamento de uma rede social. Constatou-se que as redes socias atuais funcionam de forma independente uma das outras, i.e., não permitem a portabilidade dos dados de registo, provocando com isto a possibilidade de existência de múltiplas identidades para apenas uma pessoa.
Verificou-se também que a utilização de bases de dados não-relacionais pode ser benéfica quando se trata de uma plataforma como uma rede social. O facto de estar, constantemente, a surgir novos dados faz com que esse modelo seja aceite como o “ideal”, visto que não aplica uma estrutura rígida.
25 https://slack.com/
A manipulação da informação também foi abordada, concluindo-se a necessidade de representação de cada recurso, tanto a nível estrutural como semântico.
Por fim, na vertente comunicacional, apesar da existência de vários protocolos, frameworks e API, conclui-se que, das soluções estudadas, o conceito de “context-aware” ainda não está muito presente, e que poucas evoluções existiram no sentido de tornar a utilização dos canais H2H mais unificada, onde a ausência de consciência sobre o canal utilizado está presente.
Devido a estas conclusões em relação ao Estado da Arte, o capítulo seguinte aborda o que se pensa ser fundamental existir numa rede social federada e o que está em falta, estendendo esse conceito através da exposição de temáticas capazes de colmatar as lacunas identificadas.
3. Os Alicerces de uma EFSN
Vimos que uma FSN se caracteriza por estar inserida num sistema com uma topologia federada, onde cada utilizador passa a ser único e, com um conjunto de regras de interoperabilidade, consegue comunicar com utilizadores de outras redes federadas.
Estender uma FSN resulta em novas capacidades assentes em novos serviços. Na essência estende-se o modelo de rede federada comum com a capacidade necessária para responder a um contexto onde os membros que dela fazem parte (recursos), apresentam um comportamento autónomo, mas devidamente integrados num ecossistema digital que se pretende desenvolver. Os recursos existem e partilham entre si contextos – ubiquidade – que condicionam a relevância – context-aware – de determinado recurso para determinado objetivo. Os recursos alteram o seu estado e com agilidade e rapidez o sistema toma conhecimento dessa alteração – broker – e tem de reagir facilmente – reconfigura-se – perante as implicações desse novo estado. É fundamental que o sistema disponha de ferramentas – dashboards – que possibilitem a gestão de todos estes acontecimentos, de forma a que o decisor possa sustentar respostas eficazes e no tempo devido.
3.1. Ubiquidade de Recursos
Da vária bibliografia consultada, constatou-se que dois grandes conceitos povoam os paradigmas de negócio e engenharia de software mais recentes: a Computação Ubíqua e os Ambientes inteligentes.
A Computação Ubíqua – Ubiquitous Computing – surgiu pela primeira vez nos finais dos anos 80, pelo cientista do Centro de Pesquisa Xerox Parc, Sr. Mark Weiser através do seu artigo “The Computer for the 21st Century” (Weiser, 1993). Nessa altura os programadores estavam essencialmente focados nas ferramentas, isto é, nos computadores. Este facto contrariava aquilo que seria realmente importante na altura, segundo o mesmo Mark Weiser, a tarefa a executar. Uma boa ferramenta é aquela que é invisível, fora da consciência das pessoas, devendo estas estarem apenas concentradas na tarefa.
Por outro lado, a “computação na nuvem” (vulgo Cloud Computing) potenciou o desenvolvimento de infraestruturas físicas capazes de garantirem computação de alta performance, armazenamento eficiente, seguro e escalável, de facto! Reúnem-se agora condições muito favoráveis para que estes requisitos sejam suportados: Datacenters robustos, virtualização “séria” de recursos, elevado desempenho apoiado em algoritmos de Big Data, aprendizagem assente em algoritmos de Inteligência Artificial e Machine Learning, representam uma plataforma onde a computação ubíqua começa a tomar forma (Ferreira, Lopes, Putnik, Lopes, & Cunha, 2014).
Alargando ao contexto do atual impacto da Internet das Coisas (vulgo Internet-of-Things), o tuplo sensor-atuador-internet constitui claramente o core das soluções tecnológicas de curto e longo prazo (Gubbi, Buyya, Marusic, & Palaniswami, 2013). O esperado ambiente inteligente continua a ser modelado, onde os middlewares representam cada vez mais peças essenciais na partilha de informação entre as múltiplas “coisas” que necessitam de interagir e interoperar.
A Computação Ubíqua e a IoT representam um passo importante rumo à capacidade de suportar a contínua reconfiguração dinâmica de recursos que estão envolvidos num sistema (Putnik et al., 2013). Caminhar junto com a IoT é uma realidade que potencia enormes volumes de dados e elevadas capacidades de resposta, desde que exista a capacidade de os processar de forma rápida e devida, i.e., entender o real valor dos dados através da modelação, raciocínio e distribuição do contexto em que esses dados foram gerados e adquiridos (Perera, Zaslavsky, Christen, & Georgakopoulos, 2013).
Tudo isto se manifesta crítico na necessidade de encontrar, na altura certa, o(s) recurso(s) necessários, na capacidade de decidir no momento adequado, na capacidade de dinamicamente o sistema reagir às constantes variações e consequente volatilidade do contexto. Estes processos de descoberta e decisão referenciam mecanismos de brokering de recursos de elevada performance, para os quais a participação ativa e eficaz das pessoas é crítica e essencial.
Os mecanismos capazes de possibilitar esta eficácia assentam também na possibilidade de comunicação, colaboração e co-decisão entre os stakeholders de um sistema, independentemente das restrições impostas
pelas tecnologias utilizadas: M2M já se explora, Máquina-Humano (Machine-to-Human – M2H) também, mas
H2H, no mundo das TIC, ainda não é realidade, pelo menos na sua maior dimensão (Putnik, 2010). São, contudo, claras as evidências para processos que caminham nesse sentido, uma vez que a procura em integrar canais comunicacionais (chat, videoconferência, etc.) nos novos sistemas de informação é expressiva.
3.2. Mercado de Recursos
Um “Mercado de Recursos” pode ser visto como um espaço “povoado” por tudo o que seja considerado recurso (tempo, pessoas, máquinas, empresa, etc.) e sobre os quais se possam especificar atividades de identificação, análise e seleção de recursos.
Numa rede federada estendida este repositório de recursos constitui o espaço onde os recursos são devidamente classificados e registados, onde eventuais relações são definidas ou estabelecidas e, onde o estado ou contexto de cada recurso é monitorizado e devidamente controlado.
3.2.1. Reconfiguração Dinâmica
A capacidade de reagir de forma ágil, adequada e atempada a alterações de estado em determinado recurso ou recursos, onde um novo contexto pode ser criado, tornam-se essenciais para lidar com a incerteza que caracteriza este mercado. A sustentabilidade deste mercado assenta pois, na alta disponibilidade de recursos e na capacidade de lidar de forma eficaz com as suas alterações, i.e., reconfigurar-se sempre que necessário (dinamicamente).
As empresas sentem necessariamente pressão na forma como lidam com os clientes, os processos de negócio, as oportunidades, as estratégias. A fidelização de clientes, por exemplo, é fortemente abalada pela enorme disponibilidade de oferta de serviços equivalentes, em níveis de qualidade bastantes competitivos. Concordando com Putnik (2005), o ambiente fortemente competitivo obriga ao alinhamento constante dos processos de negócio, assentes: i) na rápida reconfiguração e adaptabilidade da empresa (ou negócio) resultante
das incertezas, e ii) na capacidade de evoluir, aprendendo (a se reorientar) com o passado. A capacidade de identificar (as melhores) alternativas no tempo útil, é fator crítico de sucesso.
A capacidade de garantir a interoperabilidade eficaz entre sistemas de informação distintos, em empresas distintas, é tarefa difícil se a aposta recair apenas em parâmetros tecnológicos. Aceitando que a estrutura tecnológica está bem sustentada e garante mecanismos eficientes para a integração, esta continua a ser apenas tecnológica (dados, protocolos, patterns). Nos cenários de reconfiguração dinâmica (de serviços, fornecedores, recursos, etc.), onde decidir bem e rápido é essencial, é preciso que as “respostas” sejam imediatas. Os sistemas de informação “por si só” não conseguem dar resposta na sua totalidade.
“The experience of the people (information field) together with the context (time, economy, social and other) is as relevant as that automatic existing information.” (Ferreira, Putnik, & Cunha, 2012).
Abstraindo o conceito de empresa ou sistema de informação para o conceito de recurso, onde, por exemplo, tempo, pessoas, máquinas constituem exemplos de recursos, a possibilidade de alteração do estado ou contexto (avarias, ocupação, manutenção, etc.) é constante. Logo, a necessidade de ultrapassar estes fatores, constituem eventos de necessária reconfiguração.
3.2.2. Contexto
Nos primórdios da computação, o contexto utilizado nos sistemas estava definido pelo local onde os mesmos eram instalados. Os computadores pessoais eram usados em ambientes de escritório ou nas fábricas, o que levava a pouca variação de contexto nas situações em torno do computador e, consequentemente, não existia a necessidade de adaptação a diferentes ambientes (Schmidt, 2014). Mais tarde, com o aparecimento da computação ubíqua, começou-se a olhar para o contexto de uma forma diferente. Como referido anteriormente, o objetivo da computação ubíqua era apresentar transparência ao utilizador em relação à utilização de qualquer serviço em qualquer lugar e, foi essa ideia/investigação de Mark Weiser que provocou uma mudança de pensamento, não só a nível de conectividade, mas também a nível de contexto, sendo este visto como um recurso para a adaptação dos sistemas. Segundo BillSchilit (1994) uma aplicação deverá ser capaz de ser sensível ao contexto onde é executada, reagindo de forma autónoma a mudanças que nele ocorram. Estava
assim apresentado o Context-Aware Computing (CAC) “Such context-aware software adapts according to the
location of use, the collection of nearby people, hosts, and accessible devices, as well as to changes to such things over time. A system with these capabilities can examine the computing environment and react to changes to the environment.”
Seguem-se outras propostas de CAC, como por exemplo de AnindK. Dey e GregoryD. Abowd, que defendem
“que um sistema é sensível ao contexto se usar o contexto para fornecer informações e/ou serviços relevantes para o utilizador, onde a relevância depende da tarefa do utilizador” (Dey & Abowd, 2000). Estes apresentam uma definição mais geral e ao mesmo tempo não excluem certas aplicações de ser consideradas context-aware. Se compararmos estas duas abordagens reparamos que a de BillSchilit é mais específica, está mais categorizada (local físico; ao seu redor), enquanto que a de Dey e Abowd é mais geral, permitindo que uma aplicação que simplesmente apresenta o “ambiente” do utilizador para o próprio, sem estar a modificar o seu comportamento, seja considerada context-aware.
Num olhar mais prático, o contexto é estruturado hierarquicamente, descrevendo as características relevantes, quer físicas (espaço envolvente) quer humanas (participantes) (Figura 22). O recurso “espaço” pode ser um
exemplo de uma representação estruturada do contexto. AlbrechtSchmidt dá um bom exemplo disso: supondo
que um proprietário de um restaurante pretende aplicar um menu digital à entrada do seu restaurante. Se olharmos para uma versão não consciente do contexto, o mais provável é ter sempre descrita a refeição do dia. Mas, se desenvolvermos uma aplicação context-aware, o que queremos é que esta dê sugestões (reação) consoante quem passa à frente do menu: se passa uma família (pais e crianças), se calhar o melhor é apresentar um menu de cariz familiar; se passa um casal, à noite, talvez o melhor seja sugerir um jantar à luz das velas; se está muito calor e estamos no período da tarde, o melhor será apresentar a coleção de gelados. A aplicação/menu era capaz de reagir consoante vários fatores: quem está a olhar para ele, hora do dia, clima. Obviamente, que não há forma de descrever todas as opções possíveis, mas há uma vantagem: olhando para um conjunto de parâmetros, é possível determinar facilmente se uma situação corresponde a um contexto ou não (Schmidt, 2014).
Figura 22 - Hierarquias em Context-aware envolvem propriedades físicas e humanas (Schmidt, 2014)
As aplicações context-aware podem-se apoiar em três características fundamentais (Perera et al., 2013):
a) Apresentação – Contexto pode ser usado para decidir qual a informação e serviços que precisam de
ser apresentados ao utilizador;
b) Execução – Execução automática de serviços é uma característica fundamental no paradigma da IoT;
c) Tagging – No paradigma da IoT, existe um grande número de sensores associados a vários objetos
utilizados no dia-a-dia. Esses objetos irão produzir grandes volumes de dados que precisam de ser recolhidos, analisados e processados. De forma a acompanhar a união/fusão dos dados provenientes de múltiplos sensores, o contexto precisa de ser “recolhido”, isto é, o contexto precisa de ser “marcado” (tagged) juntamente com os dados do sensor a ser processado e compreendido mais tarde. Anotação de contexto (Context Annotation) desempenha um papel significativo na pesquisa da computação context-aware.
Numa rede social, o contexto assenta essencialmente em relações que se estabelecem entre os seus membros. Numa rede federada é necessário desenvolver mecanismos que consigam descobrir ou inferir “relações” assentes nos contextos distintos à partida. Um exemplo prático pode ser descrito quando, por exemplo, numa
estufa um alerta de um sensor de temperatura desencadeia o contacto de suporte de um canalizador, pois haverá um problema com as condutas da água.
3.3. Brokering
Num contexto de uma rede federada, onde coexistem múltiplos sistemas heterogéneos, a existência de dados heterogéneos é real.
Anote-se, contudo, que a heterogeneidade nos sistemas (não só de informação) não se aplica apenas a dados. Por exemplo, as diferenças de hardware e sistema operativos podem ser classificadas como heterogeneidade
de sistemas; as diferenças na representação de dados, formatos e armazenamento representam a
heterogeneidade sintática. Os esquemas de dados e respetiva modelação são outro tipo de informação heterogénea – heterogeneidade estrutural. Por último, a heterogeneidade semântica, surge das diferenças de vocabulário e terminologias utilizadas para expressar a informação, bem como dos contextos em que a informação é interpretada (Kashyap & Sheth, 2000).
Perante o cenário da heterogeneidade dos dados e da tendência da globalização de serviços, o volume de informação aumenta, aumentando com isso a complexidade dos sistemas. É na sequência destas conclusões que se entende necessário criar mecanismos capazes de ajudar na manipulação destas grandes quantidades e variedade de dados. São os chamados brokers que intermedeiam dados e informação e que sustentam as arquiteturas de “intermediação de informações” – brokering.
Nesta arquitetura, a semântica é considerada um aspeto importante, visto que se reflete na compreensão e exploração do significado e uso dos dados, assim como na compreensão das necessidades, intenções e perceção da informação por parte dos participantes.
“A minimal definition of an information brokering architecture on the Global Information Infrastructure is an architecture that guides creation and management (brokering) of systems and solutions to serve the information and business needs of a variety of information stakeholders, including providers, facilitators, and consumers” (Kashyap & Sheth, 2000) (Figura 23).
Figura 23 - Dimensões do Brokering de Informação (Kashyap & Sheth, 2000)
Na rede federada estendida, o Brokering – atividade suportada pelo Broker – deve suportar um conjunto de operações encarregues da: i) Mediação, que permite ao sistema interagir remotamente com o recurso; ii) Gestão, que possibilita conhecer tudo sobre um determinado recurso (o que faz; o que fez; o que pode fazer; estado; classificação; etc.) e iii) Seleção de recursos, que se encarrega de encontrar recursos no mercado com maior ou menor rigor dos critérios de pesquisa (Ferreira et al., 2012).
Dispondo deste conjunto de operações, o broker tem um papel essencial na reconfiguração dinâmica do(s)