Avaliação Inteligente de Redes Sociais aplicada ao Portal do Software Público Brasileiro

Transcrição

1 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Avaliação Inteligente de Redes Sociais aplicada ao Portal do Software Público Brasileiro Eduardo Ferreira dos Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Orientadora Prof ā. Dr ā. Fernanda Lima Coorientadora Prof ā. Dr ā. Christiana Freitas Brasília 2011

2 Universidade de Brasília UnB Instituto de Ciências Exatas Departamento de Ciência da Computação Curso de Computação Licenciatura Coordenador: Prof. Dr. Homero Luiz Piccolo Banca examinadora composta por: Prof ā. Dr ā. Fernanda Lima (Orientadora) CIC/UnB Prof ā. Dr ā. Christiana Freitas ADM/UnB Prof. MSc Fernando Albuquerque CIC/UnB CIP Catalogação Internacional na Publicação Eduardo Ferreira dos Santos. Avaliação Inteligente de Redes Sociais aplicada ao Portal do Software Público Brasileiro/ Eduardo Ferreira dos Santos. Brasília : UnB, p. : il. ; 29,5 cm. Monografia (Graduação) Universidade de Brasília, Brasília, Software Público, 2. Redes Sociais, 3. CPM, 4. Análise de Redes Sociais, 5. Portal, 6. Colaboração CDU 004 Endereço: Universidade de Brasília Campus Universitário Darcy Ribeiro Asa Norte CEP Brasília DF Brasil

3 Universidade de Brasília Instituto de Ciências Exatas Departamento de Ciência da Computação Avaliação Inteligente de Redes Sociais aplicada ao Portal do Software Público Brasileiro Eduardo Ferreira dos Santos Monografia apresentada como requisito parcial para conclusão do Curso de Computação Licenciatura Prof ā. Dr ā. Fernanda Lima (Orientadora) CIC/UnB Prof ā. Dr ā. Christiana Freitas ADM/UnB Prof. MSc Fernando Albuquerque CIC/UnB Prof. Dr. Homero Luiz Piccolo Coordenador do Curso de Computação Licenciatura Brasília, 07 de fevereiro de 2011

4 Dedicatória Dedico o trabalho às noites sem dormir, aos fins de semana estudando, à ausência de férias e às mais dez greves que enfrentei. Dedico o trabalho ao céu da capital, à floresta de bambuzal, ao cerrado, às luzes de natal, ao Lago Paranoá. Dedico o trabalho às aulas que não fui, às aulas que fui e não estava lá, às que estava lá e desejei não estar, aos desejos latentes que surgiram na Universidade. Dedico o trabalho às aulas que não tive, aos professores que conheci sem conhecer, aos que tentaram ensinar, aos que não tentaram ensinar, aos que serviram de incentivo, aos que não me incentivaram, aos que não gostam de mim. Dedico o trabalho aos que acreditaram, aos que não acreditaram, aos que viveram comigo, aos que morreram sem mim, aos que ajudaram, aos que atrapalharam, aos que existiram. Dedico o trabalho ao Brasil, por me dar a oportunidade de estudar, ainda que tenha tentado retirar. Dedico o trabalho à vida, pois o fim da Universidade é apenas um dos vários começos.

5 Agradecimentos Agradeço primeiramente ao meu chefe à época no Ministério do Planejamento e agora grande amigo, Corinto Meffe, que num momento de desânimo me ofereceu o apoio e o suporte para continuar lutando. Agradeço também ao meu primeiro chefe na área de informática e grande amigo, Rodrigo Proença, que além de possuir um caráter inquestionável, me ajudou a abrir as portas da vida profissional. Agradeço meu pai e minha mãe, que nunca deixaram de acreditar em mim e me deram não somente a vida, mas educação e saúde. Finalmente, agradeço à pessoa que esteve e estará para sempre ao meu lado, não somente pelo seu amor, mas também pela paciência e compreensão: minha esposa Daniela. Aos amigos, que fizeram e ainda fazem parte da longa caminhada que agora chega a um final, agradeço o amor e os incentivos recebidos. Não seria possível chegar até aqui se não fossem vocês, e espero que continuem comigo, pois eu estarei sempre com vocês em espírito.

6 Resumo O trabalho apresenta uma análise do Portal do Software Público Brasileiro, com foco em análise de redes sociais e métodos de previsão para comportamentos de rede. A análise tem como principal objetivo verificar os fatores que atestam a sustentabilidade da rede e suas implicações para os outros membros do ecossistema. Ao final são apresentadas sugestões de atitudes gerenciais que podem aumentar a probabilidade de sustentação da rede. Palavras-chave: Software Público, Redes Sociais, CPM, Análise de Redes Sociais, Portal, Colaboração

7 Abstract This research presents an analysis about Brazillian Public Software Portal, focusing on social network analysis and prediction methods for network nodes behavior. The analysis is focused on finding the key factors that affect the network sustainability and its implications to other members in the ecossystem. Suggestions about management atitudes to improve the network sustainability are presented. Keywords: Public Software, Social Networks, CPM, Social Network Analysis, Portal, Colaboration

8 Sumário Lista de Figuras 10 Lista de Tabelas 11 Trechos de código 12 Capítulo 1 Introdução O papel do Estado no fomento ao desenvolvimento colaborativo Teoria e método de verificação das hipóteses Capítulo 2 Análise de Redes Sociais Princípios e Perspectivas Teoria dos Grafos Definições em Grafos Notação Sociométrica Encontrando os Atores mais Importantes Escopo da Análise Redes Complexas Comportamento e Predição em Redes Complexas Capítulo 3 O Portal do Software Público Brasileiro Ideais e Justificativas A Escassez Artificial A Sociedade da Informação no Brasil O Portal do Software Público Brasileiro Construção e Base Tecnológica Gestão do Conhecimento e Comunidades Virtuais OpenACS e os subsistemas Modelo MVC Banco de Dados Aplicações Verticais e dotlrn O Portal do Software Público Brasileiro e suas comunidades 45 Capítulo 4 Obtenção dos Dados Visão Geral do Portal Métricas da Pesquisa Aplicando o método de previsão

9 4.3.1 Extraindo os Dados Construção das consultas e cálculo do peso Cálculo do coeficiente de autocorrelação Probabilidade de extinção Análise Gráfica Formatação dos dados Grafos traçados com a ferramenta PEx-Graph Capítulo 5 Análise dos Dados Do objeto de análise Características da colaboração e mobilidade Sustentabilidade do ecossistema Grafo conjunto de relações e análise de redes sociais Capítulo 6 Conclusão 80 Referências 83 Apêndice A Dados utilizados para a construção dos gráficos 87 A.1 Coeficiente de autocorrelação A.2 Tempo de vida da relação A.3 Probabilidade de extinção A.4 Formato VNA para a ferramenta PEX-Graph A.5 Índice de participação A.6 Histórico de registros A.7 Evolução do número de objetos de colaboração com o tempo A.8 Índice de mobilidade

10 Lista de Figuras 2.1 Grafo Exemplo G Dígrafo Exemplo G Rede Exemplo Dinâmica para redes complexas Ecossistema do Portal do Software Público Brasileiro Diagrama dos subsistemas do OpenACS Modelo MVC Modelagem dos Objetos no OpenACS Modelo de grupos e permissões Esquema de diretórios de uma instalação típica Esquema de diretórios de um pacote O Portal do Software Público Brasileiro Entrando em uma comunidade Modelagem de dados para as mensagens de fórums Modelagem de dados para as páginas Wiki Gráfico do coeficiente de autocorrelação para comunidades selecionadas Tempo de vida da relação versus taxa w out /(w in + w out ) Probabilidade de extinção versus taxa w out /(w in + w out ) Grafo de colaboração nos fóruns das comunidades Grafo de colaboração nas páginas Wiki das comunidades Total de membros na comunidade e participantes Número de novos membros cadastrados por período Criação de objetos de colaboração com o tempo Participação das principais comunidades no total de objetos de colaboração por período Gráfico do índice de mobilidade para as comunidades do Portal Tipos de rede Grafo de contribuições destacando nós centrais

11 Lista de Tabelas 2.1 Matriz Sociométrica para o Grafo G Lista de Objetos Lista de objetos mais criados

12 Trechos de código 4.1 Seleção dos tipos de objeto Seleção dos objetos mais criados Teste de chave estrangeira na coluna package id Consulta por colaborações nos fóruns Consulta por colaborações em páginas Wiki Função em PL/pgSQL que constrói o coeficiente de autocorrelação Consulta que calcula os pesos entre as relações inter e extra comunidade Consulta que calcula os pesos entre as relações inter e extra comunidade para todo o Portal Consulta que obtém a probabilidade de extinção versus a taxa W out /(W in + W out ) para todo o Portal Arquivo exemplo para o formato VNA Consulta que extrai os grafos no formato de entrada da ferramenta Pex-Graph Consulta que extrai os dados dos nós no formato de entrada da ferramenta Pex-Graph Arquivo VNA exemplo com os dados do Portal do Software Público Consulta sobre a mobilidade nas relações

13 Capítulo 1 Introdução O Portal do Software Público Brasileiro é reconhecido mundialmente como uma iniciativa importante de compartilhamento e construção de conhecimento colaborativo. Um dos mais importantes grupos de estudo sobre o universo do software livre no mundo, o consórcio organizador do Open World Forum 1, escolheu, no ano de 2008, a iniciativa brasileira como uma das que faria parte do FLOSS Roadmap [Laisné and Others, 2008]. O documento tem por objetivo analisar e acompanhar algumas das iniciativas que podem impulsionar o desenvolvimento do software livre como um todo. Além do reconhecimento internacional, a iniciativa ganhou vários prêmios e menções honrosas no Brasil, como o Prêmio TI & Governo, e citações em artigos e revistas de grande prestígio. Do ponto de vista do reconhecimento, pode-se dizer que a iniciativa é um grande sucesso. Todavia, com o crescimento da importância, surge também uma grande preocupação com a sustentabilidade. Empresas e governos necessitam realizar projetos de longo prazo, e um ambiente inseguro desestimula o apoio a qualquer iniciativa. A vida democrática no Brasil é relativamente nova, uma vez que as eleições diretas foram retomadas somente em 1989, e não há cultura de projetos de Estado. Para que projetos perdurem e se tornem importantes precisam ser reconhecidos pela sociedade e aceitos pelas diversas estruturas governamentais. Mas seria o reconhecimento social suficiente para garantir a sustentabilidade do Projeto? De fato, a sociedade do conhecimento baseada na rede demonstra grande capacidade de mobilização, e em nenhum outro momento da história da humanidade o conhecimento foi tão importante ou teve tanto valor real. No livro A Riqueza Revolucionária [Tofler and Tofler, 2007], os autores citam um fenômeno definido por eles como terceira onda de riqueza. Passa a ser um desafio então mensurar o fenômeno e obter informações concretas que subsidiem análises mais aprofundadas. O objetivo principal do trabalho é descobrir quais os elementos fundamentais no interior da rede que afetam sua sustentabilidade e como mensurar tais 1 O Open World Forum ou apenas OWF é um evento realizado anualmente em Paris que reúne as maiores autoridades do universo do Software Livre no mundo. Mais informações podem ser encontrados no Portal do evento: 2 Sigla para software livre e aberto como é conhecida principalmente na Europa: Free, Libre and Open Source Software. 13

14 elementos sob a ótica de uma rede baseada na Internet. Técnicas de coleta e métricas de análise vêm sendo desenvolvidas para lidar com os fenômenos da nova geração da Internet, principalmente no que diz respeito à colaboração. O estudo e aplicação das métricas ao caso do Portal do Software Público Brasileiro são os temas debatidos nos próximos capítulos. 1.1 O papel do Estado no fomento ao desenvolvimento colaborativo O livro Wikinomics [Tapscott, 2007] traz uma importante questão sobre o papel do Estado em relação ao desenvolvimento no modelo colaborativo. Afinal, como resolver a equação provisionamento versus inovação e garantir um modelo sustentável no desenvolvimento de software para o país? O livro sugere uma resposta ao introduzir o conceito de base comum de produção, um ambiente neutro que compartilha os mesmos recursos e divide responsabilidades entre todos que o habitam. O Professor Imre Simon coloca o conhecimento entre os bens de propriedade difusa definidos por ele como commons [Simon and Vieira, 2007]: Commons são conjuntos de recursos utilizados em comum por uma determinada comunidade. Todos os membros dessa comunidade podem utilizá-los, de forma transparente, sem necessidade de permissões de acesso. No caso do Portal do Software Público Brasileiro, o Governo tenta agir como indutor da inovação, mas instrumentos de avaliação que permitam entender a complexidade dos agentes envolvidos e o retorno de cada um são importantes justificativas de si mesmos. Em teoria uma rede democrática sob a qual paire algum mecanismo de controle e acompanhamento tem mais chances de ser bem-sucedida do que redes completamente dispersas. Uma das hipóteses a ser analisada é se há de fato a necessidade de um instrumento central para coordenar as redes, ou se o livre desenvolvimento pode favorecer o crescimento. É importante ainda observar o caráter da colaboração. Se o ato de interagir para gerar um objeto de conhecimento é a riqueza da comunidade, como é possível garantir que ela continue produzindo? Uma outra hipótese a ser verificada é de que comunidades cuja aprendizagem é mais fácil são capazes de produzir mais conhecimento. Uma comunidade se torna mais efetiva quando aumenta a absorção do conhecimento entre seus membros, ou seja, se eles estão de fato aprendendo alguma coisa. Para medir a intensidade da troca do conhecimento e suas implicações serão necessárias teorias capazes de analisar redes e suas dinâmicas. É necessário também mapear os agentes do sistema, o grau de interação entre eles e sua importância para o ecossistema como um todo. 14

