Influences opérationnelles des chemins de fer

A partir do estudo de casos de projetos de coleta de dados e sensoriamento participativo, foi possível observar comportamentos e conceitos comuns. A partir dessas observações, foi possível mapear as atividades desse tipo de projeto e buscar modelar utilizando Unified Modeling Language (UML). A seguir, foram listadas as definições dos termos utilizados na construção dos diagramas.

A. Termos Utilizados

Solicitante: Ator que irá disponibilizar uma tarefa a ser realizada por um ou

mais participantes.

Participante: Ator que irá interagir com o intuito de realizar uma ou mais

tarefas.

Avaliador: Ator que irá interagir com o intuito de avaliar a qualidade, corretude,

ou completude de uma tarefa realizada por um ou mais participantes.

Tarefa: Unidade de trabalho. Uma tarefa pode ser realizada por um ou mais

participantes e envolve a coleta de medidas.

Medida: Dado coletado pelo participante. A coleta de medidas pode ser

realizada de maneira manual ou automática, por meio de sensores.

Projeto: Conceito que engloba tarefas segundo um contexto definido.

Expertise: Habilidade manual ou cognitiva necessária para a realização de uma

tarefa.

Treinamento: tutoriais, vídeo aulas ou qualquer outro tipo de disponibilização

de informações com o intuito de que um participante adquira expertise suficiente para realizar certa tarefa.

Motivação: Razão, a qual um participante é levado à realização de uma tarefa. Recompensa: Retribuição oferecida ao participante ao realizar uma tarefa, esta

podendo ser reconhecimento (status no projeto), satisfação pessoal, motivação altruística, aprendizado, diversão, bônus ou financeira apenas para citar algumas.

B. Diagramas

Inicialmente, um diagrama de atividades foi criado com o objetivo de mapear o fluxo e as etapas desse projeto. O diagrama em questão está apresentado na Figura 21. No diagrama é possível perceber que existem três atores principais. O solicitante, que é a pessoa que possui a necessidade de que uma determinada tarefa seja realizada. TWEDDLE et al. (2012) referem-se à esse ator como cientista e nesta tese de doutorado como Gestor. A escolha pelo termo solicitante nesse meta-modelo se deve ao objetivo de obter um maior grau de generalização. O avaliador, por sua vez, é um ator que fica responsável pela avaliação dos dados e, por consequência, a qualidade final dos dados

coletados. Esta etapa pode ser realizada pela equipe gestora do projeto (ex.: especialista) ou retornar para a multidão, utilizando outro workflow específico para esta atividade.

O workflow padrão se inicia com a criação de um projeto de coleta de dados pelo solicitante. As atividades do projeto são quebradas em tarefas, como a observação quantitativa ou qualitativa de um determinado evento ou a medição automática de um fenômeno por um artefato. A partir daí, o solicitante realiza uma chamada aberta para a comunidade e os participantes podem começar a contribuir. Um participante, dotado da expertise necessária para a realização da tarefa poderá executá-la. Caso não possua o conhecimento adequado, o participante poderá ser treinado para a realização da tarefa utilizando material de apoio, como: tutoriais, protocolos de coleta e vídeos fornecidos pelo solicitante. Depois de executada a tarefa, os dados coletados deverão ser enviados para o solicitante e esses podem passar por um processo de avaliação da qualidade antes de serem efetivamente aceitos pelo solicitante.

O processo de avaliação deverá ser realizado pelo avaliador, que pode ser o próprio solicitante, a comunidade ou um terceiro sendo, portanto, um papel que pode ser ocupado por diferentes entidades e/ou mecanismos (por ex.: esta etapa pode incluir a utilização de algoritmos computacionais específicos para o controle de qualidade).

Feito o levantamento dos projetos existentes, foi possível criar um diagrama de caso de uso com os três atores encontrados: solicitante, participante e avaliador. Os participantes poderão ser classificados como automáticos ou manuais dependendo da interação humana que exigem para submeter suas coletas. Ele poderá optar por realizar tarefas ou realizar treinamentos para aumentar sua expertise. O solicitante, por sua vez, poderá criar projetos de coleta de dados e solicitar tarefas para a comunidade. O avaliador, se existir, ficará com a ação de avaliar as medidas enviadas. O diagrama de caso de uso pode ser observado na Figura 22.

