O modelo do Banco de Dados foi desenvolvido para atender a Programação Orientada a Objetos e foi concebido a partir de três visões: (1) Projetos, (2) workflows e (3) usuários. A Figura 47 apresenta o Modelo Entidade Relacionamento (ER) da plataforma Fast Science, onde as três visões são apresentadas em um modelo integrado.
A modelagem dos requisitos para o grupamento (3) “Apoio a Participação/Contribuição e criação/reuso de workflows”, descrito na seção 7.1, foi o principal desafio do design da plataforma Fast Science. Para a sua modelagem, considerou-se que cada projeto de crowd science deve ser concebido através da definição de um fluxo de tarefas (workflow) que pode ser customizado com um conjunto de componentes disponíveis. Tais componentes podem ser tanto elementos HTML5 – como caixas de texto, checkboxes, etc. – quanto por widgets complexos – como componentes para marcar as coordenadas (x,y) em uma imagem. O resultado final é um fluxo de atividades previamente ordenadas e desenhadas em formulários customizados.
Um dos desafios enfrentados foi representar as diversas características dos componentes de uma forma genérica em um banco de dados relacional. Como cada componente depende da tarefa que ele pertence, o modelo deve ser flexível o bastante para aceitar valores mutáveis.
Outra necessidade do sistema é o armazenamento das contribuições fornecidas pelos participantes destes projetos. Assim, além de cada componente possuir suas características, ele deve possuir também um registro para cada usuário que efetivamente executou tarefas de um determinado workflow. A seguir é detalhada visão desta parte do modelo de dados.
7.3.1 Detalhe da visão Workflow
Para garantir a implementação dos requisitos listados no grupamento (3) da seção 7.1, um modelo de dados foi desenvolvido para apoiar a aplicação Web bem como garantir a consistência das características gerais da plataforma. Nele, a criação de workflows, armazenamento de contribuições pelos usuários e reusabilidade foram especialmente trabalhados.
No modelo simplificado e ilustrado na Figura 48, um usuário pode criar vários projetos. Tal usuário será o responsável pela administração do projeto, recebendo o papel denominado gestor do projeto. Além de preencher as informações básicas, o gestor será responsável pela criação de workflows, ou seja, definir as atividades e respectivas tarefas em uma sequência ordenada, para serem executadas pelos usuários da plataforma. Para fins de protótipo, cada projeto está limitado a apenas um workflow, embora o modelo apoie o sistema sem essa limitação.
Um workflow, então, é constituído de várias tarefas, cujas ações variam desde o envio de uma foto, georreferenciamento da localização de uma determinada coleta, preenchimento de formulários até tarefas de análise de dados como identificação de padrões em imagens. Essa variedade de opções foi identificada na avaliação dos projetos classificados no item 2.3 e na avaliação das plataformas de hospedagem (Capítulo 5) e as principais foram então selecionadas e transformadas em componentes. Um componente é um conjunto de elementos visuais com uma funcionalidade específica. Cada componente pode ser personalizado para uma tarefa específica através da edição de suas meta-informações, que podem ser tanto de estilo (texto da legenda, cores) quanto de funcionalidade (permitir a inserção manual de um endereço no mapa).
Uma vez que as tarefas e seus componentes estão especificadas, o workflow pode ser exibido em uma página pública para ser executado pelos usuários da plataforma. Cada componente de tarefa terá sua resposta armazenada junto com o usuário que a preencheu.
A Tabela 10 exemplifica os principais grupamentos de componentes e seus usos nos diferentes tipos de tarefas (coleta e processamento de dados).
Tabela 10 – Exemplo de tipos de componente por categoria de tarefa.
Tipo de Componente Tarefas de
Coleta de dados Tarefas de processamento de dados Pergunta X X Desenho X Captura X
Conforme exibido na tabela acima, os componentes utilizados nas tarefas podem ser de três tipos:
Perguntas: são componentes comuns tanto para as tarefas de processamento como
para coleta de dados. Permitem que os gestores do projeto elaborem formulários com perguntas que serão respondidas com o objetivo de descrever dados coletados ou analisar/classificar um conjunto de imagens, áudio ou vídeos pré-existentes.
Desenho: Muito utilizada em tarefas de processamento de imagem, pois permite que
os participantes identifiquem feições que serão marcadas ou desenhadas em suas imagens.
Captura: São componentes exclusivos das tarefas de coleta de dados e deverão
incluir APIs para captura e detecção de recursos de mídia existentes em celulares e tablets (câmera, áudio e vídeo, entre outros).
Para o armazenamento das mídias (imagens, vídeos e áudios), uma tabela de mídias em geral foi criada. Para fins de protótipo, apenas imagens são aceitas. Essas imagens podem estar associadas tanto à captura de imagens feita pelos participantes dos projetos de coleta de dados quanto imagens associadas ao conjunto de imagens (dataset) que serão utilizadas em um projeto de análise/processamento de dados.
Figura 48 - Modelo de dados simplificado da plataforma Fast Science – visão “Workflow”.
Descrição das tabelas do modelo simplificado da Figura 48.
User: armazena dados de um usuário. Pode ser utilizado para gerenciar um projeto ou contribuir para workflows no sistema.
Project: armazena informações gerais sobre o projeto. Possui múltiplos workflows.
Workflow: entidade que representa uma sequência de tarefas a serem executadas por um usuário. Pode ser de dois tipos (Coleta ou Processamento). No caso de Processamento, um dataset pode ser cadastrado para ser exibido aos usuários. Task: entidade que representa uma tarefa que compõe o workflow. Possui vários
componentes e uma ordem a ser exibida dentro do workflow.
Component: armazena a lista de componentes disponíveis no sistema. Esses componentes podem ser personalizados para cada tarefa.
TaskComponent: tabela intermediária entre as tabelas Task e Component. Armazena quais componentes pertencem a uma determinada tarefa. O resultado armazenado é o que será apresentado aos usuários no momento da contribuição. TaskComponentMeta: armazena meta-informações sobre itens que podem ser
personalizados nos componentes das tarefas “TaskComponent”. É composto por um par <name, value>, representando o nome da característica a ser personalizada e o seu valor. Um caso típico é o item “legenda” que todos os
componentes possuem. Seus dados serão armazenados sob o name “label” e value “Minha Legenda”. Na hora de renderizar o componente, a aplicação buscará pelos meta-valores existentes e montará o componente de acordo. Essa abordagem permite que componentes sejam estendidos e reutilizados sem comprometer componentes existentes, uma vez que o código da aplicação é o responsável por identificar quais características devem ser adicionadas.
TaskComponentAnswer: união de um TaskComponent com a resposta dada por um usuário no momento da contribuição. Esta tabela armazena a resposta, quando aplicável, de um colaborador ao TaskComponent criado. Inclui o id do colaborador e, se requerido pelo componente, o id da mídia associada. No caso do id da mídia, este pode estar associado a uma tarefa de processamento (imagem exibida de um dataset) ou ser um componente de uma tarefa de coleta (imagem capturada e enviada pelo contribuidor).
Media: armazena o caminho de uma imagem no sistema e o workflow a qual ela pertence. Dessa forma, um dataset escolhido pelo gestor será referenciado nessa tabela, assim como as imagens capturadas e enviadas pelos participantes de determinado workflow de coleta de dados.