15 1.2 Teoria e método de verificação das hipóteses Para medir a intensidade da troca de conhecimentos e suas implicações a teoria da Análise de Redes Socias [Wasserman and Faust, 2007] permite mapear as relações construindo uma espécie de árvore indicando possíveis pontos de acumulação do conhecimento. Permite ainda identificar a fluidez das relações e concluir como os membros se organizam dentro da comunidade. O objetivo da análise é gerar um conjunto de grafos de suas relações construindo esboços de figuras geométricas que possuem comportamento comum. O comportamento aliás é analisado na ótica dos possíveis caminhos que a informação pode percorrer. Grafos com geometria comum possuem características em comum, como ausência ou presença de liderança e organização hierárquica entre os membros. Todavia, somente com a análise das redes sociais não é possível realizar observações sobre o futuro da rede. O método é capaz de isolar fatias do tempo, mas não possui métricas diretas para analisar as possibilidades de crescimento e morte. Para resolver a limitação causada pelo método de análise do grafo é necessário utilizar teorias que envolvem análise com a variação do tempo. O método CPM [Derényi et al., 2005], ou k-clique Percolation Method, fornece subsídios para organizar redes aleatórias, cujo nascimento e morte obedecem a critérios não intrinsecamente definidos. No caso do Portal, as comunidades são fortemente definidas e possuem espaço delimitado, não sendo análogas diretamente às geradas pelo método CPM. Todavia, pode ser importante utilizar algumas de suas técnicas para facilitar a visualização de determinadas características dos dados. A análise quantitativa da evolução do sistema social é uma técnica que permite fazer observação dos grafos entre períodos sucessivos dentro de uma comunidade. Dos grafos são extraídos parâmetros que mais tarde serão capazes de constituir métricas de análise da evolução temporal. A cada fatia do tempo um novo grafo é desenhado, e o conjunto de grafos entre tempos sucedidos poderá gerar coeficientes úteis para o trabalho, tais como coeficiente de expansão e peso da relação. Assim, para verificar as hipóteses e responder à questão central do trabalho será necessário utilizar técnicas mistas de modelagem e desenho, comparando os valores a conjuntos de dados já analisados e tirando conclusões sobre o seu comportamento. No capítulo 2 a teoria de análise de redes sociais é discutida e definida sob a ótica de redes complexas. No capítulo 3 está sob observação a construção do Portal do Software Público Brasileiro, tanto no que diz respeito à tecnologia quando no que diz respeito à fundamentação teórica. A aplicação da análise de dados ao Portal é discutida no capítulo 4, enquanto a análise dos resultados é tema do capítulo 5. Na conclusão (capítulo 6), além de comentários sobre a validação das hipóteses, são apresentadas sugestões de melhoria para o ambiente. 15

16 Capítulo 2 Análise de Redes Sociais Neste capítulo é apresentada a teoria para análise de redes sociais, bem como sua aplicação em um sistema de Internet, com foco em rastreamento de ações de usuário e identificação de objetos. 2.1 Princípios e Perspectivas A análise de redes sociais difere levemente das ciências comportamentais de maneira geral ao analisar a importância das relações entre os entes que estão interagindo. As relações são definidas por ligações entre unidades, constituindo um conceito fundamental da teoria. Além disso, as seguintes questões são importantes, entre outras: Atores e suas ações são vistos como interdependentes ao invés de independentes, unidades autônomas; Nós ou ligações relacionais entre atores são canais para transferência ou fluxo de recursos. Sendo os nós utilizados como canais para transferência de recursos, se observamos uma acumulação maior em um determinado canal, podemos identificar um nó que tem papel importante na rede. É o elemento que serve para ligar os outros, e sem a sua existência a circulação de recursos pode ficar prejudicada. Uma complexidade ainda maior pode ser acrescentada à análise dos fluxos se percebermos que grande parte do que é circulado numa rede complexa tem caráter intangível e de difícil mensuração. O livro de Wasserman and Faust [Wasserman and Faust, 2007] contém uma explicação sobre a técnica de obtenção dos dados: Dados de redes sociais consistem em um conjunto de medidas de relações para um ou mais conjuntos de atores. (...) Serão necessárias notações para o conjunto de atores, a relação e os atributos do ator de forma que possamos nos referir a importante conceitos de rede de maneira unificada. 16

17 O mais importante para a análise é construir então um conjunto de dados, que terá como principal objetivo mapear as relações e atributos dos principais atores do sistema. Contudo, existem três importantes perspectivas pelas quais os dados podem ser observados e terão notações diferentes, uma complementar à outra: 1. Teoria dos Grafos: o esquema mais elementar pelo qual atores e suas relações podem ser representados é a Teoria dos Grafos. Considerando a rede um conjunto, os vértices são todos os objetos ou atores envolvidos, e cada relação representa uma aresta. 2. Notação Sociométrica: a notação sociométrica se utiliza de matrizes, onde as linhas representam o ator e as colunas as relações mapeadas a ele, também conhecidas como Matrizes Sociométricas. Talvez seja o método mais comum na análise de redes sociais. 3. Notação Algébrica: com as técnicas da álgebra de matrizes, podemos criar relações que sejam um conjunto de outras, ou relações compostas. Podemos ainda definir relações múltiplas e hierárquicas, e utilizar técnicas formais para adquirir os valores absolutos. O objetivo central do trabalho é produzir uma matriz sociométrica para a partir daí construir o grafo com as relações da rede. Contudo, em sistemas com tantos objetos e papéis diferentes, a quantidade de atores envolvidos pode ser tão grande que um grafo de todas as relações seja ininteligível. Com a utilização da álgebra estrutural aplicada aos grafos pode-se mapear os objetos que possuem mais relações em todo o sistema, ainda que de forma composta. 2.2 Teoria dos Grafos Como citado em [Feofiloff et al., 2009] e [Mariani, 2009], um grafo G(V,A) é definido por V e A, onde V representa os vértices ou nodos do grafo e A as arestas. Temos então que: V - conjunto não vazio A - pares ordenados (v, w), onde v e w são elementos distintos de V Um interessante exemplo ilustrativo pode ser encontrado em [Mariani, 2009]: Seja por exemplo o grafo dado por V = {p p é uma pessoa} A = {(v,w) v é amigo de w} Esta definição representa toda a família de grafos. Um exemplo da família é dado pela figura: 17

18 V = {Maria, Pedro, Joana, Luiz} Figura 2.1: Grafo Exemplo G1 A = {(Maria, Pedro), (Joana, Maria), (Pedro, Luiz), (Joana, Pedro)} No exemplo acima temos um grafo clássico, onde as arestas são definidas como uma relação de amizade entre os nós do grafo. Contudo, como a relação é simétrica, ou seja, se v é amigo de w, então w é amigo de v, as arestas não possuem qualquer orientação. Existem outros tipos de grafos, conhecidos como dígrafos, onde a orientação determina se a relação fornecida é válida. Utilizamos mais um exemplo de [Mariani, 2009] para ilustrar: Considere, agora, o grafo definido por: V = {p p é uma pessoa da família Castro} A = {(v,w) v é pai/mãe de w} Um exemplo deste grafo (ver G2) é: Figura 2.2: Dígrafo Exemplo G2 V = {Emerson, Isadora, Renata, Antonio, Rosane, Cecília, Alfredo} A = {(Isadora, Emerson), (Antonio, Renata), (Alfredo, Emerson), (Cecília, Antonio), (Alfredo, Antonio)} 18

19 No exemplo apresentado, a relação de parentesco está diretamente definida pela direção da seta. Assim, podemos concluir que Emerson é pai de Isadora e Alfredo, mas não podemos dizer que Alfedo é pai de Emerson. Um dígrafo é bastante útil para representar relações assimétricas, também conhecidas como grafos orientados Definições em Grafos Complementando a análise dos grafos, existem ainda alguns conceitos que serão importantes no decorrer o trabalho que precisam ser definidos. Ordem: número de vértices ou cardinalidade do grafo. Nos exemplos 2.1 tem grau 4 e 2.2 tem grau 6. ordem(g1) = 4 ordem(g2) = 6 Adjacência: dois vértices são adjacentes se há uma aresta incidente a ambos no grafo. Em 2.1 Maria e Pedro são adjacentes. No caso de dígrafos, precisamos considerar a orinetação, que resultará em vértices do tipo: Sucessor: w é sucessor de v se há um vértice que parte de v para w. Na figura 2.2, dizemos que Emerson e Antonio são sucessores de Alfredo. Antecessor: v e antecessor de w se há um vértice que parte de v para w. Novamente na figura 2.2, Alfredo e Cecilia são antecessores de Antonio. Grau: número de arestas que lhe são incidentes. No grafo 2.1, grau(pedro) = 3, por exemplo. Se estamos falando de grafos dirigidos, consideramos outras definições: Grau de emissão: número de arcos que partem de um nó. Ex.: grau- Emissão(Antonio) = 1. Grau de recepção: número de arcos que chegam a um nó. Ex.: grau- Recepção(Renata) = 1. Fonte: um vértice v é fonte se seu grau de recepção é zero. Sumidouro: um vértice v é sumidouro se seu grau de emissão é zero. Laço: um laço é uma aresta ou arco do tipo a = (v, v), ou seja, é emissor e receptor ao mesmo tempo. Muitos outros conceitos e definições sobre grafos podem ser encontrados em [Feofiloff et al., 2009], [Mariani, 2009] e [Pimentel and Oliveira, 2009]. 19

20 2.3 Notação Sociométrica De acordo com [Wasserman and Faust, 2007], a sociometria é o estudo das relações afetivas de contradição, ou seja, amor/ódio e amigos/inimigos. Os dados de uma rede social composta de pessoas onde as relações afetivas puderam ser medidas é conhecida como sociométrica. Os dados das relações são apresentados em matrizes bidimensionais onde os atores que emitem representam as linhas e os que recebem são as colunas. Um paralelo direto entre emissão e recepção pode ser feito entre sucessores e receptores citados na seção Uma matriz sociométrica para uma relação de dicotomia é exatamente a matriz de adjacência para o grafo que qualifica os nós entre os atores para a relação em questão. Há portanto uma relação direta entre a teoria dos grafos e a sociometria para análise de redes sociais, que poderemos utilizar na análise dos dados da pesquisa. Vejamos a matriz da figura 2.1: Maria Joana Pedro Luis Maria Joana Pedro Luis Tabela 2.1: Matriz Sociométrica para o Grafo G1 Utilizando a teoria de que a relação é de dicotomia, ou seja, os únicos valores possíveis são 0 e 1, e o fato de que todas os vértices não estão orientados, os nós adjacentes estão todos relacionados. Se considerássemos a orientação, seria necessário analisar em cada nó a direção da interação. Se Luis interage com Pedro e Pedro não interage com Luis, a matriz teria que ser construída sob uma outra ótica. A grande dificuldade na análise de grafos das redes sociais é que dois pesquisadores analisando a mesma rede com os mesmos dados produzem grafos (ou sociogramas) diferentes. Grande parte do problema está relacionado ao fato de que a colocação dos atores em linhas do espaço bidimensional é completamente arbitrária. A matriz sociométrica surge como uma tentativa dos pesquisadores de fornecer um caráter decisório formal à teoria. Portanto, utilizaremos na pesquisa a abordagem sociométrica que fornece mais subsídios à montagem dos grafos, reduzindo o caráter aleatório. Surgiram então combinações e operações com matrizes para refinar os grafos e identificar melhor subgrupos de atores, e as técnicas computacionais tornaramse cada vez mais importantes, possibilitando cruzamento dos dados e algoritmos cada vez mais complexos. É comum uma rede social possuir dezenas e até centenas de milhares de nós em uma primeira análise, e para reduzir esse número até um tamanho aceitável é necessária a aplicação de algoritmos e operações de matrizes, que só podem ser resolvidas com muito poder computacional. Quando lidamos com relações complexas, é fundamental poder utilizar artifícios matemáticos para facilitar a visualização das redes. Como os dados serão sempre representados por matrizes na análise sociométrica descritas na seção anterior, o primeiro passo é identificar os tipos de dados que estamos tratando. 20

21 Quando tratamos de dicotomias, que já foi discutido na seção 2.2, temos uma rede que chamamos 1-mode network. Os resultados para os questionamentos serão sempre do tipo 0 ou 1. Também é possível tratar dados com redes do tipo 2-mode network, ou seja, redes que possuem elementos de um tipo ou de outro. Podemos obter uma rede 2- mode a partir de uma 1-mode multiplicando-se pela sua transposta, por exemplo. Várias outras operações poderão ainda ser realizadas para definir cruzamento de dados, como subtração, adição e multiplicação de matrizes, cálculo da inversa e muitos outros. No ponto da análise de redes sociais, a Álgebra serve como ferramenta de apoio para o refinamento das matrizes e consequentemente uma melhor visualização dos grafos. Caso algum algoritmo de matriz necessite ser utilizado, sua aplicação e resultados serão citados. 2.4 Encontrando os Atores mais Importantes Alguns autores defendem que a importância de um determinado nó para a rede está diretamente relacionado à sua posição. Uma posição mais central indicaria uma maior quantidade de relações fluindo por/para ele, e aí estaria um importante sinal. Também podem ser considerados lugares de destaque os nós localizados em posições mais estratégicas dentro da rede. Numa rede de inovação, por exemplo, a posição mais estratégica pode não ser aquela que mais interage, e sim a que tem contato com as pessoas que realmente realizam o trabalho. Em redes com direcionamento, ou seja, onde as relações fluem para um determinado ponto, talvez a posição mais importante seja aquela de receptor, ou seja, de pessoa que recebe mais do que fornece aos outros, como descrito na seção 2.2. Contudo, a natureza da relação em estudo pode alterar os critérios do que definimos como central. Se o objetivo for analisar um grupo, as relações que os mantêm unidos talvez sejam mais importantes, e o elemento responsável por isso está sim numa posição estratégica. Quando montamos o sociograma para uma rede complexa, é possível inferir visualmente a quantidade de passos necessários para chegar de um ator a outro. Quanto menor a distância, maior é a proximidade entre os nós e mais rápido acontece a interação. Como o caminho que leva à ligação pode ser diverso, é preciso considerar todas as possibilidades. A menor distância percorrida entre dois nós é também conhecida como geodésica. Os três conceitos que definem a centralidade de um ator em uma determinada rede social, conforme citado em [Guarnieri, 2008] são: atividade, intermediação ou betweenness e proximidade. A atividade indica a quantidade de relações que um nó possui, a intermediação indica a posição estratégica ocupada por um nó, normalmente ligando dois subgrupos em sociogramas e a proximidade define quantos passos são necessários até que a interação entre dois nós aconteça. Todas são importantes, e a escolha será baseada no que for definido como escopo da análise. Para o caso específico de comunidades virtuais, como o Portal do Software Público Brasileiro, talvez o mais interessante seja conseguir identificar relações 21