Figura 22 – Diagrama de caso de uso.

Após esse mapeamento inicial foi possível criar uma diagrama de classes conceitual que busca representar os conceitos e as relações entre eles. Esse modelo busca ser genérico o suficiente para atender às aplicações existentes e servir de base para a criação de novas iniciativas. O modelo é apresentado na Figura 23.

Figura 23 – Diagrama de Classe Conceitual

No modelo podemos perceber diversos conceitos que já foram apresentados anteriormente, como o conceito de participante, solicitante e projeto, por exemplo. Além dos conceitos já estabelecidos, outros foram criados para satisfazer os requisitos desse tipo de fluxo de atividade. Para uma determinada tarefa, o participante poderá realizar medições e enviá-las para o solicitante. A classe Medição pode ser representada tanto por uma Medição Manual, quando realizada de forma manual pelo participante ou uma Medição Automática, quando realizada com auxilio de aplicativo móvel ou por algum tipo de sensor. A cada medição realizada, o participante poderá obter uma ou mais recompensas, sendo possíveis benefícios financeiros, benefícios para o grupo ou vantagens individuais. As recompensas, no entanto, não estão restritas a esses grupos, podendo pertencer as mais diferentes naturezas. A motivação foi mapeada como uma associação entre participante e projeto para representar a “cola” que une o participante

ao projeto, é o que NOV et al. (2011) descreve como prazer associado à experiência da participação. A expertise, por sua vez, representa habilidades ou conhecimento de ferramentas que a tarefa requisitará para sua realização completa. Além disso, um participante poderá possuir um determinado conjunto de expertises. A expertise necessária para concluir a tarefa e a que o participante possui determinarão se é possível que haja uma contribuição desse membro com a tarefa em questão.

Para validar o modelo apresentado, utilizando um terceiro modelo existente na UML que é o diagrama de objetos. Utilizando o projeto The Great SunFlower Project7, simulamos o funcionamento e criamos as instâncias de objetos fictícios para verificar se o modelo proposto atendia a um sistema já existente. Esse resultado é apresentado no diagrama de objetos aplicado ao Projeto The Great SunFlower (Figura 24).

No modelo podemos perceber que existe um solicitante, de nome “Gretchen LeBuhn”. Esse solicitante cria um projeto denominado The Great SunFlower e que foi dividido em uma tarefa, cujo objetivo foi estabelecido como “Contar abelhas que visitam a flor plantada”. Para realização dessa tarefa é solicitada uma expertise, sendo esta descrição como: “Saber identificar as espécies de abelhas”. Para facilitar o entendimento, criamos apenas dois participantes no projeto. Os participantes possuem uma determinada motivação para contribuir com o projeto. No caso, os participantes possuem uma motivação descrita como “Contribuir com a pesquisa”. Para entender como funciona a contribuição para o projeto, observaremos o participante “Peter” que possui a expertise necessária para contribuir com a tarefa solicitada. No exemplo, Peter contribuiu três vezes para o projeto. Em cada contribuição, ele obteve para si uma recompensa, no caso descrito como “Satisfação pessoal”. O projeto de exemplo não possui uma validação explícita dos dados. Portanto, não é possível afirmar que exista um avaliador e uma avaliação sobre a coleta realizada. Por esse motivo não foi apresentado nenhum objeto com o papel de avaliador.

Os resultados aqui discutidos foram primeiramente apresentados na conferência internacional CSCWD 2014 (MORAES, A. D., FONSECA, F., ESTEVES, M. G. P., et al, 2014). Com a criação deste meta-modelo, observou-se que conceitos, etapas e tarefas que são comuns podem ser reaproveitados e reutilizados em projetos semelhantes.

7 _{http://www.greatsunflower.org}

Capítulo 4 – Mix4Crowds: Um Framework para o