22 complexas e imprevisíveis. Assim, a atividade pode ser considerada um dado mais substantivo. Todavia, ao definirmos os elementos que fornecem maior sustentabilidade, o caráter de ligação entre os diferentes grupos torna-se de fundamental importância, ou seja, a capacidade de intermediação. Comunidades de Software Livre existem em vários lugares do mundo, até mesmo com soluções de governo. Todavia, a presença de um elemento conectivo e, até certo ponto, regulador, torna a experiência única e interessante. Dado seu caráter multifacetado, é muito provável que a sustentabilidade não possa ser definida somente com a Análise das Redes Sociais, e outras teorias podem servir para complementar o estudo e fornecer uma análise mais precisa do problema. No decorrer do estudo encontraremos teorias que se combinam muito bem e serão utilizadas para enriquecer a análise. 2.5 Escopo da Análise A definição do escopo na teoria de Análise de Redes Sociais define o objetivo do estudo, ou seja, o que se quer medir. Além de ajudar na concentração dos esforços, serve também para dizer como serão tratados e analisados os dados obtidos na pesquisa, ou ainda que tipo de dado deve ser aferido. Temos basicamente dois tipos de abordagem: redes totais (whole networks) e redes egocêntricas. As redes totais são aquelas em que o total de interações deve ser aferido, considerando uma unidade específica de análise. Se queremos analisar uma determinada comunidade, podemos separar seu ambiente em usuários e administradores e verificar o total de interações que ocorrem entre cada um deles. Os maiores desafios referentes a esse tipo de abordagem estão relacionados à definição teórica da unidade de análise e o universo de dados. Se decidirmos analisar, por exemplo, todos os tipos de conversa realizados na rede, a definição de o que seria uma conversa pode influenciar diretamente o resultado da pesquisa, e voltamos ao problema da análise de sociogramas onde dois pesquisadores obtinham resultados diferentes com o mesmo conjunto de dados. Há ainda o problema de que, se falamos de uma rede total, precisamos ter acesso às informações de todos os possíveis nós, o que normalmente requer um grande esforço computacional. Já redes egocêntricas são representações da interação de um indivíduo (ou ator, em nossos termos) com toda a sociedade. No caso queremos saber exatamente o papel que representa na comunidade, observando como são suas atividades cotidianas. São muito utilizadas na análise de distúrbios psicológicos e em pesquisas comportamentais da psicologia Redes Complexas Quando o problema das redes é levado para a Internet aparece um universo não trivial de interações que, em alguns casos, tornam o trabalho de construção do grafo bastante difícil. Nas figuras 2.1 e 2.2 estão representados exemplos de grafos orientados em relações facilmente identificadas através de matrizes sociométricas. Em ambos os exemplos todas as relações são contidas em pequenas figuras de fácil visualização, e todas as relações podem ser facilmente distinguidas. 22

23 Todavia, ao tratarmos sistemas de relacionamento baseados em Internet, podemos presenciar uma quantidade muito grande de nós e relações entre eles. Um sistema de 2000 usuários possui, por exemplo, potenciais 2000 nós que precisam ter suas interações dentro de uma comunidade mapeadas. Tais redes são denominadas Redes Complexas e são representadas por grafos que possuem grandes números de vértices e arestas. Um bom exemplo é dado no experimento de Milgram descrito por [Andery, 2010]: Para realizar o experimento, pessoas foram selecionadas aleatoriamente em duas cidades dos Estados Unidos. Para cada pessoa selecionada, foi entregue um envelope contendo o nome de um destinatário, o qual pertencia a alguma cidade do outro lado do país. Foi solicitado, então, que cada participante enviasse o envelope ao destinatário caso o conhecesse; caso contrário, que escrevesse o próprio nome em uma lista e a enviasse junto com o envelope a algum conhecido que, em sua opinião, teria maior probabilidade de conhecer o destinatário. Muitos envelopes se perderam, mas os que chegaram passaram na mão de aproximadamente seis pessoas. Atualmente, esse efeito tem sido verificado diretamente em um grande número de redes complexas. Para entender melhor o experimento descrito é preciso acrescentar a definição de profundidade a uma relação. Entende-se por profundidade o número de nós que um vértice precisa percorrer até encontrar-se com outro que não está necessariamente adjacente. No exemplo acima vimos que as relações têm profundidade máxima de seis, ou seja, são no máximo seis pessoas até que a mensagem atinja o seu destino. Um Portal de Internet é claramente uma rede complexa de colaboração, mas difere do exemplo apresentado exatamente pelo conceito de colaboração. Em [Cortelazzo, 2000] vemos que: Para desenvolvermos uma colaboração, temos que criar e manter relações que incluam interesses pessoais e sociais comuns entre nós e os demais parceiros que compõem uma densa teia de conexões interpessoais que, por sua vez, pode mesmo gerar outros projetos previstos. Em uma rede de colaboração para a Internet, estamos interessados no fenômeno de criação de conteúdos derivados ou objetos de conhecimento construídos colaborativamente. Partindo do princípio que comunidades de software possuem por definição o objetivo tecnológico comum, as relações que vamos observar são aquelas relacionadas com a construção do conhecimento. Tais relações se iniciam com uma dúvida ou construção que pode surgir ao acaso dentro da comunidade e se dispersa à medida que mais pessoas vão interagindo com o objeto inicial. Por isso a profundidade das relações é tão interessante: se conseguirmos mapear os estímulos que geraram a maior quantidade de respostas, podemos detectar a complexidade da rede. 23

24 2.5.2 Comportamento e Predição em Redes Complexas O grande conjunto de interações em um sistema de Internet resulta em estruturas complexas que mudam com bastante frequência. É muito difícil prever e construir dinâmicas precisas para qualquer tipo de rede, mas existem métodos que nos permitem fazer aproximações interessantes. O método CPM (k-clique Percolation Method) [Derényi et al., 2005] pode ser utilizado para estudar o comportamento de redes, mas antes é necessário definir a dinâmica e a forma de observação. Imaginemos a função f(t) onde t é o intervalo de tempo que definimos para observar a rede em recortes. A ideia é traçar o grafo no tempo t = 0, caminhar uma unidade e desenhar o grafo novamente. A rede complexa possui comunidades que são agrupamentos de nós adjacentes até uma profundidade máxima p a ser definida. Uma rede modelada assim teria o formato descrito pela figura 2.3. Figura 2.3: Rede Exemplo 24

25 Figura 2.4: Dinâmica para redes complexas A dinâmica para tal rede teria então os seguintes fenômenos: Crescimento Num determinado tempo t = t + 1 tem-se o o grafo da figura 2.4 letra (a). Vê-se que, pela adição dos nós 11, 12, 13 e 14, o número de nós da rede cresceu possuindo um novo subconjunto de nós. O método CPM considera o subconjunto de nós adjacentes como uma comunidade 25

26 e o fenômeno de adição de um subconjunto de nós pode ser definido como crescimento. Contração No tempo t = t + 1 obtemos o grafo da figura 2.4 letra (b). Vimos que a remoção de alguns nós forçou o desaparecimento de um subconjunto de nós. Nesse caso dizemos que a rede está em contração. Junção No tempo t = t + 1 analisamos os grafos nas letras (c) e (d). Vimos a chegada de um conjunto completo de nós composto por 11, 12 e 13. Após a passagem do tempo, vimos que os conjuntos de nós se juntaram, formando uma nova rede. É o fenômeno que conhecemos como junção. Separação Ao considerar o exemplo inverso do anterior (do estado d para o estado c) temos o fenômeno conhecido como separação, onde dois grafos de dividem. Nascimento A letra (e) mostra como pode ser um nascimento. Não havia nada e apareceu o primeiro subconjunto de nós no tempo indicado. Morte Se todas as relações que existiam inicialmente forem eliminadas acontece o fenômeno conhecido como morte. É o inverso da relação (e). Em [Palla et al., 2007] observa-se como um método pode ser utilizado para analisar o comportamento de redes complexas. Colaboração entre pessoas podem se repetir de tempos em tempos, e maiores frequências de colaboração normalmente indicam relações mais próximas. A adição do componente peso ocorre então de forma natural: uma página Wiki construída por n pessoas corresponde a um 1 ato de colaboração de peso [Palla et al., 2007] entre cada par de autores na (n 1) comunidade. Da mesma maneira, uma mensagem de fórum é uma construção por si só, que incentiva outras construções subsequentes. Podemos definir então o peso w entre dois nós a e b no tempo t como w a,b (t) = i w i exp( λ t t i w i ) onde a soma ocorre em todos os eventos de colaboração em que a e b estiverem presentes, e w i representa o peso do evento i ocorrendo no tempo t i. A constante λ é uma constante de decaimento que depende do sistema social que está sendo estudado. É possível dizer então que a evolução da rede com o tempo se manifesta com a alteração do peso das conexões. Contudo, se adicionamos uma constante w, de threshold ou limite mínimo a partir dos quais os grafos serão traçados, temos um efeito na observação da rede no qual as conexões só aparecerão no intervalo de tempo próximo ao evento de colaboração e desaparecerão em outros períodos. Pode ser aplicado como correção e para tornar a função mais discreta, ou seja, normalizar o intervalo de tempo para intervalos em que há e intervalos em que não há. Para cada par de intervalos de tempo consecutivos (t e t + 1) é construído um grafo conjunto da união das conexões das duas redes. Qualquer comunidade de ambos t ou t + 1 está contida em exatamente uma comunidade no novo grafo, e a 26

27 adição de novas conexões ao grafo permite apenas que a comunidade cresça, sofra uma separação ou permaneça inalterada. Assim a comunidade no grafo conjunto fornece uma conexão natural entre as comunidades nos tempos t e t + 1. Se a comunidade contém então uma única comunidade de t e uma única de t + 1, comparamos as duas; se o grafo conjunto possui mais de uma comunidade de ambos em cada intervalo de tempo, realizamos a comparação com intervalo de tempo descendente a partir da sobreposição dos nós. Após definida a dinâmica de mudanças em uma comunidade, precisamos considerar duas quantidades características: o tamanho s e a idade τ. Em teoria, quanto mais antiga uma comunidade mais membros ela tem. Podemos então construir a função de autocorrelação C(t) para quantificar a sobreposição relativa entre dois estados da mesma comunidade A(t) em um número de intervalos de tempo t: C(t) A(t 0) A(t 0 + t) A(t 0 ) A(t 0 + t) onde A(t 0 ) A(t 0 + t) é o número de nós em comum entre A(t 0 ) e A(t 0 + t); A(t 0 ) A(t 0 + t) é o número de nós na união entre A(t 0 ) e A(t 0 + t). Em redes muito dinâmicas o coeficiente decai mais rápido, ou seja, as relações mudam com muita frequência. Se o coeficiente muda pouco com o tempo, temos que a rede é mais estática. Para quantificar o aspecto da rede relacionado à evolução da comunidade, definimos o coeficiente de estacionariedade ou de tendência a mudanças ζ como a correlação média entre estados subsequentes: ζ tmax 1 t=t 0 C(t, t + 1) t max t 0 1 onde t 0 representa o nascimento da comunidade e t max é o último passo antes da extinção da comunidade. Da mesma forma, 1 ζ representa a taxa média de mudança no número de membros que aconteceu em um passo. As diferentes regras de estabilidade presentes em comunidades grandes e pequenas e identificadas pelo função ζ e pela função de autocorrelação descritas anteriormente levantam a seguinte questão: é possível realizar previsões sobre o futuro da comunidade conhecendo seu comportamento? A resposta apresentada em [Palla et al., 2007] é a utilização de uma métrica baseada no peso entre as relações intra comunidade (w in ) e as relações inter comunidade (w out ). Se o peso das relações entre os nós de dentro da comunidade com os de fora foi maior do que as relações internas, há uma tendência de que as relações de maior peso prevaleçam e a comunidade desapareça no futuro. A probabilidade é calculada como uma função do peso agregado das relações inter comunidade w out com o peso total agregado (w in + w out ) de cada nó. Depois a mesma conta pode ser feita para todos os nós de uma comunidade e verificar a probabilidade das relações sumirem com o tempo. Os resultados sugerem que verificar o comprometimento dos indivíduos com os outros membros da comunidade pode fornecer subsídios para prever o futuro da comunidade. Para realizar observações acerca do tempo de vida da comunidade, é necessário delimitar o nascimento e a morte de uma relação. É fácil observar que, se uma 27

28 relação existe no tempo t e deixa de existir no tempo t + 1, para o período observado o fenômeno é de morte. Se não existem mais relações entre dois períodos de tempo distintos, a comunidade como um todo sofreu um fenômeno de morte, como descrito na seção A forma direta de analisar nascimento e morte de comunidades funciona bem quando o método CPM [Derényi et al., 2005] é utilizado, já que as comunidades são definidas em termos dos k-cliques. Todavia, a pesquisa é realizada em comunidades que estão muito bem definidas em espaços de colaboração, e mesmo que não haja relação nenhuma em um determinado período ela continua existindo conceitualmente. Como saber então que relações não voltarão a acontecer em um determinado período? Em comunidades de Internet é comum a operação de limpeza da base, ou remoção dos usuários considerados inativos. São realizadas normalmente de tempos em tempos e algum critério de exclusão é definido com base na contribuição de cada indivíduo. Como o conjunto de dados tem tempo definido pela data da extração, é possível utilizar um critério simples de que se a relação aparecer e não se repetir dentro do período disponível, pode-se dizer que ela morreu. 28

29 Capítulo 3 O Portal do Software Público Brasileiro O Portal do Software Público Brasileiro é fruto de uma parceria entre entidades da sociedade civil, órgãos da administração pública direta e indireta, empresas e pessoas. Sua construção foi parte das ações do Comitê Técnico de Gestão do Conhecimento e Informação e Estratégica [Brasil, 2010], vinculado à Secretaria de Logística e Tecnologia da Informação do Ministério do Planejamento. Este capítulo descreve os aspectos técnicos e teóricos envolvidos na construção e evolução do Portal. 3.1 Ideais e Justificativas O Software Livre já é uma realidade em governos de todo o mundo, não apenas pela redução iminente de custos, mas também pelo caráter estratégico fornecido pelo acesso ao código-fonte. Uma iniciativa de compartilhamento entre órgãos e instituições públicas já seria justificável por si só, mas o Portal do Software Público Brasileiro trouxe inúmeras outras questões que não haviam sido previstas. Ao analisar sua construção e seus impactos para a sociedade, precisamos levar em consideração não somente a análise das questões inerentes ao Portal, mas de todo o ambiente social, político e tecnológico no qual ele se inseriu. Sua construção acontece em duas etapas: a construção teórica, ou os conceitos que permitiram que o ecossistema caminhasse até o estado atual e a construção tecnológica e suas implicações. Na seção atual será abordado o primeiro aspecto. O conceito de ecossistema apresenta muitas características em comum com a biologia, onde todos as comunidades interagem entre si. Aqui os membros são apresentados em um ambiente neutro onde todos têm igual importância teórica, sendo o diferencial a atitude de cada um perante a comunidade. Imaginando o software como elemento central, todos os outros elementos associam-se a ele de alguma forma, e no momento da conexão passam a existir perante os outros. 29

30 3.1.1 A Escassez Artificial No livro [DoD, 2007], o Departamento de Defesa dos Estados Unidos demonstra suas preocupações com o modelo de aquisição de software adotado no país. O DoD tem dois interesses concorrentes: 1. Assegurar a defesa dos Estados Unidos (EUA) e; 2. Prover apoio e estimular o crescimento da base industrial norteamericana, que fornece materiais e sistemas para que o DoD possa cumprir sua missão. O modelo de contratação atendeu bem ao DoD até agora: eles financiam o desenvolvimento das indústrias, que mais tarde vão se transformar em produtos de exportação para outros países, gerando mais impostos e aumentando a participação dos EUA no PIB do mundo. Contudo, com a mudança do paradigma de riqueza, alguns problemas inesperados começaram a aparecer: Ao tratar o código de software desenvolvido pelo DoD como se fosse um bem físico, este tratamento está restringindo a capacidade do mercado de competir [nas licitações] para fornecer capacidades e soluções recentes e inovadoras. Aparentemente, de acordo com o ponto de vista do governo americano, o modelo de contratação está restringindo a inovação. Há ainda o problema da escassez artificial criada com a compra de licenças, que é descrito da seguinte forma: Atualmente, o DoD não possui uma política ou um mecanismo interno de distribuição de códigos de software desenvolvidos e pagos pelo DoD. Ao não permitir a distribuição interna desses códigos, o DoD cria uma escassez arbitrária de seu próprio código de software, o que aumenta os custos de desenvolvimento e manutenção da tecnologia da informação em todo o Departamento. Na visão do Departamento de Defesa americano, uma política de compartilhamento que permitisse o reuso dos softwares se faz necessária para evitar a falsa escassez gerada pela licença, além do redesenvolvimento de aplicações similares para diferentes órgãos de governo. Uma análise das instituições públicas brasileiras foi feita primeiramente pela PROCERGS, no ano de 2001 [PROCERGS, 2001], no sentido de evitar a recompra: A análise das limitações estruturais da gestão pública: uma demanda descontrolada e crescente, exigindo imediatamente melhores serviços públicos; grandes restrições orçamentárias e pouca capacidade de financiamento; dificuldades administrativas e mudanças tecnológicas aceleradas mostra que os problemas foram ampliados nas áreas de informática e telecomunicações, exigindo que os entes públicos que 30

31 atuam nestas áreas adotem uma estratégia suficientemente eficaz para cumprir sua missão e objetivos. Esta estratégia propõe a sinergia dos esforços realizados por todos esses entes públicos para obter escala, reduzir e ratear custos, aumentar rapidez e produtividade, evitar duplicação de investimentos, recuperar funcionalidades, racionalizar a gestão, eliminar a ociosidade e alcançar muitos outros benefícios. Também no governo brasileiro já aparecia a importância de se construir uma iniciativa de compartilhamento, ainda no escopo do melhor aproveitamento dos recursos. Tal iniciativa teria como meta transformar o software em um bem público, amparado pelos princípios da indivisibilidade e da não-rivalidade, que pudesse ser utilizado e desenvolvido por todos. Para definir o bem software no contexto apresentado foi utilizado pela primeira vez o termo Software Público A Sociedade da Informação no Brasil Desde o início do século vem sendo constatada a conformação de uma nova sociedade, conhecida como Sociedade da Informação, que explicitou a importância das interações como elementos de riqueza em sociedades modernas. O governo brasileiro, prevendo a importância que as novas tecnologias teriam na sociedade, elaborou um estudo que ficou conhecido como Livro Verde [Takashi and Co-autores, 2000], que tinha como objetivo:...cobrir, de forma articulada e abrangente, todos os aspectos considerados relevantes para a Sociedade da Informação no Brasil, de P&D a aplicações, do setor governamental ao setor privado, de tecnologias avançadas a impacto social; A Riqueza Revolucionária defendida por [Tofler and Tofler, 2007] nos mostra como o atual sistema de riquezas pode ser complexo, principalmente se considerarmos a mensuração do trabalho intelectual. Enxergando as possibilidades da nova conformação social, o Livro Verde é ainda mais abrangente, na página 9, ao dizer que: Em um mundo onde conhecimento, informação, criatividade e inovação são fatores de riqueza, a diversidade cultural é para ser reconhecida e explorada como fator de vantagem competitiva. A mensagem proposta pelo livro traz algumas mudanças conceituais importantes em comparação à análise baseada em economia de recursos que era feita normalmente em governos de todo o mundo. É possível resumir as principais alterações da seguinte forma: 1. Sendo o software um elemento gerador de conhecimento para o país, ainda que sua utilização não seja financeiramente vantajosa em uma análise superficial, a possibilidade de produzir inovação deve ser considerada importante; 31

32 2. Se imaginarmos o Mercado global de desenvolvimento de software, o caráter regional é muito importante e deve ser encarado como uma possível vantagem competitiva. Assim, a criação de tecnologias nacionais é benéfica para o futuro e pode ser considerada por si só. Contudo, de acordo com a análise feita pelo governo americano [DoD, 2007], o modelo de compra baseado em software proprietário não contribui com as características acima. Somente o modelo proposto pelo software livre possibilita um total aproveitamento dos benefícios indiretos associados ao software. Tudo isso significa que, além de criar um ambiente propício ao compartilhamento de software pelos entes da administração pública, seria necessário o surgimento de uma figura agregadora. É a pedra fundamental do Portal do Software Público Brasileiro O Portal do Software Público Brasileiro Um histórico do Portal do Software Público Brasileiro pode ser encontrado no artigo A Materialização do Conceito de Software Público [Peterle et al., 2006] e nos artigos Um Primeiro Modelo para o Software Público [Meffe, 2008b] e A Consolidação do Software Público em 2008 [Meffe, 2008a]. Ao completar três anos em 2010, já é possível dizer que o modelo de compartilhamento proposto pelo Portal está consolidado. Mais do que apenas um espaço para compartilhamento de soluções que possibilita a economia de recursos, o Portal do Software Público Brasileiro conseguiu formar em sua rede de parceiros o que foi definido no Livro Wikinomics [Tapscott, 2007] como base comum de produção. Ocorreu assim a transição para um modelo mais abrangente, melhor definido como ecossistema, conforme define [Alves et al., 2009]: Como se pode observar, o Ecossistema é nucleado pelo conceito de software como um bem público, que tem por base o modelo de software livre, mas estabelece uma nova dinâmica para o papel do Estado e seu relacionamento com entidades interessadas em disponibilizar soluções e conhecimentos de software. 32

33 Figura 3.1: Ecossistema do Portal do Software Público Brasileiro A figura 3.1 apresenta todas as instituições que fazem parte do ecossistema do Portal do Software Público Brasileiro, identificadas pela área de atuação em azul, que são as seguintes: Internacional O Projeto Software Público Internacional foi criado em parceria com o PNUD para formar uma rede latino-americana de colaboração de software e replicar o modelo brasileiro nos países interessados; Grupos Temáticos Os grupos temáticos são comunidades que representam grupos de usuários do Portal com interesses específicos como a Academia (4CAcadBr) e os municípios (4CTecBr); Qualidade Grupo que discute a qualidade de software em modelos colaborativos com o objetivo de construir um modelo para o Portal do Software Público; Qualificação Instituições que têm interesse em treinar usuários e desenvolvedores nas soluções do Portal do Software Público; Catálogo O catálogo de software é um inventário geral de software do governo federal; Marco Legal e/ou Institucional Construção de normas e regulações que permitem e incentivam a utilização de softwares públicos; Financiamento Instituições de fomento para o desenvolvimento das soluções do Portal e iniciativas relacionadas; 33

34 Certificação Fornecer certificados de proficiência para os usuários e desenvolvedores dos softwares é uma demanda do mercado de trabalho; Mercado Registro de empresas e empreendedores individuais que prestam serviços com base nos softwares do Portal; SPB SPB ou Portal do Software Público Brasileiro é o ambiente de compartilhamento que representa na figura principalmente a demanda por software. Formada a abrangente teia de relacionamentos, passa a ser um desafio para todos os envolvidos encontrar indicadores de qualidade que possam medir o sucesso do Projeto, e quem sabe garantir sua sustentabilidade. É possível afirmar, sem sombra de dúvidas, que o Portal é um sucesso? Numa análise mais profunda, o que pode ser definido como sucesso? Do ponto de vista dos idealizadores do modelo, que tinham como objetivo único disponibilizar uma solução para inventário de hardware e software e atender às demandas do SISP 1, imaginar que dois anos depois seriam mais de trinta soluções disponibilizadas parece um passo muito maior do que se imaginava. Contudo, uma das perguntas que precisam ser respondidas no momento é: quantidade de soluções disponibilizadas é um indicador de qualidade e sustentabilidade? Para responder essas e outras perguntas foram formados grupos de trabalho para trabalhar em duas frentes. O primeiro, liderado pelo Centro de Tecnologia da Informação Renato Archer de Campinas (CTI) ficou responsável por elaborar um modelo de qualidade do Portal do Software Público. Dentre as várias questões a serem esclarecidas pela equipe de pesquisadores, as principais são identificar indicadores que definam o sucesso do modelo e mapear alternativas de sustentabilidade. A outra equipe, liderada pela Professora Christiana Freitas da Universidade de Brasília, foi responsável por analisar os aspectos sócio-interacionistas identificados entre cada um dos possíveis nós da rede [Freitas and Meffe, 2010]. Afinal, com seus mais de oitenta mil usuários, o Portal constitui uma das mais complexas e interessantes redes sociais de que se tem notícias no Brasil. Sendo Coordenador Técnico do Portal do Software Público Brasileiro e responsável pelo desenvolvimento e manutenção, caberia a mim fornecer apoio a ambas as equipes. Participei da equipe de desenvolvimento desde o princípio e detenho o conhecimento sobre a administração dos recursos e a modelagem das bases de dados. Aproveitando a oportunidade do trabalho de conclusão de curso de Computação na Universidade de Brasília, iniciei a presente investigação para preencher e validar alguns pontos em ambos os estudos. É objetivo do trabalho analisar sua evolução em tempo real e utilizar teorias de simulação para redes sociais e observar seu comportamento no futuro. 1 O SISP é o Sistema de Administração de Recursos de Informação e Informática. Liderado pela Secretaria de Tecnologia de Informação do Ministério do Planejamento, Orçamento e Gestão, é composto pelos coordenadores de informática da administração direta e tem como objetivo definir políticas e metas para a área de Tecnologia da Informação no Governo Federal. Mais informações sobre o grupo, sua missão e objetivos podem ser encontrados no endereço 34

35 3.2 Construção e Base Tecnológica Ainda que não tenha sido inicialmente planejada, a base tecnológica se revelou uma das características mais marcantes do Portal. Primeiro por sempre ser mantido por uma equipe bastante reduzida; segundo por seu modelo de dados com foco na persistência das informações e mapeamento do relacionamento entre os vários objetos do sistema ter tornado possível uma análise bastante detalhada da rede. Na seção atual discutiremos a base tecnológica e sua implementação no Portal do Software Público Brasileiro Gestão do Conhecimento e Comunidades Virtuais Segundo o Dr. Paulo Fresneda, especialista em Gestão do Conhecimento, uma comunidade virtual pode ser definida como [Fresneda, 2010]: Compreende os grupos de indivíduos que se relacionam de forma colaborativa, presencialmente e no mundo digital virtual, por curto ou longo período de tempo, independentemente da localização, motivados por algum interesse ou propósito comum. A história da implantação da Gestão do Conhecimento no Brasil se confunde com a história da utilização da ferramenta OpenACS, que serve de base para o Portal do Software Público Brasileiro. Uma das primeiras iniciativas que se tem conhecimento é da CGECon (Centro de Gestão Estratégica do Conhecimento em Ciência e Tecnologia) do Ministério das Relações Exteriores que, com o apoio do MCT e do BID, realizou uma ampla pesquisa sobre ferramentas que possibilitassem a implantação de comunidades virtuais. O resultado da consultoria foi apresentado e implantado no ano de 2004, tendo sido introduzido como produto da seleção das melhores tecnologias disponíveis à época, conforme conta um dos responsáveis pela iniciativa, Daniel Lledó [Lledó, 2006]: Nesse contexto, ressalta-se o trabalho pioneiro da antiga equipe do CGECon que desenvolveu, a partir de um software do Massachusetts Institute of Technology (MIT), um avançado pacote de soluções tecnológicas totalmente baseado em software livre. De fato a solução em questão era totalmente baseada em Software Livre e tinha grande parte de seu desenvolvimento realizado no MIT. O OpenACS foi desenvolvido como prova de conceito para publicação de conteúdo colaborativo na Internet pela empresa ARS Digita, cujo proprietário era professor do MIT. A maior parte dos conceitos utilizados estão presentes num livro chamado PANDA [Greenspun, 1999], uma referência também histórica sobre criação de páginas na Internet. A principal preocupação dos desenvolvedores sempre foi trabalhar com o estado-da-arte em tecnologia para todas as camadas. Desde a modelagem inicial dos dados (que permanece como uma de suas maiores riquezas) até a escolha das dependências, tudo foi pensado selecionando as melhores tecnologias disponíveis 35

36 no mercado à época. Mais tarde a evolução do sistema e da própria Internet foi documentada em um outro livro chamado SEIA [Greenspun et al., 2006] que ainda é utilizado na disciplina Engenharia de Software para Sistemas de Internet no MIT OpenACS e os subsistemas O OpenACS é um framework composto de vários componentes ou subsistemas. Nesta seção trataremos da base tecnológica e do funcionamento de cada um deles. A figura 3.2 descreve a estrutura interna da ferramenta simulando o acesso à uma aplicação de Internet construída com o OpenACS. A parte inferior da figura representa o acesso simultâneo de vários clientes, que utilizam-se de um browser ou navegador, contido em um sistema operacional instalado em alguma peça de hardware. A conexão é feita através da rede e chega até o servidor que trata as requisições. De acordo com Kurose [Kurose and Ross, 2006], página 128, um modelo simples de servidor Web deve ser capaz de: Manipular uma requisição HTTP 2 ; Aceitar e analisar a requisição HTTP; Obter o arquivo solicitado no sistema de arquivos do servidor físico; Criar uma mensagem de resposta HTTP consistindo no arquivo requisitado precedido de linhas de cabeçalho; Enviar a resposta diretamente ao cliente. 2 HTTP ou Hyper Text Transfer Protocol é o protocolo de comunicações utilizado em sistemas de Internet para visualização de conteúdo. Mais informações sobre a Internet e o protocolo podem ser encontradas em [Kurose and Ross, 2006] nos capítulos 1 e 2. 36

37 Figura 3.2: Diagrama dos subsistemas do OpenACS [OpenACS, 2010b] Um servidor Web deve ser capaz de, basicamente, receber, tratar e devolver uma resposta à requisição de conteúdo feita pelo usuário. A maneira de tratar tal requisição é o que diferencia as aplicações de Internet, e realizar um tratamento eficiente é uma questão que sempre foi bastante discutida entre os especialistas. Um dos estudos mais conhecidos e que serviu como base para o desenvolvimento de softwares modernos como Nginx 3 e Varnish 4 é o artigo O Paradigma C10k [Kegel, 2006]. A ideia descrita passa pela constatação de que a Internet cresceu bastante, e os sistemas devem estar prontos para atender usuários simultâneos. As discussões atravessam a maneira com a qual o servidor deve tratar as requisições do usuário, e classifica-a em cinco diferentes tipos: 3 O Nginx é um servidor HTTP e proxy conhecido por sua performance, estabilidade e grande número de possibilidades. Foi desenvolvido com o objetivo de resolver o paradigma C10k [Kegel, 2006]. Mais informações no Wiki oficial: 4 Varnish é um servidor proxy com foco em cache construído para acelerar a visualização de conteúdos. O objetivo é armazenar a maior quantidade de páginas possível na memória de modo que o servidor original não precise carregá-la novamente. Mais informações no site do projeto: 37

38 1. Utilizar uma thread para muitos clientes, I/O não bloqueante e notificação de liberação; 2. Utilizar uma thread para muitos clientes, I/O não bloqueante e liberar quando o recurso estiver disponível; 3. Utilizar uma thread para muitos clientes, I/O assíncrono e notificação de completude; 4. Utilizar uma thread para cada cliente; 5. Compilar o código do servidor junto com o kernel ou núcleo do sistema operacional. As estratégias baseiam-se na maneira com a qual o servidor utiliza os recursos do sistema operacional para melhor servir as conexões provenientes dos clientes. A utilização ou não de threads é uma questão importante, pois em sua definição tradicional uma thread é um processo que possui algum recurso que pode ser compartilhado por outras threads. A utilização de I/O diz respeito à estratégia de utilização dos recursos de entrada e saída, e as notificações estão relacionadas à forma com a qual o servidor avisa o sistema operacional que aquele recurso já está disponível para uma nova conexão. Uma leitura mais aprofundada do artigo de Kegel pode trazer definições mais completas. Os primeiros servidores que foram escritos para servir páginas de Internet não tinham uma preocupação tão grande com o desempenho [Hirata, 2002], e demoraram a abordar as questões observadas por Kegel. Já o AOLServer, apesar de desenvolvido antes que o artigo fosse escrito, já diferia dos demais produtos disponíveis à época por utilizar uma arquitetura multithread. Além de servir conteúdo no protocolo HTTP, páginas dinâmicas necessitam apresentá-lo de acordo com escolhas feitas pelo usuário, o que só pode ser possível através de uma linguagem de programação. Temos o overhead adicional de necessitar evocar algum tipo de interpretador e/ou compilador para a linguagem se desejamos servir conteúdo dinâmico. A conexão realizada ao servidor está representada no lado esquerdo da figura 3.2, e explicita uma das características mais marcantes do framework 5. O AOLServer é fortemente integrado à linguagem de programação Tcl, representada pelo item 2 na figura. É possível realizar programação diretamente no servidor, que tem um interpretador nativo. As razões da integração são explicadas por um dos líderes do Projeto, em mensagem à lista de desenvolvedores [Shiobara, 2006]: Tcl é uma das únicas linguagens maduras que podem ser seguramente embarcadas em uma aplicação multi-threaded. O que eu quero dizer especificamente é que Tcl é uma das únicas linguagens que podem ter múltiplos interpretadores no mesmo processo sendo executados concorrentemente em múltiplas threads. 5 Framework ou arcabouço é um conjunto de ferramentas de desenvolvimento. O conceito é muito amplo e aborda vários softwares e pedaços de software muito diferentes, e não serão abordados. Para facilitar o entendimento diremos apenas que o OpenACS pode ser entendido com um framework de Desenvolvimento Web. 38

39 Tcl é uma das poucas linguagens que permitem a execução de múltiplos interpretadores dentro do espaço de um único processo. Assim, mesmo que cada uma das threads possua lógica diferente elas podem aproveitar-se do espaço de memória comum para utilizar variáveis globais que podem ser interpretadas de maneira diferente para cada um dos cliente conectados. Outras linguagens de programação utilizam-se de um travamento (lock) de chamadas a API s nativas, e mesmo que estejam sendo chamadas de diferentes threads, cada chamada do núcleo será bloqueante e não haverá nenhum ganho de performance pela utilização da área compartilhada. Claro que a abordagem prática possui outras complexidades e implementações práticas que maximizam a eficiência dos locks utilizados por outras linguagens, mas nunca se aproximam de uma implementação totalmente multithread. A mensagem na lista da comunidade AOLServer [Shiobara, 2006] contém mais informações sobre o tema Modelo MVC Na seção o foco estava no funcionamento dos subsistemas e como eles eram integrados. Na seção atual trataremos da parte específica do framework, desde a maneira com a qual o sistema trata uma requisição de página até os padrões de desenvolvimento utilizados. A figura 3.3 detalha o caminho que uma requisição persegue até que seja retornado o conteúdo desejado. O OpenACS trabalha com o modelo MVC que separa o software em camadas para suportar múltiplas apresentações de dados. Cada usuário interage com as apresentações de uma maneira que seja mais adequada para si mesmo. O M vem de Model ou Modelo, e está relacionado aos dados que serão acessados. O V é View ou Visualização e trata da interface com o usuário. Finalmente o C é de Controller e está relacionado com a parte do programa que faz a interface entre o usuário e os dados construindo a lógica necessária para gerar a visualização. O importante do modelo adotado é que cada parte funciona de maneira semiindependente e possui um arquivo com um formato de extensão que o identifica. É interessante notar que a única parte obrigatória é o Controle, identificado na figura pelo arquivo dynamic-page.tcl. É possível devolver uma resposta ao usuário sem necessariamente chamar o banco de dados, da mesma forma que a página pode não apresentar uma interface. Se o arquivo possui chamadas ao banco de dados é identificado com a extensão.xql 6 e se possui interface com o usuário será identificado com a extensão.adp. 6 É possível conectar-se ao banco diretamente de um arquivo.tcl, mas não faz parte das boas práticas e não se beneficia do cache de consultas feito em todos os arquivos.xql 39

40 Figura 3.3: Modelo MVC O banco de dados é acessado por API s internas do sistema, que se utilizam do driver nativo do servidor (ns postgres ou ns oracle) para conectar-se ao SGBD 7. Para aumentar a performance o processo de inicialização do servidor cria um cache com a formatação de todas as consultas presentes nos arquivos com a extensão.xql. As consultas que são realizadas muitas vezes já sobem com resultados carregados e evita o trabalho de acesso ao banco, que costuma ser bastante custoso Banco de Dados Quando o sistema foi desenvolvido o SGBD base para a modelagem era o Oracle. Contudo, por iniciativa de alguns membros da comunidade entre eles um brasileiro que queriam utilizar o sistema sem ter que comprar a licença, iniciou-se no Sourceforge 8 um projeto chamado ACS to Pg com o objetivo de migrar a base de dados para o PostgreSQL. A atitude contribuiu muito também com o desenvolvimento do próprio PostgreSQL, pois muitas das ferramentas utilizadas na base Oracle do OpenACS não estavam disponíveis ainda no PostgreSQL e foram desenvolvidas para preencher as lacunas. A migração foi concluída com o 7 Sistema Gerenciador de Banco de Dados 8 Sourceforge é um repositório de aplicações conhecido mundialmente onde os desenvolvedores podem constituir uma estrutura mínima para o desenvolvimento colaborativo de software sem muitos custos. Mais informações podem ser encontradas no endereço 40

41 lançamento da versão do OpenACS em 28 de outubro de 2002, e desde então o desenvolvimento no banco de dados livre tem sido significativamente maior. Como o sistema é construído com foco em Gestão do Conhecimento, a sua modelagem de dados tem algumas caraterísticas marcantes: 1. Persistência dos dados; 2. Modelagem orientada a objeto; 3. Extensibilidade de objetos com uso de meta-dados. O primeiro ponto a ser observado é que possuir uma modelagem orientada a objeto não significa que o sistema seja orientado a objeto. A ausência de tecnologias maduras e, principalmente, a forte integração do servidor com a linguagem Tcl que é estruturada, impediram que uma completa implementação orientada a objeto fosse construída. A maneira encontrada de contornar o problema foi construir a orientação a objetos dentro do próprio banco de dados, utilizando PL/SQL 9 para construir os métodos e um conjunto de boas práticas para utilizálos. A modelagem permite que todos os artefatos inseridos sejam tratados como objetos e concentrados em uma única tabela, denominada acs objects. Os objetos são agrupados em tipos, que são armazenados em outra tabela chamada acs object types. A figura 3.4 mostra a modelagem básica do sistema de objetos. A partir dos tipos de objetos podem ser definidos os atributos, que serão parte fundamental da construção dos meta-dados. Como podemos ver, uma das colunas da tabela acs objects se chama table name. Aqui é possível fornecer o nome de uma nova tabela que estende os dados do objeto principal, seja qual for ele, resguardando a integridade da chave primária. A coluna id column faz uma referência ao nome da coluna na nova tabela que representará uma chave estrangeira para o objeto principal. Da forma que a modelagem foi construída é possível percorrer o banco de dados e procurar pelas referências à coluna object id da tabela acs objects. A coluna name method indica o nome de uma função ou método que pode ser chamada para recuperar o nome do objeto. A abordagem é análoga aos modelos orientados a objeto, com a diferença que está implementada diretamente no banco e independe de linguagem de programação. Tal abordagem permite que, em teoria, qualquer tipo de linguagem se aproveite de algumas características da orientação a objeto mesmo que não faça parte do seu escopo. 9 PL/SQL é a linguagem de programação do banco de dados Oracle que permite realizar programação dentro do próprio servidor. Sua similar no PostgreSQL é a linguagem PL/pgSQL. 41

42 Figura 3.4: Modelagem dos Objetos no OpenACS Os usuários são tratados como um objeto único, e são atrelados aos objetos de colaboração através da coluna creation user da tabela acs objects. Para todos os objetos criados no sistema existe uma referência a seu criador, o que torna a identificação da autoria bastante fácil. Todavia, em uma comunidade virtual, duas características marcantes precisam ser observadas: 1. Os usuários mudam de papel de acordo com o contexto; 2. As colaborações acontecem em um contexto especial dentro de uma comunidade. O mesmo usuário pode representar um especialista desenvolvedor em uma comunidade e ser apenas um usuário em outra. A confusão ordenada de papéis é uma característica marcante em comunidades de software. A comunidade é uma entidade abstrata que pode ser materializada no banco de dados através de um grupo de indivíduos em determinado contexto. A figura 3.5 contém o diagrama que representa a modelagem dos grupos e papéis. 42

43 Figura 3.5: Modelo de grupos e permissões Para adicionar um usuário a um grupo é necessário primeiro criar um grupo, ou seja, uma entrada na tabela groups. A esse grupo está associado um party id, que é o identificador único do grupo. A definição vem do Unix 10, onde um usuário é um grupo ou apenas um usuário. Ambos possuem a mesma tabela de origem: parties. Se temos um usuário haverá duas representações a mais: uma entrada na tabela persons e uma outra na tabela users. O conceito permite a perpetuação dos dados mesmo após a exclusão de um usuário, pois mesmo que a entrada na tabela users seja removida, o identificador person id da tabela persons se mantém fazendo referência à tabela parties, de forma que seja possível sempre identificar quem é o verdadeiro autor do objeto. Quando falamos de grupos estamos tratando de um novo tipo de objeto que contém uma entrada na tabela groups. A adição de um usuário a um grupo é realizada através do sistema de relações descrito na figura 3.5. É possível criar uma relação entre quaisquer dois objetos do sistema utilizando-se da tabela acs rels. Primeiro criamos um tipo de relação (rel type) na tabela acs rel types entre dois tipos de objeto (object type) onde são definidos dois papéis para os objetos em questão. A tabela acs roles armazena todos os possíveis papéis. Uma vez definido o tipo de relação podemos inserir uma entrada na tabela acs rels que vai conter o identificador dos dois objetos e o tipo de relação entre eles. Um tipo de relação específico é identificado pela tabela membership rels: muitas vezes a relação precisa ser aprovada ou realizar alguma ação no sistema antes de ser efetiva, então armazenamos o estado da relação na tabela. A extensão do modelo inicial pode ser feita através de pacote, que é uma aplicação integrada à modelagem principal do OpenACS. Em teoria, qualquer modelo pode ser integrado ao núcleo do sistema, bastando que para o seu objeto principal seja adicionado uma referência à tabela acs objects. Todas as chaves definidoras devem ser únicas em todo o sistema, controladas pela sequência que identifica o objeto principal object id. 10 O Unix foi o primeiro sistema operacional a trabalhar com o conceito de múltiplos usuários, e o modelo lógico do OpenACS obedece aos mesmos princípios 43

44 3.2.5 Aplicações Verticais e dotlrn Podemos chamar de aplicações verticais os módulos acoplados ao núcleo do sistema, pois permitem a expansão de funcionalidades sobre a mesma base. Uma instalação típica possui a estrutura de diretórios da figura 3.6. As aplicações ou pacotes estão armazenadas no diretório packages, que por sua vez possui a estrutura de diretórios da figura 3.7. Figura 3.6: Esquema de diretórios de uma instalação típica [OpenACS, 2010a] Em um pacote o arquivo mais importante é aquele que possui a extensão.info, que passa para o sistema as informações da aplicação que está presente no diretório. É um tipo de arquivo XML com uma sintaxe especial que será lida pelo sistema. A pasta www contém tudo o que for interface com o usuário relacionado à aplicação, com exceção das páginas presentes no diretório lib, que contém páginas a serem inseridas dentro de outras páginas (server side includes). O diretório sql possui os scripts SQL que criam o modelo de dados do pacote e o diretório tcl possui as API s específicas para o seu namespace. Em suma, todas as definições são realizadas por organização hierárquica de arquivos, que mais tarde serão interpretadas pelo sistema. Dentre as várias aplicações ou pacotes disponíveis podemos destacar o dotlrn. Construída como uma aplicação com foco em ensino e aprendizagem para universidades, tem sido amplamente utilizada como ferramenta para EAD (Ensino à Distância) e comunidades virtuais para gestão do conhecimento. Com a ferramenta dotlrn foi construído o Portal do Software Público Brasileiro. Suas principais características são a possibilidade de criação de comunidades com interface de administração intuitiva e o sistema de portais dinâmicos baseados em portlets. Uma aplicação desenvolvida para funcionar no OpenACS pode ter seu conteúdo encapsulado num portlet, uma interface específica para a aplicação em espaço reduzido. Com a utilização do dotlrn, é possível customizar e encapsular o conteúdo em applets, permitindo sua inserção e retirada em portais. Em resumo, a utilização do dotlrn permite a criação de páginas customizadas hierarquicamente com o objetivo de facilitar e descentralizar a administração. Não é o objetivo do trabalho abordar detalhes específicos da utilização da ferramenta, mas detalhes adicionais podem ser encontrados em [Comunidade, 2010]. 44

45 Figura 3.7: Esquema de diretórios de um pacote [OpenACS, 2010a] O Portal do Software Público Brasileiro e suas comunidades A implementação do Portal do Software Público Brasileiro é baseada na ferramenta dotlrn para as comunidades e na ferramenta XoWiki para gerência de conteúdo da página inicial. Na figura 3.8 é possível visualizar a página inicial, 45

46 onde à direita está a lista de comunidades. Figura 3.8: O Portal do Software Público Brasileiro Após clicar em uma das comunidades da lista o usuário pode ler alguns detalhes sobre sua descrição e clicar sobre o link de entrada, que o levará ao cadastro para baixar o software. O procedimento de entrada em uma comunidade está representado na figura 3.9. Figura 3.9: Entrando em uma comunidade 46

47 Capítulo 4 Obtenção dos Dados Após a apresentação da base teórica para a construção da rede, o capítulo descreve como as técnicas serão aplicadas ao sistema para extração dos dados desejados. A primeira parte faz uma análise do modelo de dados e define as consultas que devem ser implementadas, enquanto a segunda aplica os dados extraídos às teorias estudadas. É a parte de levantamento de dados da pesquisa. 4.1 Visão Geral do Portal Antes de apresentar a métrica da pesquisa e seus resultados, é interessante apresentar alguns dados de ordem geral sobre o Portal do Software Público Brasileiro e suas comunidades. Todos os dados foram extraídos no dia 02 de fevereiro de comunidades de software; 4 grupos de interesse ativos: 4CMBr (Municípios), 4CTecBr (Tecnologia), 5CQualiBr (Qualidade de Software) e 4CMulti (Multimídias); usuários válidos; mensagens de fórum; páginas Wiki; 682 Prestadores de Serviço cadastrados no Mercado Público Virtual. 4.2 Métricas da Pesquisa Uma definição de métricas indica basicamente quais os dados que serão analisados e qual a metodologia de extração. Já está definido que o objeto de estudo é a análise das colaborações ocorridas em rede de maneira virtual, na ótica do conceito apresentado por [Cortelazzo, 2000]. Consideramos então todos os objetos de conhecimento que possam ser depois alterados e/ou reconstruídos por outros indivíduos ou grupos. 47

48 Objeto por si só é uma definição que traz uma carga teórica e uma diversidade muito grande de definições, mas o tratamento que receberá obedece a lógica dos dados. Objeto é, para fins da pesquisa, a inserção de qualquer coisa no banco de dados, podendo significar conteúdos interativos ou não. Quando se realiza a análise de um sistema de Internet, alguns dados são considerados importantes até porque são fáceis de serem medidos, mas não necessariamente são produto de um processo de construção coletiva de conhecimento. Não há como dizer que a leitura de um determinado artigo em um portal na Internet não ajuda na disseminação do conhecimento, e não se trata de defender tal linha de pensamento, e sim de saber como e quando aquele artigo foi gerado. A pesquisa tem como foco mapear a quantidade de objetos de conhecimento gerados através da construção coletiva e analisar o seu ciclo de vida. Mais importante ainda é analisar o contexto de sua geração, pois conhecer o ciclo de vida da comunidade pode nos fornecer informações a respeito de seu futuro. O método de previsão fornece os subsídios necessários à análise do conhecimento, uma vez que define claramente os conceitos de comunidade e permite uma análise temporal. Uma vez aplicado, a análise do grafo pode ajudar a validar os conceitos obtidos através dos cálculos matemáticos. 4.3 Aplicando o método de previsão Conforme explicitado na seção existe um método que permite a análise do comportamento de redes complexas através da observação do grafo da comunidade com o tempo. Em sua metodologia de aplicação é necessário coletar os dados para a construção das comunidades e seus subgrafos adjacentes. A modelagem do sistema nos permite fazer uma consulta que vai trazer o número exato de nós que determinada comunidade possui. Dois interesses são destacados quando na fase da coleta: aplicar o método de previsão e visualizar os grafos. Devido à grande quantidade de relações pode ser difícil construir uma imagem da comunidade que seja suficientemente inteligível em um grafo, e precisaremos do auxílio de uma ferramenta poderosa. Na pesquisa realizada por [Andery, 2010] e comprovada com a utilização no trabalho, a mais adequada ao tipo de análise é a ferramenta PEXGraph, desenvolvida pelo Instituto de Ciências Matemáticas e de Computação da Universidade de São Paulo/São Carlos (USP/São Carlos). As consultas realizadas devem contemplar as saídas de dados necessárias tanto para a análise matemática quanto para a construção e visualização dos grafos Extraindo os Dados A extração dos dados se inicia buscando subsídios para a aplicação do método de previsão. Como o objetivo é realizar uma análise temporal, o primeiro passo é definir o intervalo de tempo que será observado. Para todos os efeitos o intervalo utilizado será de 1 mês, ou seja, será observado o crescimento ou decaimento mês a mês das relações. 48

49 O método indica que devemos começar o cálculo pela definição do peso w, que tem por objetivo corrigir a colaboração com base no número de pessoas que contribuíram para o objeto. É óbvio que um objeto de conhecimento construído por quatro pessoas precisa ter um peso menor na relação entre dois membros do que a colaboração direta entre eles. A proposição é aplicar um fator de correção onde w i = 1 para cada intervalo de tempo. Em seguida, é possível construir n 1 o coeficiente de correlação para observar a comunidade nos tempos t e t + 1 e verificar a relação entre quantidade de nós em comum e a quantidade de nós somando os dois conjuntos. Considerando colaboração a construção de conhecimento coletivo, os objetos interessantes no banco de dados serão aqueles relacionados a conhecimento. Primeiro obtém-se a lista de todos os tipos de objeto registrados na tabela acs object types (trecho de código 4.1), cuja saída está representada na tabela 4.1: Trecho de código 4.1: Seleção dos tipos de objeto s e l e c t o b j e c t t y p e from a c s o b j e c t t y p e s ; Dentre os tipos de objeto apresentados na tabela 4.1, quais melhor identificam a construção de conhecimento coletiva? Uma primeira análise pode ser feita buscando os objetos mais presentes no banco de dados. A consulta está explicitada no trecho de código 4.2. Tabela 4.1: Lista de Objetos object type acs object relationship authority party person user group composition rel membership rel admin rel rel segment rel constraint (...) dotlrn community dotlrn class instance dotlrn club (214 registros) Trecho de código 4.2: Seleção dos objetos mais criados s e l e c t count ( o b j e c t i d ) as n o b j e c t s, o b j e c t t y p e from a c s o b j e c t s where c r e a t i o n u s e r i s not null 5 group by o b j e c t t y p e order by n o b j e c t s desc ; 49

50 Os resultados da consulta estão apresentados na tabela 4.2. Os primeiro objetos do sistema estão relacionados a objetos e relações gerados pelo próprio sistema, categoria em que se encaixam dotlrn member rels e as outras relações. O objeto content item representa a criação de um objeto no content-repository ou repositório de conteúdos, assim como content folder, que representam as pastas. Normalmente estão relacionados a conteúdos binários enviados pelos usuários, tais como artigos e imagens. Não representam a colaboração em si, apesar de certamente fazerem parte do processo. Tabela 4.2: Lista de objetos mais criados n objects object type content item dotlrn member rel notification request content folder as item data as session results calendar dotlrn student profile rel forums message as section data events registration ::xowiki::page 8886 file storage object (...) (114 registros) Vale a pena então observar as mensagens de fórum (forums messages) e as páginas Wiki (::Xowiki::Page), sendo que o primeiro representa quase o dobro do segundo colocado. As próprias mensagens de fórum representam uma parcela significativa do total de objetos. É possível concluir observando os dados que uma análise das mensagens de fórum e das páginas Wiki terá grande representatividade entre todos os objetos de colaboração do sistema. Para fazer uma busca na base de dados que traga informações sobre os objetos necessários, é necessário conhecer quais são as relações que os envolvem. A figura 4.1 contém as tabelas e as relações envolvidas em uma mensagem de fórum. A relação de criação do objeto é obtida através da coluna creation user da tabela forums messages, identificada pela chave estrangeira que aponta para a tabela de usuários (users). Todas as mensagens estão inseridas dentro de um determinado fórum, como aponta a coluna forum id, e podem ter uma mensagem pai, identificada pela coluna parent id. O caso da coluna para a mensagem pai é um apontamento de uma coluna da tabela para a outra, o que significa que seu identificador também representa uma mensagem. É daí que vem o princípio da colaboração na modelagem dos dados: uma colaboração acontece quando existe uma mensagem filho coluna parent id não nula cujo criador é diferente da mensagem pai. Em termos semânticos significa que um usuário respondeu a uma mensagem inserida por outro construindo um objeto de conhecimento a quatro 50

51 mãos. O produto da construção é a própria sequência de mensagens, que pode conter um tipo difuso de conhecimento, mas é certamente relevante. Figura 4.1: Modelagem de dados para as mensagens de fórums A colaboração conforme apresentada pela modelagem é um elemento genérico 51

52 que não possui agrupamento social explícito. O método de previsão permite identificar as comunidades através das conexões existentes entre os vários nós, mas a base de dados fornece subsídios necessários para a definição explícita de tais grupos. Observando a figura 4.1 é possível ver que as três tabelas superiores (forums forums, dotlrn communities all e apm packages), apesar de não terem nenhuma relação de chave estrangeira identificada, possuem uma coluna em comum: package id. A coluna de fato representa o mesmo dado, mesmo não possuindo chaves estrangeiras, e a integridade é garantida através dos procedimentos de inserção dos dados. Ainda é possível fazer um teste executando a consulta apresentada no trecho de código 4.3. A consulta não deve retornar resultados, garantindo assim que não há dados na coluna package id da tabela forums forums que não estão presentes na tabela apm packages. Trecho de código 4.3: Teste de chave estrangeira na coluna package id s e l e c t f. package id, p. p a c k a g e i d from f o r u m s f o r u m s f l e f t join apm packages p on f. package id = p. package id 5 where f. package id i s null or p. p a c k a g e i d i s null ; É possível agora observar com mais cuidado a tabela dotlrn community applets, que serve para identificar todas as aplicações ou módulos do OpenACS e as comunidades em que estão instalados. Observando a chave estrangeira de nome dotlrn ca community id fk é possível visualizar a relação que as aplicações tem com as comunidades Construção das consultas e cálculo do peso Finalmente é possível construir o modelo de consulta do trecho de código 4.4. Como o mesmo conjunto de dados será requisitado várias vezes, é conveniente criar uma tabela com a consulta, que se chamará contrib forums. A saída revela três colunas: pretty name Nome da comunidade onde a colaboração aconteceu; message from Identificador da mensagem inicial; from Usuário que iniciou a construção do objeto de conhecimento. No caso, a mensagem de fórum; message to Identificador da mensagem de resposta; to Usuário que respondeu à mensagem inicial e colaborou para a construção do objeto de conhecimento; weight Peso calculado para o nó no formato 1/(n 1); periodo Período que foi levado em consideração na análise (variável t). 52

53 Trecho de código 4.4: Consulta por colaborações nos fóruns drop table i f e x i s t s c o n t r i b f o r u m s ; create table c o n t r i b f o r u m s as s e l e c t d i s t i n c t c. pretty name, 5 m. message id as message from, m. u s e r i d as from, m2. message id as message to, m2. u s e r i d as to, ( / ( s e l e c t count ( u s e r i d ) 10 from f o r u m s m e s s a g e s where t r e e s o r t k e y between t r e e l e f t (m. t r e e s o r t k e y ) and t r e e r i g h t (m. t r e e s o r t k e y ) and f o r u m i d = m. f o r u m i d ) : : r e a l ) as weight, / t o c h a r (m. p o s t i n g d a t e, M M / Y Y Y Y ) as p e r i o d o from f o r u m s m e s s a g e s m, f o r u m s m e s s a g e s m2, forums forums f, dotlrn community applets d, 20 d o t l r n c o m m u n i t i e s a l l c where m. forum id = f. forum id and m2. forum id = f. forum id and f. package id = d. package id and d. community id = c. community id 25 and m2. t r e e s o r t k e y between t r e e l e f t (m. t r e e s o r t k e y ) and t r e e r i g h t (m. t r e e s o r t k e y ) and f. e n a b l e d p = t group by c. pretty name, 30 m. message id, m. u s e r i d, m. t r e e s o r t k e y, m. forum id, m2. message id, 35 m2. u s e r i d, t o c h a r (m. p o s t i n g d a t e, M M / Y Y Y Y ) order by periodo, c. pretty name, m. u s e r i d ; 40 create index c o n t r i b f o r u m s p r e t t y n a m e i d x on c o n t r i b f o r u m s ( pretty name ) ; create index c o n t r i b f o r u m s f r o m i d x on c o n t r i b f o r u m s ( " f r o m " ) ; create index c o n t r i b f o r u m s t o i d x on c o n t r i b f o r u m s ( " t o " ) ; A consulta traz os elementos necessários para iniciar o cálculo do coeficiente de auto-correlação (C(t)) para as mensagens de fórum. A mesma análise precisa ser feita em relação às páginas Wiki para completar a extração dos dados. A modelagem de páginas Wiki é um pouco diferente pois utiliza o sistema de revisões da aplicação content-repository, conforme descrito na figura 4.2. Cada item armazenado no content-repository é um item na tabela cr items, cujo tipo é representado pela coluna content type. Também é um objeto no sistema, então possui uma chave estrangeira para a coluna object id da tabela acs objects. Os mais variados itens podem sofrer diversas revisões, que em última análise nada mais são que novos objetos que contêm uma referência ao conteúdo que está relacionado. A relação está representada pela chave estrangeira na tabela cr revisions, que aponta para o item id principal na tabela cr items. Cada revisão é por si só um objeto, que possui identificação do usuário que a criou. Da mesma forma que foi feito com as mensagens de fórum também é possível utilizar a coluna package id para fazer referência à tabela dotlrn community applets. O resultado da consulta com as relações no intervalo de tempo desejado está no trecho de código 4.5. Também é conveniente criar uma tabela temporária para as colaborações em páginas Wiki, que será chamada de contrib xowiki. 53

54 Figura 4.2: Modelagem de dados para as páginas Wiki Trecho de código 4.5: Consulta por colaborações em páginas Wiki drop table i f e x i s t s c o n t r i b x o w i k i ; create table c o n t r i b x o w i k i as s e l e c t d i s t i n c t c. pretty name, 5 o1. o b j e c t i d as item from, o1. c r e a t i o n u s e r as from, o2. o b j e c t i d as r e v i s i o n i d, o2. c r e a t i o n u s e r as to, ( / ( ( s e l e c t count ( d i s t i n c t ao. c r e a t i o n u s e r ) 10 from c r r e v i s i o n s c r inner j o i n a c s o b j e c t s ao on c r. r e v i s i o n i d = ao. o b j e c t i d where i t e m i d = c1. i t e m i d ) : : r e a l 1.00) ) as weight, 0 1 / t o c h a r ( o2. c r e a t i o n d a t e, M M / Y Y Y Y ) as p e r i o d o from c r i t e m s c1 15 inner j o i n a c s o b j e c t s o1 on c1. i t e m i d = o1. o b j e c t i d inner j o i n c r r e v i s i o n s c2 on c1. i t e m i d = c2. i t e m i d inner j o i n a c s o b j e c t s o2 20 on c2. r e v i s i o n i d = o2. o b j e c t i d inner j o i n d o t l r n c o m m u n i t y a p p l e t s d on o1. package id = d. package id inner j o i n d o t l r n c o m m u n i t i e s a l l c on d. community id = c. community id 25 where c1. c o n t e n t t y p e l i k e % x o w i k i : : % and o1. c r e a t i o n u s e r <> o2. c r e a t i o n u s e r group by c. pretty name, o1. o b j e c t i d, o1. c r e a t i o n u s e r, 30 o2. c r e a t i o n u s e r, o2. o b j e c t i d, c1. i t e m i d, 0 1 / t o c h a r ( o2. c r e a t i o n d a t e, M M / Y Y Y Y ) ; 35 create index c o n t r i b x o w i k i p r e t t y n a m e i d x on c o n t r i b x o w i k i ( pretty name ) ; create index c o n t r i b x o w i k i f r o m i d x on c o n t r i b x o w i k i ( " f r o m " ) ; create index c o n t r i b x o w i k i t o i d x on c o n t r i b x o w i k i ( " t o " ) ; 54

55 A consulta terá como saída os seguintes campos: pretty name Nome da comunidade onde a colaboração aconteceu; item from Objeto inicial ou página Wiki; from Usuário que iniciou a construção do objeto de conhecimento. No caso, a página Wiki; revision id Revisão que representa a colaboração; to Usuário que revisou a página inicial e colaborou para a construção do objeto de conhecimento; weight Peso para cada colaboração; periodo Período que foi levado em consideração na análise (variável t) Cálculo do coeficiente de autocorrelação De posse dos dados relativos aos conteúdos colaborativos em todas as comunidades é possível executar o algoritmo para o cálculo do coeficiente de autocorrelação C(t), para o qual é preciso identificar os conjuntos A(t 0 ) e A(t 0 + t). No primeiro estão todas as relações em um determinado instante t 0, enquanto no segundo estarão a quantidade de relações do grafo conjunto entre as relações nos instantes t 0 e t. Para construir a função de autocorrelação é necessário a utilização de alguma linguagem de programação que vai buscar os dados e realizar as contas necessárias. Um exemplo de cálculo pode ser encontrado no trecho de código 4.6. Após a execução da função no banco de dados, a tabela autocorrelacao conterá o coeficiente para cada comunidade por período de tempo 1. 1 Para que a função seja executada com sucesso, as tabelas apresentadas nos trechos de código 4.5 e 4.4 já devem ter sido criadas. 55

56 Trecho de código 4.6: Função em PL/pgSQL que constrói o coeficiente de autocorrelação CREATE OR REPLACE FUNCTION a u t o c o r r e l a c a o s q l ( ) RETURNS BOOLEAN AS $$ DECLARE linha record ; v t date ; 5 v p VARCHAR; v numerador REAL; v denominador REAL; v c o e f i c i e n t e REAL; BEGIN 10 DROP TABLE IF EXISTS autocorrelacao ; T a b e l a que v a i armazenar o c o e f i c i e n t e de çã c o r r e l a o c a l c u l a d o CREATE TABLE a u t o c o r r e l a c a o ( comunidade VARCHAR, p e r i o d o VARCHAR, 15 numerador REAL, denominador REAL, c o e f i c i e n t e REAL ) ; 20 FOR l i n h a IN s e l e c t t o d a t e ( periodo, DD / MM / YYYY ) as data, periodo, pretty name from c o n t r i b f o r u m s union s e l e c t t o d a t e ( p e r i o d o, D D / M M / Y Y Y Y ) as data, p e r i o d o, pretty name 25 from c o n t r i b x o w i k i LOOP v t = l i n h a. data + ( i n t e r v a l 1 m o n t h ) ; v p = t o c h a r ( v t, D D / M M / Y Y Y Y ) ; 30 RAISE NOTICE C a l c u l a n d o p a r a c o m u n i d a d e % e t = % e t + 1 = %, l i n h a. pretty name, l i n h a. p e r i o d o, v p ; DROP TABLE IF EXISTS numerador tmp ; DROP TABLE IF EXISTS denominador tmp ; 35 P r i m e i r o o numerador que é a çã i n t e r s e c o CREATE TABLE numerador tmp AS (SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b f o r u m s WHERE periodo = linha. periodo 40 AND pretty name = linha. pretty name UNION SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b x o w i k i WHERE periodo = linha. periodo 45 AND pretty name = linha. pretty name ) INTERSECT (SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b f o r u m s WHERE p e r i o d o = v p 50 AND pretty name = linha. pretty name UNION SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b x o w i k i WHERE p e r i o d o = v p 55 AND pretty name = linha. pretty name ) ; D e p o i s o denominador que é a ã u n i o CREATE TABLE denominador tmp AS 60 (SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b f o r u m s WHERE periodo = linha. periodo AND pretty name = linha. pretty name UNION 65 SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b x o w i k i WHERE periodo = linha. periodo AND pretty name = linha. pretty name ) UNION 70 (SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b f o r u m s WHERE p e r i o d o = v p AND pretty name = linha. pretty name UNION 75 SELECT d i s t i n c t pretty name, " from ", " to " FROM c o n t r i b x o w i k i WHERE p e r i o d o = v p AND pretty name = linha. pretty name ) ; 80 Agora éó s somar o t o t a l de óns SELECT count ( n. from ) INTO v numerador FROM numerador tmp n ; SELECT count ( d. from ) INTO v denominador 85 FROM denominador tmp d ; Aqui á e s t o c o e f i c i e n t e v c o e f i c i e n t e := ( v numerador : : r e a l / v denominador : : r e a l ) : : r e a l ; 90 RAISE NOTICE D e n o m i n a d o r : % - N u m e r a d o r : % - C o e f i c i e n t e : %, v denominador, 56

57 v numerador, v c o e f i c i e n t e ; 95 I n s i r o os d a d o s na t a b e l a de c o n t r o l e INSERT INTO a u t o c o r r e l a c a o ( comunidade, p e r i o d o, denominador, numerador, c o e f i c i e n t e ) VALUES ( l i n h a. pretty name, l i n h a. p e r i o d o, v numerador, v denominador, v c o e f i c i e n t e ) ; END LOOP; 100 RETURN 1 ; END; $$ LANGUAGE p l p g s q l ; Agora é possível traçar o gráfico e verificar a evolução do coeficiente em todo o Portal ou por cada comunidade. Como exemplo é conveniente observar o gráfico da figura 4.3 referente às comunidades Cacic e Ginga, algumas das que mais possuem colaboração no Portal, além da comunidade OpenACS, o software do Portal. Figura 4.3: Gráfico do coeficiente de autocorrelação para comunidades selecionadas Probabilidade de extinção O último passo do método analítico é a verificação da possibilidade de colapso ou extinção da comunidade. Serão utilizados os procedimentos descritos na seção 2.5.2, onde calcula-se a probabilidade de extinção como uma função da razão entre w out /(w in + w out ). A consulta do trecho de código 4.7 traz os valores agregados por comunidade. 57

58 Trecho de código 4.7: Consulta que calcula os pesos entre as relações inter e extra comunidade. create or r e p l a c e view pesos comunidade forums as s e l e c t c. from, c. pretty name, (sum( d i s t i n c t c. weight ) ) as win, 5 ( case when sum( distinct c3. weight ) IS NULL THEN 0 ELSE sum( d i s t i n c t c3. weight ) end ) as wout, 10 min( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as primeira mensagem, max( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as ultima mensagem from c o n t r i b f o r u m s c l e f t j o i n c o n t r i b f o r u m s c3 on ( c. from = c3. from and c. to = c3. t o and c. pretty name <> c3. pretty name and c. p e r i o d o = c3. p e r i o d o ) where c. from i s not null 15 group by c. from, c. pretty name ; create or r e p l a c e view pesos comunidade xowiki as s e l e c t c. from, 20 c. pretty name, (sum( d i s t i n c t c. weight ) ) as win, ( case when sum( distinct c3. weight ) IS NULL THEN 0 ELSE 25 sum( d i s t i n c t c3. weight ) end ) as wout, min( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as p r i m e i r a p a g i n a, max( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as u l t i m a p a g i n a from c o n t r i b x o w i k i c 30 l e f t j o i n c o n t r i b x o w i k i c3 on ( c. from = c3. from and c. to = c3. t o and c. pretty name <> c3. pretty name and c. p e r i o d o = c3. p e r i o d o ) where c. from i s not null group by c. from, c. pretty name ; 35 create or r e p l a c e view pesos comunidade as s e l e c t c. from, c. pretty name, ( case when c2. win i s null then c. win 40 e l s e ( c. win + c2. win ) end ) as win, ( case when c2. wout i s null then c. wout 45 e l s e ( c. wout + c2. wout ) end ) as wout, c. primeira mensagem, c. ultima mensagem, 50 c2. p r i m e i r a p a g i n a, c2. u l t i m a p a g i n a from p e s o s c o m u n i d a d e f o r u m s c l e f t join pesos comunidade xowiki c2 on c. from = c2. from group by c. from, 55 c. win, c. wout, c2. win, c2. wout, c. primeira mensagem, 60 c. ultima mensagem, c2. p r i m e i r a p a g i n a, c2. ultima pagina, c. pretty name order by c. pretty name, c. from ; A saída da consulta apresenta os seguintes elementos: from Nó que será analisado; win Soma dos pesos das colaborações realizadas na comunidade; wout Soma dos pesos das colaborações realizadas fora da comunidade; ratio Taxa w out /(w in + w out ); primeira mensagem Período em que foi realizada a primeira colaboração no fórum; ultima mensagem Período em que foi realizada a última colaboração no fórum; 58

59 primeira pagina Período da primeira colaboração no Wiki; ultima pagina Período da última colaboração no Wiki. Se extraímos a identificação da comunidade, como no trecho de código 4.8, temos a relação para todo o Portal, sendo possível obter um panorama geral do comportamento das comunidades. Trecho de código 4.8: Consulta que calcula os pesos entre as relações inter e extra comunidade para todo o Portal create or r e p l a c e view p e s o s g e r a l f o r u m s as s e l e c t c. from, (sum( d i s t i n c t c. weight ) ) as win, ( case when sum( distinct c3. weight ) IS NULL THEN 5 0 ELSE sum( d i s t i n c t c3. weight ) end ) as wout, min( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as primeira mensagem, 10 max( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as ultima mensagem from c o n t r i b f o r u m s c l e f t j o i n c o n t r i b f o r u m s c3 on ( c. from = c3. from and c. to = c3. t o and c. pretty name <> c3. pretty name and c. p e r i o d o = c3. p e r i o d o ) where c. from i s not null group by c. from ; 15 create or r e p l a c e view p e s o s g e r a l x o w i k i as s e l e c t c. from, (sum( d i s t i n c t c. weight ) ) as win, ( case when sum( distinct c3. weight ) IS NULL THEN 20 0 ELSE sum( d i s t i n c t c3. weight ) end ) as wout, min( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as p r i m e i r a p a g i n a, 25 max( t o d a t e ( c. p e r i o d o, D D / M M / Y Y Y Y ) ) as u l t i m a p a g i n a from c o n t r i b x o w i k i c l e f t j o i n c o n t r i b x o w i k i c3 on ( c. from = c3. from and c. to = c3. t o and c. pretty name <> c3. pretty name and c. p e r i o d o = c3. p e r i o d o ) where c. from i s not null group by c. from ; 30 create or r e p l a c e view p e s o s g e r a l as s e l e c t c. from, ( case when c2. win i s null then c. win 35 e l s e ( c. win + c2. win ) end ) as win, ( case when c2. wout i s null then c. wout 40 e l s e ( c. wout + c2. wout ) end ) as wout, c. primeira mensagem, c. ultima mensagem, 45 c2. p r i m e i r a p a g i n a, c2. u l t i m a p a g i n a from p e s o s g e r a l f o r u m s c l e f t j o i n p e s o s g e r a l x o w i k i c2 on c. from = c2. from group by c. from, 50 c. win, c. wout, c2. win, c2. wout, c. primeira mensagem, 55 c. ultima mensagem, c2. p r i m e i r a p a g i n a, c2. u l t i m a p a g i n a order by c. from ; De posse dos dados extraídos é possível construir o gráfico de tempo de vida da relação versus a taxa w out /(w in + w out ), utilizando a mesma metodologia descrita em [Palla et al., 2007]. Fazemos a conta para todas as relações do Portal, desprezando as relações cujo peso externo w out é nulo, o que tornaria o coeficiente nulo naturalmente. O resultado pode ser visto na figura

60 Figura 4.4: Tempo de vida da relação versus taxa w out /(w in + w out ) Para traçar o gráfico de probabilidade de extinção, temos no eixo-y a probabilidade de um nó ser extinto e no eixo-x a taxa w out /(w in + w out ). Os dados são extraídos através da consulta explicitada no trecho de código 4.9. Trecho de código 4.9: Consulta que obtém a probabilidade de extinção versus a taxa W out /(W in + W out ) para todo o Portal create or r e p l a c e view c o n t r i b m e s as select ( count ( f. message from )+count ( x. item from ) ) as n contribs, f. p e r i o d o from c o n t r i b f o r u m s f 5 l e f t j o i n c o n t r i b x o w i k i x on ( f. from = x. from and f. to = x. t o and f. pretty name = x. pretty name ) group by f. periodo ; create or r e p l a c e view e x t i n c a o g e r a l as 10 s e l e c t c. from, ( c. win+c. wout ) as peso no, ( s e l e c t sum( c2. win+c2. wout ) from p e s o s g e r a l c2 where c2. ultima mensagem i s not null ) as p e s o t o t a l, ( c. wout /( c. win+c. wout ) ) as taxa from p e s o s g e r a l c 15 where c. ultima mensagem i s not null ; A consulta para os pesos em todos os nós do Portal trará os seguintes campos: from Nó para o qual a taxa foi calculada. Deve ter sido extinto (ultima mensagem não nulo); peso no Soma dos pesos das colaborações que envolvem o nó; peso total Soma dos pesos das colaborações de todos os nós; taxa Taxa w out /(w in + w out ) para o nó; Para calcular a probabilidade de extinção fazemos a razão entre o peso do nó que foi extinto e o peso de todos os outros nós que foram extintos. O resultado está presente no gráfico da figura

61 Figura 4.5: Probabilidade de extinção versus taxa w out /(w in + w out ) 4.4 Análise Gráfica Para construir o grafo da rede de relacionamentos do Portal do Software Público Brasileiro, é necessário o uso de uma ferramenta que tenha poder de visualização para uma massa muito grande de dados. A ferramenta precisa ainda ter interface de entrada de dados pronta para os grafos e tratamento adequado dos atributos envolvidos. Uma análise sobre as ferramentas de visualização de grafos para redes sociais pode ser encontrada em [Andery, 2010], que cita as vantagens de utilização da ferramenta, após análise de outras disponíveis no mercado: O Projection Explorer (PEx), como é denominada a ferramenta, tem como principal objetivo a exploração visual de coleções de documentos de texto, sendo que cada documento é apresentado como um ponto no plano e a proximidade entre os pontos denota a similaridade entre os respectivos documentos. Além disso, o PEx possui diversos mecanismos para auxiliar no processo de exploração dos dados, como busca por termo no corpo dos documentos, atribuição de cores e tamanhos diferentes aos pontos segundo algum critério, e extração de tópicos associados a conjuntos de documentos. O objetivo da utilização da ferramenta é poder visualizar o conjunto de dados e validar as observações teóricas sobre a rede formada pelo Portal do Software Público Brasileiro. O tratamento visual permite ainda uma análise visual do conjunto de dados e seu comportamento social. A extração dos dados para posterior visualização será detalhada durante a seção. 61

62 4.4.1 Formatação dos dados Segundo o manual da ferramenta PExGraph [Paulovich et al., 2007], os dados que serão tratados precisam estar codificados em formato de arquivo que se chama VNA. O formato é baseado em duas partes: dados dos nós e dados das relações que compões o grafo. Um arquivo padrão é fornecido com a ferramenta e pode ser visto no trecho de código Trecho de código 4.10: Arquivo exemplo para o formato VNA Node data ID, gender, role, betweenness #16,birthday@DATE@d/M/y#18 HOLLY, female, p a r t i c i p a n t, , 2 8 / 0 1 / BRAZEY, female, p a r t i c i p a n t, 0, 1 9 / 1 1 / CAROL, female, p a r t i c i p a n t, , 0 7 / 1 0 / PAM, female, p a r t i c i p a n t, , 1 5 / 0 6 / PAT, female, p a r t i c i p a n t, , 1 0 / 0 4 / JENNIE, female, p a r t i c i p a n t, , 1 1 / 1 2 / PAULINE, female, p a r t i c i p a n t, , 2 5 / 0 4 / ANN, female, p a r t i c i p a n t, 0. 5, 0 1 / 0 7 / MICHAEL, male, p a r t i c i p a n t, , 0 3 / 1 2 / BILL, male, p a r t i c i p a n t, 0, 2 4 / 0 6 / LEE, male, p a r t i c i p a n t, 5, 2 9 / 0 6 / DON, male, p a r t i c i p a n t, , 0 4 / 0 8 / JOHN, male, p a r t i c i p a n t, 0, 3 0 / 0 8 / HARRY, male, p a r t i c i p a n t, , 1 6 / 0 2 / GERY, male, i n s t r u c t o r, , 1 1 / 0 9 / STEVE, male, i n s t r u c t o r, , 0 2 / 0 7 / BERT, male, i n s t r u c t o r, , 1 5 / 0 7 / RUSS, male, i n s t r u c t o r, , 0 5 / 1 2 / Tie data from, to, f r i e n d s #2, s t r e n g t h #16 HOLLY,PAM, 1, 1 PAT,HOLLY, 1, 2 25 PAULINE,PAT, 1, 2 JOHN, RUSS, 1, 3 HARRY,HOLLY, 1, 2 HARRY,MICHAEL, 1, 1 BERT, RUSS, 1, 3 30 RUSS,GERY, 1, 1 RUSS,STEVE, 1, 3 RUSS,BERT, 1, 2 HOLLY,BRAZEY, 0, 7 HOLLY,CAROL, 0, BRAZEY, PAULINE, 0, 7 BRAZEY,ANN, 0, 6 BRAZEY,MICHAEL, 0, 1 5 PAM,MICHAEL, 0, 9 PAM, BILL, 0, PAM, LEE, 0, 1 3 JENNIE,BRAZEY, 0, 8 PAULINE, JENNIE, 0, 5 PAULINE,ANN, 0, 4 ANN,PAT, 0, 7 45 ANN,MICHAEL, 0, 9 BILL, LEE, 0, 1 0 DON,ANN, 0, 1 2 Uma observação importante sobre o formato dos dados é a definição de comunidade. No método CPM [Derényi et al., 2005], a comunidade é um conjunto de subgrafos completos de tamanho k, ou seja, é dinâmica e pode ser alterada conforme a necessidade. No conjunto de dados da pesquisa há uma definição explícita de comunidade, identificado no contexto em que a colaboração acontece. Imaginando que as relações presentes em tal contexto podem ser suficientes para fazer aparecer a comunidade, é possível realizar a consulta do trecho de código A saída contempla os dados para a construção dos grafos. 62

63 Trecho de código 4.11: Consulta que extrai os grafos no formato de entrada da ferramenta Pex-Graph create or r e p l a c e view p e x g r a f o as ( s e l e c t coalesce ( x. from, f. from ) as from, coalesce ( x. to, f. to ) as to, count ( f. message from ) as forums messages, 5 count ( x. item from ) as wiki pages from c o n t r i b f o r u m s f l e f t j o i n c o n t r i b x o w i k i x on ( ( f. from = x. from or f. from = x. t o or f. from = x. to ) and f. pretty name = x. pretty name ) group by x. from, x. to, 10 f. from, f. to, f. pretty name ) union ( select distinct d. community id as from, 15 coalesce ( x. from, f. from ) as to, : : integer as f o r u m s m e s s a g e s, : : integer as w i k i p a g e s from c o n t r i b f o r u m s f inner j o i n d o t l r n c o m m u n i t i e s a l l d on f. pretty name = d. pretty name 20 l e f t j o i n c o n t r i b x o w i k i x on ( ( f. from = x. from or f. from = x. t o or f. from = x. to ) and f. pretty name = x. pretty name ) group by x. from, x. to, f. from, f. to, 25 f. pretty name, d. community id ) union ( select distinct d. community id as from, coalesce ( x. to, f. to ) as to, : : integer as f o r u m s m e s s a g e s, : : integer as w i k i p a g e s from c o n t r i b f o r u m s f inner j o i n d o t l r n c o m m u n i t i e s a l l d on f. pretty name = d. pretty name l e f t j o i n c o n t r i b x o w i k i x on ( ( f. from = x. from or f. from = x. t o or f. from = x. to ) and f. pretty name = x. pretty name ) 35 group by x. from, x. to, f. from, f. to, f. pretty name, 40 d. community id ) ; É preciso então obter os dados dos nós para completar a entrada da ferramenta. A consulta 4.12 mostra como podem ser obtidos os dados dos membros das comunidades para inserir na ferramenta Pex-Graph. 63

64 Trecho de código 4.12: Consulta que extrai os dados dos nós no formato de entrada da ferramenta Pex-Graph create or r e p l a c e view p e x u s u a r i o s as s e l e c t d i s t i n c t pa. p a r t y i d as ID, pe. f i r s t n a m e s pe. l a s t n a m e as name, ( s e l e c t at. o p t i o n as value 5 from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa, a m s o p t i o n s ao, a m s o p t i o n t y p e s at where o b j e c t i d = u. u s e r i d and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and av. v a l u e i d = ao. v a l u e i d and ao. o p t i o n i d = at. o p t i o n i d 10 and aa. a t t r i b u t e n a m e = c o u n t r y ) as country, ( s e l e c t at. o p t i o n as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa, a m s o p t i o n s ao, a m s o p t i o n t y p e s at where o b j e c t i d = u. u s e r i d and av. a t t r i b u t e i d = aa. a t t r i b u t e i d 15 and av. v a l u e i d = ao. v a l u e i d and ao. o p t i o n i d = at. o p t i o n i d and aa. a t t r i b u t e n a m e = s t a t e ) as s t a t e, ( s e l e c t a m s a t t r i b u t e v a l u e v a l u e ( av. a t t r i b u t e i d, av. v a l u e i d ) as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa 20 where o b j e c t i d = u. u s e r i d and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and aa. a t t r i b u t e n a m e = c i t y ) as c i t y, ( s e l e c t at. o p t i o n as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa, a m s o p t i o n s ao, a m s o p t i o n t y p e s at 25 where o b j e c t i d = u. u s e r i d and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and av. v a l u e i d = ao. v a l u e i d and ao. o p t i o n i d = at. o p t i o n i d and aa. a t t r i b u t e n a m e = a r e a ) as area, 30 ( s e l e c t at. o p t i o n as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa, a m s o p t i o n s ao, a m s o p t i o n t y p e s at where o b j e c t i d = u. u s e r i d and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and av. v a l u e i d = ao. v a l u e i d 35 and ao. o p t i o n i d = at. o p t i o n i d and aa. a t t r i b u t e n a m e = c o v e r a g e ) as c o v e r a g e, ( s e l e c t a m s a t t r i b u t e v a l u e v a l u e ( av. a t t r i b u t e i d, av. v a l u e i d ) as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa where o b j e c t i d = u. u s e r i d 40 and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and aa. a t t r i b u t e n a m e = o r g ) as org, ( s e l e c t a m s a t t r i b u t e v a l u e v a l u e ( av. a t t r i b u t e i d, av. v a l u e i d ) as value from a m s a t t r i b u t e v a l u e s av, a m s a t t r i b u t e s aa where o b j e c t i d = u. u s e r i d 45 and av. a t t r i b u t e i d = aa. a t t r i b u t e i d and aa. a t t r i b u t e n a m e = p o s i t i o n ) as position from d o t l r n m e m b e r r e l s a p p r o v e d u inner j o i n p a r t i e s pa on u. u s e r i d = pa. p a r t y i d inner j o i n persons pe on pa. part y id = pe. person id 50 inner j o i n c o n t r i b f o r u m s m on ( u. u s e r i d = m. from or u. u s e r i d = m. to ) where u. member state = a p p r o v e d union s e l e c t d i s t i n c t d. community id as ID, d. pretty name as name, 55 # : : varchar ( ) as country, # : : varchar ( ) as s t a t e, # : : t e x t as c i t y, # : : varchar ( ) as area, # : : varchar ( ) as c o v e r a g e, 60 # : : t e x t as org, # : : t e x t as position from d o t l r n c o m m u n i t i e s a l l d A saída possui os seguintes campos: ID Identificador único do nó. Importante: o nome do campo precisa ser ID, caso contrário a ferramenta não o reconhece; name Nome do usuário; country País de origem; state Estado; city Cidade; area Área de atuação; coverage Abrangência da instituição em que trabalha; 64

65 org Instituição em que trabalha; position Cargo. Após a realização das consultas é necessário fundir os dados em um arquivo único no formato VNA. Após a fusão o arquivo resultante deverá conter o formato apresentado como exemplo no trecho de código 4.13 Trecho de código 4.13: Arquivo VNA exemplo com os dados do Portal do Software Público Node data id, country, s t a t e, c i t y, area, c o v e r a g e, org, position 5 07, " B R ",, " { t e x t / p l a i n } í B r a s l i a ", " S e t o r ú P b l i c o - E x e c u t i v o ", " F e d e r a l ", " { t e x t / p l a i n } é M i n i s t r i o d o P l a n e j a m e n t o ", 3443, " B R ",, " { t e x t / p l a i n } í B r a s l i a ", " S e t o r ú P b l i c o - E x e c u t i v o ", " F e d e r a l ", " { t e x t / p l a i n } é M i n i s t r i o d o P l a n e j a m e n t o ", " { t e x t / p l a i n } é T c n i c o d e I n f r a - e s t r u t u r a " , " B R ", " D F ", " { t e x t / p l a i n } í B r a s l i a ",,,, (... ) Tie data from, to, forums messages, wiki pages 5 0 7, 5 0 7, 1, , , 1, , , 1, , , 1, , , 1, , , 1, , , 1, , , 1, , , 1, , , 1, 0 (... ) , , 1, , , 1, 0 (... ) , , 3 0, , , 30, , , 3 0, , , 33, Grafos traçados com a ferramenta PEx-Graph De posse dos dados no formato de entrada da ferramenta PEx-Graph é possível traçar os grafos da comunidade. A figura 4.6 apresenta o primeiro grafo, considerando as contribuições por comunidade. Abrindo a interface da ferramenta, é necessário buscar o arquivo de dados e selecionar técnica de Layout para projeções baseadas em conexão (Connectivity Based Projection) utilizando as opções padrão, que serão suficientes para gerar o grafo de contribuições de fórum da figura 4.6 A figura 4.6 revela a estrutura em grafo das comunidades, onde cada ponto representa um nó ou um usuário e cada linha representa uma relação entre os dois pontos. A relação é baseada em uma colaboração no fórum, ou seja, um usuário que respondeu a uma mensagem enviada por outro. Alterando a conectividade para as páginas Wiki, obtemos um grafo diferente, apresentado na figura 4.7. No caso a relação representa o ato de edição de uma página Wiki criada por outro usuário. 65

66 Figura 4.6: Grafo de colaborac a o nos fo runs das comunidades 66