XI Workshop de Software Livre

21 a 24 de julho de 2010

Centro de Eventos PUCRS

Porto Alegre - RS - Brasil

Coordenação Editorial: 3

XI Worshop sobre Software Livre

Cristiano André da Costa / Unisinos
Eduardo Todt / UFPR
Maria Cristina Atz / ASL

Capa e diagramação:

Pubblicato Editora Ltda.

Impressão e Acabamento:
Lupagraph

Tiragem:
1.000 exemplares

Porto Alegre/RS – Brasil

Prefácio
X Workshop de Software Livre - WSL 2009-06-15
10º Fórum Internacional Software Livre - FISL 2009
(10.: 2009 junho: Porto Alegre, RS)

X Workshop de Software Livre - WSL 2009 / 10º Fórum Internacional Sof-

tware Livre - FISL 2008 editores Andrea Schwertner Charão, Celso Maciel
da Costa, FIlipi Vianna, Marcelo D’Elia Branco, Maria Cristina Atz, Ricardo
Fritsch, Virginia Silva Ferreira - Porto Alegre.
Apoio: Sociedade Brasileira de Computação, 2009.

172 p.; 16x23cm

ISBN 85-89344-50-9

1. Software 2. Software Livre 3. Programação

CIP - Catalogação na fonte: Paula Pegas de Lima CRB 10/ 1229

 5

Fórum Internacional Software Livre

XI Worshop sobre Software Livre

11 anos

Desde 2000, o Fórum Internacional Software Livre (fisl) propor-

ciona aos participantes uma discussão política, social e técnica sobre
software livre. Este ano, chegamos à nossa 11º edição, reunindo pales-
tras, discussões, debates, festivais, oficinas e as últimas novidades da
internet e da tecnologia da informação.
Considerado o maior encontro de comunidades de software livre
da América Latina e um dos maiores do mundo, o fisl sempre foi, em
todas as suas edições, o grande sonho de encontro daqueles que coti-
dianamente se conectam na rede para trabalhar, compartilhar conheci-
mentos e ideias.
Na 10ª edição, trouxemos nomes como Jon Maddog Hall, Richard
Stallman e o criador do portal de compartilhamento de arquivos torrent
The Pirate Bay, Peter Sunde. O presidente Lula também esteve no even-
to, considerado o maior fisl de todos.
Para 2010, começamos inovando na seleção das palestras, des-
centralizando o processo de avaliação. Com a construção da programa-
ção acontecendo de forma colaborativa, ganhamos em agilidade e em
qualidade. Além das palestras, estão programadas diversas atividades
que englobam oficinas, encontro das comunidades de software livre,
Workshop Acadêmico de Software Livre, Mostra de Soluções e Negócios
Livres e Arena de Programação Livre.
O fisl11 contará com a presença de muitos dos principais nomes
do software livre no mundo, como o evangelista de Git, que trabalha na
GitHub, Scott Chacon, o criador do Postfix, Wietse Venema, o adminis-
trador de sistemas do Google na Suíça, Michael Hanselmann, que traba-
lha no desenvolvimento do projeto Ganeti, Carlos Donizete (Coringao),
que falará sobre o Ubuntu e tantos outros.
O sucesso das edições anteriores do Fórum Internacional Sof-
tware Livre mostra a importância de se discutir e trocar informações
e experiências sobre o mundo do software livre e sua importância na
tecnologia da informação. O fisl é o momento de aprender e atualizar os
conhecimentos sobre o uso de software de código aberto em diversas
áreas, como segurança, educação, economia e política. Na programação
do Fórum, a cultura livre também tem espaço, assim como as ações
ligadas à agroecologia.

Coordenação Geral
Associação Software Livre.org
 6 Comissão Organizadora do 11º Fórum Internacional Software Livre 7
XI Worshop sobre Software Livre

XI Worshop sobre Software Livre

Coordenadora Geral:
Virginia Silva Ferreira
Coordenador Financeiro:
Ricardo Fritsch
Embaixador:
Sady Jacques
Secretária Executiva:
Maria Cristina Atz

GRUPOS DE TRABALHOS:

GT Captação
Ricardo Fritsch
GT Caravanas
Junior Goergen
GT Comunicação
Thaís Rucker
Luís Henrique Silveira
GT Cultura
Lucas Alberto Santos
GT Feminino Livre
Virginia Silva Ferreira
GT Grupos de Usuários
Paloma Costa
Oscar Luz
GT Infra-estrutura
Thomas Tschoepke Soares
GT Mobilização
Felipe Santos
José Francisco Nunes Fernandez
GT Temário
Carlos Machado Oliveira
Pablo Lorenzzonni
GT TV Software Livre
Fabrício Solagna
GT Voluntários
Maurício Portal
GT Web
Airton Jordani Jardim filho
 8 Associação Software Livre.Org
XI Worshop sobre Software Livre
CONSELHO GERAL:
Titulares:
CCoordenadora Geral em Exercício: Virginia Silva Ferreira
Coordenador Financeiro: Ricardo Fritsch
Conselheira Geral: Priscilla Kurtz Vieira de Carvalho
Conselheiro Geral: José Francisco Nunes Fernandez
Conselheira Geral: Noemi Yoshinaga Cunha de Souza
Conselheiro Geral: Carlos Eurico Pittas do Canto
Suplente:
Silvio Antonio Hoffmann Jacques
Sede:
Rua dos Andradas, 1560, conjunto 1606 – 16º andar – Centro – Porto Alegre – RS
Rua dos Andradas,1560, conj.1606 – 16º andar - Centro – Porto Alegre – RS
Caixa Postal n° 443 - CEP: 90.001-970 - Porto Alegre - RS
Fone/Fax: + 55 (51) 3228-0181 – Contato: asl@softwarelivre.org – Site: www. asl.org.br
XI Workshop de Software Livre 9
XI Worshop sobre Software Livre
Apresentação
O Workshop sobre Software Livre (WSL) é um evento científico que ocorre anualmente
e faz parte do Fórum Internacional Software Livre (FISL). O WSL tem como principal objetivo
reunir pesquisadores, professores, alunos e profissionais atuantes na área de software livre,
para apresentação de trabalhos que estão sendo desenvolvidos nas diferentes organizações,
universidades e centros de pesquisa.
Nesta 11ª edição foram inscritos 115 artigos ao WSL, o que caracteriza uma continui-
dade no alto número de submissões já registrado no ano passado. Dos manuscritos submetidos,
28 foram selecionados para apresentação, o que representa uma taxa de aceitação de 24,3%.
Os processos de submissão, avaliação e seleção foram realizados de forma eletrônica, com o
uso do sistema de gerência de eventos JEMS, da Sociedade Brasileira de Computação. Em geral
cada artigo submetido foi distribuído para avaliação a três membros do comitê de programa,
composto por professores e pesquisadores de diversas universidades e organizações do país. O
número de submissões e a taxa de aceitação refletem uma seleção criteriosa em uma base sig-
nificativa, indicando a maturidade do evento, que na prática já se tornou referência qualificada
na área. Também a qualidade científica dos artigos está em um nível elevado, resultado de um
processo evolutivo contínuo ao longo dos últimos anos.
Nesta edição, o evento está organizado em sete sessões técnicas, compostas a partir
dos tópicos de interesse do evento e dos temas dos artigos selecionados. Estas sessões tratam
de Casos de sucesso de pesquisa na universidade, empresa e governo, Banco de Dados, En-
genharia de Software, Sistemas Baseados na Web, Software Básico e Sistemas Operacionais,
Redes, Sistemas Distribuídos e Computação Móvel e Computação Gráfica, Processamento de
Imagens e TV Digital.
Gostaríamos de agradecer aos membros do comitê de programa do WSL pelo esforço
em avaliar um número expressivo de artigos em um prazo reduzido, e aos membros do comitê
de organização do FISL pela presteza no atendimento de nossas solicitações.
Estes anais contêm os artigos selecionados e que serão apresentados nas sessões
técnicas do WSL 2010, os quais, com certeza, representam uma amostra significativa da pes-
quisa atualmente em desenvolvimento em software livre.
Cristiano André da Costa (Unisinos)
Coordenador Geral
Eduardo Todt (UFPR)
Coordenador do Comitê de Programa
 10 XI Workshop de Software Livre Revisores 11
XI Worshop sobre Software Livre

XI Worshop sobre Software Livre

Organização Adenauer Corrêa Yamin (UCPel e UFPel) Ilmerio Reis da Silva (UFU)
Universidade do Vale do Rio dos Sinos Adenilso Simão (ICMC-USP) Jéferson Nobre (UFRGS)
(UNISINOS) Alba Melo (UnB) João Netto (UFRGS)
Universidade Federal do Paraná Aldelir Luiz (UFSC) José Santanna (UFRGS)
(UFPR) Aldri dos Santos (UFPR) José Ramos Gonçalves (UFC)
Alessandro Santos (UFRGS) Josiney Souza (UFPR)
Apoio Alexandre Carissimi (UFRGS) Jussara Issa Musse (UFRGS)
Sociedade Brasileira de Computação Alexandre Ribeiro (UCS) Kalinka Castelo Branco (ICMC-USP)
(SBC) Alfredo Goldman (IME-USP) Lau Cheuk Lung (UFSC)
André Detsch (UNISINOS) Leonardo Fernandes (UNISINOS)
Editores André Guedes (UFPR) Leliane Nunes de Barros (USP)
Cristiano André da Costa (UNISINOS) Andre Du Bois (UFPel) Lisandro Granville (UFRGS)
Eduardo Todt (UFPR) André L. S. Gradvohl (USF) Lucas Ferrari de Oliveira (UFPR)
Andrea Schwertner Charão (UFSM) Luciana Rech (UFSC)
Andrey Pimentel (UFPR) Luciano Porto Barreto (UFBA)
Autran Macêdo (UFU) Luis Carlos De Bona (UFPR)
Comitê de Programa Benhur de Oliveira Stein (UFSM) Marcelo Finger (USP)
Bruno Cesar Ribas (UFPR) Marcelo Rodrigues (UFU)
Adenauer Corrêa Yamin (UCPel e UFPel) José Carlos Maldonado (ICMC-USP)
Carlos Eduardo Santos (USP) Marcos Castilho (UFPR)
Alba Melo (UnB) José Ramos Gonçalves (UFC)
Celso Maciel da Costa (PUCRS) Marcos Sunye (UFPR)
Alexandre Ribeiro (UCS) Jussara Issa Musse (UFRGS)
Cesar Loureiro (UFRGS) Marilton Sanchotene de Aguiar (UCPel)
Alfredo Goldman (IME-USP) Lau Cheuk Lung (UFSC)
Chauã Queirolo (UFPR) Mauricio de Diana (IME-USP)
André Detsch (UNISINOS) Leonardo Lemes Fagundes (UNISINOS)
Cláudia de O. Melo (IME-USP) Nelson Lago (IME-USP)
André Du Bois (UFPel) Lisandro Zambenedetti Granville (UFRGS)
Cláudio de Sá (UNESC) Patrícia Kayser V. Mangan (UNILASALLE)
André L. S. Gradvohl (USF) Lucas Ferrari de Oliveira (UFPR)
Cristiano André da Costa (UNISINOS) Patrick Shinzato (USP)
Andrea Schwertner Charão (UFSM) Luciano Porto Barreto (UFBA)
Cristine Gusmão (UFPE) Paulyne Jucá (UFPE)
Autran Macêdo (UFU) Luis Carlos De Bona (UFPR)
Daniel Weingaertner (UFPR) Regina Araujo (UFSCAR)
Benhur Stein (UFSM) Marcelo Finger (USP)
Eduardo de Almeida (UFPR) Renata Fortes (ICMC-USP)
Celso Maciel da Costa (PUCRS) Marcos Castilho (UFPR)
Eduardo Katayama (USP) Ricardo Luis dos Santos (UFRGS)
Cláudio de Sá (UDESC) Marcos Sunye (UFPR)
Eduardo Todt (UFPR) Rivalino Matias Jr. (UFU)
Cristiano André da Costa (UNISINOS) Marilton Sanchotene de Aguiar (UFPel)
Egon Hilgenstieler (UFPR) Rodrigo Araújo Real (Freedom Veíc. El. Ltda)
Daniel Weingaertner (UFPR) Patrícia Kayser V. Mangan (UNILASALLE)
Elisa Yumi Nakagawa (USP) Roland Teodorowitsch (ULBRA)
Eduardo Todt (UFPR) Paulyne Matthews Jucá (UFPE)
Ewerton Longoni Madruga (INMETRO) Ronaldo Fernandes Ramos (IFET-CE)
Ewerton Madruga (INMETRO) Regina Borges de Araujo (UFSCar)
Fabiano Silva (UFPR) Rubens Suguimoto (UFPR)
Fabiano Silva (UFPR) Renata Galante (UFRGS)
Fernando Santos Osório (USP) Sílvio Cesar Cazella (UNISINOS)
Fernando Santos Osório (USP) Rodrigo A. Real (Freedom Veíc. Elétr. Ltda.)
Gaspare Bruno (COPPE-UFRJ) Simone André da Costa (UFPel)
Gaspare Bruno (UNILASALLE) Ronaldo Teodorowitsch (ULBRA)
Gerson G. H. Cavalheiro (UFPel) Valdir Stumm Junior (UFSC)
Gerson G. H. Cavalheiro (UFPel) Ronaldo Fernandes Ramos (IFET-CE)
Gustavo Pessin (USP) Viviane Malheiros (SERPRO e ICMC-USP)
Hisham H. Muhammad (GoboLinux.org) Silvio Cesar Cazella (UNISINOS)
João Cesar Netto (UFRGS) Simone André da Costa (UFPel) Hisham H. Muhammad (GoboLinux.org)
 12 Sociedade Brasileira de Computação (SBC) Sumário 13
XI Worshop sobre Software Livre

XI Worshop sobre Software Livre

15 Sessão I - Casos de sucesso de pesquisa na universidade, empresa e governo
Presidência

Presidente: José Carlos Maldonado (ICMC-USP)
Vice-Presidente: Marcelo Walter (UFRGS)
Diretorias
Administrativa: Luciano Paschoal Gaspary (UFRGS)
Finanças: Paulo Cesar Masiero (ICMC-USP)
Eventos e Comissões Especiais: Lisandro Zambenedetti Granville
(UFRGS)
Educação: Mirella M. Moro (UFMG)
Publicações: Karin Breitman (PUC-Rio)
Planejamento e Programas Especiais: Ana Carolina Salgado (UFPE)
Secretarias Regionais: Thais Vasconcelos Batista (UFRN)
Divulgação e Marketing: Altigran Soares da Silva (UFAM)
16 Integração Contínua com Software Livre: Um relato de implantação na Fun-
dação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL – Felipe Queiroz
(UFPE), Leonardo Oliveira (UFPE)
22 Processo Demoiselle: um processo livre para desenvolvimento de software
para e-Gov – Viviane Malheiros (SERPRO, USP/ICMC), Ronaldo Agra (Serpro), Alisson
Andrade (SERPRO, UNB)
28 Software Livre como Objetos de Aprendizagem Generalizáveis do Projeto
CONDIGITAL – Alexandre Direne (UFPR), Diego Marczal (UFPR), Jonatas Teixeira (UFPR),
Felipe Moreschi (UFPR), Derik Silva (UFPR), Danilo Picolotto (UFPR), Fernando Coelho
(UFPR), Jorge Salvi (UFPR)
34 Uso de software livre para gestão do serviço de atendimento ao usuário de TI
no INMETRO – Eduardo Abreu (Apex-Brasil), Sandra Dias (INMETRO), Luiz C. Dalcorno
(INMETRO), Fabiano Lanini (INMETRO), Angela Albarello (ESAF)
41 Sessão II - Banco de Dados

Conselho
42 Implementing a modern API for CDS/ISIS, a classic semistructured NoSQL da-

Mandato 2009-2013 tabase – Luciano Ramalho (BIREME/OPAS/OMS)

48 pgGrid: uma Implementação de Fragmentação de Dados para o PostgreSQL –
Virgílio Almeida (UFMG) Gustavo Tonini (UFSC), Frank Siqueira (UFSC)
Flávio Rech Wagner (UFRGS) 54 SatBudgets: Projeto Conceitual de Satélites Baseado em Conhecimento e Di-
Silvio Romero de Lemos Meira (UFPE) rigida a Modelos – Bruno Leonor (INPE-CPTEC), Walter Abrahão dos Santos (INPE),
Itana Maria de Souza Gimenes (UEM) Stephan Stephany (INPE)
Jacques Wainer (UNICAMP)
60 Setfon: Sistema Open Source para produção e organização de Semioetiquetas
Fonológicas – Ana Matte (UFMG), Rubens Takiguti Ribeiro (UFLA)
Suplentes - 2009-2011

Geraldo B. Xexeo (UFRJ) 67 Sessão III - Engenharia de Software

Taisy Silva Weber (UFRGS)
Marta Lima de Queiroz Mattoso (UFRJ)
68 Avaliando a Qualidade de Conjuntos de Teste de Produtos de Software de
Raul Sidnei Wazlawick (UFSC)
Código Aberto por meio de Critérios de Teste Estruturais – Adriana Rocha (UFG),
Renata Vieira (PUCRS)
André Rincon (UFG/UFTO), Márcio Eduardo Delamaro (ICM/USP), José Carlos Maldonado
(ICM/USP), Auri Marcelo Rizzo Vincenzi (UFG)
Mandato 2005 - 2009
74 Extensões para Refatoração de Código Fortran no Eclipse – Bruno Boniati (UFSM),
Gustavo Rissetti (UFSM), Andrea Charao (UFSM), Eduardo Piveta (UFSM)
Ana Carolina Salgado (UFPE)
Jaime Simão Sichman (USP) 80 Nodipo: ferramenta de levantamento colaborativo de requisitos para software
Daniel Schwabe (PUC-Rio) livre – José Eduardo De Lucca (UFSC), Yuri Cardenas (UFSC)
Vera Lúcia Strube de Lima (PUCRS) 86 Spider-MPlan: Uma Ferramenta para Apoio ao Processo de Medição do MPS.
Raul Sidnei Wazlawick (UFSC) BR – Sandro Ronaldo Bezerra Oliveira (UFPA), Bernardo Estácio (UFPA)
 14 93 Sessão IV - Sistemas Baseados na Web 15
XI Worshop sobre Software Livre

94 certificaPET: Sistema Gerenciador de Certificados de Eventos em Formato Di-

gita – Adriano Pereira (UFSM), Vinícius Pinto (UFSM), Andrea Charao (UFSM)
100 Software livre baseado na web para estimativa numérica de dados meteorológi-
cos – Rafael Camargo Ferraz (UFSM), Angélica Rossana Castro de Souza (UFSM), Adroal-
do Dias Robaina (UFSM), Marcia Xavier Peiter (UFSM)
106 Um Portal Web Livre para Disseminação de Informações sobre Sistemas Em-
barcados Críticos – Ricardo Amaral Martins Reimão (USP), Elisa Yumi Nakagawa (USP),
Thiago Bianchi (USP), José Maldonado (SSC/ICMC-USP/ São Carlos)
112 XadrezLivre: Proposta de Arquitetura de Ambiente de Jogos baseado em XMPP
com clienteWeb – Rubens Suguimoto (UFPR), Luis Carlos De Bona (UFPR), Alexandre
Direne (UFPR) Sessão I
Casos de sucesso de pesquisa na
119 Sessão V - Software Básico e Sistemas Operacionais universidade, empresa e governo

120 Análise Experimental Comparativa de Algoritmos de Alocação de Memória de

Código Aberto – Rivalino Matias Jr. (UFU), Autran Macêdo (UFU), Tais Ferreira (UFU)
16 Integração Contínua com Software Livre: Um relato de
126 Avaliação Experimental do Índice de Carga Usado no Kernel Linux – Rivalino Ma- implantação na Fundação de Amparo a Pesquisa do Es-
tias Jr. (UFU), Leonardo Alt (UFU), Otávio Augusto (UFU) tado de Alagoas - FAPEAL
132 MDM: Um Software Livre para Configuração de Ambientes Multiterminais
– Francisco Kaseker (UFPR), Aramis Stach Haiduski Fernandes (UFPR), Lucas Ferreira Felipe Queiroz (UFPE), Leonardo Oliveira (UFPE)
(UFPR), Paulo Zanoni (UFPR), Pedro Eugenio Rocha (UFPR), Eduardo Todt (UFPR)
22 Processo Demoiselle: um processo livre para desenvol-
138 WFS: Um Sistema de Arquivos FUSE-Linux Baseado na Política Write-Once Re- vimento de software para e-Gov
ad-Many – Tiago Falcão (UFPE), Ermeson Andrade (UFPE), Rubens Matos (UFPE), Paulo
Maciel (UFPE), Stephen Worth (EMC Corporation), Paul Malenfant (EMC Corporation) Viviane Malheiros (SERPRO, USP/ICMC), Ronaldo Agra (Serpro),
Alisson Andrade (SERPRO, UNB)

XX Sessão VI - Sistemas Baseados na Web 28 Software Livre como Objetos de Aprendizagem Genera-
XX Sessão VII - Sistemas Baseados na Web lizáveis do Projeto CONDIGITAL

Alexandre Direne (UFPR), Diego Marczal (UFPR), Jonatas Teixei-

ra (UFPR), Felipe Moreschi (UFPR), Derik Silva (UFPR), Danilo
Picolotto (UFPR), Fernando Coelho (UFPR), Jorge Salvi (UFPR)

34 Uso de software livre para gestão do serviço de atendi-

mento ao usuário de TI no INMETRO.

Eduardo Abreu (Apex-Brasil), Sandra Dias (INMETRO), Luiz C.

Dalcorno (INMETRO), Fabiano Lanini (INMETRO), Angela Alba-
rello (ESAF)
 16
XI Worshop sobre Software Livre
Integração Contínua com Software Livre: Um
relato de implantação na Fundação de Amparo
a Pesquisa do Estado de Alagoas – FAPEAL
Felipe B. de Queiroz1, Leonardo F. M. de Oliveira1
1
Fundação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL
CEP 57.020-330 – Maceió – AL – Brasil
{felipe.buarque, leonardo.fernandes}@fapeal.br
ABSTRACT. The task of integrating artifacts is inherent in the process of software de-
velopment, where all parts are being worked by different team members are put together
and a check is made whether the system is functioning according to requirements. Therefore,
Continuous Integration emerged as a strategy to attach the artifacts used in the software de-
velopment process constantly and in short cycles. This work aims to demonstrate the process
of adopting the IC practice using open source software in the Fundação de Amparo a Pesquisa
do Estado de Alagoas - FAPEAL, approaching its concepts and demonstrating the benefits of
their use.
RESUMO. A tarefa de integrar artefatos é inerente ao processo de desenvolvimento
de software, onde todas as partes que estão sendo trabalhadas pelos diferentes membros da
equipe são colocadas juntas e é feita uma verificação se o sistema está funcional, conforme
os requisitos. Visto isso, a Integração Contínua surge como uma estratégia de unir os artefa-
tos usados no processo de desenvolvimento de software de maneira constante e em ciclos
curtos. Assim, este trabalho tem por objetivo demonstrar o processo de adoção da prática de
IC utilizando software livre na Fundação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL,
abordando seus conceitos e demonstrando os benefícios de sua utilização.
1. Introdução
O processo de integrar software não é um problema novo [Duval et al. 2007]. No processo de de-
senvolvimento de software, toda equipe, com duas ou mais pessoas, precisa lidar com a tarefa de
integrar seus artefatos. À medida que a complexidade do projeto aumenta, há uma grande neces-
sidade de tais artefatos serem integrados com uma certa frequência, afim de manter os mesmos
atualizados em relação ao projeto e assegurar que os componentes trabalhem juntos e de maneira
funcional. Visto isso, a falta de automação e adiamento para o final do ciclo de desenvolvimento o
deixa passivo de alguns problemas, como o esquecimento por parte do responsável pela integra-
ção da inclusão de algum artefato, ou descobrir que dois desenvolvedores usaram versões diferen-
tes de bibliotecas de terceiros o que acarretou em erro no momento da integração.
Assim, a Integração Contínua (IC) surge como uma estratégia de unir os artefatos utili-
zados no processo de desenvolvimento de software de maneira constante e em ciclos curtos,
permitindo aos desenvolvedores a habilidade de realizar alterações no código, sabendo que,
se o sistema “quebrar”, os mesmos possam ser alertados imediatamente e tenham mais tem- 17
po para corrigir o problema e se ajustar às mudanças mais rapidamente.
Integração Contínua com Software Livre: Um relato de implantação na Fundação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL
Paralelo a isso, o alto grau de maturidade alcançado pelas ferramentas livres nos úl-
timos anos, principalmente aquelas que auxiliam os ciclos de desenvolvimento de software,
vem permitindo sua adoção nos mais diferentes contextos, inclusive servindo como base para
a estratégia de IC.
Portanto, este trabalho relata o processo de adoção da prática de IC utilizando software
livre pelo time de desenvolvimento da Fundação de Amparo a Pesquisa do Estado de Alagoas
- FAPEAL, procurando abordar seus conceitos e apresentar, qualitativamente, os benefícios de
sua utilização, objetivando contribuir com estudos empíricos relacionados à produtividade de
equipes de desenvolvimento de software.
2. Integração Contínua
A Integração Contínua é definida como um processo que realiza as tarefas de construção, teste,
análise e deploy de uma aplicação, para assegurar que a mesma funcione corretamente e siga
as melhores práticas [Kawalerowics and Berntson 2010]. Todo esse processo é executado a
cada modificação no código fonte e provê um feedback imediato ao time de desenvolvimento,
como será descrito em mais detalhes na seção 4.
Reunindo o que foi escrito por outros autores ([Fowler 2006], [Duval et al. 2007] e [Ka-
walerowics and Berntson 2010]), esta definição enfatiza que o processo de IC não se restringe
apenas a compilar sua aplicação, mas sim, junto a isso, rodar os testes, os analizadores e dis-
ponibilizar o software, de maneira que todo este processo seja automatizado e que ao seu final,
um mecanismo de feedback informe à equipe o status do projeto. É por isso que muitos autores
afirmam que a IC é o “gatilho” para outras definições, como Continuous Compilation [Saff and
Ernst 2004], Continuous Building [Kim et al. 2008], Continuous Testing [Saff and Ernst 2004],
Continuous Deployment [Duval et al. 2007], dentre outras.
De acordo com [Duval et al. 2007], num nível mais alto, a adoção de IC numa equipe de
desenvolvimento traz os seguintes valores:
• Redução de riscos: Dado que a integração, execução dos testes e inspeções são
feitas várias vezes ao dia, existe grande chance de descobrir um erro assim que o
mesmo é introduzido;
• Redução de processos manuais repetitivos: Atividades como, compilação de
código, integração de banco de dados, testar, inspecionar, disponibilizar e feedba-
ck são encorajadas a serem automatizadas o que torna cada tarefa muito menos
propensa a erros;
• Geração de software “implantável” a qualquer momento: Dado que o proces-
so roda da mesma maneira, em todo momento, ao final do ciclo da IC é gerado um
software funcional. O que ocorre a cada pequena mudança em algum artefato;
• Permite melhor visibilidade do projeto: A redução de suposições sobre o an-
damento do projeto ocorre de maneira natural, visto que a IC provê informações a
todo momento sobre recentes construções, métricas de qualidade entre outras;
• Estabelece maior confiança da equipe no produto: Em toda construção, a
equipe saberá que testes estarão rodando sobre o software e analisadores verifica-
rão aderência aos padrões estabelecidos, o que encoraja o time a realizar altera-
ções sempre que necessárias.
 18 Levando em consideração tais valores, observa-se que a adoção do processo de IC
complementa outras práticas do desenvolvimento de software, como a aderência aos padrões
XI Worshop sobre Software Livre
de código, refactoring e releases curtos, não importando se o projeto utiliza RUP [Sommerville
2007], XP [Teles 2004], SCRUM [Schwaber 2001], Crystal [Cockburn 2009], ou qualquer outra
metodologia.
3. Método de pesquisa
Este trabalho utilizou o método de pesquisa-ação, o qual é um método intervencionista, que
permite ao pesquisador testar hipóteses sobre o fenômeno de interesse implementando e aces-
sando as mudanças no cenário real [Lindgren et al. 2004].
Conforme [Stringer 1996], a pesquisa-ação compreende uma rotina composta por três
ações principais: observar, para reunir informações e construir um cenário; pensar, para ex-
plorar, analisar e interpretar os fatos; e agir, implementando e avaliando as ações. Tais ações
se refletem no contexto da FAPEAL, onde se fez necessário observar o ambiente e perceber os
problemas reais relacionados ao desenvolvimento de software, de modo a buscar e implantar
soluções, com o foco essencial de investigar a adoção da prática de IC utilizando ferramentas
livres pela equipe de desenvolvimento da Fundação.
A escolha dos sujeitos se fez de maneira intencional, estando constituída de 5 pessoas,
sendo 4 (quatro) desenvolvedores e 1 (um) designer, lotadas na Unidade Gestora de Tecnolo-
gia da Informação (UGTI) da FAPEAL, representando a equipe que utilizou as práticas de IC no
desenvolvimento de 1 (um) projeto. Assim, os dados primários da pesquisa foram coletados
por meio de exame dos artefatos do projeto, que é um método no qual o pesquisador examina
documentos, materiais e/ou artefatos, e registra os dados sobre instrumentos previamente pre-
parados. Por meio de exame dos artefatos do projeto, pôde-se constatar a melhoria ou não, na
qualidade do produto resultante e na velocidade de desenvolvimento imposta no projeto para
alcançar o produto final.
4. Implantação
Durante um período de 04 meses (Outubro de 2009 a Janeiro de 2010), buscou-se implantar
algumas técnicas de IC visando prover maior velocidade à equipe de desenvolvimento e maior
qualidade nos produtos apresentados, utilizando como base o projeto de um sistema para con-
trole financeiro da Fundação. Os membros da equipe de desenvolvimento já adotavam práticas
de algumas metodologias de desenvolvimento (Scrum e XP) como código coletivo, programa-
ção em par, reuniões diárias, releases curtas (02 semanas) etc., e procuraram adaptar-se para
a adoção de mais uma prática no dia-a-dia.
4.1. Ambiente de Desenvolvimento
Algumas ferramentas são essenciais para adoção da prática de IC. Seguindo o modelo
de migração para software livre adotado pela FAPEAL no início de 2009, procurou-se configurar
um ambiente 100% livre no que diz respeito às ferramentas utilizadas pelos desenvolvedores.
Tal modelo foi proposto, a princípio, com o objetivo de reduzir ou, se possível, eliminar os custos
com licenças de software, os quais eram responsáveis por cerca de 6, 5% do orçamento anual
da UGTI. A descrição das principais ferramentas utilizadas no processo de IC segue abaixo.
• Sistema de controle de versão (SCV): Seu propósito é gerenciar mudanças 19
no código fonte e outros artefatos (como documentação), provendo um ponto de
Integração Contínua com Software Livre: Um relato de implantação na Fundação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL
acesso único de acesso controlado ao repositório. Como se tratava de uma equipe
de desenvolvimento pequena e com experiência prévia na ferramenta, o SCV esco-
lhido foi o Subversion (SVN) [Collins-Sussman et al. 2008].
• Servidor de IC: Funciona como um gerenciador de atividades no processo de IC.
Começando pela verificação de mudanças no repositório de controle de versão e re-
cuperação dos artefatos, o servidor dispara scripts, como um script de Construção, e
tarefas numa ordem preestabelecida. Devido a facilidade de configuração, a ferramen-
ta escolhida para tal tarefa foi o Hudson, o qual possui integração com diversas ferra-
mentas de teste e feedback, e contém uma imensa gama de plugins disponíveis.
• Scripts de Construção: Também chamado de Gerenciador de Construção, consti-
tui de um simples script, ou conjunto do mesmo, que é usado para compilar, testar,
inspecionar e disponibilizar o software de maneira automatizada. Não foi utilizada
uma única ferramenta para esta fase do processo (como o Ant), mas sim diversos
scripts escritos em Python, que supriram as necessidades do projeto.
• Mecanismos de feedback: Não existe um mecanismo padrão para oferecer tal
recurso. Pode-se utilizar e-mails, SMS, Twitter, ou mesmo dispositivos físicos como
sirenes. Devido a integração do Hudson com o servidor de e-mail, mensagens so-
bre os status das construções, relatórios de inspeção e resultado dos testes eram
enviadas ao final de cada integração.
• Ferramentas de Teste: Não necessariamente uma ferramenta de IC, mas de
extrema importância para qualquer sistema. Para o projeto realizado na Fundação,
foram automatizados os testes unitários, com o uso de DocTests e PyUnit, e os tes-
tes funcionais, com o uso de um componente do framework web utilizado.
• Ferramentas de Análise de Código: Automatizar inspeção de código, para ve-
rificar, por exemplo, aderência as normas pré-estabelecidas, a complexidade ci-
clomática, modularidade, duplicação de código entre outras. Como a linguagem
de programação utilizada no projeto foi Python, o Pylint se mostrou um recurso
interessante para a análise estática de código, verificando a aderência aos padrões
especificados pela PEP0008 [Rossum 2001].
A tabela 1 apresenta as ferramentas utilizadas no ambiente de desenvolvimento.
Tabela 1. Ferramental utilizado no ambiente de desenvolvimento
Sistema de controle de versão Subversion (SVN) subversion.apache.org
Servidor de IC Hudson hudson-ci.org
Scripts de Construção Scripts Python python.org
Mecanismos de feedback E-mail www.postfix.org
Ferramentas de Teste DocTests e PyUnit pyunit.sourceforge.net
Ferramentas de Análise de Código Pylint www.logilab.org/857
4.2. Dia-a-dia da IC
No projeto realizado na Fundação, a adoção do processo de IC mudou a maneira
como alguns desenvolvedores se comportavam em relação ao código, pois os mesmos sa-
 20 biam que caso não realizassem os testes automatizados ou não aderissem aos padrões de
codificação, os relatórios gerados após cada integração mostrariam o problema. Isso gerou
XI Worshop sobre Software Livre
um certo desconforto por parte dos desenvolvedores no início do projeto, pois cada um
possuía um estilo próprio de codificar. No entanto, o número reduzido de pessoas e a práti-
ca de programação em par fez com que, rapidamente, a equipe se adequasse aos padrões
exigidos (PEP0008).
Assim, após inserir um novo trecho de código ou alterar algum existente, os desenvol-
vedores executavam os scripts de construção (compilação, teste e inspeção) localmente. Caso
não ocorressem problemas durante a construção local, cada desenvolvedor submetia os arte-
fatos inseridos/modificados/excluídos para o SCV. Em períodos pré-determinados, o servidor de
IC, utilizando o auxílio da ferramenta cron, verificava se havia ocorrido alguma alteração no
projeto. Tal período foi determinado calculando-se o tempo médio do intervalo entre commits
ao SCV, que era em torno de 20 minutos. Caso houvesse modificações, o servidor recuperava
todos os artefatos do projeto e iniciava a execução dos scripts de construção, dessa vez com
todos os componentes integrados. Ao final do processo, o servidor de IC enviava um e-mail com
informações sobre o status da construção a todos os desenvolvedores envolvidos no projeto,
deixando-os cientes do produto “final” obtido.
5. Resultados
No projeto realizado pela equipe de desenvolvimento da FAPEAL, vários benefícios foram encon-
trados com a adoção da prática de IC, dos quais podemos citar:
1. Maior confiabilidade na realização de alterações no código, dado a constante ins-
peção e testes realizados neste artefato;
2. Maior visibilidade do projeto como um todo, visto que os relatórios e a documen-
tação do projeto passaram a ser gerados automaticamente no processo de cons-
trução através de ferramentas como o Epydoc, Cobertura e plugins do SVN, como
o WebSVN e StatSVN;
3. Ganho de produtividade, dado que algumas tarefas manuais passaram a ser au-
tomatizadas, como a inserção de dados de teste na base de dados e o deploy do
projeto no ambiente de homologação, permitindo que os desenvolvedores se preo-
cupassem com as regras do negócio, de fato;
4. Aumento da qualidade do código, devido a presença de analizadores estáticos;
5. Maior estabilidade nos releases gerados, visto que os mesmos só eram entregues
caso se apresentassem completamente funcionais.
Apesar dos benefícios citados acima, algumas dificuldades foram encontradas durante
as fases de adoção e utilização das práticas de IC, como a definição de um modelo estrutural
que se adequasse a realidade do projeto, o processo de configuração inicial das ferramentas
utilizadas e a grande quantidade de construções que falharam no início do projeto.
6. Conclusões
Diante do que foi apresentado com o desenvolvimento deste trabalho, ficaram claras as vanta-
gens obtidas pela adoção da prática IC no desenvolvimento de software, pois esta se apresen-
tou como uma ferramenta que contribuiu para satisfazer às necessidades da Fundação no que 21
se refere à velocidade e qualidade da entrega do produto final do projeto.
Integração Contínua com Software Livre: Um relato de implantação na Fundação de Amparo a Pesquisa do Estado de Alagoas - FAPEAL
Vale a pena ressaltar que a utilização de ferramentas livres na estratégia de IC se fez de
suma importância, pois além de proporcionar as vantagens intrínsecas ao software livre, como
a redução de custos e o apoio ativo da comunidade, a utilização de ferramentas livres agrega
ainda mais aos valores que a IC traz aos projetos, aumentando o grau de confiança da equipe
sobre o produto final desenvolvido.
Como trabalho futuro, pretende-se continuar com a utilização da prática de IC no de-
senvolvimento de outros projetos internos à Fundação, a fim de se obter uma análise mais
detalhada dos resultados de sua adoção a partir do exame de um maior número de artefatos e
métricas de software para extração de dados mais formais.
Referências
Cockburn, A. (2009). Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-
Wesley, 1 edition.
Collins-Sussman, B., Pilato, C. M., and Fitzpatrick, B. W. (2008). Version control with subversion,
volume 4. O’Reilly Media, Inc.
Duval, P. M., Matyas, S., and Glover, A. (2007). Continuous Integration, volume 26. Addison-
Wesley.
Fowler, M. (2006). Continuous integration.
Kawalerowics, M. and Berntson, C. (2010). Continuous Integration in .NET. Manning.
Kim, S., Park, S., Yun, J., and Lee, Y. (2008). Automated Continuous Integration of Component-
Based Software: An Industrial Experience. 2008 23rd IEEE/ACM International Conference on
Automated Software Engineering, pages 423–426.
Lindgren, R., Henfridsson, O., and Schultze, U. (2004). Design principles for competence man-
agement systems: A synthesis of an action research study. MIS QUARTERLY, 28(3):435–472.
Rossum, G. V. (2001). Style guide for python code. http://www.python.org/dev/peps/pep-0008/.
Acessado em: Dezembro de 2009.
Saff, D. and Ernst, M. (2004). An experimental evaluation of continuous testing during develop-
ment. In Proceedings of the 2004 ACM SIGSOFT international symposium on Software testing
and analysis, page 85. ACM.
Schwaber, K. (2001). Agile Software Development with Scrum. Series in Agile Software Develop-
ment. Prentice Hall, 2 edition.
Sommerville, I. (2007). Engenharia de Software. Tradução de Selma Shin Shimizu Melnikoff. Ad-
dison Wesley, São Paulo, 8 edition.
Stringer, E. T. (1996). Action Research: A Handbook for Practitioners. Sage.
Teles, V. M. (2004). Extreme Programming: Aprenda como encantar seus usuários desenvolven-
do software com agilidade e alta qualidade. Novatec.
 22
XI Worshop sobre Software Livre
Processo Demoiselle: um processo livre para
desenvolvimento de software para e-Gov
Viviane Malheiros1, Ronaldo Agra1, Alisson Andrade1
1
Serpro – Serviço Federal de Processamento de Dados SGAN Quadra 601
Módulo V– Brasília – DF – Brasil
{viviane.malheiros, jose-ronaldo.souza, alisson-wilker.silva}@serpro.gov.br
Abstract. Process quality can significantly influence product quality. For most organiza-
tions, software development processes must be technologically competitive and adaptable and
must help generating products that consistently meet business and user requirements. This
scenario is not different when developing software solutions for the government. In this paper
we present the Demoiselle software development process, which integrates best practices of
agile methods and focuses in software architecture and anticipation of tests, that may be a
standard to developing software for the government.
Resumo. A qualidade do processo pode influenciar significativamente na qualidade
do produto final. Para a maioria das organizações, processos de desenvolvimento de software
devem ser tecnologicamente competitivos e adaptáveis e devem ajudar a gerar produtos que
atendam aos requisitos dos usuários e do negócio. Esse cenário não é diferente se o assunto
é o desenvolvimento de soluções para o governo. Neste artigo apresentamos o processo de
desenvolvimento Demoiselle, que integra boas práticas de métodos ágeis e possui foco em
arquitetura e em antecipação de testes, podendo ser utilizado como padrão para desenvolver
sistemas para o governo.
1. Introdução
A utilização de um processo de desenvolvimento de software possibilita gerir melhor um pro-
jeto de desenvolvimento de sistemas. Isso é possível porque os processos de desenvolvimento
orientam a equipe no cumprimento das metas do projeto. Adicionalmente, as discussões sobre
software e processos livres vêm ganhando espaço no mercado e na academia. A definição de
um processo livre pode beneficiar empresas e comunidades de desenvolvimento de software,
apresentando-se como uma forma mais barata de incorporar melhorias ao desenvolvimento.
Em paralelo a essas discussões, vários autores defendem que a qualidade do processo
de desenvolvimento pode favorecer a qualidade do produto final [Humphrey 1989]. Durante
os últimos anos vários esforços foram concentrados na definição e melhoria desse tipo de
processo; seja em metodologias mais focadas na agilidade como, por exemplo, o XP (Extreme
Programming) [Beck 1999], seja em processos mais formais, como é o caso do RUP (Rational
Unified Process) [IBM 2010]. Mais recentemente trabalhos que propõem o balanceamento
entre ambas as abordagens têm sido publicados, a exemplo de [Lindvall 2002].
Alinhado com a diretriz de governo para ampliar o uso de software livre foi criado o Pro-
jeto Demoiselle [Serpro 2010], cujo objetivo é promover: (i) o aumento da produtividade, por
meio, por exemplo, do reúso de software e do uso de técnicas ágeis; e (ii) a melhoria da quali- 23
dade, por meio do foco em testes e da utilização de componentes de software e de técnicas de
Processo Demoiselle: um processo livre para desenvolvimento de software para e-Gov
desenvolvimento consolidadas no mercado.
Este artigo apresenta o Processo Demoiselle, que é um subprojeto do Projeto Demoiselle.
O Processo Demoiselle define-se como um processo livre para desenvolvimento de software para
o governo, que busca mesclar as boas práticas dos métodos ágeis com as dos processos formais,
para auxiliar no desenvolvimento de software com mais qualidade.
Este artigo está estruturado da seguinte forma: a Seção 2 apresenta o Projeto Demoisel-
le; a Seção 3 apresenta o subprojeto Processo Demoiselle, que é o foco deste artigo; a Seção 4
apresenta a Comunidade Demoiselle; e a Seção 5 apresenta conclusões e trabalhos futuros.
2. O Projeto Demoiselle
O Projeto Demoiselle é ao mesmo tempo um produto e um processo livre que buscam promo-
ver o aumento da produtividade e da qualidade do desenvolvimento de sistemas Web em Java
para o governo. Por meio do estabelecimento de padrões abertos, o Projeto Demoiselle apóia o
desenvolvimento de aplicações operadas e/ou mantidas por órgãos da Administração Pública.
Sua manutenção e evolução são de responsabilidade da comunidade Demoiselle.
O Projeto Demoiselle pode ser agrupado em 3 temáticas: o framework, o processo e a
infraestrutura Demoiselle. O framework, desenvolvido em Java, propõe-se a integrar diversos
padrões abertos em uma única solução com o objetivo de prover uma base para a construção
de aplicações Web compatíveis com o padrão de interoperabilidade do governo (e-PING) [SLTI/
MP 2010]. O projeto de infraestrutura tem o objetivo de criar um ambiente de desenvolvimento
padrão e pré-configurado para os desenvolvedores de aplicações Web do governo federal. Por
fim, o Processo Demoiselle tem o objetivo de possibilitar a padronização do processo de desen-
volvimento dos sistemas de informação Web dos órgãos governamentais, utilizando o Framework
Demoiselle como arquitetura de referência. O processo Demoiselle é detalhado na Seção 3.
3. O Processo Demoiselle
O Processo Demoiselle é um processo livre para desenvolvimento de software para o governo
com o uso do Framework Demoiselle. Ele pode ser livremente utilizado, adaptado e redistribuí-
do. Sua construção está firmada sobre 5 princípios: simplicidade; liberdade; iteratividade; foco
em testes e arquitetura de software; e alinhamento com o Framework Demoiselle.
A simplicidade do Processo Demoiselle é um princípio que se traduz em documentação
e artefatos simples e suficientes para o desenvolvimento de um software com qualidade. Trata-
se, portanto, de produzir apenas a documentação e os artefatos necessários para atender as
expectativas do cliente. O foco está nas informações que devem ser armazenadas para uso
futuro e não no formato da documentação.
A liberdade do Processo Demoiselle refere-se à possibilidade de uso, adaptação e redistri-
buição deste sem restrições. Assim, qualquer pessoa ou grupo de pessoas que tiver interesse em
usar, adaptar ou redistribuir o Processo Demoiselle pode fazê-lo sem se preocupar com restrições
legais de autoria. Essa característica permite ao processo evoluir vislumbrando diferentes pers-
pectivas e necessidades, e ser enriquecido através das experiências de seus colaboradores.
O Processo Demoiselle indica o desenvolvimento iterativo, ou seja, o seu ciclo de vida é
particionado em intervalos de tempo (iterações), normalmente regulares e pequenos, que têm
 24 por objetivo o desenvolvimento de incrementos de software integráveis. Essa prática visa uma 25

maior facilidade de integração de código de software e validação dos artefatos por parte do
XI Worshop sobre Software Livre

Processo Demoiselle: um processo livre para desenvolvimento de software para e-Gov

cliente e, consequentemente, diminui os custos de integração e a probabilidade de insatisfação
do cliente com o produto final.
O foco em testes e arquitetura de software traduz-se em práticas como o desenvolvi-
mento orientado a testes (TDD - Test-Driven Development) [Ambler 2010a] e na execução de
validações e verificações ao longo do processo de desenvolvimento, a fim de aumentar a sua
qualidade desde o início. Além disso, o processo preza por uma modelagem de arquitetura refi-
nada, como forma de minimizar riscos e apoiar o desenvolvimento de sistemas escaláveis.
Por fim, o Processo Demoiselle é centrado no Framework Demoiselle. Isso implica que
as técnicas e métodos escolhidos são adequados às características do framework e o processo
faz referência direta aos seus componentes.
Em termos de estrutura, o Processo Demoiselle é baseado no meta-modelo SPEM1 e,
por isso, seu conteúdo está dividido em processo, elementos e orientações. A versão atual
do processo foi escrita com o apoio da ferramenta livre EPF Composer2. A documentação do
processo (apresentações, “código do processo”, canais de comunicação, histórico e a última
versão do processo publicada) está disponível para os interessados no sítio: http://demoiselle.
sourceforge.net/process. Figura 1: Ciclo de vida do Processo Demoiselle.

Poucas ações referentes ao desenvolvimento de processos livres foram detectadas,

sendo a mais concreta o OpenUP [Eclipse Foundation 2010]. Trata-se de um processo livre de
desenvolvimento de software que apresenta o princípio da iteratividade e a filosofia ágil, além
de ter foco na natureza colaborativa do desenvolvimento de software.
O Processo Demoiselle diferencia-se do OpenUP principalmente por possuir foco no desen-
volvimento de software para o governo, buscando contribuir para a padronização do desenvolvi-
mento de software nos órgãos governamentais. Essa característica pode contribuir para que as
empresas, em especial as de pequeno porte, possam desenvolver para o governo de uma forma
mais barata, incorporando melhorias ao desenvolvimento de software.
A diferença prática entre ambas é que a iteração de validação possui mais atividades de
garantia de qualidade, visto que sempre resulta na entrega de algum produto, resultando assim
em um momento de aproximação do cliente com a equipe de desenvolvimento. No caso de uma
iteração de desenvolvimento, os artefatos produzidos não são imediatamente validados com o
cliente, não necessitando então da presença deste. Podem ocorrer várias iterações de desen-
volvimento antes de uma iteração de validação. Essa decisão é tomada pelo gerente de projeto
em conjunto com o cliente, de acordo com a sua disponibilidade e a necessidade do negócio.

3.1. Visão Geral da Estrutura do Processo 3.2. As Disciplinas do Processo

O Processo Demoiselle mescla métodos ágeis com técnicas de processos mais
formais, como por exemplo o Processo Unificado, balanceando ambas as abordagens.
A estrutura e o ciclo de vida do Processo Demoiselle são apresentados na Figura 1.
O ciclo de vida do Processo Demoiselle está dividido em fases. São elas: Concepção,
Análise e Projeto, Construção e Encerramento. À medida que o projeto avança nas fases, as in-
certezas e, consequentemente, os riscos diminuem. Por outro lado, o valor agregado do projeto
aumenta para o cliente simultaneamente.
Por ser um processo voltado para o desenvolvimento de software para o governo, é pos-
sível que os projetos guiados pelo Processo Demoiselle se caracterizem por não possuir clientes
com alta disponibilidade. Por outro lado as metodologias ágeis indicam que a aproximação do
cliente durante o desenvolvimento do projeto é um grande benefício para o desenvolvimento do
software. Para resolver esse problema, o Processo Demoiselle utiliza a alternância de iterações de
desenvolvimento com iterações de validação [Ambler 2010b].
1
O meta-modelo SPEM (Software & Systems Process Engineering Meta-Model) [OMG 2010] é um conjunto de conceitos
e elementos, criados pelo OMG (Object Management Group), para representar processos de desenvolvimento de
sistemas de informação.
2
http://www.eclipse.org/epf/composer_dev_guide/
Uma disciplina consiste de um conjunto de atividades que têm em comum o relacio-
namento com uma área específica de conhecimento. A versão inicial do Processo Demoiselle
apresenta 4 disciplinas: modelagem, implementação, testes e gestão de projetos. As atividades
relacionadas com essas disciplinas são realizadas ao longo das iterações de cada fase, podendo
elas estar presentes em uma ou mais fases do processo. Além dessas disciplinas, atualmente a
comunidade está desenvolvendo a disciplina de Gestão de Configuração, a qual será publicada
na próxima versão do processo, e a próxima prevista é a de licenciamento.
A disciplina de Modelagem no Processo Demoiselle trata do levantamento das necessi-
dades e expectativas do cliente e do mapeamento destas em decisões arquiteturais do sistema
de informação a ser desenvolvido. Essa disciplina é composta, portanto, por atividades de aná-
lise e projeto de um sistema de informação.
Já a disciplina de Implementação trata da construção do sistema de informação especi-
ficado pelo cliente e tem foco no desenvolvimento iterativo e incremental. Suas atividades são
distribuídas em iterações, nas quais o sistema é desenvolvido e evoluído em funcionalidades
e estabilidade.
Outra disciplina trabalhada no Processo Demoiselle que contribui para a qualidade do
sistema produzido é a disciplina de Testes. Nesta disciplina é definido o conjunto de atividades
necessárias para o planejamento, o projeto e a execução dos testes do sistema. Essas ativida-
 26 des buscam assegurar que o produto gerado seja confiável e que corresponda aos requisitos no desenvolvimento para o governo. Além disso, a comunidade começa a discutir atividades 27

solicitados pelo cliente. relacionadas com a definição de licenças de produto para as aplicações do governo.
XI Worshop sobre Software Livre

Processo Demoiselle: um processo livre para desenvolvimento de software para e-Gov

Por fim, a disciplina de Gestão de Projetos trata da iniciação, do planejamento, da exe-
cução, do controle e do encerramento do projeto de desenvolvimento de sistemas. Um dos
principais objetivos dessa disciplina é garantir a criação e manutenção do sistema no prazo
estipulado e dentro do orçamento previsto. Uma característica desta disciplina é o fato dela ser
baseada em práticas ágeis e, portanto, focada em atividades e artefatos simples e úteis para a
gestão de um projeto que utiliza o Framework Demoiselle.
Apesar da definição das disciplinas no processo, ainda não foram estabelecidas fer-
ramentas que deem apoio à operacionalização das atividades destas disciplinas. Além disso,
sabe-se que a aceitação de um processo de desenvolvimento de software depende da compro-
vação de que o mesmo é eficiente. No Processo Demoiselle esta avaliação ainda não foi feita,
mas está prevista para acontecer ainda no ano de 2010. O processo será validado durante a
execução de projetos pilotos; inicialmente serão selecionados um ou mais projetos do SERPRO
e, em seguida, serão escolhidos outros projetos da Comunidade Demoiselle.

4. Comunidade Demoiselle
A construção do Projeto Demoiselle é fundamentada nos princípios da filosofia de liberdade da
comunidade de software livre. Por esse motivo, todos os seus subprojetos, inclusive o Processo
Demoiselle, podem ser usados, adaptados e redistribuídos segundo licenças livres, e contam
com a contribuição da comunidade interessada. Assim, além de consultar, utilizar, adaptar e
aprender com o projeto, a comunidade pode contribuir para sua evolução sugerindo melhorias
e participando das discussões sobre o projeto.
No caso específico do Processo Demoiselle, a comunidade também pode participar re-
portando uma inconsistência ou editando diretamente o processo, ajudando na documentação,
traduzindo, ou, simplesmente, relatando sua experiência de uso.
A participação da comunidade é extremamente importante, uma vez que as informa-
ções fornecidas por ela podem direcionar o desenvolvimento de um processo mais estável e
maduro. Para facilitar essa participação, foi criado o ambiente de colaboração que está dispo-
nível no sítio http://demoiselle.sourceforge.net. A partir desse ambiente é possível acessar os
arquivos do “código do processo”, submeter uma proposta de melhoria, participar de listas de
discussão e saber das últimas notícias.
5. Conclusão e Trabalhos Futuros
Referências
W. Humphrey (1989), Managing the software process, Addison Wesley Longman Publishing .
K. Beck (1999). Embracing change with extreme programming. Em IEEE Journal or Magazine,
v. 32, p. 70–77.
IBM (2010), “Rational Unified Process”, http://www-306.ibm.com/software/awdtools/rup/, Fever-
eiro.
M. Lindvall (2002), Agile Software Development, Addison Wesley.
Serpro (2010), “Projeto Demoiselle”, http:// demoiselle.sourceforge.net/, Abril. SLTI/MP (2010),
“e-PING - Padrões de Interoperabilidade de Governo Eletrônico”, http://www.governoeletroni-
co.gov.br/acoes-e-projetos/e-ping-padroes-deinteroperabilidade, Abril.
S. W. Ambler (2010a), “Introduction to Test Driven Design (TDD)”, http://www.agiledata.org/
essays/tdd.html, Maio.
Eclipse Foundation (2010), “OpenUP”, http://epf.eclipse.org/wikis/openup/, Maio.
OMG (2010), “SPEM - Software process engineering meta-model, version 2.0”, http://www.omg.
org/technology/documents/formal/spem.htm, Abril.
S. W. Ambler (2010b), “The Agile Unified Process”, http://www.ambysoft.com/unifiedprocess/
agileUP.html, Maio.

Este artigo apresentou o Processo Demoiselle, que é um processo livre que busca atender às es-
pecificidades do governo no que diz respeito ao desenvolvimento de aplicações Web para a Ad-
ministração Pública Direta e Indireta. Uma dessas especificidades é a orientação do governo em
relação ao uso de software livre pelos órgãos. Assim, o Processo Demoiselle define atividades
que têm o objetivo de (i) aumentar a produtividade e a qualidade no desenvolvimento dessas
aplicações, utilizando-se de técnicas e conceitos de métodos ágeis, como o desenvolvimento
orientado a testes e o reuso de componentes, e (ii) de orientar o desenvolvimento de soluções
livres, que inclui questões como definição da licença do produto.
O Processo Demoiselle faz parte do Projeto Demoiselle. Dentro desse projeto, o subpro-
jeto Framework Demoiselle define arquitetura, componentes e tecnologias para o desenvolvi-
mento das aplicações. Como um de seus princípios, o Processo Demoiselle se integra com o
Framework Demoiselle no sentido de orientar os desenvolvedores na utilização da arquitetura
e na escolha dos componentes do framework adequados à sua solução.
Atualmente, a comunidade do Processo Demoiselle está desenvolvendo a nova discipli-
na de Gestão de Configuração. O desafio dessa disciplina é integrar desenvolvimento ágil de
software livre com as necessidades mais formais de controle de configuração de sistemas que
serão mantidos por vários anos seguidos e por empresas diferentes, como é possível acontecer
 28
XI Worshop sobre Software Livre
Software Livre como Objetos de Aprendizagem
Generalizáveis do Projeto CONDIGITAL
Alexandre Direne, Diego Marczal, Jonatas Teixeira, Felipe Moreschi,
Danilo Picolotto, Derik Silva, Luan Santos, Raphael Andrade,Fernando Coelho,
Jorge Salvi, Gabriel Ramos, Andrey Pimentel
C3SL ­Depto de Informática – Universidade Federal do Paraná (UFPR)
Caixa Postal 15.064 – 81.531980 – Curitiba – PR – Brasil
{alexd,diego,jt08,fam08,dp08,ders08,lhrs08,rhfa08,fcc08,jorgels,andrey}@inf.ufpr.br
Abstract. This paper describes concepts and software tools aimed at supporting Maths
tutoring in Brazilian public schools. The context of Educational Technology applied here is ba-
sed on Free Software, allowing different computer-based Learning Objects to be produced by
general-purpose models. We describe details of the tools as well as the context of the CONDIGI-
TAL consortia built up by the Department of Education to carry out joint initiatives with research
and development institutions.
Resumo. O objeto central deste projeto de pesquisa e desenvolvimento é de utilizar o
estado-da-arte em termos de Tecnologia Educacional baseada em Software Livre e suas áreas
associadas para desenvolver novos Objetos de Aprendizagem e dar manutenção para as ferra-
mentas genéricas responsáveis pelo apoio computacional ao projeto nacional CONDIGITAL para
escolas públicas brasileiras que atuam no nível fundamental médio. A iniciativa é conduzida sob
a forma de convênios entre o MEC e membros de parceria
1. Introdução
O presente trabalho encontra-se inserido no projeto CONDIGITAL do grupo do estado do Paraná.
Este grupo é financiado pelo Fundo Nacional de Desenvolvimento da Educação (FNDE) por meio
do Edital 001/07 MEC/MCT. O projeto é uma iniciativa da Secretaria de Educação a Distância
(SEED) do Ministério da Educação (MEC) e do Ministério da Ciência e Tecnologia (MCT).
Na Universidade Federal do Paraná (UFPR), este projeto é realizado pelo C3SL (Centro
de Computação Científica e Software Livre) em parceria com o Instituto de Tecnologia para
o Desenvolvimento (LACTEC), o Centro de Excelência em tecnologia Educacional do Paraná
(CETEPAR) e a Universidade Estadual de Londrina (UEL). Um de seus objetivos principais é de
contribuir para a melhoria e a modernização dos processos de ensino e aprendizagem da área
de Matemática na rede de escolas públicas (e mesmo privadas).
Neste projeto estão sendo desenvolvidos quatro Objetos de Aprendizagem (OA), como
Software Livre para apoiar o ensino de matemática do nível médio. Os OA devem ser utilizados
para apoiar atividades laboratoriais nos seguintes domínios: (a) funções de primeiro grau com
exemplos sobre o coeficiente de elasticidade de molas e composições de roldanas móveis; (b)
progressões geométricas que ocorrem em elementos da geometria fractal; (c) funções cíclicas
ou trigonométricas, com exemplos sobre projeções de sombras e movimento de planetas no 29
espaço; (d) matemática financeira, com exemplos de jogos e desafios dependentes do cálculo
Software Livre como Objetos de Aprendizagem Generalizáveis do Projeto CONDIGITAL
de juros simples e compostos. Os dois primeiros já estão completamente implementados.
Cada um desses domínios compõe um OA. A abordagem arquitetural de todos eles é
baseada na existência de um núcleo comum de software, que é um arcabouço genérico cha-
mado de Controlador de Acesso Reflexivo e Retroativo Indexado por Erros (CARRIE). O presente
trabalho de pesquisa e desenvolvimento destinou-se prioritariamente (mas não exclusivamen-
te) ao desenvolvimento desse núcleo comum. O referido arcabouço genérico de acesso pode
ser aplicado em diversos OA de maneira reutilizável e reconfigurável, visando fornecer uma
maneira facilitada de desenvolver ambientes exploratórios de aprendizagem que facilitam seus
usuários a retroagir aos contextos do software onde um erro de solução de problema ocorreu.
Cabe ainda observar que o controlador de acesso tem mecanismos genéricos o suficiente para
ser utilizado não apenas em Matemática, mas também no apoio ao ensino e a aprendizagem de
conceitos em áreas como Física e Química.
Dessa forma, as principais contribuições deste trabalho para o projeto principal CON-
DIGITAL são: (a) a arquitetura genérica de Objetos de Aprendizagem; (b) acesso padronizado
a conteúdos educacionais por meio de tarefas reflexivas sobre domínios específicos (incluindo
a reflexão sobre erros cometidos no passado); (c) métricas de desenvolvimento de um OA que
facilitam a criação do mesmo. Todas essas contribuições foram alcançadas através do desen-
volvimento do CARRIE.
2. Hipóteses simplificadoras
Ainsworth aponta cinco fatores que devem ser considerados no projeto de um OA com múltiplas
representações externas. São eles: (a) o número de representações; (b) a maneira como a in-
formação está distribuída; (c) a forma das representações; (d) a sequência das representações;
(e) o suporte para a tradução entre as representações. Ao projetarmos um sistema baseado em
múltiplas representações externas, é preciso tomar decisões quanto a cada um desses fatores,
pois essas decisões terão impacto pedagógico.
Há basicamente quatro tarefas cognitivas envolvidas na manipulação de representa-
ções externas por parte de um aprendiz [Ainsworth, 2006]: (1) ele deve entender a forma da
representação; (2) cria intuitivamente a relação entre a representação e o domínio representa-
do; (3) escolhe uma representação apropriada entre várias disponíveis; (4) constrói uma nova
representação apropriada se for requisitada. Entender a forma de uma representação não é um
trabalho simples, pois envolve saber como a informação está codificada e quais operadores
pode-se aplicar a essa representação para manipular a informação que ela codifica. Por exem-
plo, em um gráfico cartesiano de uma função, a maneira de encontrar máximos e mínimos se
constitui em operadores para esse tipo de representação [Guizzadri et alli, 2003].
A atenção aos operadores é fundamental, pois não é incomum operadores para um tipo
de representação serem usados incongruentemente em representações de outro tipo. Quando
aprendizes são interpelados para selecionar um gráfico de velocidade versus tempo que repre-
senta um ciclista subindo e depois descendo um morro, eles deveriam escolher um gráfico com
o formato de U, mas geralmente eles optam por um gráfico com a curvatura invertida (i.e., com
a aparência do próprio morro). Nesses casos, operadores sobre figuras estão sendo usados er-
roneamente para interpretar o comportamento da curva do gráfico. Assim, entender a forma de
uma representação envolve aprender não só os seus operadores, mas também, em alguns casos,
aprender a ignorar o uso de operadores inapropriados para interpretar essa representação.
 30 A manipulação de representações envolve aprender também a relação entre a repre- um aluno do ensino médio, para dentro do software, eliminando a necessidade do aprendiz 31

sentação e o domínio representado, o que, para o aprendiz, pode ser mais difícil em virtude de de aprender outras representações matemáticas e permitindo que ele se concentre somente
XI Worshop sobre Software Livre

Software Livre como Objetos de Aprendizagem Generalizáveis do Projeto CONDIGITAL

ele deter um conhecimento parcial ou incompleto do domínio. Também aqui, a aprendizagem nos problemas sugeridos pelos sistemas tutores. O teclado virtual tem a capacidade de re-
dos operadores a serem empregados é fundamental, só que com um ajuste ainda mais fino. solver equações independentes de variáveis e exibir de forma atraente essas equações para
Mesmo já tendo percebido quais operadores são apropriados para a representação, o aprendiz o aprendiz.
ainda precisa aprender a relacionar operadores com entidades particulares do domínio repre- Durante o processo de construção ou correção de uma expressão o usuário poderá
sentado. Em um gráfico distância versus tempo, o aprendiz, tentando estimar a velocidade, navegar entre os números, operadores e símbolos através das setas direcionais do teclado, ou
geralmente examina a altura da curva, quando deveria olhar para a sua inclinação [Ainsworth, ainda posicionar o cursor de edição através de simples clique com o botão esquerdo do mouse
2006]. Ambos os operadores são apropriados para o gráfico, mas captam informações distintas na região desejável. Feito isso o aprendiz pode apagar aquilo que antecede ou procede a posi-
do domínio representado. ção do cursor utilizando as teclas backspace ou delete.
Por fim, aprendizes podem ser colocados na situação de construir uma representação
ao invés de interpretar uma [Feitosa et alli, 2007]. Essa é a tarefa de maior complexidade, pois
envolve as três tarefas anteriores de forma coordenada. O aprendiz precisa se familiarizar com
representações, operadores, os domínios representados e em como relacioná-los para construir
uma representação adequada. Ainsworth cita um estudo [Grossen e Carnine, 1990] que mostra
que crianças aprendem a resolver problemas lógicos de modo mais eficiente se elas desenha-
rem suas respostas dos problemas do que se elas selecionarem um diagrama pré-desenhado,
provavelmente devido ao suporte que o processo de construção da representação dá a essas
crianças.

3. Arquitetura geral

Para consolidar os fundamentos da aprendizagem adotados até então no presente projeto de

pesquisa e desenvolvimento, diversas ferramentas de software educacional estão sendo imple-
mentadas e validadas no ambientes escolar. A abordagem arquitetural de todas elas é baseada
na existência de um núcleo comum de software, o qual é um arcabouço chamado aqui de Con-
trolador de Acesso Reflexivo e Retroativo Indexado por Erros (CARRIE).
Já foram completamente implementados dois OA que fazem uso do arcabouço CARRIE,
sendo o primeiro para o domínio de Progressões Geométricas em Fractais e o segundo para o
domínio de Funções de Primeiro Grau. Atualmente, diversos esforços têm sido realizados para a Figura 1: Exemplo de uso da interface gráfica do Teclado Virtual
implementação de mais um OA que destina-se ao domínio da Matemática Financeira que tam-
bém faz uso do CARRIE. Um total de quatro softwares educacionais fará parte da fase inicial de
construção e aplicação de apoio computacional a atividades laboratoriais do ensino escolar de A Figura 1 mostra o TV ao término da construção da expressão o aluno deve submetê-la
conceitos matemáticos do nível médio. através de um botão de envio, ao fazer isso será feita uma análise automatizada com detecção
de erro na entrada dada pelo aprendiz, em caso de invalidade será fornecido um feedback para
o aprendiz alertando-o da invalidez de sua entrada e pedido que seja feita a adequação. Os
4. Principais módulos dos Objetos de Aprendizagem casos de invalidade são aqueles aonde, por exemplo, um denominador é zero.

Dentre muitas dezenas, devido ao seu caráter genérico, os dois principais módulos dos OA
desenvolvidos e aplicados na presente pesquisa são: (a) Teclado Virtual; (b) Interface com o
aprendiz. Os códigos-fonte de todos os softwares podem ser encontrados em todos os subdire-
tórios condigital do seguinte endereço: http://git.c3sl.ufpr.br/gitweb.
4.1. Teclado Virtual
A criação de forma atrativa e intuitiva de representação externa para expressões ma-
temáticas teve como base auxiliar o aprendiz. Trazendo aquilo que é prático e usual, para
4.4. Interface do aprendiz
Uma interface com o aprendiz é pré-estabelecida pelo CARRIE e está dividida em três
partes principais. A primeira é destinada ao título do OA, juntamente com o título da página
atual. Em seu canto superior direito, também estão as opções para aumentar e diminuir o ta-
manho das letras. A segunda parte é destinada ao domínio específico. A outra é reservada às
opções da dinâmica de controle oferecida ao aprendiz. Exemplos de tais controles são: paginar
para frente ou para trás, botão de acesso ao glossário, botão de acesso ao guia de retroação e
o botão de acesso ao bloco de anotações.
 32
XI Worshop sobre Software Livre
Figura 2: Exemplo de células de entrada de expressões
A Figura 2 mostra aspectos gráficos da interface em certo instante da interação com
o OA sobre força e deslocamento de molas. No quadro estão ressaltados como as constantes
elásticas das molas influenciam os gráficos das funções de primeiro grau de cada uma delas.
5. Conclusão e trabalhos futuros
O texto apresentou novos conceitos e ferramentas de software para apoiar o ensino e a aprendi-
zagem de conteúdos da disciplina de Matemática do nível médio escolar. Três linhas de pesqui-
sa foram tomadas como fundamentais para a criação dos modelos de solução: (a) arquiteturas
genéricas de Objetos de Aprendizagem; (b) Software Livre; (c) o uso de múltiplas representa-
ções externas para permitir a visualização contextual de dados sobre a solução de problemas.
Vários domínios da Matemática foram utilizados como campo de aplicação dos conceitos, por
meio dos quais um arcabouço de software mostrou seu amplo potencial de aplicação.
A partir deste ponto, novos estudos serão conduzidos para validar o modelo, integrando
os OA implementados em ambientes reais de atuação colaborativa dos laboratórios das escolas.
A ampliação da base de casos de problemas da Matemática deverá abrir novas possibilidades
de solução de problemas para aprendizes que utilizam simultaneamente os OA do arcabouço
deste trabalho. Isso, em princípio, tende a promover melhorias no desempenho dos usuários,
principalmente nos casos em que há interesse por aspectos reflexivos. Por exemplo, em Frac-
tais, o conceito de recursividade deverá evoluir para monitoramento passo-a-passo para que
um aprendiz possa não apenas retroceder a uma situação onde um erro ocorreu, mas também
obter explicações contextualizadas [Murray, 1999] sobre tais erros. Porém, para que isso seja
atingido em sua plenitude, será necessário expandir também a linguagem de representação
dos conteúdos com novos e mais avançados papéis complementares.
Referências 33
Software Livre como Objetos de Aprendizagem Generalizáveis do Projeto CONDIGITAL
Ainsworth, S. (2006). DefT – A conceptual framework for considering learning with multiple rep-
resentations. Learning and Instruction, 16 (3), 183198.
Alves, G. (2007). Um estudo sobre o desenvolvimento da visualização geométrica com o uso
do computador. Anais do XVIII Simpósio Brasileiro de Informática na Educação (SBIE), 312,
São Paulo/SP.
Bull, S., Kay, J. (2007). Student Models that Invite the Learner In: The SMILI Open Learner Model-
ling Framework. International Journal of Artificial Intelligence in Education, 17:(2), 89120.
Choua, C., Chanb, T., Linc, C. (2003). Redefining the learning companion: the past, present, and
future of educational agents. Computers & Education, 40 (3), 255–269.
Cox, R.; Stenning, K.; Oberlander, J. (1999) Contrasting the cognitive effects of graphical and
sentencial logic teaching: reasoning, representation and individual differences. Edingburgh:
Human Comunicate Research Center University of Edingburgh.
Feitosa, A., Direne, A., Silva, F., Bona, L., Guedes, A., Castilho, M., Sunye, M., Garcia, L. (2007).
Definição formal de táticas de Xadrez por meio da autoria incremental de conceitos heu-
rísticos. Anais do XVIII Simpósio Brasileiro de Informática na Educação (SBIE), 244253, São
Paulo – SP.
Gamma, E; Helm, R.; Johnson, R. and Vlissides, (2000), J. Padrões de Projeto: Soluções Reutilizá-
veis de Software Orientado a Objetos, Bookman.
Gava, T., Menezes, C. (2003). Uma ontologia de domínio para a aprendizagem colaborativa.
Anais do XIV Simpósio Brasileiro de Informática na Educação (SBIE), 355364, Rio.
Grossen, B., & Carnine, D. (1990). Diagramming a logic strategy e Effects on difficult problem
types and transfer. Learning Disability Quarterly, 13(3), 168182.
Guizzadri, R., Aroyo, L., Wagner, G. (2003). Help&Learn: A PeertoPeer Architecture to Support
Knowledge Management in Collaborative Learning Communities. Anais do XIV Simpósio Bra-
sileiro de Informática na Educação (SBIE), 285394, Rio.
Murray, T. (1999). Authoring intelligent tutoring systems: An analysis of the state of the art.
International Journal of Artificial Intelligence and Education, 10 (1), 98129.
Pressman, R. S. (2006), Engenharia de Software, McGrawHill, 6a. Edição.
Sá, E., Teixeira, J., Fernandes, C. (2007). Design de Atividades de Aprendizagem que usam Jogos
como princípio para Cooperação. Anais do XVIII Simpósio Brasileiro de Informática na Educa-
ção, (SBIE), 607616, São Paulo – SP.
 34
XI Worshop sobre Software Livre
Uso de software livre para gestão do serviço de
atendimento ao usuário de TI no INMETRO
Eduardo M. Abreu1, Sandra A. Dias2, Luiz C. Dalcorno2,
Fabiano D. Lanini2, Angela B. Albarello3
1
Apex-Brasil – Brasília, DF – Brasil
2
INMETRO – Rio de Janeiro, RJ – Brasil
3
Escola de Administração Fazendária (ESAF) – Brasília, DF – Brasil
eduardo.abreu@apexbrasil.com.br,{sdias,lcdalcorno,fdlanini}@inmetro.gov.br,
angela.albarello@fazenda.gov.br
Abstract. This article is a case study on the deployment of the free tool GLPI (Ges-
tionnaire Libre de Parc Informatique), in conjunction with the implementation process of
customer service to the user of IT in INMETRO, along the lines of Instruction nº 04/2008/
MPOG-SLTI. The text has the approach and justifies the new model for hiring the services of
Information Technology of the Brazil Federal Government. Also, it presents the process and
free software tools used for the case. Furthermore, as a benefit, identifies possible points
of improvement in GLPI with its functionalities and necessary for successful adoption of the
solution presented.
Resumo. Este artigo é um estudo de caso sobre a implantação do software livre GLPI
(Gestionnaire Libre de Parc Informatique), em conjunto com o processo de implantação do
serviço de atendimento ao usuário de TI no INMETRO, nos moldes da Instrução Normativa
nº 04/2008/MPOG-SLTI. O texto tem como abordagem e justificativa o novo modelo para
contratação de serviços de Tecnologia da Informação do governo federal, apresenta o pro-
cesso e as ferramentas de software livre utilizadas para o caso. Além disso, como benefício,
identifica-se possíveis pontos de melhoria no GLPI com suas funcionalidades utilizadas e
necessárias para o sucesso da adoção da solução apresentada.
1. Introdução
O uso de software livre no governo federal vem crescendo nos últimos anos, principalmen-
te após a criação de políticas públicas de incentivo. Alguns dos principais órgãos públicos
assumiram papel de líderes e diversos casos de sucesso foram divulgados recentemente.
Dentre as diversas soluções desenvolvidas, este artigo apresenta o caso de utilização de
uma ferramenta livre e os aspectos relacionados com a contratação de empresa terceirizada
para a prestação do serviço de atendimento ao usuário de Tecnologia da Informação (TI) no
INMETRO. Como característica importante deste caso, ressalta-se que a utilização do sof-
tware livre foi possível após a identificação de funcionalidades e mapeamento do processo
de trabalho para a contratação de uma empresa para prestação do serviço de atendimento
ao usuário de TI, conforme determinado na legislação vigente. Para isso, foi realizado o ma-
peamento do processo de atendimento ao usuário, ocorreu a definição de acordos de nível 35
de serviço e com a ferramenta livre obteve-se relatórios e estatísticas para controle. Espera-
Uso de software livre para gestão do serviço de atendimento ao usuário de TI no INMETRO
se que este estudo de caso seja usado como referência e motivação para a comunidade
de software livre e por outros órgãos do governo federal no desenvolvimento de soluções
embasadas nos mesmos conceitos apresentados.
O processo licitatório para escolha do novo fornecedor de serviços de atendimento
ao usuário de TI no INMETRO ocorreu nos moldes da Instrução Normativa nº
04/2008/MPOG-SLTI, em vigor desde 02 de janeiro de 2009. A seção seguinte resume
o cenário da solução apresentada. N a seção 3, o texto aborda aspectos relacionados com
o mapeamento do processo de atendimento ao usuário de TI. Posteriormente, na seção 4, é
apresentado o software livre GLPI e, finalmente, na seção 5, são apresentados os indicado-
res utilizados, os resultados alcançados e possibilidades de melhoria no GLPI.
2. Cenário
Criado pela Lei 5.966, de 11 de dezembro de 1973, o Instituto Nacional de Metrologia, Nor-
malização e Qualidade Industrial – INMETRO, é o órgão normativo do Sistema Nacional de
Metrologia, Normalização e Qualidade Industrial (Sinmetro) e também Secretaria Executiva
do Conselho Nacional de Metrologia, Normalização e Qualidade Industrial (Conmetro). “Sua
missão é prover confiança à sociedade brasileira nas medições e nos produtos, através da
metrologia e da avaliação da conformidade, promovendo a harmonização das relações de
consumo, a inovação e a competitividade do País.” (fonte: www.inmetro.gov.br/inmetro/
oque.asp, acessado em 30/05/2010).
Motivada pela Instrução Normativa da referência, a Coordenação-Geral de Tecnolo-
gia da Informação – CTINF preparou o termo de referência para contratação de uma empresa
para prestar o serviço de atendimento ao usuário de TI no INMETRO, denominado Service
Desk. A instrução normativa dispõe sobre as contratações de serviços de Tecnologia da In-
formação pelos órgãos e entidades integrantes do Sistema de Administração dos Recursos
de Informação e Informática – SISP. A realização dos serviços contratados abrange o Edifício
Sede, localizado no Rio de Janeiro – RJ e o campus de Xerém, localizado em Duque de Ca-
xias – RJ.
Assim, com o objetivo de melhorar o procedimento de atendimento aos usuários
de TI e ao mesmo tempo adequar à forma de contratação do serviço conforme preconiza
a instrução normativa da referência, durante o ano de 2009 realizou-se o mapeamento do
processo do serviço de atendimento ao usuário de TI, a licitação e contratação do referido
serviço, de forma que o mesmo viesse a atender as reais necessidades e expectativas do
INMETRO. Na próxima seção aborda-se esta etapa do trabalho realizado.
3. O mapeamento do processo de atendimento ao usuário de TI
As atividades de mapeamento do processo de atendimento ao usuário de TI foram realiza-
das em paralelo com o processo licitatório, de forma a permitir que a empresa vencedora
pudesse, antes de entrar em operação, conhecer os procedimentos necessários para atendi-
mento ao usuário. A figura 1 apresenta o resultado dessa etapa, onde é possível identificar
as interações entre usuário e níveis de atendimento.
 36
XI Worshop sobre Software Livre
Figura 1. Mapa de processos para o atendimento ao usuário de TI no INMETRO.
As principais atividades do processo e relacionadas com a ferramenta para registro de
atendimento são apresentadas a seguir. As demais atividades e seu detalhamento estão pre-
sentes no documento de mapeamento dos processos internos da CTINF/INMETRO.
• Abertura de chamado: é o ato ou tarefa de registrar um novo problema, que
deve ser realizado por meio telefônico ou e-mail.
• Entendimento e definição do cenário: descrever de forma simples e objetiva o
problema apresentado pelo usuário.
• Registro no sistema: é o ato ou tarefa de abrir um chamado, com atribuição au-
tomática de número de chamado, para o problema ou solicitação do usuário.
• Categorização do chamado: com base nas informações reportadas pelo usuário,
o responsável pela abertura do chamado deve identificar uma área e tipo de cha-
mado entre usuário comum e usuário VIP.
• Priorização do chamado: conforme previsto no termo de referência, o chamado
originado por usuário tipo VIP possui acordo de nível de serviço diferenciado e deve
ser priorizado.
• Documentação e atualização da Base de Conhecimento – BC: uma das obri-
gações da contratada é fornecer informações e alimentar a base de conhecimento.
A ferramenta usada deve fornecer esta funcionalidade.
• Controle de fechamento de chamado – CFC: todo chamado registrado e finalizado
deve ser incluído no relatório mensal para que seja efetuado seu pagamento. No caso dos
chamados com atendimento presencial, deverá ser recolhida assinatura do usuário.
O atendimento ao usuário de TI no INMETRO é realizado por meio de chamadas telefônicas
em ramal interno ou por e-mail, onde atendentes fazem sua triagem e atendimento de primeiro
nível. A partir disso, um chamado é registrado no software GLPI. Os técnicos cadastrados têm 37
acesso aos chamados abertos, onde os mesmos podem ser atribuídos de acordo com critérios
Uso de software livre para gestão do serviço de atendimento ao usuário de TI no INMETRO
ou grupos previamente estabelecidos. Estes critérios podem variar desde a proximidade com a
localização física do usuário ou problema, área de conhecimento ou disponibilidade do técnico.
Com o objetivo de adequar a metodologia de trabalho da CTINF com as modernas téc-
nicas de gestão de TI, buscou-se classificar os níveis de atendimento em N1 (atendimento re-
moto), N2 (atendimento no local) e N3 (problemas desconhecidos). Alinhado com as melhores
práticas de gestão de TI e no contexto do livro de suporte a serviços do ITIL, a central de serviço
tem a capacidade de realizar o gerenciamento de incidentes, gerenciamento de problemas e
gerenciamento de conhecimento. Com estes parâmetros é possível gerar relatórios que iden-
tifiquem o nível de maior incidência de atendimentos de forma a permitir que a gestão dos
serviços seja monitorada e aperfeiçoada.
4. GLPI
O software GLPI (Gestionnaire Libre de Parc Informatique – Gestão Livre de Parque de Informáti-
ca) é uma solução de fonte aberta para gestão de chamados de helpdesk, parque de hardware
e software disponibilizada em http://www.glpi-project.org, por meio da licença GPL (General
Public License), publicada pela Free Software Foundation. A Revista do Linux, em sua edição
nº 56, apresenta a matéria “Na ponta do dedo - Gerenciamento de Recursos com GLPI”, a qual
identifica a ferramenta GLPI como uma das disponíveis para a manutenção do controle sobre
os ativos de TI e suporte técnico. Outra ferramenta que pode ser usada em conjunto com GLPI
é o software livre OCS Inventory NG, o qual disponibiliza informações de inventário respeito
do parque computacional instalado e permite relacionar os equipamentos aos chamados em
atendimento. Utilizou-se neste cenário a versão 0.72.21 do GLPI em conjunto com as tecnolo-
gias Apache versão 2.2.12-1, Mysql versão 5.1, PHP versão 5.2.4 e Linux Ubuntu Server 9.10
(Karmic-Koala), kernel 2.6.31-14-server-SMP.
Após análise de ferramentas livres disponíveis, dentre elas: OcoMon (Sistema para hel-
pdesk, disponível em http://ocomonphp.sourceforge.net) e CACIC (Configurador Automático e
Coletor de Informações Computacionais, disponível em http://www.softwarepublico.gov.br), o
GLPI foi escolhido, pois apresenta funcionalidades mais próximas aos requisitos identificados e
ao modelo de processo mapeado. Além disso, permite integração com outra ferramenta livre
de inventário, o OCS Inventory NG (disponível em http://www.ocsinventory-ng.org). O GLPI está
configurado no idioma Português e com configurações direcionadas ao ambiente do INMETRO.
A tabela 1 identifica as principais funcionalidades do GLPI e o estado de sua aplicação no INME-
TRO. Todas as configurações foram implementadas através das funcionalidades da própria fer-
ramenta, ou seja, sem intervenção no código-fonte, exceto para a tela visualização de chamado
fechado, a qual contém um texto puro em seu rodapé a ser usado para assinatura do técnico
e do usuário no momento do fechamento dos chamados de atendimento presencial, que são
impressos e arquivados. A seguir, destacam-se os perfis de usuário configurados:
• Técnico: usado pelos usuários técnicos da empresa contratada. Tem a capacidade
de abrir e registrar chamados.
• Coordenador: usado pelo coordenador da empresa contratada. Tem a capacidade
de abrir, registrar e atribuir chamados, acessar relatórios e estatísticas.
• Supervisor: usado pelo(s) gestor(es) do contrato. Tem a capacidade de ler os cha-
mados registrados, acessar relatórios e estatísticas.
 38 Dentre os diversos relatórios gerados pela ferramenta, alguns indicadores apresentados 39
Tabela 1. Funcionalidades do GLPI e sua aplicação no INMETRO
nos relatórios são usados pelo gestor do contrato no INMETRO e pelo coordenador da empresa
XI Worshop sobre Software Livre

Uso de software livre para gestão do serviço de atendimento ao usuário de TI no INMETRO

Funcionalidade Descrição
Gestão de inventário Centraliza informações de hardware com base na
de hardware integração com a ferramenta inventário (OCS In-
ventory)
Gestão de inventário Permite o inventário de software e gerenciamento
de software de licenças e datas de término.
Permissões de acesso Com base nos perfis de usuário é possível permitir
acesso a funcionalidades com níveis de permissão.
Exportação de Permite exportação de relatórios do sistema e es-
informações tatísticas diversos formatos, como PDF.
Localização e centros de Associação dos equipamentos ou chamados por
custos áreas geográficas e departamentos.
Abertura e Permite a abertura de chamado por e-mail e pela
acompanhamento intranet, gerando um número único identificador
de chamados do chamado. Permite o acompanhamento de ati-
vidades, mudança de status e consulta de chama-
dos por status.
Emissão de Relatórios Geração de relatórios configurados por período e
específicos por técnico ou empresa, equipamento,
usuário, categoria de chamado, prioridade etc.
Reserva de itens Gestão de reservas de itens do inventário.
Base de Conhecimento Gestão de um ambiente de base de conhecimento
hierárquico e consulta à FAQ público.
Gestão de helpdesk Permite a atribuição dos chamados aos técnicos
ou grupo de técnicos, com acompanhamento dos
chamados e seus status. Registra o histórico das
intervenções realizadas pelo técnico em cada
chamado. Permite o registro de atendimento da
agenda do técnico para acompanhamento de
suas atividades.
Customização Permite a criação de categorias de chamados, de
perfis e grupos de usuários ou itens de menu.
INMETRO
prestadora do serviço. São eles: número de chamados abertos e número de chamados fecha-
Em desenvolvimento
dos; número de chamados por usuário e por técnico. Outras informações e relatórios não são
apresentados diretamente na ferramenta, e como sugestões de melhoria incluem-se: estatís-
Não ticas de chamados por nível de atendimento; estatísticas de chamados VIPs; estatísticas de
chamados por nível de severidade; estatísticas sobre a base de conhecimento; e, estatísticas
Sim sobre custos de atendimento. O serviço oferecido antes da referida licitação dispunha de ferra-
mentas proprietárias e limitadas para registro e acompanhamento dos chamados, dificultando
Sim desta forma a geração de relatórios e estatísticas de atendimento. Antes do uso do GLPI, não
era possível monitorar acordos de nível de serviço, localizar um chamado com número de regis-
Em desenvolvimento tro e também acompanhar um atendimento com seu histórico. Essa é, portanto, uma iniciativa
inovadora entre os órgãos de governo. O Instituto foi um dos pioneiros a adequar-se às novas
Sim diretivas da Secretaria de Logística e Tecnologia da informação (SLTI) do Ministério do Planeja-
mento, visando à melhoria da qualidade do serviço público com redução de custos.
Vale ressaltar a importância da capacidade de adaptação da ferramenta. Disponível na
linguagem PHP, o GLPI permite que os relatórios apontados sejam desenvolvidos, de forma a
Sim
fornecer os indicadores que o órgão necessita para a gestão do seu contrato. Esta atividade
está em desenvolvimento e futuramente deverá ser apresentada como contribuição para a
Não comunidade do software livre.
Sim Com este trabalho, conclui-se que o planejamento da contratação deve ser alinhado
com a estratégia organizacional e centrado no conceito da solução de TI adotada. O modelo do
Sim processo de atendimento ao usuário e a ferramenta usada necessitam estar em plena conformi-
dade. Todo o processo de contratação deve ser baseado em fases, papéis, responsabilidades e
documentos de apoio alinhados com as normas e práticas de Governança de TI. A contratação
do atual serviço é baseada em resultados, uma vez que o uso da ferramenta GLPI no INMETRO
possibilitou o controle dos atendimentos realizados, por meio de relatórios e estatísticas de
atendimento.
Sim

Referências
5. Indicadores, resultados alcançados e possibilidades de
melhoria Gestionnaire Libre de Parc Informatique – GLPI. Disponível em http://www.glpiproject.org. Aces-
sado em 15/08/2009.
Com o objetivo reduzir o tempo de atendimento e melhorar a produtividade do serviço presta- Brasil. Ministério do Planejamento, Orçamento e Gestão. Sec. de Logística e Tecnologia da Infor-
do, o INMETRO obteve sucesso usando os indicadores presentes na tabela 2. mação (MPOG-SLTI). Instrução Normativa nº 04/2008, de 19/05/2008.
Control Objectives for Information and related Technology (COBIT). Management Guidelines. IT
Governance Institute. 2000.
Tabela 2. Indicadores para acordo de nível de serviço Indicador Descrição Controles
IT Infraestructure Library (ITIL). Planning to Implement Service Management. Office Of Govern-
Tempo de espera para Tempo decorrido entre a abertura do No atendimento presencial não deve
atendimento chamado e o início do atendimento. ser maior que 1 hora. ment Commerce – OGC. 2002.
PRODROMOU, EVELTHON. “Na ponta do dedo - Gerenciamento de Recursos com GLPI”. Revista
Tempo de atendimento Tempo médio decorrido desde o início Não deve ser maior que 3,5 horas
do atendimento até o fechamento do Linux Magazine nº 56, São Paulo, p. 36, julho, 2009.
chamado, considerando o tempo de
diagnóstico e tempo de resolução.
Número de recorrências Número de reabertura de chamados Não deve ser maior que 5% do total
de chamados no mês.
Número de roteiros de Número de novos roteiros de atendi- Não deve ser inferior a 5% do total de
atendimento criados mento criados pela equipe do 3º nível atendimentos mensais, até que 96%
de atendimento. dos atendimentos tenham roteiro as-
sociado.
 41

Sessão II
Banco de Dados

42 Implementing a modern API for CDS/ISIS, a classic se-

mistructured NoSQL database

Luciano Ramalho (BIREME/OPAS/OMS)

48 pgGrid: uma Implementação de Fragmentação de Dados

para o PostgreSQL

Gustavo Tonini (UFSC), Frank Siqueira (UFSC)

54 SatBudgets: Projeto Conceitual de Satélites Baseado

em Conhecimento e Dirigida a Modelos

Bruno Leonor (INPE-CPTEC), Walter Abrahão dos Santos (INPE),

Stephan Stephany (INPE)

60 Setfon: Sistema Open Source para produção e organiza-

ção de Semioetiquetas Fonológicas

Ana Matte (UFMG), Rubens Takiguti Ribeiro (UFLA)

 42
XI Worshop sobre Software Livre
Implementing a modern API for CDS/ISIS,
a classic semistructured NoSQL database
Luciano G. S. Ramalho
Departamento de Biblioteconomia e Documentação, Escola de Comunicações e Artes
Universidade de São Paulo – São Paulo, SP – Brazil
BIREME/PAHO/WHO, Latin-American and Caribbean Center on Health Sciences Information
luciano.ramalho@bireme.org
Abstract. CDS/ISIS is a family of semistructured, “NoSQL” database products created by
Unesco and used at the SciELO digital library as well as thousands of academic libraries since
the 1980s. This paper describes how a database-independent API is being developed to allow
the LILACS bibliographic methodology created by BIREME to be implemented over CDS/ISIS and
modern semistructured databases such as MongoDB and CouchDB.
1. Introduction
Much of the data on the Web is organized in hierarchies and is multimedia in nature, therefore
consisting of several parts that nevertheless must be treated as a unified whole. Modeling such
data in normalized relational databases is difficult, and may result in performance problems due
to the cost of joins. De-normalization and horizontal scaling help meet the scalability challen-
ges of the Web, but are non-trivial to implement on relational databases originally designed to
enforce consistency at all times [Eure, 2009]. These issues have prompted renewed interest in
non-relational databases, collectively known since 2009 by the informal “NoSQL” term.
Apache Cassandra, Redis, Apache CouchDB and MongoDB are some examples of Open
Source NoSQL databases. Cassandra was created by Facebook and is also used by Twitter and
Digg. Two large-scale deployments of proprietary NoSQL databases are BigTable, by Google,
and Dynamo by Amazon.com, used by its S3 storage web service.
While most NoSQL products mentioned have been released in the past 10 years, CDS/
ISIS is a non-relational database created by Unesco in the 1960s, ported to PC/DOS microcom-
puters in the 1980s and then to the Windows and Linux operating systems. Today it is used by
thousands of libraries to run their on-line catalogs.
The C language port of CDS/ISIS for Linux and Windows, called CISIS, is used to run two
of the largest on-line digital libraries in Latin America, LILACS1 and SciELO2, and is deployed in
hundreds of cooperating scientific information centers, handling more than 18 million bibliogra-
phic records. CISIS was developed and is maintained, since the early 1990s, by BIREME/PAHO/
WHO, the Latin American and Caribbean Center on Health Sciences Information, a specialized
LILACS: Latin American and Caribbean Literature in Health Sciences), part of the Virtual Health Library coordinated by
1 3
BIREME/PAHO/WHO
SciELO: Scientific Electronic Library Online), a partnership between FAPESP, CNPq, FapUNIFESP and BIREME/PAHO/WHO
2 5
center of the Pan American Health Organization/World Health Organization, located in São Pau- 43
lo, Brazil, at the main UNIFESP3 campus.
Implementing a modern API for CDS/ISIS, a classic semistructured NoSQL database
2. The data model of CDS/ISIS
Beyond the informal NoSQL descriptor, CDS/ISIS is more precisely described as a docu-
ment database implementing the data model of the ISO-2709 Format for Information Exchange
standard, which in turn reflects the data model of the Library of Congress MARC4 format for the
representation of bibliographic records.
2.1. Relaxing the restrictions of the First Normal Form
MARC fields can be multivalued and composite. Therefore, the MARC data model viola-
tes the First Normal Form (1NF) atomicity requirement: “values in the domains on which each
relation is defined are required to be atomic with respect to the DBMS” [Codd, 1990]. Relaxing
the 1NF atomicity requirement greatly simplifies the development of bibliographic databases
and the exchange of records among libraries.
[...] it is interesting to note the absurdity of the NRM [Normalized Relational
Model]: if a book has 3 authors and 5 subjects, it will be necessary to represent
it in the NRM through a row in the Books table, plus 3 rows in the AuthorNames
(which would implement the corresponding multivalued attribute) and another
5 in the Subjects, for a total of 9 rows in three separate tables […] yet what we
hold in our hands in the real world is just one book [...] [Setzer, 2005] 5
2.2. The semistructured data model
In the database theory literature, the data model most similar to the CDS/ISIS database
structure is the semistructured data model [Abiteboul, 1999].
The semi-structured data model is designed as an evolution of the relational data
model that allows the representation of data with a flexible structure. Some items
may have missing attributes, others may have extra attributes, some items may
have two ore more occurrences of the same attribute. The type of an attribute is
also flexible: it may be an atomic value or it may be another record or collection.
Moreover, collections may be heterogeneous, i.e., they may contain items with
different structures. The semi-structured data model is a self-describing data mo-
del, in which the data values and the schema components co-exist. [Liu, 2009]
In a CDS/ISIS record, fields are identified by numeric tags from 1 to 32767. The meaning
of each numeric tag is defined by the application. For instance, in the LILACS methodology,
field 10 is Author and field 12 is Title. The fact that each field occurrence is preceded by its tag
number means that fields may be omitted or repeated as needed.
Universidade Federal de São Paulo
4
MAchine-Readable Cataloging
Translated from the Brazilian Portuguese book by Valdemar Setzer “Bancos de dados” (1st ed., 2005)
 44 Multivalued attributes are represented by repeating field tags. In LILACS, field 10 (Au-
thor) may be repeated, and field 12 (Title) may be repeated if the title is available in multiple
XI Worshop sobre Software Livre
languages.
2.3. CDS/ISIS data model limitations
CDS/ISIS has restrictions that are not in the general semistructured data model:
1. There is only one level of nesting: fields may contain subfields but subfields may
not contain sub-subfields;
2. Subfields must be labeled from A to Z and from 0 to 9, therefore a field can only
contain 36 subfields;
In addition to the 36 subfields, a field may have content that is outside of any subfield.
Because the syntax for delimiting subfields uses only one marker at the start of the subfield,
data outside of the subfields must appear before the first subfield.
10 «Lewis Carroll^1USP^2ECA^pBrasil^cSão Paulo^rEditor»
Figure 1: Sample of an author field (10) showing subfields labeled “1”, “2”, “p”, “c” and “r”. The
“p” subfield describes the country of the author, in this case “Brasil”. The name of the author,
“Lewis Carroll” is not preceded by a subfield delimiter, therefore is not part of any subfield.
2.4. Schema definition in CDS/ISIS
Like all semistructured databases, CDS/ISIS is “schemaless” in the sense that a data-
base instance does not have a predefined schema. But in practice, CDS/ISIS databases usually
have at least a documented, human-readable schema, describing the semantics of each field
tag, and defining which field tags are mandatory or repeatable and the subfields that may
be used inside each field tag. A rich example of such a schema is the LILACS Data Dictionary
[BIREME, 2008]. Some CDS/ISIS applications, like WinISIS and ABCD, allow the user to define a
schema in a Field Definition Table (FDT), which is used to generate data entry forms.
2.5. Handling fields and subfields in the ISIS Formatting Language (IFL)
The CDS/ISIS family has a data extraction language called the “Formatting Language”,
henceforth the IFL. The IFL is used primarily to generate displays and reports of database recor-
ds and to generate indexes supporting efficient retrieval.
Table 1: Examples of ISIS Formatting Language expressions
IFL expression Result Comment
v10[1] Lewis Carroll^1USP^2ECA^ first occurrence of field tag 10
pBrasil^cSãoPaulo^rEditor
v10^p[1] Brasil content of p subfield in first occurrence of field tag 10
v10^p[1]*0.3 Bra substring starting at offset zero with length 3 of p
subfield in field tag 10
The IFL is flexible but its syntax is terse. Readability is also hindered by the fact that field 45
tags are always numeric, subfield labels are limited to one alphanumeric character, and the
Implementing a modern API for CDS/ISIS, a classic semistructured NoSQL database
language lacks abstraction mechanisms to allow the user to define functions or assign friendlier
identifiers to expression results.
3. ISIS-DM, a modern API for schema definition and access
In 2007, BIREME/PAHO/WHO started the development of the ISIS Network Based Platform (ISIS-
NBP) project [BIREME, 2010], which aims to re-implement the functionality of CISIS in the Python
programming language using a service oriented architecture. ISIS-NBP is free software, distribu-
ted under the GNU General Public License. Most of the effort from 2007 to 2009 was devoted to
the CISIS binary-compatible storage layer and the Formatting Language interpreter.
A recent development within ISIS-NBP is ISIS-DM, the ISIS Data Model application pro-
gramming interface. The ISIS-DM effort aims to provide an API for:
1. Schema definition through classes, similar to modern object persistence fra-
meworks;
2. Data extraction using operators and methods similar to modern collection and
string handling APIs;
In other words, the goal is to allow programmers to express constraints and functionality
similar to those of the CDS/ISIS Field Definition Table and the CDS/ISIS Formatting Language, but
in contemporary, object-oriented programming languages.
The API aims to be database-independent. Objects defined in the ISIS-DM should be
easily persisted in CDS/ISIS and other semistructured databases.
3.1. Schema definition
Listing 1 shows an example of a very simple ISIS-DM schema definition in Python. A
schema called Book is being defined as a subclass of CheckedModel, an ISIS-DM class which
implements schema constraints and validation. Field types are implemented as
Python descriptors, which control instance attribute access.
Listing 1: Simple schema definition showing required and repeatable fields.
Non-repeatable string fields are instances of SingularProperty; repeatable fields are ins-
tances of PluralProperty. Both types may have subfields, which are always optional. The API
checks whether subfields entered match those in the field definition. Internally, string data is
converted to instances of a CompositeField class which implements several subfield access
methods and operators, including iterators over the subfield keys and values.
A NumberProperty is non-repeatable and may only contain integers or floatingpoint
numbers. For any type of property, a validator function may be specified, returning an error
message when the field value fails a test.
 46
XI Worshop sobre Software Livre
Listing 2: Instance creation and attribute access. Fields may be handled as a whole
or by subfield, output is formatted with the Python % formatting operator.
The CheckedModel.check instance method verifies the presence of required fields (see
listing 3). It returns a dictionary of attribute names and error messages, useful for displaying in
Web or GUI forms. Validator functions are applied upon instance creation or attribute change,
and generate exceptions with custom messages.
Listing 3: Demonstration of .check method and validator functions.
4. Conclusion
4.1. Lessons learned
Using modern language features such as metaclasses, operator overloading and object
properties (Python descriptors), part of the functionality of the CDS/ISIS Field Definition Table
and of the Formatting Language was implemented in less than 700 lines of code, including auto-
mated tests (doctests), in the isisdm.properties package composed of three Python modules.6
6
Source code available at the BIREME/PAHO/WHO RedDes public repository: http://reddes.bvsalud.org/projects/isisnbp/
browser/isisdm/properties or via http://bit.ly/isisdmrepo
The CheckedModel class and the various property classes provide a means of defining 47
the schema and validating records in a way that will allow automatic generation of data en-
Implementing a modern API for CDS/ISIS, a classic semistructured NoSQL database
try forms. To allow ordered retrieval of field definitions it was necessary to define a special
metaclass for an OrderedModel, which collaborates with an OrderedProperty descriptor class.
OrderedModel is the superclass of CheckedModel, and OrderedProperty is the superclass of all
properties shown here.
Besides the functionality shown here, features already implemented include:
• Controlled-vocabulary checking via lists provided at field definition;
• Alternate syntaxes to access subfields defined with numeric keys;
• Various iterators for flexible field and subfield access;
The CDS/ISIS Formatting Language implements both presentation and data extraction
functions. Many of its presentation features were designed for fixed width displays with mo-
nospaced fonts, while today all CISIS applications in production at BIREME/ PAHO/WHO use a
Web interface where those formatting assumptions are no longer valid. On the other hand, the
richer data extraction API made possible with Python and other modern languages allow more
convenient handling of fields and subfields in the presentation layer, where sometimes data will
be rendered directly as HTML elements and other times as JSON or XML for delivery and display
via Ajax.
4.2. Future work
The ISIS-DM API aims to be language-independent. The current implementation is in
Python, but a PHP version would be valuable, because of its popularity and its use in current
BIREME/PAHO/WHO systems which are widely distributed. Also, storage drivers should be deve-
loped for ISIS-NBP, CISIS, and at least a couple of the most popular semistructured databases,
such as Cassandra, CouchDB, MongoDB and Google Datastore. The CouchDB implementation
is planned as part of a graduation monograph for a bachelors degree in Library Sciences which
the author is currently working on.
References
Abiteboul, S.; Buneman P.; Suciu, D. (1999), Data on the web: from relations to semistructured
data and XML, San Francisco: Morgan Kaufmann, 1999.
BIREME (2008), Diccionario de datos del modelo LILACS Versión 1.6a , São Paulo: BIREME/PAHO/
WHO, 2008.
BIREME (2010), ISIS-NBP Project Repository, São Paulo: BIREME/PAHO/WHO http://reddes.bvsa-
lud.org/projects/isisnbp/, accessed June 2010.
Codd, E. F. (1990) The Relational Model for Database Management Version 2, Reading, MA:
Addison-Wesley, 1990.
Eure, I. (2009) “Looking to the future with Cassandra”, In: Digg Technology Blog http://about.
digg.com/blog/looking-future-cassandra, September 9, 2009.
Liu, L.; Özsu, M. T. (2009) Encyclopedia of database systems : Springer, 2009
Setzer, V.; Corrêa da Silva, F. (2005) “Bancos de dados aprenda o que são, melhore seu conhe-
cimento, construa os seus”, 1ª ed. São Paulo: Edgard Blücher, 2005.
 48
XI Worshop sobre Software Livre
pgGrid: uma Implementação de Fragmentação
de Dados para o PostgreSQL
Gustavo A. Tonini, Frank Siqueira
Departamento de Informática e Estatística – Universidade Federal
de Santa Catarina Florianópolis – SC – Brasil
gustavotonini@gmail.com, frank@inf.ufsc.br
Abstract. As an organization grows, it needs to store great amounts of data and or-
ganize them in a way that allows its recovery. The goal of pgGrid is to offer an extension to
PostgreSQL database management system (DBMS) that allows data fragmentation and distribu-
tion in the most convenient form among multiple database servers. It was necessary to modify
the “pgcluster” tool to manage data location and to optimize distributed queries. Moreover,
an extension to the data definition language (DDL) was proposed to define data distribution
parameters and distributed system’s topology.
Resumo. À medida que as organizações crescem, também cresce a necessidade de
armazenar grandes massas de dados e organizá-los de uma forma que favoreça sua recupe-
ração. A proposta deste trabalho é oferecer uma extensão ao sistema gerenciador de banco
de dados (SGBD) PostgreSQL que permita a fragmentação e a distribuição dos dados da forma
mais conveniente em vários servidores de banco de dados. Para isso foi necessário modificar a
ferramenta ‘’pgcluster’’ a fim de gerenciar a localização dos dados no sistema distribuído e oti-
mizar as consultas. Além disso, foi proposta uma extensão à linguagem de definição de dados
(DDL) para a definição dos parâmetros da distribuição dos dados e dos ‘’sítios’’ que formam o
sistema de banco de dados distribuído (SBDD).
1. Introdução
Nos primórdios da computação, todo processamento era realizado de forma centralizada. Com
o passar dos anos foi-se notando o potencial que as características dos sistemas distribuídos
proporcionam. Sistemas de banco de dados distribuídos são sistemas distribuídos que armaze-
nam, manipulam e organizam dados.
De acordo com [Ozsu 1999], as principais promessas e características dos sistemas de
banco de dados distribuídos são:
• Administração transparente dos dados fragmentados nas máquinas que compõem
o sistema;
• Melhoria no desempenho das consultas, através da paralelização das mesmas e de
outras estratégias de otimização; e
• Fácil expansão e boa escalabilidade do sistema.
Muitos gerenciadores de banco de dados relacionais proprietários possuem funções re-
lativas a sistemas deste tipo, podendo-se destacar: Oracle Database, Microsoft SQL Server e 49
IBM DB2 [Bedoya 2001]. No entanto, existem poucas implementações disponíveis para uso no
pgGrid: uma Implementação de Fragmentação de Dados para o PostgreSQL
âmbito do software livre.
O presente artigo apresenta a implementação de uma extensão para o SGBD PostgreS-
QL que adiciona suporte para fragmentação e replicação de dados.
O trabalho está dividido em seis seções. As seções dois e três apresentam o pgGrid e
detalham seu funcionamento. A quarta seção faz um comparativo com outras implementações
disponíveis no mercado e as duas seções finais apresentam um caso de uso e os testes de de-
sempenho realizados sobre o mesmo.
2. PostgreSQL e pgCluster
PostgreSQL é um sistema gerenciador de banco de dados de código-fonte aberto, multiplata-
forma, com mais de 15 anos de desenvolvimento. Segue o padrão SQL99 e seu gerenciador
de transações garante as propriedades atomicidade, consistência, isolamento e durabilidade
(ACID) [PostgreSQL 2009].
Dentre uma gama enorme de SGBDs relacionais e objeto-relacionais disponíveis no mer-
cado, o PostgreSQL se sobressai devido à sua aceitação pela comunidade de software livre
mundial, estabilidade e aderência ao padrão SQL.
O pgCluster é uma extensão do PostgreSQL que fornece replicação síncrona dos dados.
A ferramenta possui duas funções principais:
• Balanceamento de carga: Um módulo recepciona os comandos de consulta e
transações e os distribui da forma mais conveniente, levando em consideração a
carga (capacidade de processamento comprometida) dos servidores.
• Alta disponibilidade: É garantida através da replicação total dos dados; assim,
se um servidor falha, os demais podem responder em seu lugar, desde que pelo
menos um servidor de replicação continue no ar.
Conforme se pode facilmente perceber, o maior problema do pgCluster é a falta das
funcionalidades de fragmentação, que exigem que o usuário replique totalmente as bases de
dados para que o sistema funcione, degradando o desempenho e também desperdiçando re-
cursos do sistema.
3. Extensões propostas ao pgCluster
Fragmentar os dados é uma necessidade básica na maioria dos ambientes distribuídos [Ozsu
1999]. Com este propósito, o pgGrid adiciona funções de fragmentação para o pgCluster e
fornece comandos, como uma extensão à DDL, para definição dos fragmentos e alocação dos
mesmos nos servidores. Três grupos de instruções especiais foram adicionados à gramática:
• Adição e exclusão de servidores no sistema (CREATE SERVER);
• Definição de fragmentos (CREATE FRAGMENT);
• Alocação de fragmentos nos servidores (PLACE);
A Figura 1 apresenta alguns exemplos de uso dos comandos adicionados.
 50 Os gerenciadores avaliados foram: MySQL [MySql AB 2007], Oracle Database [Gopa- 51
CREATE SERVER “site1” HOST “inf.ufsc.br” PORT 5432 RECOVERY PORT 7000;
CREATE FRAGMENT cliente_pessoa_fisica ON CLIENTE (cod_cliente, nm_cliente) where lakrishnan 2006] e IBM DB2 [Bedoya 2001]. A avaliação foi realizada segundo alguns critérios
XI Worshop sobre Software Livre

pgGrid: uma Implementação de Fragmentação de Dados para o PostgreSQL

tipo_pessoa = ‘F’; relevantes para a manutenção de um sistema de banco de dados distribuído, de uma forma
CREATE FRAGMENT cliente_filial1 ON CLIENTE where cod_filial = 1;
PLACE cliente_pessoa_fisica ON site1; comparativa com o pgGrid, tais como sincronismo (as operações devem, obrigatoriamente, ser
realizadas em todos os sites logo após à solicitação) e assincronismo (as operações podem ser
Figura 1. Exemplo de uso dos comandos de definição do cluster realizadas em outro momento em alguns dos servidores).
A Tabela 1 lista os critérios escolhidos e a avaliação de cada produto quanto à compa-
As informações definidas nos comandos supracitados ficam armazenadas nos catálogos tibilidade com o mesmo.
do sistema. Quatro catálogos foram adicionados com este propósito:
Tabela 1. Comparativo entre as tecnologias de BDD
pg_grid_site, pg_grid_fragment, pg_grid_fragment_attribute e pg_grid_allocation;
Característica MySQL Oracle IBM DB2 pgGrid
Depois que os parâmetros foram definidos, o pgGrid mantém os servidores sincroniza- Consultas distribuídas Sim Sim Sim Sim
dos, garantindo as regras de fragmentação explicitadas pelo administrador. Tecnologia multi-mestre Sim Sim Sim Sim
Sites e fragmentos podem ser definidos e alocados a qualquer momento, sem a neces- Replicação parcial Não Sim Sim Sim
sidade de interrupção do funcionamento do sistema. Tal característica provê a escalabilidade
Replicação síncrona Sim Sim Sim Sim
necessária para aplicações reais.
Replicação assíncrona Não Sim Não Não
As próximas seções explicam brevemente como o pgGrid trata os comandos de manipu-
lação de dados, tornando a fragmentação possível. Fragmentação Sim Sim Sim Sim
Integridade referencial entre tabelas armazena-
Não Não Não Sim
3.1. Processamento dos comandos de manipulação de dados das em servidores distintos
Protocolo de commit distribuído 2PC 2PC 2PC 2PC
Toda vez que um comando INSERT, UPDATE ou DELETE é submetido ao servidor, o mes-
mo é analisado e enviado para um módulo denominado executor. O executor foi alterado para
verificar nos novos catálogos a necessidade de replicação da solicitação. 5. Caso de uso
Quando o sistema identifica que um comando deve alterar dados de um ou mais sítios re-
motos, é iniciada uma transação distribuída onde o comando em questão é replicado para todos os Para demonstrar as funcionalidades do pgGrid, um esquema de BDD foi montado. O esquema
sites envolvidos. A execução do comando somente é dada como concluída quando todos os sites armazena dados sobre produtos produzidos no estado de Santa Catarina, conforme ilustrado no
confirmarem o sucesso da operação para o site que recebeu a solicitação. Se algum servidor repor- modelo lógico da Figura 2.
tar problemas na execução do comando, são enviadas mensagens para desfazer as alterações em
todos os nodos envolvidos, segundo o protocolo de recuperação adotado pelo pgCluster.

3.2. Processamento das consultas distribuídas

Toda vez que um comando SELECT é submetido ao servidor, o mesmo é analisado, pas-
sa por otimizações para melhorar seu desempenho e depois é enviado para o mesmo módulo
executor dos demais comandos. O executor das consultas foi alterado para consultar os catálo-
gos do pgGrid e verificar a necessidade de solicitação de dados para outros sites do cluster.
Quando o sistema identifica que uma consulta necessita de dados externos (através de
reduções [Ozsu 1999]), uma solicitação é enviada para cada site que contém dados usados pela
consulta. Cada site processa as operações possíveis no seu conjunto de dados (provendo paraleli-
zação) e envia o resultado para o servidor que recebeu a solicitação, este é responsável por “jun-
tar” os dados (através de operações de união e junção) e apresentar o resultado final ao usuário.
4. Outros SGBDs Distribuídos
Figura 2. Modelo lógico correspondente ao caso de uso
Cinco sites pertencem ao sistema, localizados nas principais cidades do estado: Flo-
rianópolis (FLN), Joinville (JVL), Blumenau (BLU), Criciúma (CRI) e Chapecó (XAP). As regras de
armazenamento são simples: cada cidade armazena seu cadastro e os produtos produzidos em
sua região. A capital (FLN), além dos dados de seus produtos, armazena o cadastro de todas as
cidades do estado para facilitar a listagem da tabela neste local. Os produtos possuem como
atributos: código, nome e cidade de origem. As cidades possuem código, nome e a distância
(em quilômetros) até a capital.
Depois que os cinco servidores foram configurados e colocados no ar, o modelo de da-
dos e sua fragmentação foram definidos através dos comandos apresentados na Figura 3.

Como parte do trabalho, foi realizada a avaliação de várias implementações de banco de dados /*relação cidade*/
sc=# CREATE TABLE CIDADE (ID INT, NOME VARCHAR, DISTANCIA_CAPITAL INT);
distribuídos disponíveis no mercado. sc=# ALTER TABLE CIDADE ADD CONSTRAINT PK_CIDADE PRIMARY KEY (ID);
 52 /*relação produto*/ Pode-se notar, através dos dados obtidos, que a fragmentação nos dados melhorou as 53
sc=# CREATE TABLE PRODUTO (ID INT, NOME VARCHAR, ID_CIDADE_ORIGEM INT);
sc=# ALTER TABLE PRODUTO ADD CONSTRAINT PK_PRODUTO PRIMARY KEY (ID); operações de atualização, pois não é necessário acessar todos os sites do sistema quando um
XI Worshop sobre Software Livre

pgGrid: uma Implementação de Fragmentação de Dados para o PostgreSQL

sc=# ALTER TABLE PRODUTO ADD CONSTRAINT FK_PRODUTO_CIDADE FOREIGN
sc=# KEY (ID_CIDADE_ORIGEM) REFERENCES CIDADE (ID); item de dado é modificado. No entanto, a maioria das operações de consulta envolvendo mais
/*definição e alocação dos fragmentos dos produtos*/ de um site teve seu desempenho degradado devido à necessidade de juntar os dados distri-
sc=# CREATE FRAGMENT PRODUTO_FLN ON PRODUTO WHERE ID_CIDADE_ORIGEM=1;
sc=# PLACE PRODUTO_FLN ON FLN; buídos entre os servidores. No caso do pgCluster, com os dados totalmente replicados, apenas
sc=# CREATE FRAGMENT PRODUTO_JVL ON PRODUTO WHERE ID_CIDADE_ORIGEM=2;
sc=# PLACE PRODUTO_JVL ON JVL; uma consulta local resolve o problema.
sc=# CREATE FRAGMENT PRODUTO_BLU ON PRODUTO WHERE ID_CIDADE_ORIGEM=3; A grande melhoria notada pela fragmentação se refere ao desempenho das atualiza-
sc=# PLACE PRODUTO_BLU ON BLU;
sc=# CREATE FRAGMENT PRODUTO_CRI ON PRODUTO WHERE ID_CIDADE_ORIGEM=4; ções e consultas distribuídas. Com a remoção das réplicas desnecessárias, os recursos utiliza-
sc=# PLACE PRODUTO_CRI ON CRI;
sc=# CREATE FRAGMENT PRODUTO_XAP ON PRODUTO WHERE ID_CIDADE_ORIGEM=5; dos em cada servidor podem ser configurados de uma forma mais otimizada para atender às
sc=# PLACE PRODUTO_XAP ON XAP; necessidades dos seus usuários.
/*definição e alocação dos fragmentos das cidades*/
CREATE FRAGMENT CIDADE_FLN ON CIDADE;
PLACE CIDADE_FLN ON FLN;
CREATE FRAGMENT CIDADE_JVL ON CIDADE WHERE ID=2;
PLACE CIDADE_JVL ON JVL;
CREATE FRAGMENT CIDADE_BLU ON CIDADE WHERE ID=3; 7. Conclusões
PLACE CIDADE_BLU ON BLU;
CREATE FRAGMENT CIDADE_CRI ON CIDADE WHERE ID=4;
PLACE CIDADE_CRI ON CRI; Com a crescente necessidade de compartilhamento de informações, há uma demanda muito
CREATE FRAGMENT CIDADE_XAP ON CIDADE WHERE ID=5;
PLACE CIDADE_XAP ON XAP; grande para o armazenamento das mesmas. Na maioria das vezes, os dados ficam centraliza-
dos em grandes servidores. No entanto, com volumes muito grandes, a centralização torna o
Figura 3. Comandos utilizados na definição do caso de uso do pgGrid
processo de recuperação e carga dos dados ineficiente [Ozsu 1999].
Para resolver tal problema, os sistemas distribuídos entram em jogo fornecendo solu-
Foram realizados testes inserindo as cidades e vários produtos no sistema. Depois todos
ções escaláveis e paralelizáveis. Este trabalho propõe uma solução deste tipo no contexto de
os sites foram reiniciados no modo centralizado (sem sincronia com o cluster). Cada site conti-
banco de dados relacionais e objeto-relacionais.
nha somente os dados da cidade que representava, atestando o funcionamento do pgGrid.
A proposta apresentada no início do trabalho mostrou-se viável no decorrer do desen-
volvimento do mesmo. Tal viabilidade foi ilustrada pelo caso de uso e pelos testes de desem-

6. Testes de desempenho penho. No entanto, o módulo planejador de consultas precisa ser melhorado para usufruir mais
da paralelização que a fragmentação proporciona e o software deve passar por testes mais

Os testes executados no caso de uso abordaram principalmente as garantias da integridade e rigorosos antes de ser colocado em produção em casos reais.
reconstrução dos dados distribuídos no sistema. Também foram realizados testes para examinar o Como próximo passo planeja-se implementar as otimizações de consultas que o am-
desempenho das operações dentro do sistema distribuído utilizado no caso de uso, fazendo uma biente distribuído possibilita, tais como a paralelização de subconsultas.
comparação com o desempenho do pgCluster com a mesma configuração e massa de dados.
Buscando resultados mais precisos, foi gerada uma massa de dados com 500000 produtos Repositório do projeto
que foi dividida em partes iguais nos sites do sistema, de acordo com as regras de fragmentação
PgGrid é um software de código-fonte aberto, disponível pela licença GPL, que pode ser
definidas anteriormente. Os testes foram realizados utilizando dois servidores (três sites alocados
baixado do site http://pgfoundry.org/projects/pggrid/.
no servidor A e dois no servidor B) conectados a um switch de 100 Mbps (Fast Ethernet).
As operações utilizadas nos testes estão listadas na Tabela 2, e correspondem ao tempo
das operações, carga dos servidores, comunicação através da rede e dos acessos aos disposi-
Referências
tivos de armazenamento.

Ozsu, M. Tamer (1999) “Principles of distributed database systems”. New Jersey, United States,
Tabela 2. Resultados dos testes de desempenho Prentice Hall, p. 7-10.
Parâmetro pgCluster pgGrid PostgreSQL Development Group (2009). “About PostgreSQL”, http://www.postgresql.org/.
Bedoya, H. et al (2001). “Advanced Functions and Administration on DB2 Universal Database for
Tempo para atualização (UPDATE) na relação CIDADE 1.8s 0.9s
iSeries”, http://www.redbooks.ibm.com/abstracts/sg244249.html.
SELECT * FROM PRODUTO 5.3s 16.5s
MYSQL AB (2007). “MySQL 5.0 Reference Manual”, http://dev.mysql.com/doc/refman/5.0/.
SELECT * FROM PRODUTO WHERE NOME = ’PROD500001’ 4s 2.3s GOPALAKRISHNAN, K “Oracle Database 10g Real Application Clusters Handbook”. Columbus:
Pacotes de rede transmitidos durante a atualização 16 4 McGraw-Hill Osborne Media (Oracle Press), 2006, ISBN 9780071465090.
Carga de trabalho durante a consulta 20% 38%
Espaço médio ocupado pelo banco de dados em cada site 30MB 7.57MB
 54
XI Worshop sobre Software Livre
SatBudgets: Projeto Conceitual de Satélites
Baseado em Conhecimento e Dirigida a Modelos
Bruno B. F. Leonor1, Walter A. Santos2, Stephan Stephany3
Centro de Previsão de Tempo e Estudos Climáticos (CPTEC)
1
2
Divisão de Sistemas Espaciais (DSE)
3
Laboratório Associado de Computação e Matemática Aplicada (LAC/CTE)
Instituto Nacional de Pesquisas Espaciais - Brasil
bruno.leonor@cptec.inpe.br, walter@dss.inpe.br, stephan@lac.inpe.br
Resumo. Satélites estão se tornando cada vez mais complexos, fazendo com que de-
cisões técnicas do projeto interdisciplinar impactem custos e prazos. Uma solução proposta
é apoiar a fase de projeto conceitual de satélite com adoção de uma engenharia dirigida por
modelo (MDE - Model Driven Engineering). Entretanto, softwares de Engenharia de Sistemas
Espaciais geralmente podem ser sujeitos a embargo tecnológico ou ter alto custo. Este trabalho
visa atenter esta demanda empregando somente software livre e a linguagem SysML (Systems
Modeling Language) para implantar MDE através do desenvolvimento de uma ferramenta de
software baseado em conhecimento, denominada SatBudgets. A metodologia MDE é geral o
bastante para ser aplicada a qualquer projeto de satélite como o ITASAT, um satélite universitá-
rio aqui adotado como estudo de caso.
Abstract. Satellites are becoming highly complex systems making technical decisions
from the interdisciplinary project impact on costs and deadlines. A solution is to underpin the
conceptual design phase of satellite systems by adopting a model-driven engineering approach
(MDE). Nevertheless, software for Space Systems Engineering generally may be subject to tech-
nological embargo or have high costs. This work targets this demand by employing only free
software and SysML (Systems Modeling Language) to enable MDE by developing a software tool
based on knowledge, named SatBudgets. This approach is general enough to be applied to any
satellite project like the ITASAT, a university satellite here taken as a case study.
1. Introdução
Os sistemas modernos estão tornando-se cada vez mais complexos, por este motivo proje-
tos conceituais estão ganhando cada vez mais espaço no desenvolvimento de um produto,
podendo-se assim preliminarmente especificar, analisar, projetar e verificar sistemas sem a
necessidade de produção de uma única peça [Leonor et al. 2009].
O Projeto Conceitual é a fase inicial do processo de projeto de um sistema e exige a
aplicação de conhecimento de domínio do produto.
Para o projeto de satélites isso não é diferente, levando em consideração a grande
quantidade de recursos, tanto humanos quanto financeiros, envolvidos em sua produção e tam-
bém os benefícios trazidos pelos mesmos à população. Um bom planejamento é essencial, pois
evita erros que podem comprometer todo um empreendimento [dos Santos et al. 2009]. 55
A dificuldade para se encontrar softwares adequados para a área espacial foi a principal
SatBudgets: Projeto Conceitual de Satélites Baseado em Conhecimento e Dirigida a Modelos
motivação para a criação do sistema SatBudgets, que tem como objetivo mostrar a viabilidade
do desenvolvimento deste tipo de ferramental. Adicionalmente, outras grandes dificuldades po-
dem ser embargo tecnológico ou mesmo o alto custo das ferramentas existentes no mercado.
Desta maneira um dos requisitos para o sistema SatBudgets foi utilizar somente software livre
no seu desenvolvimento.
Para auxiliar na fase de projeto conceitual foi utilizada uma nova abordagem que permi-
te o reuso e integração da informação chamada MDE [Schmidt 2006]. Esta abordagem foca-se
na criação de modelos maximizando a compatibilidade entre subsistemas do projeto e simpli-
ficando o processo de comunicação entre os diversos especialistas de domínio. No entanto, a
MDE requer o uso de uma linguagem de descrição de arquitetura (ADL) para o sistema a ser
engenhariado.
A SysML [OMG 2006] foi a linguagem adotada neste trabalho. SysML foi proposta pela
OMG (Object Management Group) para se tornar uma linguagem padrão na modelagem de
sistemas que surgiu como complemento a UML (Unified Modeling Language) [OMG 2009]. Sys-
ML é uma linguagem gráfica de modelagem que pode apoiar a análise, especificação, projeto,
verificação e validação de sistemas complexos [Friedenthal et al. 2008].
Um protótipo de software baseado em conhecimento, denominado SatBudgets, foi cria-
do para auxiliar na fase conceitual de projeto de satélite fazendo uso de diagramas SysML. O
software pode ser aplicado na fase conceitual de projetos de subsistemas de satélites para au-
xiliar na geração de balanços (mecânico, elétrico, entre outros). MDE neste contexto é utilizada
como um estudo de caso aplicado ao satélite universitário ITASAT.
Uma prototipação de aquisição de conhecimento inserido na ferramenta para a geração
do balanço é efetuada minimamente através da captura de regras de negócio que norteiam
decisões de projeto. Esta atividade faz parte de um escopo maior de Engenharia do Conheci-
mento onde habilidades de especialistas podem ser armazenadas num ambiente computacio-
nal [Leonor 2010].
2. O Projeto ITASAT e Projeto Conceitual de Satélites
O satélite abordado neste trabalho é o ITASAT [AEB et al. 2005], um satélite universitário, cujo
projeto foi iniciado no ano de 2005, atualmente desenvolvido pelo INPE (Instituto Nacional de
Pesquisas Espaciais), ITA (Instituto Tecnológico de Aeronáutica) e algumas universidades públi-
cas brasileiras. A Figura 1(a) ilustra o satélite ITASAT.
Além da sua funcionalidade experimental, o ITASAT irá contar com um transponder para
transmissão dos dados coletados por PCDs (Plataforma de Coleta de Dados) distribuídas por
todo o território brasileiro como mostrado na Figura 1(b) e é parte integrante do Sistema Na-
cional de Coleta de Dados.
A fase inicial de projeto de um sistema, conhecida por Projeto Conceitual, exige funda-
mentalmente a aplicação de conhecimento de domínio do problema a ser atacado.
Essa fase deve ser sistematizada para que aumente a produtividade via automação e
possibilite sua integração com as demais fases do projeto, prototipação, planejamento de ma-
nufatura e a fabricação propriamente dita [Almeida 2000].
O projeto conceitual envolve várias linhas de raciocínio e uma grande quantidade de
informações interdisciplinares. Dessa forma, é visível a grande complexidade de tal fase do
processo de projeto e as interdependências que esta ocasiona.
 56
XI Worshop sobre Software Livre
Figura 1. ITASAT e sua utilização na arquitetura de coleta de dados ambientais
Vale realçar a grande importância da fase inicial de projeto no custo, prazo de entrega
e no sucesso do sistema final. Decisões tomadas nessa fase apresentam grande importância e
qualquer alteração posterior pode acarretar alto custo para modificações nas fases posteriores
do desenvolvimento de um sistema.
Com a automatização do processo de Projeto Conceitual obtém-se uma maior eficiência
e velocidade de desenvolvimento, necessidade essencial no mercado competitivo atual.
3. Satbudgets - uma Instância de Engenharia Dirigida por Mo-
delos
SatBudgets é o protótipo de uma ferramenta relatada neste trabalho para auxiliar na fase
conceitual de um projeto de satélite automatizando a geração de balanços (mecânico, elétrico,
entre outros) e aplicado a dados do projeto do satélite ITASAT.
A Figura 2 apresenta sumariamente o fluxo de trabalho associado à ferramenta SatBud-
gets e o conjunto de ferramentas de software livre que apoiam seu desenvolvimento.
Através da interface gráfica do SatBudgets, um arquivo SysML é informado como o
modelo que servirá de entrada para o processamento bem como quais balanços devem ser
calculados. Finalmente um formato de arquivo de saída é selecionado pelo engenheiro de sis-
temas para a apresentação do relatório de balanços, seja via visualizador da ferramenta ou
armazenamento nos formatos PDF, XLS ou HTML.
A ferramenta SatBudgets foi desenvolvida na linguagem Java, fazendo uso somente de
ferramentas e APIs (Application Programming Interface) de livre distribuição como requisito
inicial ao desenvolvimento da ferramenta.
No fluxo de funcionamento da ferramenta SatBudgets, ilustrado na Figura 2, um modelo
SysML, mais especificamente o diagrama de blocos, do satélite servirá de entrada para a leitura
do arquivo do modelo. Um parser é responsável por encontrar dentro da estrutura do arquivo
os tokens definidos e extrair seus valores. Em seguida, uma atribuição é feita a cada um dos
valores extraídos no parsing. Estas funcionalidades foram implementadas fazendo uso da API
JDOM, uma API Java para manipulação de arquivos XML. As regras de negócio serão aplicadas
57
SatBudgets: Projeto Conceitual de Satélites Baseado em Conhecimento e Dirigida a Modelos
Figura 2. Fluxo de trabalho do SatBudgets apoiado por software livre
sobre os parâmetros extraídos da configuração de arquitetura de satélite e será gerado um
relatório contendo o balanço para a dada configuração.
4. Softwares Livres Utilizadas no SatBudgets
Na fase exploratória de potenciais ferramentas disponíveis de apoio ao desenvolvimento do
SatBudgtes, várias alternativas foram consideradas, entretanto as ferramentas relatadas a se-
guir foram escolhidas por serem as mais convenientes para o projeto. O conhecimento prévio
de utilização e grande comunidade de usuários foram alguns dos fatores que influenciaram
substancialmente o processo dessa escolha.
Para a modelagem de sistemas foi escolhida a ferramenta TOPCASED. Esta ferramenta
possibilita a modelagem de sistemas fazendo uso da SysML [OMG 2006], uma ADL de uso geral
que possibilita a modelagem de sistemas. A SysML é uma extensão da UML sugerida pela OMG
para possibilitar a modelagem de sistema que incorporam hardware e/ou software. TOPCASED
baseia-se no Galileo (Eclipse 3.5) e requer uma JVM (Java Virtual Machine). Seu download pode
ser feito como um aplicativo autônomo ou pode ser instalado diretamente através do gerencia-
dor de instalação do Eclipse [Lescot 2009].
O Eclipse [Burnette 2005] é uma IDE (Integrated Development Environment) desenvol-
vida em Java, com código aberto para a construção de programas de computador. O projeto
Eclipse foi iniciado na IBM que desenvolveu a primeira versão do produto e doou-o como sof-
tware livre para a comunidade de computação.
Para a manipulação do modelo SysML foi utilizada a API JDOM [JDOM 2009], uma API de
código aberto baseado em Java que cria um modelo de objeto do documento XML (Extensible
Markup Language). Está API fornece uma forma fácil e eficiente de representar este documento
para manipulação.
Para o processamento das regras de negócio foi adotado o framework Drools. Drools é
um mecanismo baseado em regras que foi lançado pela Codehaus e posteriormente adotado
como um projeto do JBoss, conhecido também como JBoss Rules [JBoss 2009]. Em Drools, o
domínio de conhecimento é representado através das classes do sistema e as necessidades de
 58 uso do sistema geram as regras. Uma regra tem uma ou mais condições (ou fatos), que levam Referências 59

a uma ou mais ações (ou consequências). Uma regra Drools é tratada em uma memória interna
XI Worshop sobre Software Livre

SatBudgets: Projeto Conceitual de Satélites Baseado em Conhecimento e Dirigida a Modelos

chamada de Working Memory.
Para a geração do relatório de balanço foram utilizadas as APIs JasperReports e JFre-
eChart, sendo o relatório projetado na ferramenta iReport. A biblioteca JasperReports é uma
poderosa e flexível ferramenta de geração de relatório que tem a capacidade de oferecer rico
conteúdo sobre a tela, para a impressora ou em PDF, HTML, CSV, XLS, RTF ou arquivos XML
[Danciu 2002].
O relatório é gerado através da criação de um modelo XML que contém o layout do
relatório. Este modelo XML do relatório é compilado utilizando a API JasperReports, o que irá
resultar em um arquivo com a extensão .jasper que contém toda a formatação do relatório e
como as colunas se relacionam com os dados. O ciclo para geração do relatório é concluído com
a compilação dos dados que irão compor o relatório com o arquivo .jasper criado pelo modelo
do relatório.
O iReport é um designer de relatório de código aberto para o JasperReports, disponível
para todos os principais sistemas operacionais sob a GNU (General Public License). O iReport
possibilita a criação de layouts complexos contendo gráficos, imagens, sub-relatórios, tabelas
de referência cruzada e muito mais [JasperSoft 2009].
Finalmente, JFreeChart é uma consistente e bem documentada API para criação de grá-
ficos que provê uma ampla gama de tipos de gráfico [Gilbert 2004], possibilitando muitos tipos
de saída, incluindo componentes Swing, arquivos de imagem (JPEG e PNG), e gráficos vetoriais
(PDF, EPS e SVG).
A integração entre os diferentes softwares livre utilizados foi facilitada pela IDE Eclipse
com seu grande número de plugins disponíveis e pela facilidade de agregação das diversas fer-
ramentas. Atualmente há uma discussão sobre implicações em se disponibilizar a ferramenta
SatBudgets como um software livre para uso na área de projetos espaciais.
5. Conclusões
AEB, INPE, and ITA (2005). Itasat - www.itasat.ita.br
Almeida, F. J. (2000). Research and choice of a methology for the conceptual design. Revista de
Ciência & Tecnologia, 8 (16):31–42.
Burnette, E. (2005). Eclipse IDE, volume 1. O’Reilly Media, Sebastopol, 1 edition.
Danciu, T. (2002). The jasperreports ultimate guide -http://www.jaspersoft.com/jasperreports-
ultimate-guide
dos Santos, W. A., Leonor, B. B. F., and Stephany, S. (2009). A knowledge-based and model-
driven requirements engineering approach to conceptual satellite design. Lecture Notes in
Computer Science - Conceptual Modeling - ER 2009, 1:487–500.
Friedenthal, S., Moore, A., and Steiner, R. (2008). A practical guide to SysML, volume 1. Morgan
Kaufmann, Oxford, UK.
Gilbert, D. (2004). The jfreechart developer guide - http://www.jfree.org/jfreechart/devguide.
html
JasperSoft (2009). ireports tutorials & help - http://jasperforge.org.
JBoss (2009). Drools expert user guide - www.jboss.org/drools/documentation.html.
JDOM (2009). JDOM documentation - http://www.jdom.org
Leonor, B. B. F. (2010). Um enfoque baseado em conhecimento e dirigido a modelos de en-
genharia de requisitos para projeto conceitual de satélites. MSc Thesis, INPE, (INPE-16670-
TDI/1621).
Leonor, B. B. F., dos Santos, W. A., and Stephany, S. (2009). A model-driven requirements en-
gineering approach to conceptual satellite design. In Anais... Brazilian Symposium on Aero-
space Engineering, São José dos Campos.
Lescot, J. (2009). Topcased v3 - www.topcased.org.
OMG (2006). Sysml specification - www.omgsysml.org.
OMG (2009). UML - www.uml.org
Schmidt, D. C. (2006). Model-driven engineering. IEEE Computer, Feb. 2006, pages 25–31.

Sistemas espaciais requerem cada vez mais bons princípios de engenharia de sistemas para
lidarem com as questões de crescente complexidade. Softwares de apoio aos processos da
Engenharia de Sistemas Espaciais podem apresentar limitações de uso como embargo tecno-
lógico ou alto custo.
Neste sentido, o trabalho adota a abordagem MDE para projeto conceitual de satélites
empregando uma ferramenta desenvolvida a partir somente de software livre, o SatBudgets.
MDE permite a reutilização de informações entre diferentes projetos de satélites uma vez que
é focada em modelos.
A aplicação de MDE neste trabalho foi baseada no uso da linguagem SysML para mo-
delagem de satélites e na ferramenta proposta SatBudgets para dar apoio à um processo de
atividades do projeto conceitual. Partindo da modelagem SysML, a ferramenta SatBudgets gera
automaticamente balanços (mecânico, elétrico, entre outros) de projeto de satélite. Isto de-
monstra sua viabilidade na construção dos sistemas e pode diminuir o impacto das alterações
ao logo do projeto. Um estudo de caso foi aplicado ao projeto do satélite universitário ITASAT.
No atual estágio, MDE e SatBudgets estão em fase de implantação experimental e gra-
dual ao ciclo de engenharia para projetos futuros de satélites bem como na sua utilização em
outros sistemas diversos como veículos lançadores de satélites como já demonstrado com o IAE
(Instituto de Atividades Espaciais) em São José dos Campos.
 60 bilizar um estudo científico da emoção na fala. Estudos [Matte 2006] [Barbosa 2006] mostram 61

que a utilização de softwares desenvolvidos por ou com pesquisadores da área, contexto co-
XI Worshop sobre Software Livre

Setfon: Sistema Open Source para produção e organização de Semioetiquetas Fonológicas

mum no desenvolvimento de software livre, produzem resultados sensivelmente mais práticos
Setfon: Sistema Open Source para produção e para a realização de pesquisas nessa área, quando comparados com softwares proprietários.
organização de Semioetiquetas Fonológicas* Neste artigo vamos apresentar a parte conceitual que sustenta as análises do Setfon no campo
da linguística e as soluções computacionais adotadas para obtenção de dados.
Ana Cristina Fricke Matte1, Rubens Takiguti Ribeiro2

2. Semioetiquetas Fonológicas
Faculdade de Letras – Universidade Federal de Minas Gerais (UFMG) -
1

Av. Antônio Carlos, 6627 – 31.270-970 – Belo Horizonte – MG – Brasil O conceito de semioetiqueta fonológica, aqui proposto, é uma abordagem da análise de fala que
2
TecnoLivre – Cooperativa de Tecnologia e Soluções Livres trabalha com os segmentos de som de fala como objetos. Uma semioetiqueta fonológica é uma
Universidade Federal de Lavras (Ufla) – 37.200-000 – Lavras – MG – Brasil classe de objetos cujos atributos são dados intrínsecos ou adquiridos. Os objetos são segmentos
anacrifm@ufmg.br, rubens@tecnolivre.com.br de som de fala, que podem ter tamanhos diferentes. Adotamos aqui o segmento VV (vogal a vo-
gal) [Marcus 1981] e o grupo acentual como base para a segmentação [Barbosa 2006]. Esses ob-
jetos são obtidos pela análise automática de trechos de fala acompanhados de uma transcrição
Abstract. Setfon is an open source web information system for data collecting in the
ortográfica [Barbosa 1996]. O grupo acentual é uma sequência de segmentos VV obtida pela aná-
field of speech sciences. Its architecture is component based and it emerged from the necessity
lise quantitativa e qualitativa da duração dos segmentos VV, portanto, uma análise dependente
of raising up the acoustic-phonological data quantity in order to solve the problem of statistic
já dos atributos da original. Assim, define-se a classe Segmento VV e a classe Grupo Acentual. Por
significance in expression of emotion in speech studies. Moreover, Setfon is on-line and, then,
um lado, os dados intrínsecos são variáveis independentes, essencialmente quantitativas e que
allows the creation of a national database about this matter, that can be easily shared between
podem ser obtidos por análise acústica automática. Já os dados adquiridos são parâmetros cuja
the researchers in speech sciences.
automatização ainda é uma possibilidade pouco explorada até o momento, dada sua dependên-
cia de uma análise qualitativa. Atualmente é possível dispor de parsers sintáticos e semânticos
Resumo. Setfon é um sistema de informação web livre para coleta de dados em pes-
para auxiliar o processo, mas a análise semiótica é totalmente manual.
quisas sobre a fala. O sistema aborda o problema central através de componentes e nasceu da
Tanto o Grupo Acentual quanto o segmento VV podem receber atributos intrínsecos e
necessidade de aumentar significativamente a quantidade de dados acústico-fonológicos para
adquiridos, embora de naturezas diferentes. O primeiro atributo adquirido do segmento VV é
atender a demandas de estudos estatísticos de expressão da emoção e de estilo. Além disso,
uma etiqueta fonológica, obtida pela transcrição fonológica e segmentação do texto correspon-
por ser on-line, o Setfon permite a criação um banco de dados nacional sobre o tema, compar-
dente a um som de fala. Somente com a obtenção desta etiqueta fonológica é possível calcular
tilhável entre pesquisadores das ciências da fala.
seus atributos intrínsecos (duração, intensidade, frequência, configuração formântica) e criar
os objetos da classe Grupo Acentual. Já os objetos desta última possuem atributos intrínsecos
da ordem do prosódico, tais como taxa de elocução, curva melódica variação de intensidade,
1. Introdução variação de duração, posição do acento e número de segmentos VV. Os atributos adquiridos são
totalmente dependentes do tipo de resultado almejado, podendo advir de parsers sintáticos,
O presente trabalho discorre sobre o desenvolvimento de um software livre para auxiliar pes-
parsers semânticos e/ou de análises de conteúdo específicas como análise semiótica tensiva ou
quisas relacionadas à fonoestilística e a outros estudos da fala, o Setfon. O problema central
narrativa, só para citar alguns exemplos.
é a interdisciplinaridade: não é viável trabalhar com fonoestilística, em especial expressão da
emoção na fala, sem ultrapassar os limites dos estudos linguísticos dos sons de fala, compre-
endidos pela fonética e pela fonologia. O processamento do Setfon, portanto, visa a elaboração
3. Etiquetador Fonológico
de tabelas para análise estatística com a obtenção de conjuntos de dados aos quais chamamos
semioetiquetas fonológicas.
A concepção do semioetiquetador fonológico seguiu o processo de desenvolvimento de sof-
Pesquisas nesta área são sustentadas por avaliações estatísticas resultantes do cruza-
tware baseado em componentes proposto por [Brito et all 2005], sendo dividida nas seguintes
mento de dados intrínsecos ao som (como os dados acústicos) e dados adquiridos (avaliações
etapas: (i) análise do domínio; (ii) modelagem dos componentes; (iii) implementação dos com-
semióticas, normalmente relacionadas à cultura do falante ou a circunstâncias da coleta de
ponentes; (iv) testes dos componentes; (v) implementação da interface Web; e (iv) teste de in-
amostras de fala). Esta vasta gama de variáveis envolvidas implica um corpus de magnitude
tegração. Durante o desenvolvimento de cada componente do Setfon, foram criadas interfaces
muito superior à usualmente alcançada [Matte 2004].
para utilização individual (scripts em shell), tornando possível realizar testes independentes. A
Assim, automatizar o processo de coleta de dados é uma etapa imprescindível para via-
Programação Orientada a Componentes é uma abordagem técnica para solucionar problemas
de forma computacional através de estruturas lógicas atômicas e bem definidas através de in-
*
Projeto financiado pelo CNPq, processo número 473616/2007-6. terfaces. Componentes encapsulam processos ditos de caixa preta, ou seja, processos que não
 62 exigem conhecimento aprofundado da estratégia de implementação, já que, a nível modular,
não possuem acoplamento. As semioetiquetas fonológicas formam um conjunto de dados com-
XI Worshop sobre Software Livre
plexo; para obtê-los, cada atributo foi tratado por um componente diferenciado.
O processo baseado em componentes tem grande proximidade com as atividades manuais
e semi-automáticas realizadas por pesquisadores para obtenção de dados acústicos. A maioria das
operações são atômicas, e possuem entradas e saídas bem definidas. Neste sentido, foram identi-
ficados 4 componentes essenciais: (i) segmentador de som; (ii) fonotranscritor de texto tradicional
para texto fonológico; (iii) manipulador de TextGrid1; (iv) extrator de dados acústicos. Estes com-
ponentes são manipulados por uma camada Web que funciona tanto como controlador das etapas
envolvidas no processo de extração quanto interface direta com o usuário pesquisador.
Figura 1: Interface da ferramenta principal do Setfon
A principal ferramenta do Setfon é representada na Figura 1. Ela funciona a partir do
envio de um arquivo de som de fala e um arquivo de texto (com valores semânticos correspon-
dentes). Para se obter os dados acústicos, é preciso avaliar o arquivo de som com o seu respec-
tivo TextGrid, preenchido com segmentos fonológicos e outros dados relevantes. Para se obter
o TextGrid, por sua vez, são necessárias três sub-etapas: (i) realizar uma transcrição do arquivo
de texto para um texto fonológico e segmentá-lo com a estratégia VV; (ii) gerar um TextGrid
apenas com os dados obtidos do arquivo de som, mas ainda sem os segmentos fonológicos; e
(iii) inserir os segmentos fonológicos nos respectivos espaços reservados no TextGrid.
A estratégia adotada para abordar a solução deste problema foi definir as entradas
e saídas de cada componente como sendo arquivos de diferentes tipos. Cada componente,
portanto, recebe um ou mais arquivos de entrada e produz um arquivo resultante. A camada
Web apresenta os arquivos (na região central da Figura 1) e as possíveis operações sobre estes
arquivos (na parte inferior da Figura 1). Para realizar uma operação, é necessário selecionar os
arquivos de entrada (clicando sobre eles) e, depois, acionar a operação desejada. Cada compo-
nente deste processo utilizou as técnicas e tecnologias mais apropriadas ao propósito.
1
Estrutura computacional responsável por representar os limites entre os segmentos de um arquivo de som, e que
pode agregar anotações, como as transcrições fonológicas dos segmentos.
3.1. Segmentação do Som 63
Setfon: Sistema Open Source para produção e organização de Semioetiquetas Fonológicas
O segmentador de som é um componente do sistema, implementado com a lingua-
gem Praat2, que recebe como entrada um arquivo de som para produzir um TextGrid semi-
preenchido. O código foi baseado no script intitulado “BeatExtractor”, de autoria de Plínio A.
Barbosa. Este componente recebe uma configuração (por exemplo: sexo do falante, tipo de
filtro a ser utilizado e tipo de técnica a ser utilizada) e identifica os pontos de segmentação
VV, produzindo um arquivo TextGrid contendo os intervalos de tempo entre cada segmento e
outros dados relevantes, conforme exemplo na Figura 2. O componente possui uma pequena
camada implementada com a linguagem PHP3, que faz a comunicação entre a interface Web
com o script em Praat.
Para ajustar as possíveis configurações de segmentação, a interface Web oferece uma
ferramenta para criar e editar um arquivo INI, que armazena as possíveis configurações a serem
utilizadas. Desta forma, o componente pode receber, opcionalmente, um arquivo de configura-
ções como entrada, além do arquivo de som, que é obrigatório. Definir um arquivo de configura-
ções é útil para reutilização por diferentes análises ou por diferentes instâncias do sistema (em
servidores diferentes). A utilização de scripts na interface gráfica do Praat agiliza sobremaneira
o processamento manual do sinal, mas implica em realizar a operação arquivo a arquivo, tor-
nando o processo todo bem mais demorado. A primeira implementação do script de Barbosa foi
via shell script, com significativo aumento na performance da coleta de dados, e constituiu a
primeira versão do componente de obtenção de dados intrínsecos do Setfon.
3.2. Etiquetas Fonológicas
O preenchimento de etiquetas fonológicas no TextGrid (produzido pelo segmentador de
som) é realizado por dois componentes: o fonotranscritor e o manipulador de TextGrid, ambos
implementados exclusivamente com a linguagem PHP. Primeiramente, o fonotranscritor é res-
ponsável por converter um texto natural em texto fonológico. Por exemplo, a palavra “comple-
xo” (texto natural) é transcrita para “kõple’kso” (que utiliza os símbolos fonéticos definidos pelo
IPA – International Phonetic Alphabet), em seguida transcrita para “koNple’kso” (texto fonológi-
co) e, finalmente, dividida nos segmentos: /oNpl/ /e’ks/ /o/ (segmentos VV). O arquivo resultante
deste processo é um arquivo texto, onde cada linha guarda um segmento.
Para realizar a transcrição inicial, foi utilizado um algoritmo baseado em expressões
regulares que avalia uma palavra trecho a trecho e, de acordo com uma tabela de regras gra-
maticais e uma lista de exceções, símbolos de algum alfabeto são convertidos para símbolos do
IPA. A tabela de regras gramaticais e a lista de exceções são especificadas em um arquivo se-
parado, já que dependem do alfabeto utilizado para representar o texto. As demais operações
são relativamente simples e diretas.
Já o componente manipulador de TextGrid possui um parser, um manipulador e um ge-
rador de TextGrid. Desta forma, o componente é capaz de ler o TextGrid semipreenchido gerado
pelo segmentador de som e incluir os segmentos fonológicos produzidos pelo fonotranscritor,
gerando, assim, um TextGrid totalmente preenchido. O TextGrid original faz parte da segmen-
tação do som, sem qualquer dado qualitativo. A inserção das etiquetas fonológicas, que era
2
Software livre destinado à manipulação e extração de dados de arquivos de som. Possui tanto uma interface de
acesso por pesquisadores quanto uma linguagem de script que permite automatizar operações que poderiam ser
realizadas pela interface tradicional. Disponível em <http://praat.org/>.
3
Linguagem de script open source de uso geral e especialmente guarnecida para desenvolvimento Web, disponível em
<http://php.net/>.
 64 feita manualmente pelo pesquisador, passou a ser feita por um praat script, dependente de
interface gráfica e restrito a rodar um arquivo por vez. O Setfon reescreveu o código em PHP
XI Worshop sobre Software Livre
e automatizou o processo, dispensando a interface gráfica do Praat, o que também contribuiu
significativamente para a melhoria do desempenho da coleta de dados.
Figura 2: Exemplo de TextGrid.
3.3. Extração de Dados Acústicos
O extrator de dados acústicos é um componente responsável por avaliar um arquivo de
som e, com auxilio de um arquivo TextGrid completo, obter os dados acústicos, que são, então,
armazenados em um arquivo CSV (comma-separated values). Este componente foi escrito es-
sencialmente com a linguagem Praat, e possui uma camada implementada em PHP para comu-
nicação com a interface Web. O algoritmo utilizado para extração dos dados é baseado em no
script intitulado “SGdetector”, de autoria de Plínio A. Barbosa e adaptado por Ana C. F. Matte
pra obtenção de maior número de variáveis.
3.4. Etiquetas Semióticas
A inserção de etiquetas semióticas ainda é feita diretamente pelo pesquisador, por meio
de uma interface web que organiza os dados como atributos da classe Grupo Acentual. A in-
terface possibilita a replicação automática de entradas e a criação de diferentes atributos con-
forme o tipo de análise. Criada para a inserção de dados provenientes de análises semióticas,
a interface confere à ferramenta maleabilidade suficiente para a inserção de qualquer tipo de
dado qualitativo para fins de análise estatística paramétrica ou não, por exemplo, informações
circunstanciais sobre a coleta e/ou classificações do corpus [Mendes 2009].
4. Conclusão4 65
Setfon: Sistema Open Source para produção e organização de Semioetiquetas Fonológicas
O sistema, registrado no Sourceforge.net5 como GPL v.2, atingiu os objetivos esperados, pos-
sibilitando um aumento significativo na coleta de dados para estudos fonoestilísticos. Vários
processos usualmente manuais passaram a ser automatizados e padronizados, com a utilização
do Setfon.
Embora o sistema signifique um passo importante para o campo dos estudos da fala,
existem várias melhorias que ainda podem ser exploradas, tais como: incorporar um compo-
nente de reconhecimento de fala (permitindo a geração do texto a partir do arquivo de som),
oferecer um recurso que possibilite uma interação assíncrona (para minimizar a conectividade
entre cliente/servidor durante o processamento), criar um framework que ofereça recursos es-
pecíficos de estudos da fala e oferecer as funcionalidades do Setfon sob uma arquitetura de
Web Service.
Referências Bibliográficas
Barbosa, P. A. (1996) “At least two macrorhythmic units are necessary for modeling Brazilian
Portuguese duration: emphasis on segmental duration generation” In: Cadernos de Estudos
Lingüísticos, 31, 1, Brasil.
Barbosa, P. A. (2006) “Incursões em torno do Ritmo da Fala”, Campinas: Pontes Editores, v.1,
1.
Brito, P. H. da S.; Barbosa, M. A. M.; Guerra, P. A. de C. & Rubira, C. M. F. (2005) “Um Processo
para o Desenvolvimento Baseado em Componentes com Reuso de Componentes”, Brasil.
Marcus, S. M. (1981) “Acoustic determinants of Perceptual –Center (p-center) location” In: Per-
ception and Psychophysics, 30, 3.
Matte, A. C. F. (2004) “Relating emotional content to speech rate in Brazilian Portuguese” In:
SP2004 CD-ROM Proceedings , Speech Prosody 2004, Nara, Japão.
Matte 2006: Matte, A. C. F. , SL: inclusão social e pesquisa de ponta na Letras da UFMG, In: Pro-
gramação do 7.o FISL, Porto Alegre, 2006.
Mendes, C. (2009) “A Expressão e o Conteúdo da Fala do Jornal Nacional”, Programa de Pós-
Graduação em Estudos Lingüísticos, Universidade Federal de Minas Gerais (UFMG), Coorde-
nação de Aperfeiçoamento de Pessoal de Nível Superior.
4
Agradecimentos: Adelma Araújo, Alexandro Meireles, Cecilio C. Fraguas, Conrado Mendes, Daniervelin Pereira, Leo-
nardo Amaral, Marcos P. Rebello, Mônica Santos e Plínio A. Barbosa.
5
http://www.sourceforge.net/projects/setfon
 67

Sessão III
Engenharia de Software

68 Avaliando a Qualidade de Conjuntos de Teste de Produ-

tos de Software de Código Aberto por meio de Critérios
de Teste Estruturais

Adriana Rocha (UFG), André Rincon (UFG/UFTO), Márcio Eduar-

do Delamaro (ICM/USP), José Carlos Maldonado (ICM/USP), Auri
Marcelo Rizzo Vincenzi (UFG)

74 Extensões para Refatoração de Código Fortran no Eclipse

Bruno Boniati (UFSM), Gustavo Rissetti (UFSM), Andrea Charao

(UFSM), Eduardo Piveta (UFSM)

80 Nodipo: ferramenta de levantamento colaborativo de

requisitos para software livre

José Eduardo De Lucca (UFSC), Yuri Cardenas (UFSC)

86 Spider-MPlan: Uma Ferramenta para Apoio ao Processo

de Medição do MPS.BR

Sandro Ronaldo Bezerra Oliveira (UFPA), Bernardo Estácio

(UFPA)
 68
XI Worshop sobre Software Livre
Avaliando a Qualidade de Conjuntos de Teste de
Software de Código Aberto por meio de Crité-
rios de Teste Estruturais*
Adriana Rocha1, André Mesquita Rincon1, 2, 3, Márcio Eduardo Delamaro4,
José Carlos Maldonado4 e Auri Marcelo Rizzo Vincenzi1
1
Instituto de Informática – INF/UFG – Goiânia, GO
{adriana,andrerincon,auri}@inf.ufg.br
1
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas
Universidade do Tocantins – UNITINS – Palmas, TO
3
Instituto Federal de Educação, Ciência e Tecnologia do Tocantins – IFTO –
Paraíso do Tocantins, TO
4
Instituto de Ciências Matemáticas e de Computação – ICMC/USP – São Carlos, SP –
{delamaro, jcmaldon}@icmc.usp.br
Abstract. QualiPSo (Quality Platform for Open Source Software) is an international pro-
ject investigating Free/Libre/Open Source Software (FLOSS) products to define quality requi-
rements that are important in establishing the trustworthiness of these products. One of the
supported activities of QualiPSo aims at evaluating the quality of the test sets developed by the
FLOSS community. This paper presents the results of employing structural testing criteria as a
measure of quality for such a test sets aiming at identifying the state-of-practice played by the
FLOSS community and contributing to the establishment of an incremental testing strategy to
evolve the test sets.
1. Introdução
Existem sinais de uma ampla divulgação dos conceitos de código aberto na indústria e no go-
verno. Grandes empresas como IBM e Nokia já consideram código aberto em suas operações
de pesquisa e desenvolvimento. Governos dos países membros da União Européia, do Brasil e
da China consideram Free/Libre/Open Source Software (FLOSS) como uma oportunidade chave
para o desenvolvimento de uma indústria de software independente [QualiPSo 2008]. No en-
tanto, ainda há uma relutância quanto à adoção massiva de FLOSS devido, principalmente, à
falta de “confiança” nesses produtos [QualiPSo 2008]. Segundo Meirelles [Meirelles 2003], em
termos quantitativos, a utilização de FLOSS ainda é expressivamente inferior à utilização de
alternativas proprietárias.
A falta de “confiança” está relacionada a aspectos jurídicos, de qualidade (por exemplo:
ciclo de desenvolvimento, suporte, confiabilidade e desempenho) e também por um modelo
de negócio que possa garantir sustentabilidade. Neste contexto, o QualiPSo [QualiPSo 2008] é
considerado um projeto integrado que visa consolidar a aliança natural da indústria e do gover-
* Este trabalho conta com o apoio do CNPq (Processo 570917/2008-5), CAPES e Projeto QualiPSo -Quality Platform for
Open Source Software (Grant Number IST-FP6-IP-034763).
no com FLOSS provendo o nível de qualidade que a indústria necessita relacionado a aspectos 69
legais e de modelos de negócio.
Avaliando a Qualidade de Conjuntos de Teste de Software de Código Aberto por meio de Critérios de Teste Estruturais
Este trabalho está inserido no contexto deste projeto e atua em uma das atividades do
projeto que visa obter informações sobre FLOSS de modo a “encontrar” requisitos de qualidade
que possam ser importantes no estabelecimento de confiança (trustworthness) a esses pro-
dutos. Neste contexto, o trabalho está voltado para avaliação da qualidade dos conjuntos de
testes criados pelas comunidades de desenvolvimento de FLOSS utilizando, para isso, critérios
de testes estruturais. O objetivo é identificar o estado da prática da comunidade na criação de
conjuntos de teste e, posteriormente, contribuir no estabelecimento de uma estratégia de teste
que contribua para a evolução dos conjuntos de teste existentes.
O texto está organizado da seguinte forma: a Seção 2 dá uma visão geral sobre os
processos de teste e desenvolvimento utilizados pelas comunidades que desenvolvem FLOSS;
a Seção 3 mostra os resultados parciais obtidos na avaliação de projetos FLOSS; e, por fim, a
Seção 4 traz as considerações finais e trabalhos futuros.
2. Processo de Teste em FLOSS
Embora ainda seja pequena a utilização de produtos FLOSS pela indústria, existe uma tendên-
cia de crescimento na adoção desse tipo de software uma vez que um número cada vez maior
de indústrias opta por tais soluções. Um dos fatores que dificulta a adoção é a incerteza nos
processos de garantia de qualidade adotados em tais produtos. Pode-se dizer que os processos
de teste empregados pelas comunidades que desenvolvem FLOSS ainda é uma incógnita. Um
estudo realizado por Zhao e Elbaum (2003) mostrou que 80% dos desenvolvedores de FLOSS
não criavam planos de teste.
Um dos agravantes para isso é que as atividades de análise e projeto de produtos FLOSS
não são bem planejadas pelas comunidades de desenvolvimento, seja devido à visão de curto
prazo e não comercial que caracteriza muitos projetos FLOSS, ou pelo fato de muitos terem sido
iniciados para resolver problemas particulares de um usuário sem uma visão de longo prazo e
uma percepção real da inovação e grau de evolução que o projeto poderia ter no futuro [Mo-
rasca et al. 2009].
Mockus et al. (2000) afirmam que o desenvolvimento de FLOSS é radicalmente diferente
da indústria de Closed Source Software (CSS) pois, no desenvolvimento de FLOSS, encontram-
se as seguintes características: o trabalho não é atribuído (as pessoas se comprometem ao
trabalho que optaram por realizar); não existe um sistema explícito e nem um plano de projeto;
e não há um cronograma ou uma lista de produtos a serem construídos. No entanto, apesar de
não seguir um processo formal de desenvolvimento, os resultados obtidos pelas comunidades
que desenvolvem FLOSS são considerados equivalentes ou até superiores os das organizações
que desenvolvem CSS. Alega-se, por exemplo, que os defeitos são encontrados e resolvidos
mais rapidamente, pois há “muitos olhos” voltados para os problemas. Além disso, acredita-se
que o código é escrito com mais cuidado e criatividade, porque os desenvolvedores estão tra-
balhando apenas em coisas para as quais eles tem uma verdadeira paixão, além da exposição
de suas habilidades de programação [Raymond 2000] apud [Mockus et al. 2000].
Decorrente dessas características do modelo de desenvolvimento de FLOSS, como pou-
co foco no planejamento e na especificação de requisitos, quando um produto FLOSS evolui, ge-
ralmente o principal artefato que é considerado nesse processo de evolução é o código fonte.
Segundo Zaidman et al. (2008) acredita-se que códigos de teste e códigos de produção
devam ser desenvolvidos e mantidos de forma síncrona, pois: 1) Novas funcionalidades devem
 70 ser testadas o mais breve possível no processo de desenvolvimento, por exemplo, por meio 71
Tabela 1. Número de requisitos gerados e cobertura dos testes para cada
de testes de unidade, muito disseminados na comunidade FLOSS; 2) Quando mudanças são um dos critérios da ferramenta JaBUTi.
XI Worshop sobre Software Livre

Avaliando a Qualidade de Conjuntos de Teste de Software de Código Aberto por meio de Critérios de Teste Estruturais
aplicadas, a preservação de comportamento do software precisa ser verificada; e 3) Mesmo
quando as alterações preservam o comportamento, os testes podem ser invalidados, pois pe-
quenas alterações no código de produção podem ter sérias consequências sobre a cobertura
de código que o conjunto de teste irá abranger [Elbaum et al. 2001].
Sendo assim, considera-se que o processo de construção de conjuntos de testes em-
pregados pelas comunidades, deve ser analisado na busca por requisitos que possam auxiliar
no estabelecimento de confiabilidade a produtos FLOSS e até mesmo na melhoria do processo
de geração de casos de teste.
3.1. Resultados parciais

3. Experimentos realizados A Tabela 2 apresenta as médias de cobertura obtidas para cada um dos cinco produtos
avaliados. Cada coluna mostra o número de requisitos cobertos (COV Req) pelo número total de
A grande maioria dos produtos FLOSS investigados possuem um conjunto de teste funcional requisitos gerados (Total Req) para os critérios de testes independentes de exceção e a porcen-
(caixa-preta) criado pela comunidade de desenvolvimento visando a verificação constante do tagem de cobertura obtida para cada projeto. Por exemplo, para o Log4J, considerando o critério
FLOSS desenvolvido. Uma pergunta natural seria: “Qual a qualidade desses conjuntos de tes- All-Nodesei foram cobertos 2.173 de um total de 5.280 requisitos, ou seja, uma cobertura de
tes funcionais?”. Nos experimentos realizados, a qualidade de tais conjuntos foi avaliada em 41,08%. Analogamente, a Tabela 3 mostra os resultados de cobertura para os critérios de testes
relação a critérios de teste estruturais visando investigar qual a porcentagem de cobertura dependentes de exceção. De modo geral, observa-se que os resultados gerais apresentados nas
de código de produção que é efetivamente executada pelos testes funcionais disponibilizados Tabelas 2 e 3 deixam claro que a qualidade dos conjuntos de testes desenvolvidos é questionável
juntamente com o código fonte de produtos FLOSS. do ponto de vista da cobertura obtida. A maior cobertura obtida foi em relação ao critério All-
Tal avaliação foi conduzida com a ferramenta de teste JaBUTi1, que apóia a aplicação Nodes-ei para o Log4J (41,08%). Em muitos casos a cobertura foi inferior a 5% dos requisitos e em
de oito critérios estruturais, sendo que seis deles foram utilizados: All-Nodesei, All-Nodesed, All- outros não chegou a atingir nem 1% (como no caso do critério todos os arcos do subconjunto de-
Edgesei, All-Edgesed, All-Usesei e All-Usesed. Para mais informações sobre a ferramenta, o leitor pendente de exceção do JMeter – Tabela 3). Tal situação demonstra a necessidade de definição de
interessado pode consultar a página do projeto. A diferença entre os critérios ei (exception uma estratégia de testes incremental para a melhoria da qualidade desses conjuntos de teste.
independent) e ed (exception dependent) é decorrente da presença de tratamento de exce-
Tabela 2. Cobertura de código para critérios independentes de exceção.
ção da linguagem Java. Ou seja, os critérios seguidos de ei produzem requisitos de teste que
All-Nodes-ei All-Edges-ei All-Uses-ei All-Pot-Uses-ei
podem ser executados sem a necessidade de ocorrência de exceção, ao passo que aqueles Critério/OSS
Cov Reg/Total Reg(%) Cov Reg/Total Reg(%) Cov Reg/Total Reg(%) Cov Reg/Total Reg(%)
seguidos de ed geram requisitos que, necessariamente, exigem que uma exceção seja gerada
8.029 / 40.703 7.476 / 45.098 19.720 / 126.246 67.847 / 458.843
HSQLBD
para serem cobertos. (19,73%) (16,58%) (15,62%) (14,79%)
Até o momento, cinco projetos foram analisados (HSQLDB, JMeter, JUnit, Log4J e PMD). 7.845 / 20.462 5.461 / 19.317 10.935 / 41.180 33.615 / 130.547
JMeter
(38,34%) (28,27%) (26,55%) (25,75%)
O processo de avaliação foi conduzido da seguinte forma: 1) download da última versão dispo-
nível do software; 2) configuração do ambiente de teste (variáveis, diretórios, bibliotecas); 3) 1.475 / 6.243
JUnit 608 / 1.951 (31,16%) 380 / 1.436 (26,46%) 631 / 2.624 (24,05%)
(23,63%)
preparação das aplicações (instrumentação do código) para que as informações de cobertura
2.173 / 5.290 1.956 / 5.173 4.243 / 10.416 10.286 / 26.881
de código possam ser coletadas durante a execução dos testes; 4) execução dos testes uni- Log4J
(41,08%) (37,81%) (40,74%) (38,26%)
tários do JUnit com a ferramenta JaBUTi; 5) coleta e análise dos resultados; e 6) Geração de 7.938 / 21.184 6.858 / 23.249 13.331 / 57.552 38.404 / 252.261
PMD
relatórios de cobertura por método, por classe e por projeto. (37,47%) (29,50%) (23,16%) (15,22%)

Com intuito de apresentar o processo de coleta e análise de dados que foi realizado,
considere o programa Log4J que é composto por 276 classes, totalizando 8.543 LOC (Lines of
Tabela 3. Cobertura de código para critérios Dependentes de Exceção
Code). Parte das classes desse programa e a cobertura do seu conjunto de teste funcional são
All-Nodes-ei Cov Reg/ All-Edges-ei Cov Reg/ All-Uses-ei Cov Reg/ All-Pot-Uses-ei Cov
apresentadas na Tabela 1. Por exemplo, para a classe SMTPAppender, o critério All-Nodesei Critério/OSS
Total Reg(%) Total Reg(%) Total Reg(%) Reg/Total Reg(%)
gerou 144 requisitos de teste (#REQ) dos quais 49 foram cobertos (#COV); uma cobertura de 3.591 / 38.032
HSQLBD 141 / 1.942 (7,26%) 49 / 6.513 (0,75%) 256 / 2.750 (9,31%)
34% (%COV). Para a classe SocketAppender(terceira classe), considerando o mesmo critério, (9,44%)

foram gerados 49 requisitos mas nenhum deles foi executado pelos casos de teste. Esses da- JMeter 51 / 1.541 (3,31%) 39 / 4.863 (0,80%) 52 / 2.093 (2,48%) 276 / 15.301 (1,80%)

dos foram coletados para todas as classes de determinado programa e a média de cobertura JUnit 12 / 156 (7,69%) 9 / 184 (4,89%) 13 / 183 (7,10%) 29 / 632 (4,59%)

em relação a cada critério foi calculada. Os resultados são apresentados nas Tabelas 2 e 3. Log4J 30 / 544 (5,51%) 10 / 973 (1,03%) 41 / 604 (6,79%) 186 / 3.773 (4,93%)

1.689 / 20.285
PMD 325 / 2.039 (15,94) 121 / 3.814 (3,17%) 388 / 3.590 (10,81%)
(8,33%)
1
Ferramenta de teste JaBUTi. Disponível em: http://ccsl.ime.usp.br/en/project/jabuti/.
 72 Além dos dados de cobertura, a ferramenta JaBUTi também computa, para cada classe, • Concluir a estratégia de testes incremental visando aumentar a qualidade dos con- 73

uma série 27 métricas orientadas a objeto, dentre elas, a complexidade ciclomática de McCabe, juntos de testes empregados pelas comunidades de desenvolvimento de FLOSS.
XI Worshop sobre Software Livre

Avaliando a Qualidade de Conjuntos de Teste de Software de Código Aberto por meio de Critérios de Teste Estruturais
o acoplamento entre objetos, falta de coesão entre métodos, dentre outras. Um exemplo de
parte dessas métricas computadas para o Log4J é mostrado na Tabela 4.
Referências

Tabela 4. Exemplos de métricas Orientadas a Objetos computadas pela JaBUTi

Com base nos dados computados, os estudos atuais buscam o estabelecimento de
uma estratégia de teste incremental. Por exemplo, dado que se tenha um conjunto de classes
que não tiveram boa cobertura, as métricas de software podem ser utilizadas para ordenar as
classes de modo a priorizar para quais delas serão desenvolvidos novos casos de teste. Isto é,
após a execução dos testes (por exemplo, do JUnit), é possível ordenar todas as classes que ti-
veram cobertura de requisitos igual ou inferior a determinada cobertura mínima e estabelecer
uma ordem entre elas, seja pelo maior tamanho (LOC), pela complexidade ciclomática (CC)
ou pelas que possuem maior acoplamento. O objetivo é priorizar os testes daquelas classes
que irão contribuir de forma mais significativa para a melhoria da qualidade do produto de
software em teste.
4. Considerações Finais
Os dados obtidos até o momento e as análises preliminares demonstram que os conjuntos de
teste disponibilizados junto aos produtos FLOSS apresentam coberturas de código inferior a
42% considerando todo o código do produto avaliado. Sendo esse o melhor caso, isso significa
que os produtos são liberados para uso com mais de 50% do código não sendo executado por
nenhum caso de teste.
A partir desses resultados iniciais, verificou-se a necessidade de uma avaliação mais
detalhadas desses projetos FLOSS para que outros elementos importantes possam ser iden-
tificados no estabelecimento da confiabilidade a esses produtos como, por exemplo, a real
importância de códigos de produção que não são cobertos por nenhum caso de teste, pois eles
poderiam ser reavaliados para verificação da sua real necessidade na lógica do programa pos-
sibilitando uma otimização do código de produção e até a diminuição de defeitos causada por
códigos que “nunca” são executados.
Como foi dito anteriormente, este trabalho está inserido em um contexto maior que é o
Projeto QualiPSo e, para dar continuidade à execução do projeto, tem-se os seguintes trabalhos
futuros:
Elbaum, S., Gable, D., and Rothermel., G. (2001). The impact of software evolution on code cov-
erage information. In ICSM ’01: Proceedings of the IEEE International Conference on Software
Maintenance (ICSM’01), pages 170–179, Washington, DC, USA. IEEE Computer Society.
Meirelles, F. S. (2003). Pesquisa Anual - Administração de Recursos de Informática - CIA - Centro
de Informática Aplicada. FGV/EAESP.
Mockus, A., Fielding, R. T., and Herbsleb, J. (2000). A case study of open source software devel-
opment: the apache server. In ICSE ’00: Proceedings of the 22nd international conference on
Software engineering, pages 263–272, New York, NY, USA. ACM.
Morasca, S., Taibi, D., and Tosi, D. (2009). Towards certifying the testing process of open-source
software: New challenges or old methodologies? In Emerging Trends in Free/Libre/Open
Source Software Research and Development, 2009. FLOSS ’09. ICSE Workshop on, pages
25–30.
QualiPSo (2008). Quality Platform for Open Source Software: Trust and Quality in Open Source
Systems. Página Web do Projeto QualiPSo. Disponível em: HTTP://www.qualipso.org/. Acesso
em 20/01/2010.
Raymond, E. S. (2000). The cathedral and the bazaar. O’Reilly & Associates, Inc., Sebastopol,
CA, USA.
Zaidman, A., Rompaey, B. V., Demeyer, S., and Deursen, A. v. (2008). Mining software reposi-
tories to study co-evolution of production & test code. In ICST ’08: Proceedings of the 2008
International Conference on Software Testing, Verification, and Validation, pages 220–229,
Washington, DC, USA. IEEE Computer Society.
Zhao, L. and Elbaum, S. (2003). Quality assurance under the open source development model.
J. Syst. Softw., 66(1):65–75.

• Continuar o processo de análise da cobertura de código em projetos FLOSS desen-

volvidos em Java (ao todo serão 27);
• Realizar uma avaliação comparativa entre as diversas versões disponíveis nos pro-
jetos FLOSS para verificar se os conjuntos de teste evoluem na mesma proporção
que o código do produto;
 74
XI Worshop sobre Software Livre
Extensões para Refatoração
de Código Fortran no Eclipse
Bruno B. Boniati , Gustavo Rissetti , Andrea S. Charão , Eduardo K. Piveta
1 2 2 2
Colégio Agrícola de Frederico Westphalen (CAFW)
1
Universidade Federal de Santa Maria (UFSM)
Caixa Postal 54 – 98.400-000 – Frederico Westphalen – RS – Brasil
2
Departamento de Eletrônica e Computação – Universidade Federal de Santa Maria
(UFSM) – Santa Maria – RS – Brasil.
brunoboniati@gmail.com, {rissetti,andrea,piveta}@inf.ufsm.br
Abstract. Refactoring is a software engineering technique aiming to perform internal
changes in application source code, without influencing its behaviour. In scientific computing,
in which there is a lot of legacy code, refactoring is not enough explored, because such ap-
plications are written in non-object oriented languages, such as Fortran. In this context, we
explore this field by the development and deploying of new refactorings for the Eclipse IDE,
using the Photran framework (a plugin for Fortran programming integrated into Eclipse).
Resumo. Refatoração é uma técnica de engenharia de software que visa aplicar
mudanças internas no código-fonte de aplicações, sem afetar seu comportamento observá-
vel. Na computação científica, onde existem muitos códigos legados, a refatoração é pouco
explorada, pois tais códigos são escritos em linguagens não orientadas a objetos, como
Fortran. Este trabalho explora tal lacuna através do desenvolvimento e disponibilização de
extensões de refatoração para o ambiente integrado de desenvolvimento Eclipse, utilizan-
do-se do framework Photran (um plugin para programação Fortran integrado ao Eclipse).
1. Introdução
A evolução é uma propriedade natural em processos de desenvolvimento de software. Du-
rante o ciclo de vida de um sistema, geralmente existe necessidade de evolução do sof-
tware, seja para a adição de um novo requisito, ou para a alteração de funcionalidades
existentes. O problema é que nem sempre o sistema está preparado para receber novos
requisitos ou para suportar adaptações em suas funcionalidades. Dependendo de como
essas alterações são feitas, elas podem acabar degradando a qualidade e enfraquecendo o
projeto original do sistema.
Refatoração é uma técnica de evolução que consiste na aplicação de transforma-
ções na estrutura interna de aplicações, sem que isso afete seu comportamento observável
[Fowler et al. 1999, Opdyke 1992]. Tal técnica é empregada com o intuito de melhorar a
qualidade de software durante o ciclo de vida das aplicações.
As refatorações estão fortemente vinculadas ao paradigma da orientação a objetos
e estão presentes de forma automatizada em diversas ferramentas alinhadas com este pa-
radigma. Na computação científica, a refatoração de código é uma técnica pouco explorada, 75
principalmente em função de que boa parte do código legado de tais aplicações está escrita
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
em linguagens procedurais [Johnson et al. 2006]. Esse é o caso do Fortran, uma linguagem
estruturada cuja gramática original já possui mais de cinquenta anos e que, ainda hoje, é
amplamente utilizada em aplicações científicas.
Este artigo descreve a automação de um conjunto de refatorações para código em
Fortran, implementadas como extensões ao framework Photran do Eclipse, que é um popu-
lar ambiente integrado de desenvolvimento (Integrated Development Environment - IDE).
Essa automação visa reduzir a lacuna existente entre a grande quantidade de código legado
escrito em Fortran e o reduzido número de IDEs voltadas para essa linguagem, distribuídas
como software livre.
O artigo está organizado como segue. A Seção 2 apresenta os recursos e as caracte-
rísticas do Eclipse e do Photran, bem como os requisitos para desenvolvimento e integração
de ações de refatoração ao IDE. A Seção 3 descreve as extensões desenvolvidas, incluindo
sua forma de atuação, questões de implementação e eventuais limitações. Por fim, a Seção
4 apresenta as considerações finais e as possibilidades de trabalhos futuros.
2. Eclipse e Photran
O Eclipse é um IDE com suporte para diversas linguagens, tais como Java, C e C++. Re-
centemente, por meio do plugin Photran, o Eclipse passou também a suportar a linguagem
Fortran, em suas versões 77, 90, 95 e 2003. No texto Eclipse Plataform Technical Overview,
o Eclipse é definido como “uma IDE para nada, e para nada em particular” [Beaton and des
Rivieres 2006]. Isso caracteriza um pouco da filosofia de desenvolvimento do Eclipse, que
é fortemente baseada na idéia de plugins, os quais são estendidos para prover em um só
ambiente de desenvolvimento uma série de funcionalidades de suporte ao desenvolvimento
de software.
Arquiteturalmente pode-se compreender o framework do Eclipse como sendo uma
aplicação que disponibiliza uma interface gráfica padrão (com menus, barras de ferramen-
tas, editores, etc.), na qual as funcionalidades são implementadas por meio de plugins. Um
plugin é um artefato de software conectável por meio de uma interface padrão a outros
artefatos. O núcleo do Eclipse (microkernel) implementa mecanismos para a descoberta
dinâmica dos plugins. O gerenciamento das funções do ambiente é feito pelo núcleo e cada
plugin responsabiliza-se por tarefas com escopo bem definido.
O Photran [Eclipse.org 2010] é um plugin para o Eclipse que estende as funciona-
lidades do IDE para suportar o desenvolvimento de código Fortran. Atualmente, seu de-
senvolvimento é mantido como um projeto oficial da Eclipse Foundation e faz parte de um
macro projeto denominado PTP (Parallel Tools Platform). O objetivo do projeto PTP é explorar
a deficiência de ferramentas para computação científica [Watson and DeBardeleben 2006]
e de alto desempenho [Vanter et al. 2005], organizando em torno do IDE do Eclipse ferra-
mentas para o desenvolvimento, a depuração, a distribuição e o monitoramento de tais
aplicações.
Um dos objetivos do projeto Photran é disponibilizar um framework que possibilite o
desenvolvimento rápido de ações de refatoração para código Fortran, reutilizando a infra-
estrutura fornecida pelo Eclipse [De 2004]. Para isso, são utilizadas reescritas de árvores
sintáticas abstratas (ASTs), as quais são manipuladas através da adição, da modificação e
da remoção de nós e informações desses nós em suas estruturas.
 76 3. Extensões Desenvolvidas
XI Worshop sobre Software Livre
A automação de ações de refatoração normalmente requer a existência de um analisador sin-
tático específico para a linguagem de programação com a qual se deseja trabalhar. A análise
sintática utiliza algoritmos para a decomposição de sentenças de um código-fonte a partir de
uma gramática formal e constrói uma árvore gramatical (AST, Abstract Syntax Tree) [Aho et al.
2006].
O plugin Photran disponibiliza, além de métodos para construção e manipulação da
AST, uma estrutura denominada VPG (Virtual Program Graph). Um VPG agrega às ASTs algumas
ligações adicionais entre seus nós. Essas ligações podem representar, por exemplo, um vínculo
entre a utilização de determinada variável (em uma expressão) e sua respectiva declaração, ou
ainda um comando e seu escopo (bloco lógico de atuação).
Através de uma VPG é possível obter um conjunto bastante rico de informações para
auxiliar na manipulação dos nós de uma AST. A construção de ações de refatoração para a
ferramenta Photran é feita a partir de um conjunto base de classes que são estendidas e da
implementação de métodos de pré-validação, manipulação e pós-validação das ASTs. A utiliza-
ção dessas ferramentas abstrai do programador a ação direta sobre o código-fonte, respeitando
eventuais dependências e interligações entre suas entidades.
Neste trabalho, foram automatizadas algumas técnicas de refatoração aplicadas a ca-
racterísticas da linguagem Fortran, utilizando-se o framework Photran. As técnicas selecionadas
objetivam a evolução da linguagem (refatoração de código escrito para determinada versão de
Fortran, substituindo-o por construções de uma versão mais recente) e organização de código
(refatorações que afetam apenas aspectos ligados ao projeto do código-fonte, facilitando a ma-
nutenção de código). A seguir, são detalhadas as técnicas de refatoração automatizadas.
3.1. Substituir Operadores Obsoletos
Dentre as várias evoluções sintáticas pelas quais Fortran tem passado ao longo do tem-
po, uma delas é a forma de representação dos operadores relacionais (por exemplo, o operador
de igualdade .EQ. é equivalente ao sinal ==). Em geral, as construções mais recentes são mais
facilmente entendidas, principalmente por programadores menos experientes em Fortran.
A substituição de operadores obsoletos consiste na alteração de símbolos obsoletos da
linguagem, que nesse caso são operadores relacionais, por suas construções mais recentes. É
uma técnica ligada à evolução e ao projeto do código-fonte. Sua mecânica de funcionamento
consiste em percorrer a árvore sintática em busca de nós que representem operadores. Ao
identificar uma construção obsoleta, o texto do token correspondente é alterado para o novo
formato do operador relacional.
3.2. Extrair Subrotina
Extrair uma subrotina consiste em escolher um fragmento de código e transformá-lo no
corpo de um novo subprograma substituindo o fragmento original por uma chamada ao novo
subprograma. A principal problemática de longos trechos de código é a excessiva informação
que fica oculta pela complexidade da lógica associada [Fowler et al. 1999].
Para extrair uma subrotina é preciso indicar um conjunto de linhas no editor de código
e um nome para a nova subrotina. A ação de refatoração deve verificar dentro do conjunto
de comandos selecionados para extração se existe a utilização de variáveis. Se não existirem
variáveis, a refatoração deve simplesmente declarar um novo subprograma (SUBROUTINE) con-
tendo o código selecionado pelo programador e no lugar do código que foi selecionado deve 77
ser incluído uma chamada ao subprograma (no caso do Fortran, através do comando CALL). Se
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
houver utilização de variáveis no código a ser extraído é necessário transformá-las em parâme-
tros (caso sejam utilizadas além do código a ser extraído) ou então declará-las como variáveis
locais dentro da nova subrotina (quando não são utilizadas externamente ao código extraído).
3.3. Introduzir Intenção
O atributo INTENT é uma construção relativamente recente (versão 90 do Fortran) e é
utilizada para especificar a intenção de uso de determinado argumento em um subprograma.
São três formas possíveis de indicar a intenção de uso de um argumento com o atributo INTENT:
IN (quando o atributo somente é referenciado), OUT (se o atributo sofre somente alteração sem
ser previamente referenciado) e INOUT (se o atributo é referenciado e alterado).
A automação da refatoração Introduce INTENT pressupõe a indicação por parte do pro-
gramador de um subprograma no qual a refatoração atuará e também que o escopo do sub-
programa indicado seja implicit none, ou seja, exija a declaração explícita dos tipos de dados
utilizados1. A declaração explícita pode ser conseguida através da refatoração Introduce Implicit
None (disponível na ferramenta Photran).
A mecânica da refatoração detecta todas as declarações do subprograma que são ar-
gumentos do mesmo e verifica no corpo do subprograma que tipo de ação estes argumentos
sofre. As ações podem ser basicamente duas: referência (em expressões, por exemplo) ou
alteração (atribuição e leitura). Uma vez detectados os parâmetros e as ações que os mesmos
sofrem, é possível inferir o tipo de INTENT.
3.4. Remover Variáveis Não Utilizadas
Normalmente, durante a codificação de um programa, podem sobrar variáveis inutiliza-
das, muitas vezes, por descuido do programador, que comenta algum bloco do código que não
será mais utilizado sem remover as variáveis utilizadas exclusivamente no bloco. A eliminação
de variáveis não utilizadas possibilita diminuir o tamanho do código-fonte e o tamanho do códi-
go executável gerado, além de melhorar sua legibilidade.
A mecânica de funcionamento desta refatoração consiste em percorrer as ASTs em bus-
ca de nós que representem a definição de variáveis. Quando uma definição de variável encon-
trada não possui nenhuma referência no código-fonte, significa que ela nunca foi usada depois
de sua declaração. Assim essa definição de variável sem referências consiste em uma das
variáveis esquecidas do código, e deve, portanto, ser eliminada da AST, para que o objetivo da
refatoração seja alcançado.
3.5. Padronizar Sentenças
Na linguagem Fortran, variáveis podem ser declaradas de diferentes maneiras (uma
variável por declaração ou múltiplas variáveis de mesmo tipo na mesma declaração). Essa mis-
tura de gêneros de declarações (comum em grandes projetos de software, onde estão envolvi-
dos diferentes desenvolvedores) pode dificultar a leitura de código, uma vez que uma grande
lista de variáveis pode ser declarada, e quando o leitor do código chega ao final de tal lista, não
lembra mais qual era o tipo de declaração das variáveis, por exemplo.
1
Fortran permite que as variáveis utilizadas não sejam previamente declaradas, neste caso considerando que variá-
veis que iniciem com as letras I..N sejam do tipo INTEGER e as demais do tipo REAL.
 78 A mecânica de funcionamento desta refatoração consiste em percorrer as ASTs em bus-
ca de nós que representem a declaração de variáveis. Quando alguma ocorrência de nós desse
XI Worshop sobre Software Livre
tipo for encontrada, deve ser verificada a existência de uma única declaração de variável pre-
sente no nó ou se o nó consiste em uma lista de declaração de variáveis. Caso seja uma lista
de declaração de variáveis, devem ser criados novos nós de declaração, cada um contendo
apenas uma variável que estava contida na lista de declaração do nó original. Assim, no final da
refatoração todas as declarações de variáveis ficam padronizadas, com uma variável declarada
em cada nó, sempre contendo o sinal de dois pontos utilizados na declaração, por exemplo,
integer :: variável.
3.6. Dado para Parâmetro
No Fortran, uma variável pode ser inicializada de diversas formas e, usualmente, em
programas existem variáveis que são constantes, isto é, tem o seu valor definido no início do
código e nunca é alterado. No Fortran, existe um atributo que serve para esse fim, chamado
parameter. Uma variável declarada como parameter tem um valor constante que o compilador
propaga diretamente em todo o código-fonte. Porém, as vezes essa declaração é confundida
com a declaração do tipo data. Uma variável do tipo data é uma variável estática. Quando se
pensa em paralelizar um código-fonte, a fim de melhorar o desempenho, as variáveis estáticas
podem ser acessadas concorrentemente por várias linhas de execução, dificultando a progra-
mação. Por isso é vantajoso usar parameter quando se quer apenas tornar uma variável cons-
tante em todo o código-fonte.
A mecânica de funcionamento desta refatoração consiste em percorrer as ASTs em busca
de nós que representem declarações do tipo data. Quando um nó encontrado não possuir seu
valor inicial modificado ao longo do código-fonte, nos deparamos com uma variável que deveria
ser declarada com o tipo parameter, pois foi usada apenas para propagar um valor constante em
todo o código. Portanto, tal nó deve ser substituído na AST por um novo nó com a declaração da
variável do tipo parameter, preservando o nome e valor inicial que continha anteriormente.
4. Considerações Finais
As extensões foram desenvolvidas gradualmente e disponibilizadas aos desenvolvedores do
Photran. Algumas delas já se encontram integradas à versão oficial da ferramenta.
Em trabalhos anteriores [Boniati et al. 2009, Rissetti et al. 2010] buscou-se avaliar o im-
pacto do uso de técnicas de refatoração em aplicações escritas em Fortran, utilizando o código-
fonte de uma aplicação cedida pelo Laboratório de Micrometeorologia, vinculado à Universidade
Federal de Santa Maria. Essa aplicação foi escrita em Fortran 77, e é atualmente utilizada para
analisar grandes conjuntos de dados captados por sensores em estações meteorológicas. As
refatorações foram aplicadas de forma isolada, e combinadas. Em todos os casos os resultados
produzidos pela compilação e execução do código refatorado e do código não refatorado foram
os mesmos, sendo que o código refatorado apresenta melhor estruturação e legibilidade sem
comprometer o desempenho da aplicação (requisito importante em aplicações científicas).
A utilização do Photran como ferramenta de apoio à codificação e à automatização de
técnicas de refatoração merece destaque como contribuição do trabalho. Ferramentas como
o Photran representam um importante avanço no sentido de se preencher a lacuna existente
entre a grande quantidade de código Fortran e o limitado número de ferramentas livres com
técnicas de refatoração integradas.
Em relação à ferramenta Photran, existem ainda diversas questões em aberto que vão 79
desde otimizações nos mecanismos que analisam o código-fonte, até novos recursos para a
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
ferramenta e principalmente a automatização de outras técnicas de refatoração. Desde o início
de seu desenvolvimento, em meados de 2004, é possível observar um crescimento constante
no número de usuários que utilizam a ferramenta, bem como de voluntários que implementam
melhorias e lhe agregam funcionalidades.
Referências
Aho, A. V., Lam, M. S., Sethi, R., and Ullman, J. D. (2006). Compilers: Principles, Techniques, and
Tools. Addison Wesley, 2 edition.
Beaton, W. and des Rivieres, J. (2006). Eclipse Platform Technical Overview. Technical report,
The Eclipse Foundation.
Boniati, B. B., Charão, A. S., and Stein, B. O. (2009). Automação de Refatorações para Progra-
mas Fortran de Alto Desempenho. In X Simpósio em Sistemas Computacionais, pages 71–78,
São Paulo, Brasil. SBC.
De, V. (2004). A Foundation for Refactoring Fortran 90 in Eclipse. Dissertação de mestrado, Uni-
versity of Illinois, Urbana-Champaign, EUA.
Eclipse.org (2010). Photran - An Integrated Development Environment for Fortran. Disponível
em: http://www.eclipse.org/photran/. Acesso em junho de 2010.
Fowler, M., Beck, K., Brant, J., Opdyke, W., and Roberts, D. (1999). Refactoring: Improving the
Design of Existing Code. Addison Wesley.
Johnson, R., Foote, B., Overbey, J., and Xanthos, S. (2006). Changing the Face of High-Perfor-
mance Fortran Code. A White Paper.
Opdyke, W. (1992). Refactoring Object-Oriented Frameworks. Tese de doutorado, University of
Illinois, Urbana-Champaign, EUA.
Rissetti, G., Charão, A. S., and Boniati, B. B. (2010). Incorporação de Novas Refatorações para
Linguagem Fortran no IDE Eclipse. In X Escola Regional de Alto Desempenho, pages 233–
236, Passo Fundo, Brasil. SBC.
Vanter, M. L. V. D., Post, D. E., and Zosel, M. E. (2005). HPC Needs a Tool Strategy. In Second
International Workshop on Software Engineering for High Performance Computing System
Applications, pages 55–59, St. Louis, EUA. ACM.
Watson, G. R. and DeBardeleben, N. (2006). Developing Scientific Applications Using Eclipse.
Computing in Science and Engineering, 8(4):50–61.
 80
XI Worshop sobre Software Livre
Nodipo: ferramenta de levantamento
colaborativo de requisitos para software livre
José Eduardo De Lucca1, Yuri Gomes Cardenas2
1
Departamento de Informática e Estatística
2
Curso de Bacharelado em Sistemas de Informação
1, 2
Universidade Federal de Santa Catarina (UFSC) – Florianópolis – SC – Brazil
delucca@inf.ufsc.br, yuri@geness.ufsc.br
Abstract. This paper introduces a collaborative requirements elicitation tool, called Nodipo,
which aims to fill the gap of some areas where free software is not or is too little available. Based on
Web 2.0 and on researches that focus on the enduser participation on software design and require-
ments elicitation, the tool’s structure is made of elements that make possible the interaction and
collaboration between endusers and other stakeholders, so that they are able to share knowledge
about the application domain and elicit requirements with certain formalization degree.
Resumo. Este artigo apresenta a ferramenta de levantamento colaborativo de requisi-
tos Nodipo, com a qual se objetiva suprir áreas de aplicação na sociedade em que o software
livre é ausente ou pouco presente. Baseada na Web 2.0 e em estudos que levam em conta a
participação de usuários-finais no processo de elicitação de requisitos e na modelagem de sof-
tware, a estrutura da ferramenta possui elementos que viabilizam a interação e a colaboração
entre os próprios usuários-finais e os demais participantes, de forma que os mesmos possam
compartilhar conhecimento sobre o domínio da aplicação e elicitar requisitos com um nível
mínimo de formalização.
1. Estrutura do artigo
Neste artigo serão abordadas algumas das teorias que fundamentam a ferramenta apre-
sentada, tais como a Engenharia Social de Requisitos, a Modelagem Sociotécnica de Software e
a modelagem contínua inerente às comunidades de Software Livre. Em seguida, é explanado o
contexto em que a proposta do Nodipo surgiu e é detalhada a proposta, a qual é complementa-
da por uma descrição do processo de levantamento de requisitos pensado pelos idealizadores
da ferramenta. Por fim, são apresentadas as conclusões e indicado o direcionamento de traba-
lhos futuros do tema em questão.
2. Engenharia Social de Requisitos e Modelagem Sociotécnica
de Software
Hammouda et al. (2008 apud LOHMANN et al., 2009) definem a Engenharia Social de
Requisitos como a aplicação de processos, métodos e ferramentas que possibilitem a criação, o
gerenciamento, a implantação e o uso de software por comunidades em ambientes online.
Dentro da concepção de que softwares de apoio à Engenharia de Requisitos deveriam 81
conter funcionalidades que incitem a colaboração, ou seja, dar suporte à Engenharia Social
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
de Requisitos, Lohmann et al. (2009) ressaltam que o grande sucesso atual de aplicações web
focadas em comunidades deve estimular a agregação das funcionalidades colaborativas des-
sas aplicações em ambiente de Engenharia de Requisitos. Também apelidadas como software
social, essas aplicações web focadas em comunidades possuem diversas características (HIPP-
NER, 2006 apud LOHMANN et al. 2009), tais como simplicidade, colaboração ágil, auto-organi-
zação, feedback social e foco em usuários e em comunidades.
Essas características, conforme Lohmann et al. (2009), são fundamentais nos sistemas
para Engenharia de Requisitos que dão suporte à Engenharia Social de Requisitos. Ainda se-
gundo esse autor, a aplicação dos conceitos de software social em uma aplicação web pode
encorajar stakeholders não-convencionais a participar do processo de modelagem de software.
A figura 1 ilustra os conjuntos de softwares citados e suas interseções, indicando a área onde
se situa a ferramenta Nodipo.
Figura 1: Interseção entre categorias de software
Scacchi (2004), por sua vez, alerta que a participação de usuários não-treinados na mo-
delagem de software pode ser frustrante. Contudo, o autor apontava como tendência na área
as técnicas de participação contínua dos usuários, o que tange inclusive às características da
modelagem de software contínua praticada pelas comunidades de FLOSS estudadas por Gasser
et al. (dez. 2003), apresentada adiante.
Em relação à Modelagem Sociotécnica de Software, segundo Scacchi (2004), ela está
intimamente ligada à participação direta dos usuários-finais no processo de modelagem de
sistemas. Esse tipo de abordagem distingue-se dos métodos de modelagem da Engenharia de
Software tradicional, que dão maior ênfase às atividades e responsabilidades dos engenheiros
de software, os quais utilizam ferramentas (computacionais) de modelagem e notações para
obter e formalizar os resultados deste tipo de processo.
3. A modelagem contínua inerente às comunidades de FLOSS
No sentido de entender a dinâmica de desenvolvimento de FLOSS, o estudo de Gasser
et al. (2003) levantou algumas tendências, relativas a esse tipo de desenvolvimento, que são
contrárias às práticas convencionais de desenvolvimento de software para sistemas de grande
porte. São elas:
 82 • As especificações das funcionalidades, da usabilidade e da estrutura do software
não são conhecidas quando de sua modelagem e desenvolvimento. Ao invés dis-
XI Worshop sobre Software Livre
so, artefatos capturam e rastreiam continuamente as preferências dos usuários
das comunidades, o que forma um ciclo permanente de inovação. Especificações
formais ou processos de modelagem formais quase nunca são encontrados. O pró-
prio código-fonte possui, em comentários, diversos traços de discussões e debates,
constituindo, assim, uma espécie de especificação.
• Os requisitos são elicitados, analisados, especificados, validados e gerenciados atra-
vés do que se pode chamar de um conjunto de informalismos de desenvolvimento
de software (SCACCHI, fev. 2002), no lugar de processos e especificações formais.
Esse conjunto é constituído de ferramentas de compartilhamento de conhecimento
semi-estruturadas e relativamente informais, representações e práticas.
Além disso, o autor considera ser surpreendente o fato de o processo de modelagem de
FLOSS ligar diversos processos interativos, contínuos, abertos e coletivos – o que poderia facil-
mente tornar-se caótico – e ter como resultado programas eficientes, estáveis e úteis.
Portanto, ao compreender-se a modelagem contínua de projetos de software livre que
define Gasser et al. (2003), vê-se que as comunidades de software livre de maneira geral não
realizam as tarefas de levantamento, análise e especificação de requisitos como a Engenharia
de Requisitos apresenta. Mas realizam, sim, levantamento e especificação contínuos, coletiva
e colaborativamente.
4. Escassez de softwares livres em determinadas áreas
Segundo Savi e De Lucca (2007), o software livre tem presença bastante significativa em alguns
setores, nos quais novas opções de software surgem a todo o momento. Por outro lado, em
outras áreas a presença de opções livres é mais escassa e até inexistente.
Considerando a taxonomia de categorias de software proposta pelos autores, os mes-
mos afirmam que a disponibilidade está claramente nas categorias de software básico e de
infraestrutura, no setor de ferramentas para desenvolvimento de software e em outros setores
específicos como comunicação e ferramentas básicas de produtividade. Sobre exemplos em
outras áreas, Savi e De Lucca (2007) afirmam que existem, mas isoladamente e a partir de
esforços específicos, e em nada comparáveis à presença na categoria de softwares básico e de
infraestrutura, por exemplo.
De uma forma geral, por parte da comunidade de desenvolvedores de softwares livres,
existe maior interesse em fazer parte de projetos de software básico ou de softwares com gran-
de visibilidade – dos quais esses desenvolvedores também são usuários –, tais como editores
de texto e navegadores [SAVI; DE LUCCA, 2007]. A visão de Scacchi (2002) colabora com essa
constatação, pois entende que os projetos de software livre geralmente contam com usuários
que também são desenvolvedores dos mesmos softwares e, por isso, conhecem bem os requisi-
tos, as dificuldades, os recursos ausentes e os roadmaps dos mesmos e passam a implementar
as funcionalidades que desejam, pessoal ou coletivamente, nos programas.
Do outro lado, os softwares aplicativos são muito específicos. Os autores afirmam que
“a comunidade de desenvolvedores de software livre não conhecem suficientemente os requi-
sitos, as demandas e regras de negócio para poder contribuir de forma significativa” [SAVI; DE
LUCCA, 2007].
Portanto, em um domínio de aplicação com que os desenvolvedores não tenham conta-
to e em que não há acesso a software que possa servir de exemplo, a ausência de conhecimen- 83
to dos requisitos tende a prejudicar o desenvolvimento de softwares livres para atender àquela
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
demanda, como confirma Nakawaga (2006).
5. A proposta do Nodipo
Dentro do cenário em que as comunidades de software livre não participam de setores espe-
cíficos e/ou não podem colaborar efetivamente por desconhecerem os requisitos, e conhecida
a natureza do processo de levantamento de requisitos dessas comunidades, os integrantes do
Via Digital idealizaram, em 2007, uma ferramenta que atuasse como elo entre comunidades
de software livre e as prefeituras municipais na concepção das funcionalidades de softwares
necessários a estas: o Nodipo.
Disso, foi modelada e desenvolvida uma ferramenta colaborativa em que usuários sem
experiência em desenvolvimento de software podem autonomamente expressar suas neces-
sidades em relação a determinado sistema. O Nodipo oferece condições para descrição de
processos e demandas, inicialmente utilizando o discurso e conceitos do usuário especialista
do domínio, que podem ser refinados iterativamente com a participação de outros usuários e
com a intervenção de desenvolvedores para o esclarecimento de dúvidas e construção de um
nível mínimo de formalização.
Baseado na web, o Nodipo possui forte viés de colaboração assíncrona – seguindo ten-
dências da Web 2.0 –, de modo a viabilizar a interação da comunidade de usuários especialis-
tas, conhecedores do domínio de aplicação, geograficamente distantes. Por meio de funciona-
lidades de colaboração e cooperação – como debates, rankings e votações – os participantes
podem refinar suas demandas e requisitos em sucessivos ciclos para detalhar, confirmar, clas-
sificar, priorizar, agregar e/ou corrigir as necessidades inicialmente definidas, auxiliando na
compreensão do sistema desejado. Dessa forma, o Nodipo tem, em sua gênese, o conceito
de rede social; sendo, entretanto, uma rede de propósito específico, focada em levantamento
colaborativo de requisitos.
Dentro de sua meta, o Via Digital pensou os artefatos resultantes desse processo como
requisitos semiformais de um novo sistema, que podem servir de base para o desenvolvimen-
to por empresas – públicas ou privadas –, profissionais, estudantes, voluntários ou quaisquer
demais interessados.
6. Descrição do processo de levantamento de requisitos no
Nodipo
A mais notória função do Nodipo é atuar como meio integrador de diferentes participantes no
processo de elicitação de requisitos para software livre. O principal fator que distingue esses
participantes é o nível de conhecimento: tanto em desenvolvimento de software quanto em um
domínio de aplicação específico. Portanto, os desenvolvedores de software livre e os especialis-
tas de domínio são considerados os atores principais do processo de elicitação com o Nodipo.
Para melhor compreensão desse processo de interação e de levantamento colaborativo de
requisitos com o Nodipo, a figura 2 e o seguinte cenário ilustram a utilização ferramenta:
• Especialistas de determinado domínio de aplicação têm uma demanda por um
software que automatize os processos de sua área de atuação. O primeiro pas-
 84 so destes especialistas é descrever, no Nodipo, características e funcionalidades
que imaginam que o software deveria apresentar, conduzidos por um questionário
XI Worshop sobre Software Livre
configurável. A função desse questionário é obter a descrição de todas as etapas
de um processo organizacional específico, bem como dos atores e suas atuações.
A modelagem possibilita a utilização de diferentes abordagens e técnicas de en-
trevistas para a descrição de processos. No Nodipo está implementado o método
Quality Sense Making.
• Ato contínuo, as diversas visões e processos dos diferentes especialistas conduzem
a um debate sobre as características e funcionalidades cadastradas, inclusive ge-
rando a descrição de novas características.
• Os ciclos de debate e o exercício de reescrita das descrições as enriquecem conti-
nuamente, conduzindo a um potencial consenso quanto às mesmas, inclusive com
possibilidades de votações.
• A atividade avança até o momento em que os participantes concordam que as
descrições dadas às funcionalidades representam o que desejam.
Figura 2: O processo de levantamento colaborativo de requisitos com o Nodipo
O resultado do cenário apresentado é o conhecimento dos especialistas do domínio ex-
plicitado e disponível. A participação de desenvolvedores durante os debates pode levar a uma
convergência mais rápida e/ou uma definição final mais próxima da semântica da Engenharia
de Software. Já no caso de uma interferência posterior por parte de um desenvolvedor, em que
ele reescreve as definições dadas, a partir de sua compreensão de todo o histórico do debate,
é possível fazer uma segunda rodada de debates e/ou de votações, como forma de validação
da interpretação do desenvolvedor, transformando as descrições em requisitos. Outro possível
passo subsequente (este não contemplado pelo Nodipo) seria a atuação de analistas de siste-
mas/engenheiros de software sobre o resultado para a geração de especificações mais formais
de requisitos com ferramentas tradicionais.
Dado o cenário apresentado, em resumo o Nodipo foi modelado de maneira que seja
possível:
• Promover um meio de debate em relação a requisitos e características de sistemas,
aproximando a comunidade FLOSS dos sistemas aplicativos e de desenvolvedores
com especialistas de domínio;
• Obter informações semiformais dos especialistas do domínio de aplicação, através 85
dos debates, consolidados nas respostas ao questionário e nas novas versões das
Nodipo: ferramenta de levantamento colaborativo de requisitos para software livre
descrições gerais das funcionalidades;
• Observar a satisfação dos participantes quanto à elicitação de determinado requi-
sito, com a votação de concordância.
7. Conclusão
Para procurar suprir algumas áreas de aplicação em que o software livre é pouco pre-
sente foi criada a ferramenta Nodipo, cuja modelagem possui elementos característicos da
Engenharia Social de Requisitos e de softwares sociais. Esses elementos são propícios para
fomentar a interação entre integrantes das comunidades FLOSS e potenciais usuários/clientes,
de forma que os mesmos possam colaborativamente trocar conhecimentos, descrever os pro-
cessos dos sistemas e elicitar os requisitos necessários a estes.
Imaginando um cenário em que a ferramenta apresentada neste artigo é utilizada em
ampla escala, atuando como referência de repositório de requisitos de sistemas, seriam es-
pecificados muitos dos softwares das áreas de aplicação nas quais o FLOSS não é presente,
oferecendo oportunidades para a atuação de profissionais e a criação de empresas nacionais
no desenvolvimento, manutenção e suporte desses softwares.
Academicamente falando, a ferramenta pode servir como ambiente de avaliação para
métodos de coleta de requisitos baseados em entrevistas e para evolução destes métodos em
direção a uma engenharia de requisitos mais social (conforme definido).
Quanto a trabalhos futuros, parece factível e interessante a adição das características
e implementações semânticas da ferramenta do projeto SoftWiki (THE SOFTWIKI) ao Nodipo
– sendo aquele um projeto contemporâneo e de objetivos similares aos apresentados neste
artigo –, o que tenderia a complementá-lo, uma vez que o Nodipo não conta com elementos
semânticos em sua estrutura.
Referências
GASSER, Les et alli. Understanding Continuous Design in F/OSS Projects. 16th International Con-
ference on Software Engineering & its Applications (ICSSEA03), Paris, França, dezembro,
2003.
LOHMANN, Steffen; DIETZOLD, Sebastian; HEIM, Philipp; HEINO, Norman. A Web Platform for
Social Requirements Engineering. Workshopband, Alemanha, 2009.
NAKAGAWA, Elisa Y. et alli. Relevância dos requisitos no desenvolvimento de software livre. VII
Workshop Software Livre, Porto Alegre, 2006.
SAVI, Rafael; De LUCCA, José Eduardo. Produção compartilhada de software para governos mu-
nicipais. VIII Workshop de Software Livre, Porto Alegre, 2007.
SCACCHI, Walt. Understanding the Requirements for Developing Open Source Software Sys-
tems. IEE Proceedings: Software, 149(1), p 2439. fev. 2002.
SCACCHI, Walt. SocioTechnical Design. The Encyclopedia of HumanComputer Interaction. Berk-
shire Publishing Group, 2004.
THE SOFTWIKI Project. Social Requirements Engineering. Disponível em <http://softwiki.de/Pro-
ject>. Acesso em: 08 de maio de 2010.
 86
XI Worshop sobre Software Livre
Spider-MPlan: Uma Ferramenta para Apoio
ao Processo de Medição do MPS.BR
Bernardo José da Silva Estácio1, Sandro Ronaldo Bezerra Oliveira1
1
Faculdade de Computação – Instituto de Ciências Exatas e Naturais (ICEN) –Universida-
de Federal do Pará (UFPA), Rua Augusto Corrêa, 01, Belém –PA – Brasil
bernardojses@gmail.com, srbo@ufpa.br
Abstract. Spider-MPlan is a free software tool which supports the Measurement process
in the F maturity level of MPS.BR quality program. This paper presents a systematic workflow,
the purpose, the context and operation of this tool, and the results that can be obtained from
the use of this one.
Resumo. Spider-MPlan é uma ferramenta de software livre para apoio ao processo
de Medição constante nível F do programa MPS.BR. Este artigo apresenta o fluxo de negócio
sistematizado da ferramenta, bem como o seu propósito, contexto de funcionamento e os re-
sultados que podem ser obtidos com a utilização deste produto.
1. Introdução
A Engenharia de software é uma disciplina que inclui processos, métodos e ferramentas. É uma
tecnologia em camadas, onde o alicerce é a camada de processo, a qual forma a base para o
controle gerencial e estabelece um contexto no qual os métodos técnicos são aplicados e os arte-
fatos (modelo, documento, dados, relatórios, formulários, etc.) produzidos [Pressman, 2006].
De forma geral, o Processo de Software pode ser definido como um arcabouço de tarefas
para se construir softwares de alta qualidade. O Processo de Software ainda é constituído de um
arcabouço de processo, o qual descreve um conjunto de atividades que são aplicáveis a todos
os projetos de software, independentemente de seu tamanho e complexidade. A complemen-
tação do arcabouço de processo é realizada pelas atividades guarda-chuva, elas ocorrem ao
longo do processo e tem o foco na gestão, monitoramento e controle de determinado projeto
[Pressman, 2006].
A Medição é uma atividade guarda-chuva de um arcabouço de processo. Pode ser consi-
derada como ato ou processo de atribuição de um número ou a categoria a uma entidade para
descrever um atributo dessa entidade [IEEE, 1998]. A medição permite obter um entendimento
do projeto e do processo, fornecendo um mecanismo para uma avaliação objetiva [Pressman,
2006]. A implementação desta atividade pode ser obtida a partir de programas para a melhoria
do processo (modelos e normas de qualidade).
Em 2003 o programa MPS.BR (Melhoria do Processo de Software Brasileiro) [Softex, 2009a]
foi concebido com o objetivo de prover a melhoria de processo ao software brasileiro com um
custo acessível, para que possa também se adequar a realidade das micro/pequenas empresas.
Neste contexto, este artigo objetiva apresentar a Spider-MPlan, uma solução de ferra-
menta de software livre para apoio ao processo de Medição do MPS.BR. A Seção 2 aborda o pro-
cesso de Medição segundo o MPS.BR. A Seção 3 apresenta a ferramenta Spider-Mplan de forma 87
abrangente, discutindo o fluxo de atividades modelado para gerenciar o processo de negócio
Spider-MPlan: Uma Ferramenta para Apoio ao Processo de Medição do MPS.BR
adotado pela ferramenta. A Seção 4 apresenta os resultados esperados do trabalho. E por fim,
na Seção 5 são apresentadas as considerações finais.
2. O Processo de Medição segundo o MPS.BR
O programa MPS.BR é baseado no modelo MPS, o qual é alicerçado nos conceitos de maturi-
dade e capacidade de processo para a avaliação e melhoria da qualidade e produtividade de
produtos de software e serviços correlatos. Dentro desse contexto, o modelo MPS possui três
componentes: Modelo de Referência (MR-MPS), Método de Avaliação (MA-MPS) e Modelo de
Negócio (MN-MPS) [Softex, 2009a]. O Modelo de Referência de processo é um modelo que com-
preende as definições de processos em um ciclo de vida. Ele é descrito em termos de propósitos
e resultados esperados.
O MR-MPS define sete níveis de maturidade. A escala de maturidade se inicia no nível G
e progride até o nível A. Os níveis de maturidade estabelecem patamares de evolução de pro-
cessos, caracterizando estágios de melhoria da implementação de processos na organização. O
progresso e o alcance de um determinado nível de maturidade do MR-MPS se obtêm quando são
atendidos os propósitos e todos os resultados esperados dos respectivos processos e os resulta-
dos esperados dos atributos de processo estabelecidos para aquele nível [Softex, 2009b].
Entres os processos descritos no MR-MPS está o de Medição, o qual se encontra no nível
de maturidade F. O seu propósito é: coletar, armazenar, analisar e relatar os dados relativos aos
produtos desenvolvidos e aos processos implementados na organização e em seus projetos,
de forma a apoiar os objetivos organizacionais [Softex, 2009b]. O processo de Medição possui
sete resultados esperados: MED1, objetivos de medição são estabelecidos e mantidos a par-
tir dos objetivos de negócio da organização e das necessidades de informação de processos
técnicos e gerenciais; MED2, um conjunto adequado de medidas, orientado pelos objetivos de
medição, é identificado e definido, priorizado, documentado, revisado e, quando pertinente,
atualizado; MED3, os procedimentos para a coleta e o armazenamento de medidas são espe-
cificados; MED4, os procedimentos para a análise das medidas são especificados; MED5, os
dados requeridos são coletados e analisados; MED6, os dados e os resultados das análises são
armazenados; MED7, os dados e os resultados das análises são comunicados aos interessados
e são utilizados para apoiar decisões.
O Guia de Implementação do nível F [Softex, 2009b] recomenda em detalhes o que
pode ser feito para que cada resultado esperado deste processo seja atendido. O processo de
Medição do MR-MPS é fundamentado na abordagem GQM - Goal-Question-Metric [Basili et al,
1994], que possibilita que um programa de medição seja baseado em necessidades específicas
e aos objetivos do processo ou da organização.
3. A Ferramenta Spider-Mplan
A Spider-MPlan é uma ferramenta de licença GPL – General Public License [GNU, 2010] voltada
especificamente para o processo de Medição do MR-MPS, o qual traz uma solução para geren-
ciamento de medidas e dos resultados esperados provenientes desse processo. Trata-se de
um ambiente voltado para a Web, onde é possível coletar, analisar medidas e gerar relatórios
para atender o propósito do processo de Medição. Além de ser uma ferramenta de apoio para
 88 instituições que implementam o modelo MRMPS, é também voltada para empresas que já o Caso não sejam validadas, os objetivos da medição são revistos e o ciclo das ativi- 89

adotaram, mas desejam facilitar e aprimorar este processo.O seu desenvolvimento foi pautado dades se reinicia a partir desse ponto;
XI Worshop sobre Software Livre

Spider-MPlan: Uma Ferramenta para Apoio ao Processo de Medição do MPS.BR

no uso de ferramentas de software livre, tais como: Sistema Operacional Ubuntu 9.10, Eclipse • Registrar Projeto: o processo de Medição está associado a um projeto de softwa-
IDE 3.2 e banco de dados MySQL 5.0. re, pois deve levar em consideração objetivos específicos. Caso este projeto seja
Em meio às pesquisas, dois trabalhos correlatos foram identificados. Trata-se da ferra- ainda inexistente, esta atividade possibilita o registro;
menta CEFRIEL GQM Tool [Lavazza, 2000] e MetriFlame [Parviainen, 2001], as quais apóiam de
forma sistematizada o processo de medição com a abordagem GQM. Entretanto, ao realizar o
mapeamento com os resultados esperados do processo de medição do MR-MPS foi percebida
a aderência a apenas três dos setes resultados: MED1, MED2 e MED7; caracterizando, assim,
um apoio parcial à implementação do processo de Medição, usando GQM, no contexto do pro-
grama de melhoria da qualidade dos processos organizacionais. Uma análise mais detalhada do
mapeamento dessas ferramentas pode ser encontrada em [Estácio, 2009].

3.1. Fluxo de Atividades

A ferramenta Spider-MPlan utiliza o conceito de ator para especificar quem realiza de-
terminada atividade no processo de Medição. Existem quatro tipos de atores: o Analista de
Medição detém a maior parte das atividades do processo como definição da abordagem GQM,
definição dos procedimentos de análise e coleta, coletar, analisar, elaborar/divulgar/revisar re-
latórios; Alta Administração, responsável pelas atividades da definição de um abstraction
sheet e, conjuntamente com a Gerência de Projetos, validam métricas, apreciam relatórios,
analisam resultados e podem estabelecer tomadas de decisão; Usuário de Medição, respon-
sável pela atividade de fornecer a base de dados para a coleta de métricas; e Bibliotecário
de Medição, responsável por qualquer dado manipulado pela ferramenta. É importante que se
ressalte que um usuário da ferramenta pode representar mais de um ator, dependendo do grau
de envolvimento com o processo de medição.
Com o objetivo de ser mais aderente ao processo de Medição descrito pelo MPS.BR, várias
atividades são definidas conforme o fluxo da Figura 1. Um detalhamento destas atividades é apre-
sentado abaixo, bem como o resultado esperado do MPS.BR que estas atividades são aderentes. Figura 1. Fluxo de Atividades do Processo de Negócio da Spider-MPlan

• Definir Necessidades de Informação: esta atividade consiste em definir “o que
é importante (necessário)” para Organização saber com o processo de Medição no
sentido de atender os objetivos organizacionais (aderente ao MED1);
• Elaborar Abstraction Sheet: consiste em realizar uma folha de entrevista com a
Alta Administração da Organização com a finalidade de extrair, estruturar informações
(como fatores de qualidade, fatores de variação) relevantes ao processo de Medição;
• Definir Objetivos de Medição: congruente à abordagem GQM sugerida pelos
resultados esperados do MR-MPS, esta atividade estabelece o(s) objetivo(s) bem
definido(s) para o processo de Medição, feito a partir da análise das necessidades
de informação e do Abstraction Sheet elicitado (aderente ao MED1);
• Definir Questões: assim como a atividade anterior, é parte da abordagem GQM,
ela consiste em levantar questões, as quais são perguntas e indagações que per-
mitem facilitar o alcance dos objetivos de medição definidos;
• Definir Medidas da Organização: esta atividade consiste em definir quais me-
didas (métricas) serão utilizadas no processo de Medição. As medidas definidas
devem conseguir responder as questões levantadas (aderente ao MED2);
• Validar Medidas: após serem definidas, as medidas devem ser revisadas para
verificar se estão de acordo com os objetivos do processo de Medição em questão.
• Selecionar Projeto: caso um projeto já esteja registrado, é necessário que ele
seja selecionado para ser incluído no processo de Medição da organização;
• • Alocar Objetivos de Medição ao Projeto: esta atividade consiste em alocar
os objetivos de medição, antes definidos para o nível organizacional, para nível de
projeto. Geralmente o Analista de Medição realiza algumas alterações sobre tais
objetivos para atender as especificidades de um determinado projeto;
• • Definir Procedimento de Coleta: detalha como será realizada a coleta sobre
os dados das métricas fornecidas. O procedimento ajuda a assegurar que os dados
corretos estão sendo coletados e a explicitar que as necessidades de informações
e os objetivos das medições estão sendo atendidos. Neste procedimento alguns
dados são especificados: freqüência, responsável, ferramenta usada, instruções,
locais de armazenamento e preservação da coleta (aderente ao MED3);
• • Definir Armazenamento das Medidas: esta atividade consiste em especificar
onde (o repositório) as métricas serão armazenadas. A definição de um repositório
no contexto de medição ajuda a assegurar que os dados estarão disponíveis e
acessíveis para uso futuro. O repositório deve ser definido em termos de locali-
zação, procedimentos de inserção e de acesso aos dados, incluindo permissões e
responsabilidades (aderente ao MED3);
 90 • Definir Procedimento de Análise: esta atividade consiste em detalhar como
será realizada a análise sobre os dados coletados. Os procedimentos de análise
XI Worshop sobre Software Livre
devem incluir a definição da freqüência, responsável, fase, dados de origem, ferra-
menta utilizada e verificações da análise (aderente ao MED4);
• Alimentar Repositório de Medidas: o Usuário de Medição, nesta atividade, for-
nece os dados referentes às medidas definidas;
• Coletar: responsável pelo agrupamento e organização dos dados fornecidos pelos
usuários, os quais serão usados nas medições (aderente ao MED5);
• Analisar: esta atividade consiste em analisar os dados coletados para que possí-
veis tomadas de decisões possam ser estabelecidas. A análise de dados é geral-
mente acompanhada por gráficos, algoritmos que facilitem a interpretação de uma
coleção de dados (aderente ao MED5);
• Gerar/Revisar Relatórios: esta atividade consiste em gerar relatórios a partir
das análises realizadas sobre as métricas com o propósito de mostrar os resultados
obtidos pelo processo de Medição;
• Divulgar Relatórios: depois de gerados, os relatórios de medição devem ser
divulgados para os Gerentes de Projetos ou a Alta Administração (aderente ao
MED7);
• Apreciar Relatórios: permite a avaliação do relatório a partir de críticas e suges-
tões dos Gerentes de Projetos ou Alta Administração (aderente ao MED7);
• Armazenar Registros, Ata de Reunião, Resoluções e Proposições: consiste
em manter o repositório de medição com a finalidade de organizar todo o produto
de trabalho produzido pelo processo de Medição (aderente ao MED6).
4. Resultados Esperados
A ferramenta Spider-MPlan tem como foco apoiar o processo de Medição do MPS.BR. Com base
nisso, espera-se a obtenção de alguns resultados:
• agilidade na implementação do processo de Medição do MPS.BR nas organizações,
onde normalmente é adotado o uso de planilhas eletrônicas em conjunto com do-
cumentos impressos e não sistematizados, dificultando o gerenciamento e arma-
zenamentos das medidas;
• facilidade no acompanhamento do processo de Medição;
• conferir qualidade à medição como um todo através de um processo de negócio
bem definido, baseado no guia de implementação do modelo MR-MPS;
• um repositório de métricas estritamente estruturado para melhorar gerenciamento
dos produtos de trabalho obtidos;
• possibilidade de customização da ferramenta, por se tratar de um software livre,
para atendimento as diferentes culturas organizacionais.
Com a ferramenta Spider-MPlan espera-se que o processo de Medição também possa
ser totalmente distribuído geograficamente, permitindo que os dados provenientes das me-
didas possam ser consultados pelos devidos interessados a qualquer instante e de maneira
simples. Isso implica em um melhor acesso às informações geradas pelo processo, facilitando
assim a tomada de decisões para atendimento aos objetivos organizacionais.
5. Considerações Finais 91
Spider-MPlan: Uma Ferramenta para Apoio ao Processo de Medição do MPS.BR
A Spider-MPlan tem o intuito de apoiar a implementação do MPS.BR, especificamente a do
processo de Medição. Desta forma, ela vai ao encontro do que é apresentado nos relatórios
de “Resultados de Desempenho das organizações que adotaram o modelo MPS” e de “Lições
Aprendidas do MPS.BR”, ambos de 2008, os quais enfatizam que a duração de uma implemen-
tação é reduzida substancialmente ao se adotar como prática ferramentais automatizados, o
que torna o processo de implementação mais ágil e menos custoso [Oliveira, 2009].
Os trabalhos futuros estão permeados no refinamento do fluxo de atividades proposto
pela ferramenta e na verificação de uma política de customizações para adaptação da ferra-
menta em diferentes contextos organizacionais. Em médio prazo a ferramenta também será
integrada a outras ferramentas livres de apoio a outros processos do MR-MPS, conforme os
estudos sugeridos por [Mendes, 2009] e [Nascimento, 2009].
Vale ressaltar que as boas práticas apresentadas neste trabalho encontram-se em ins-
titucionalização no Projeto SPIDER (www.ufpa.br/spider), a fim de validar a efetividade do fluxo
de atividades da ferramenta Spider-MPlan a partir da elaboração de estatísticas sobre os re-
sultados obtidos com o seu uso. Desta forma, é possível um relato das experiências e lições
aprendidas com a implantação deste ferramental e um Manual de Implementação do processo
de Medição do MPS.BR adotando a Spider-MPlan.
Agradecimentos
Este trabalho está recebendo o apoio financeiro do PIBIC/UFPA através do Edital PIBIC/
CNPq/FAPESPA/UFPA de 2009.
Referências
Basili. V., Caldiera, G., Rombach, H. (1994) “GQM: Goal Question Metric Paradigm”. Encyclope-
dia of Software Engineering.v.2.p: 527 – 532.
Estácio, B., Valente, K. (2009) “Uma análise da aderência de ferramentas para apoio ao Proces-
so de Medição segundo o MPS.BR”. TCC - IFPA/TADS. Belém.
GNU Project. “General Public License”. Disponível em: http://www.gnu.org/licenses/gpl.html.
Acessado em 25 de outubro de 2010.
Instituto de Engenheiros Eletricistas e Eletrônicos (1998) “IEEE Std. 1061-1998-Standard for a
Software Quality Metrics Methodology”. NJ: IEEE Standards Dept.
Lavazza, L. (2000) “Providing Automated Support for the GQM Measurement Process”. IEE Software.
Mendes, H., Ávilla, J. “Uma proposta de Integração dos Resultados Esperados do Nível F do MPS.
BR”. UFPA/CBCC. Trabalho de Conclusão de Curso. Belém.
Nascimento, P., Lira, W. “Uma proposta de Integração dos Resultados Esperados do Nível G do
MPS.BR”. UFPA/CBCC. Trabalho de Conclusão de Curso. Belém.
Oliveira, S. R. B. (2009) “SPIDER: Uma Proposta de uma Solução Sistêmica de Apoio à Imple-
mentação do modelo MPS.BR”. Projeto de Pesquisa. Belém.
Parviainen, P., Komi-sirviö, S., Ronkainen, K. (2001) “Measurement Automation: Methodological
Background and Practical Solutions: A Multiple Case Study”. 7th International Software Met-
rics Symposium METRICS 2001. London.
Pressman, R. S. (2006) Engenharia de Software, McGraw-Hill, 6 ed., Rio de Janeiro.
SOFTEX (2009a) “MPS.BR – Guia Geral”.
SOFTEX (2009b) “MPS.BR – Guia de Implementação Parte 2”.
 93

Sessão IV
Sistemas Baseados na Web

94 certificaPET: Sistema Gerenciador de Certificados de

Eventos em Formato Digita

Adriano Pereira (UFSM), Vinícius Pinto (UFSM), Andrea Charao

(UFSM)

100 Software livre baseado na web para estimativa numérica

de dados meteorológicos

Rafael Camargo Ferraz (UFSM), Angélica Rossana Castro de

Souza (UFSM), Adroaldo Dias Robaina (UFSM), Marcia Xavier
Peiter (UFSM)

106 Um Portal Web Livre para Disseminação de Informações

sobre Sistemas Embarcados Críticos

Ricardo Amaral Martins Reimão (USP), Elisa Yumi Nakagawa

(USP), Thiago Bianchi (USP), José Maldonado (SSC/ICMC-USP/
São Carlos)

112 XadrezLivre: Proposta de Arquitetura de Ambiente de

Jogos baseado em XMPP com clienteWeb

Rubens Suguimoto (UFPR), Luis Carlos De Bona (UFPR), Alexan-

dre Direne (UFPR)
 94 Este artigo divide-se em seis seções. A próxima seção trata do problema da geração e 95

disponibilização de certificados para eventos. A seção 3 traz uma breve discussão acerca de
XI Worshop sobre Software Livre

Software livre baseado na web para estimativa numérica de dados meteorológicos

soluções semelhantes. Na seção 4 é feita a descrição do sistema, de forma que atenda às ne-
certificaPET: Sistema Gerenciador de Certifica- cessidades expostas na seção 2. A seção 5 expõe uma aplicação do sistema, e, por fim, a seção
dos de Eventos em Formato Digital 6 conclui o artigo, mencionando a continuação do trabalho.

Adriano Pereira1, Vinícius Garcia Pinto1, Andrea Schwertner Charão2

2. O problema

1
Programa de Educação Tutorial (PET) O processo de geração, controle e disponibilização de certificados de participação e organi-
zação de eventos, em formato digital, envolve demandas, como controle de participantes e
2
Laboratório de Sistemas de Computação (LSC)
organizadores, envio e armazenamento dos certificados, que podem ser automatizadas através
Curso de Ciência da Computação – Universidade Federal de Santa Maria (UFSM) de ferramentas computacionais.
Este cenário foi visualizado no grupo PET do Curso de Ciência da Computação (PET-CC)
Campus UFSM – 97105-900 – Santa Maria – RS – Brasil
da Universidade Federal de Santa Maria (UFSM). O grupo promove eventos, como palestras,
{apereira, vgarcia, andrea}@inf.ufsm.br oficinas e minicursos, sendo necessário gerar e distribuir um elevado número de certificados de
participação e organização.
A partir dos casos de uso mais frequentes do grupo, generalizados para outras institui-
Abstract. Attendance certificates in digital format are increasingly popular in confer-
ções promotoras de eventos, pode-se observar requisitos para um sistema gerenciador de certi-
ences and similar events. The digital certificates replace and improve the traditional, printed
ficados em formato digital: uso de formato de arquivo acessível aos usuários; reaproveitamento
ones, but raise a need for computational tools to assist the process. This paper presents the
de informações dos participantes; disponibilidade de reemissão de certificados; certificados
development of certificaPET, a Web based system for generation, storage, delivery and valida-
flexíveis em termos de leiaute, para diferentes eventos; validação dos certificados; e controle
tion of attendance certificates in digital format. The system was developed using free software
de acesso aos certificados emitidos.
tools and is distributed as an open source software.

Resumo. A utilização de certificados de participação em eventos em formato digital

3. Soluções Correlatas
substitui o método tradicional, em meio impresso, com vantagens, tornando necessário o uso
de ferramentas computacionais para auxiliar o controle desses certificados. Este artigo trata do
Pode-se emitir certificados de participação em eventos utilizando recursos de mala direta, pre-
desenvolvimento do certificaPET, um aplicativo Web para a geração, armazenamento, disponi-
sentes em editores de texto, como o OpenOffice Writer. Dessa forma, certificados são gerados
bilização e validação de certificados de participação em eventos, em formato digital. O sistema
partir de um modelo, escrito no próprio editor de texto, e de um conjunto de dados. Entretanto,
foi desenvolvido usando ferramentas abertas, e é distribuído como Software Livre.
este método não permite validação do certificado, e apresenta problemas de distribuição e dis-
ponibilização dos arquivos gerados, sendo mais indicados para distribuição impressa.
O PET-CC desenvolveu, anteriormente, um sistema para a geração de certificados de eventos
1. Introdução
em formato digital. Conforme visto em [Vicentini et al. 2006], trata-se de um sistema Web, desen-
volvido em linguagem de programação PHP. O sistema, porém, não atende requisitos de segurança,
Uma das etapas da organização de eventos consiste na geração de certificados para os par-
uma vez que o acesso aos certificados emitidos é livre; não possui especificações sobre validação dos
ticipantes. Tradicionalmente, os certificados são disponibilizados em papel, o que traz custos
certificados emitidos; e não permite personalização do modelo de certificado gerado.
para impressão e disponibilização. Como alternativa ao meio impresso, passou-se a utilizar
Existem sistemas livres para gerenciamento de eventos. Alguns deles são capazes de
certificados em formato digital, disponibilizados pela Internet. Com isso, torna-se necessário o
emitir certificados, como o Flisys, que gerencia um evento [Flisys 2008]. O Flisys é capaz de
uso de ferramentas computacionais que auxiliem a geração, disponibilização, armazenamento
emitir certificados específicos para palestras e workshops do evento, mas não provê mecanis-
e validação de certificados para eventos.
mos de validação dos certificados emitidos, tampouco permite grande customização do mo-
Nesse sentido, o presente trabalho trata do desenvolvimento de um sistema Web para
delo. O Comitiva é um sistema livre capaz de gerenciar mais de um evento, mas não emite
a geração de certificados em formato digital, disponibilização para os participantes e validação
certificados [Comitiva 2010].
de participações. Os certificados são gerados a partir de modelos construídos pelos usuários do
sistema, sendo possível a utilização de leiautes diferentes para diferentes eventos. O sistema
foi construído a partir de ferramentas livres, e é disponibilizado como Software Livre. Estima-se
4. O Sistema
que este sistema tenha valia para instituições promotoras de eventos, que necessitem gerar e
disponibilizar certificados para os participantes.
Tendo como base o problema mencionado na seção 2, desenvolveu-se um sistema para geren-
 96 ciamento de certificados para eventos, o certificaPET, distribuído como Software Livre. O sistema
está disponível em http://sourceforge.net/projects/certificapet. A figura 1 ilustra uma
XI Worshop sobre Software Livre
tela do sistema, responsável pela recuperação dos certificados de um participante.
Figura 1. Tela de Recuperação dos Certificados
Optou-se por desenvolver um sistema baseado na Web, em virtude do requisito de dis-
ponibilidade de reemissão dos certificados emitidos. Como servidor, utilizou-se o Apache Tom-
cat, uma implementação em software para as tecnologias de Servlet Java e JavaServer Pages
(JSP) [Tomcat 2010]. para sistemas desenvolvidos em Java.
Definiu-se que o formato do arquivo do certificado a ser gerado seria Portable Document
Format (PDF), por se tratar de um formato consolidado para este tipo de aplicação. Nesse sen-
tido, utilizou-se o JODConverter, um Software Livre que realiza a conversão entre arquivos em
formato escritório, bem como desses arquivos para o formato PDF [JODConverter 2010].
Utilizou-se um banco de dados para armazenamento de informação dos participantes,
eventos e participações, possibilitando reaproveitamento de dados e validação dos certificados.
Optou-se por utilizar o sistema gerenciador de banco de dados MySQL [MySQL 2010], por pos-
suir ampla comunidade de usuários. Dessa forma, não é necessário armazenar os arquivos dos
certificados gerados, sendo possível construí-los, quando necessário, através das informações
contidas na base de dados.
Para permitir a personalização do leiaute do certificado, utilizou-se o formato de texto
(ODT) do OpenDocument Format (ODF). O OpenDocument Format é um formato de arquivos
público e aberto para documentos de escritório que pode ser adotado por qualquer pessoa ou
instituição, sendo um padrão internacionalmente reconhecido através da norma ISO/IEC 26300.
Os arquivos do formato ODF são estruturados como um conjunto de diretórios e arquivos, estes
em XML (eXtensible Markup Language), que são reunidos em um arquivo compactado.
Abaixo estão relacionados pontos do desenvolvimento que se julga merecer maiores
explicações.
4.1. Modelo de Dados
A partir dos requisitos levantados pelo PET-CC, gerou-se o modelo de dados represen-
tado na figura 2.
97
Software livre baseado na web para estimativa numérica de dados meteorológicos
Figura 2. Modelo Entidade Relacionamento do Banco de Dados
O modelo está dividido em 4 seções principais: Evento; Palestra, considerada subseção
de Evento; Pessoa, armazena dados utilizados na emissão dos certificados e para a utilização
do sistema; e Curso, armazenando cursos de graduação, visto que o sistema foi desenvolvi-
do para ser utilizado em uma Universidade, primeiramente. As participações das Pessoas em
Eventos e em Palestras são armazenadas, respectivamente, em Evento_has_Pessoa e em Pales-
tra_has_Pessoa. Evento está ligado à Pessoa que o cadastrou.
4.2. Níveis de Usuário
Constatou-se que o sistema seria utilizado por quatro tipos de usuários: administrado-
res, organizadores de eventos, participantes dos eventos e interessados em validação. Sendo
assim, o sistema foi desenvolvido com áreas pública e privada. A área pública é utilizada para
a validação dos certificados, enquanto a área privada possui três níveis de acesso: administra-
dores, com acesso global às informações; organizadores, com acesso restrito às suas inclusões;
e usuários participantes, com acesso à recuperação de seus certificados.
Administradores e organizadores podem ser definidos como participantes de eventos,
possuindo, também, acesso `a emissão de seus certificados.
4.3. Modelo do Certificado
O leiaute do certificado de cada evento e palestra é definido pelo usuário (organizador
do evento, ou palestra, ou administrador), através de um arquivo do formato ODT. Este arquivo
deve conter labels específicos, demarcados pelos caracteres abre e fecha chaves ({ e }), os
quais serão substituídos pelos dados do participante e do evento, ou palestra, no processo de
geração do certificado. Conforme visto na seção 4, os arquivos no formato ODT são conjuntos
de arquivos compactados. O arquivo do modelo é armazenado de forma descompactada, faci-
litando a geração dos certificados.
4.4. Geração do Certificado
A etapa de geração do certificado foi implementada através de um Servlet HTTP. A
requisição do cliente para geração do certificado é feita através de método POST, fornecendo
 98 como parâmetros uma indicação de evento ou palestra, identificador do evento ou palestra,
identificador da pessoa e tipo de participação. Primeiramente, valida-se os parâmetros recebi-
XI Worshop sobre Software Livre
dos. Após, é feita a busca na base de dados para recuperação dos dados que serão incluídos no
certificado, bem como a criação do código para validação.
Na estrutura do modelo descompactado, o arquivo content.xml contém as informações
textuais do leiaute. Este arquivo é lido e, a partir dele, gera-se um novo arquivo content.xml,
específico para o certificado, onde os labels do modelo são substituídos pelos dados recupera-
dos da base de dados. Então, é gerado um novo ODT, que reúne todos os arquivos do modelo,
exceto o arquivo content.xml, substituído pelo gerado anteriormente. A partir do ODT criado,
é feita a conversão para o formato PDF, utilizando o software JODConverter. Este PDF é, então,
fornecido para download do cliente. A figura 3 ilustra o processo de geração do certificado.
Os arquivos ODT e PDF gerados não são armazenados de forma permanente no sistema.
Eles são utilizados como temporários para conversão e envio para o cliente, sendo excluídos
após estas etapas. Optou-se por não manter os arquivos gerados para reduzir a carga de arma-
zenamento no servidor.
Figura 3. Geração do Certificado
4.5. Validação
A validação de um certificado é necessária para comprovar que os dados presentes
no certificado são compatíveis com os que estão armazenados junto ao emissor. Dessa forma,
pode-se confirmar que o certificado foi gerado pelo sistema. O certificado, quando emitido,
recebe um código para validação, através do qual é possível recuperar os dados armazenados
junto ao emissor. Este código é gerado através de um conjunto de informações único para cada
certificado, composto por um valor binário que indica se o certificado é de evento ou palestra,
identificador do evento ou palestra, identificador da pessoa e tipo de participação. Esses dados
são armazenados em uma string, encriptada utilizando o algoritmo de chave única DES (Data
Encrypt Standard), a qual é escrita no certificado, substituindo o label {autenticacao} do mo-
delo. A figura 4 ilustra o processo de criação do código de validação, e recuperação dos dados,
a partir dele.
Para verificação da validade do certificado, é feito acesso à área pública do sistema,
onde é informado o código de validação. Através do código, o sistema recupera as informações
referentes ao nome da pessoa, nome do evento ou palestra, tipo de participação e carga horá-
ria, a fim de que essas informações possam ser comparadas com as presentes no certificado.
5. Estudo de Caso 99
Software livre baseado na web para estimativa numérica de dados meteorológicos
O certificaPET está em processo de implantação no PET-CC. Como mencionado na seção 2, o
grupo realiza atividades diversificadas, onde é necessária a emissão de certificados.
Figura 4. Geração e Recuperação do código para validação
Atualmente, os certificados são gerados de forma automática, mas enviados manual-
mente, por e-mail. Além disso, não há formas de validação dos certificados emitidos.
Com o uso do sistema, será possível gerenciar os certificados dos eventos desenvolvidos
pelo PET-CC, suprindo as necessidades de disponibilização e validação verificadas atualmente.
Além disso, o público alvo dos eventos tende a se repetir - alunos da área de Computação da
UFSM, de forma que informações sobre participantes possam ser reutilizadas, facilitando o pro-
cesso de atribuição de participantes e organizadores aos eventos.
6. Conclusão e Trabalhos Futuros
Neste artigo foi relatado o caso de desenvolvimento de um sistema gerenciador de certifica-
dos para eventos, o certificaPET. O sistema foi desenvolvido utilizando Software Livre, como o
JODConverter, e padrões livres, como o ODT. Seus requisitos foram levantados a partir do Grupo
PET do Curso de Ciência da Computação da UFSM, o qual realiza atividades onde é necessária
a emissão de certificados. O grupo será alvo de um estudo de caso futuro.
O sistema traz um conjunto de soluções para o problema de geração, armazenamen-
to, disponibilidade e validação de certificados, o qual não é totalmente coberto por outras
ferramentas livres, de código aberto. Como trabalhos futuros, propõem-se uma divulgação do
sistema, além do desenvolvimento de manuais de uso e busca por otimização dos processos
envolvidos.
Referências
Comitiva (2010). Comitiva: Sistema de gerenciamento de eventos de tecnologia. Disponível
em: http://www.phpms.org/artigos/4-codigo/226-comitiva. Acesso em: maio de 2010.
Flisys (2008). Flisys - the flisol open source system. Disponível em: http://sourceforge.net/pro-
jects/flisys. Acesso em: maio de 2010.
JODConverter (2010). Jodconverter — art of solving. Disponível em: http://www.artofsolving.
com/opensource/jodconverter. Acesso em: maio de 2010.
MySQL (2010). Mysql :: The world’s most popular open source database. Disponível em: http://
www.mysql.com. Acesso em: maio de 2010.
Tomcat (2010). Apache tomcat. Disponível em: http://tomcat.apache.org. Acesso em: maio de
2010.
Vicentini, C. F., Carli, D. M. D., Bevilaqua, F., dos Santos, R. C. M., and Sishonani, O. R. (2006).
Sistema de gestão de certificados em php 5 e mysql. Anais do Simpósio de Informática da
Região Centro do RS - V SIRC-RS.
 100 vezes irreversíveis durante uma safra, causando não só a escassez de alimentos, mas também 101

alterações na economia (FERRAZ et al. 2006).

XI Worshop sobre Software Livre

Software livre baseado na web para estimativa numérica de dados meteorológicos

Conforme Santana et al. (2003), o número de estações meteorológicas no Brasil ainda
Software livre baseado na web para estimativa é insuficiente para uma boa cobertura do território nacional, o que tem dificultado a boa carac-
numérica de dados meteorológicos terização das condições atmosféricas.
Com o surgimento da era digital, as técnicas de coleta, processamento e análise de da-
Rafael C. Ferraz¹, Angélica R. C. de Souza², Adroaldo D. Robaina³ e Marcia X. Peiter³ dos meteorológicos evoluíram, e a tecnologia da informação e o surgimento das geotecnologias
permitem inferências no processamento de um maior número de informações meteorológicas
globais, regionais e locais, facilitando o planejamento agrícola (VOLPATO et al., 2008).
¹Aluno doutorado Engenharia Agrícola – Universidade Federal de Santa Maria (UFSM) A mobilidade associada a informações de localização permite selecionar a informação
Rua Roraima, 1000, Prédio 42, Sala 3331 – 97105-900 – Santa Maria – RS - Brasil a ser disponibilizada, de forma que o conteúdo retornado seja filtrado de acordo com a posição
²Mestranda em Geomática – Universidade Federal de Santa Maria (UFSM) geográfica do usuário. O uso da tecnologia WebServices na disponibilização de soluções visa
atender estes requisitos, uma vez que ela permite que sistemas executados em diferentes am-
³Departamento de Engenharia Rural – Universidade Federal de Santa Maria (UFSM) bientes se comuniquem (ARSANJANI et al., 2003).
{rafacferraz, angelsoubio}@gmail.com, {robaina,mpeiter}@smail.ufsm.br Tendo em vista a importância das informações meteorológicas e pela insuficiência de
dados para diversas regiões, o presente trabalho tem como objetivo, desenvolver um software
livre baseado na web para a estimativa numérica de dados meteorológicos pra o Estado do
Abstract. This study aims at developing a free web system for numerical estimate of
Rio Grande do Sul, o qual servirá de apoio para a tomada de decisão em diversas áreas, em
meteorological data in the RS’s state, based on the automated surface weather stations from
especial a agrícola.
the National Institute of Meteorology. For the application’s development, it were used the pro-
gramming languages PHP and JavaScript, besides a MySQL database. The method for interpola-
tion of the inverse distance weighting (with the distance raised to the exponent five) was used
2. Materiais e Métodos
as a data estimator model, once it showed the best performance for the following variables:
temperature, relative humidity, atmospheric pressure and dew point. It was developed a SWIM
Para a realização deste trabalho foram utilizados os dados da rede de estações meteorológi-
database and the web system, which can be used in several human activities, mainly on agri-
cas de observações de superfície automáticas do Instituto Nacional de Meteorologia (INMET),
culture as a support for making decisions.
instaladas nas cidades do Estado do Rio Grande do Sul. O banco de dados foi desenvolvido em
MySQL, que é um gerenciador de banco de dados multiusuário e para o desenvolvimento do
Resumo. Este estudo visa desenvolver um sistema web livre para estimativa numérica
aplicativo web foram utilizada as linguagens de programação PHP e JavaScript, integrados na
de dados meteorológicos no estado do Rio Grande do Sul, com base nas estações climáticas
linguagem padrão HTML.
automáticas de superfície do Instituto Nacional de Meteorologia. Para o desenvolvimento da
Para a estimativa dos dados meteorológicos para as regiões sem informações, utilizou-
aplicação, foram utilizadas as linguagens de programação PHP e JavaScript, além de um banco
se o modelo de interpolação da potência do inverso da distância. O método de interpolação foi
de dados MySQL. O método para interpolação da ponderação do inverso da distância (com a
programado utilizando a equação:
distância elevada ao expoente cinco) foi usado como um modelo estimador de dados, uma
vez que apresentou o melhor desempenho para as seguintes variáveis: temperatura, umidade
relativa, pressão atmosférica e ponto de orvalho. Foi desenvolvida uma base de dados SWIM e
o sistema web, os quais podem ser usados em diversas atividades humanas, principalmente na
agricultura como suporte para a tomada de decisões.

1. Introdução
Onde Xp são as variáveis interpoladas, Xi : valor da variável de i-ésima localidade vi-
A agricultura mundial está enfrentando desafios cada vez maiores, como a expansão urbana, as
zinha; di: distância euclidiana entre o i-ésimo ponto de vizinhança e o ponto amostrado, B o
competições globais de comércio e a baixa margem de lucro. Para manter a competitividade e
expoente de ponderação (peso) e n é o número de pontos utilizados para interpolar a amostra.
a viabilidade econômica, os agricultores necessitam aumentar a eficiência na produção (YANG,
O expoente de ponderação pode ser selecionado e o mesmo possui efeitos sobre os resultados
et al., 2010).
estimados.
A região Sul do Brasil tem uma economia basicamente dependente da agricultura e,
Para realizar a comparação foi utilizada a análise de regressão entre os valores dos
deste modo, existe uma estreita ligação entre as alterações climáticas e o ciclo de vida de de-
dados climatológicos interpolados pelos diferentes expoentes com o objetivo de se obter o
terminadas culturas. Alterações drásticas no regime de chuvas podem provocar danos muitas
coeficiente de correlação (r) e o índice de concordância de Wilmont (c).
 102 Conhecendo-se esses indicadores foi determinado o índice de desempenho (Id), que A partir da analise dos expoentes, definiu-se o grau 5 para aplicação no modelo inter- 103

pode ser calculado por: polador, por apresentar os melhores desempenhos para as variáveis: temperatura, umidade
XI Worshop sobre Software Livre

Id = rc
Onde Id é o índice de desempenho, r é o coeficiente de correlação e c é o índice de
concordância de Wilmont.
O índice de desempenho tem a finalidade de avaliar o desempenho do método propos-
to, considerando as seguintes classes de interpretação, conforme Tabela 1 (COSTA, 2004).
relativa do ar, ponto de orvalho e pressão atmosférica. As demais variáveis não poderão ser
disponibilizadas através do sistema por não alcançarem desempenho satisfatório.
Após definir o modelo de interpolação, foram onde foram determinadas as algumas fun-
ções básicas do sistema, como a as formas de consulta e obtenção dos dados meteorológicos e
as regiões de interpolação a partir das estações do INMET.
A Figura 1 ilustra a distribuição da rede de pontos de coleta de dados meteorológicos do
INMET e a delimitação das áreas de carências formadas a partir destas bases conhecidas.

Tabela 1. Classificação do índice de desempenho do método proposto.

Classes Valores de Id Desempenho
1 > 0.85 Ótimo
2 0.76 a 0.85 Muito Bom
3 0.66 a 0.75 Bom
4 0.61 a 0.65 Regular
5 0.51 a 0.60 Fraco
6 0.41 a 0.50 Muito Fraco
7 < 0.41 Péssimo

3. Resultados e Discussão

Figura 1. Triângulos delimitados para aplicação no sistema web de interpolação meteorológica, a

Inicialmente, foi realizada a comparação entre os diferentes expoentes do modelo interpolador
partir das coordenadas conhecidas das estações do INMET
para as variáveis climáticas disponibilizadas pelo Instituto Nacional de Meteorologia e analisa-
das o índice de desempenho, conforme Tabela 2.
O Sistema Web de Interpolação Meteorológica (SWIM) possui duas formas de consultas,
Tabela 2. Índice de desempenho para as variáveis analisadas a partir do grau 0 ao 5 o que estabelece dois tipos de funcionamentos, sendo a opção visual e opção por formulário.
do modelo de interpolação do inverso da potência da distância. A obtenção do resultado é conseqüência do processo de armazenamento de informa-
Grau Temperatura Pressão at- Umidade re- Ponto de Radiação Precipitação ções e cálculos, sendo que, conforme já citado, utilizou-se a linguagem de programação php e
mosférica lativa do ar orvalho Solar
javascript, o que possibilita um sistema dinâmico, rápido e seguro.
IPD*0 0,923 0,843 0,734 0,105 0,637 0,133 Na Figura 2, pode-se visualizar a rotina de trabalho do sistema SWIM, desde a coleta dos
IPD 1 0,927 0,989 0,740 0,260 0,625 0,128 dados, até a disponibilização dos mesmos.
IPD 2 0,927 0,999 0,739 0,516 0,622 0,114
IPD 3 0,926 1,000 0,737 0,739 0,594 0,101
IPD 4 0,925 1,000 0,734 0,846 0,570 0,090
IPD 5 0,923 1,000 0,731 0,881 0,549 0,081
*IPD - Inverso da Potência da Distância.

Pode-se observar que para a variável temperatura, todos os modelos demonstraram

ótimo desempenho, conforme índice de Wilmont. Para a pressão atmosférica o desempenho se
repetir ótimo para os modelos a partir do grau 1, respondendo muito bom para o IPD de grau
0. A variável umidade relativa do ar respondeu com bom desempenho, com índices entre 0,73
e 0,74. O ponto de orvalho demonstrou ótimo desempenho apenas para o IPD5, ou seja, para o
grau 5 como expoente de interpolação. O modelo não demonstrou-se eficiente para as variáveis
de radiação solar e precipitação, quando analisada para os expoentes entre 0 e 5, onde para
apresentou desempenho fraco à regular para a radiação solar e péssimo quando analisado para
a precipitação. Figura 2. Estrutura de funcionamento do Sistema Web de interpolação meteorológica
 104 O sistema SWIM está programado a partir dos dados meteorológicos coletados junto a REFERÊNCIAS 105

base do INMET, e armazenado em servidor independente, possibilitando maior flexibilidade na

XI Worshop sobre Software Livre

Software livre baseado na web para estimativa numérica de dados meteorológicos

articulação dos processos internos do aplicativo. O Instituto disponibiliza as informações mete-
orológicas em seu endereço eletrônico, em intervalos de uma hora, mas não libera o acesso di-
nâmico aos dados. Sendo assim, como o sistema encontra-se em fase de testes, são realizadas
atualizações semanais e de forma manual.
No desenvolvimento do aplicativo, buscou-se utilizar uma apresentação visualmente
agradável e de fácil utilização, por ser um sistema utilizado por diversos usuários e estes nem
sempre possuírem experiência em informática.
ARSANJANI, A. et al. Web services: promises and compromises. ACM Queue, New York, NY,
USA, v. 1, n. 1, p. 48-58, 2003.
COSTA, S. V. Desenvolvimento e calibração de um mini-tanque evaporimétrico. 80 f. Disserta-
ção (Mestrado em Engenharia Agrícola) – UFSM, 2004.
FERRAZ, S.; PAMPUCH, L.; FOSS, M.; CERA, J. C. Climatologia da precipitação na região central
do rio grande do sul e possíveis mudanças no regime de precipitação, In: CONGRESSO BRA-
SILEIRO DE METEOROLOGIA, 2006, Florianópolis. Anais<http://www.cbmet.com/edicoes.
php?pageNum_Recordset_busca=5&totalRows_Recordse_busca=1006&cgid=14>. Acesso
em 21 mar. 2009.
SANTANA, M. O.; RIBEIRO, A.; SEDIYAMA, G. C. Sistema de geoespacialização da demanda de
irrigação suplementar para o Estado de Minas Gerais. Revista Brasileira de Engenharia
Agrícola e Ambiental. Campina Grande, v.7 n.1, p 57-63, 2003.
SILVA, A. J. S.; JÚNIOR, A. S. de A.; MARIN, F. R. Um sistema web para a consulta de dados me-
teorológicos como ferramenta de apoio ao manejo de irrigação no estado do Piauí. Revista
Tecnologia, Fortaleza, v. 29, n. 2, p. 141-147, dez. 2008.
VOLPATO, M. M. L.; ALVES, H. M. R.; VIEIRA, T. G. C. Geotecnologias aplicadas à agrometeorolo-
gia. Informe Agropecuário, Belo Horizonte, v. 29, n. 246, 2008. Não paginado.
YANG, Y.; WILSON, L.T. E. Development of an automated climatic data scraping filtering and
display system. Computers And Eletronics in Agriculture, v.71, p. 77-87, 2010.

Figura 3. Apresentação visual do Sistema Web de Interpolação Meteorológica.

A Figura 3 demonstra as formas de consultas no sistema, sendo que pode ser realizada
de duas formas: (i) ao clicar sobre o mapa do Rio Grande do Sul, o sistema registra as coordena-
das em pixel do ponto desejado e determina a área a qual pertence (Figura 1) e posteriormente
calcula as distâncias entre as bases conhecidas, que servirão de ponderação para o cálculo da
interpolação; (ii) na opção dados, o usuário informa a localização do local (altitude, longitude e
altitude) e o sistema realiza as operações de determinação da região de interpolação e calcula
a interpolação dos dados.
Silva et al. (2008), desenvolveu um sistema web para consulta de dados meteorológicos
do Estado do Piauí, o qual acessa o banco de dados da Embrapa Meio-Norte e disponibiliza as
informações dos municípios que possuem estações. O autor afirma que os sistemas web dina-
mizam a distribuição e manipulação das variáveis climática.

4. CONCLUSÕES

Pode-se concluir que o modelo interpolador do inverso da potência da distância ao expoente 5

foi satisfatório para a estimativa de dados das variáveis: temperatura, umidade relativa do ar,
pressão atmosférica e ponto de orvalho. O software livre baseado na web para a interpolação
dos dados meteorológicos pode ser disponível e aplicado nas mais diversas atividades huma-
na e principalmente na agricultura. O meio rural necessita de ferramentas gratuitas de apoio
nas decisões, para o aumento da produtividade, principalmente nas áreas sem cobertura de
informações.
 106
XI Worshop sobre Software Livre
Um Portal Web Livre para Disseminação de
Informações sobre Sistemas Embarcados Críti-
cos
Ricardo A. M. Reimão, Elisa Y. Nakagawa, Thiago Bianchi, José C. Maldonado
Instituto de Ciências Matemáticas e de Computação (ICMC) - USP
rreimao@grad.icmc.usp.br, {elisa,tbianchi,jcmaldon}@icmc.usp.br
Resumo. A disponibilização de informações e compartilhamento de conhecimentos,
inclusive de cunho científico, por meio da Internet têm-se tornado extremamente relevan-
tes para a sociedade atual. Assim, o principal objetivo deste artigo é apresentar a RIPSEC
(Rede de Inovação e Prospecção em Sistemas Embarcados Críticos), uma rede de colabo-
ração disponibilizada por meio de um portal web, cujo código fonte é livre, e que visa agre-
gar informações sobre pesquisas, desenvolvimento e uso de Sistemas Embarcados Críticos
(SEC). Essa rede é uma das contribuições do INCT-SEC, um projeto de pesquisa que visa
principalmente elevar o nível de conhecimento, competência e qualidade no Brasil sobre o
desenvolvimento de SEC.
Abstract. The information dissemination and knowledge exchange, including those
related to scientific one, through Internet have become extremelly relevant to the current
society. Thus, the main objective of this paper is to present RIPSEC (Rede de Inovação e
Prospecção em Sistemas Embarcados Críticos), a collaborative net available by a web portal
(that is open source) and that aggregates information related to researches, development,
and use of Critical Embedded Systems (CES). This net is a contribution of the INCTSEC, a
research project that aims at improving the level of knowledge, competence, and quality of
CES development in Brazil.
1. Introdução
Atualmente, a disseminação de informações e o compartilhamento de conhecimento têm sido
como nunca beneficiados pela Internet. Nesse contexto, uma diversidade de redes sociais e de
colaboração têm-se formado, agregando diferentes pessoas e instituições, independentemente
de suas localizações geográficas.
No tocante à comunidade científica, a Internet tem também impactado fortemente e
contribuído diretamente para a troca e disseminação de informações, principalmente de ca-
ráter científico, contribuindo de fato para o fortalecimento de novas áreas de pesquisa, bem
como para o amadurecimento e consolidação de áreas e grupos de pesquisa das universidades,
centros de pesquisa e mesmo da indústria. Além disso, a Internet é um veículo fundamental
para o estabelecimento e fortalecimento da colaboração entre grupos de pesquisas no Brasil e
também no exterior. Nesse contexto, têm-se inúmeros projetos de pesquisa, sendo conduzidos
por pesquisadores distribuídos em diferentes instituições. Como exemplo, pode-se citar o INCT-
SEC (Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados Críticos) [INCT-SEC, 107
2009], com sede no Instituto de Ciências Matemáticas e de Computação da Universidade de
Um Portal Web Livre para Disseminação de Informações sobre Sistemas Embarcados Críticos
São Paulo (ICMC/USP) e que agrega atualmente mais de 250 pesquisadores oriundos de nove
universidades e de sete empresas. Dessa forma, observa-se que o INCT-SEC, e até mesmo
diversos outros projetos de pesquisa, podem, muitas vezes, ter como característica a distri-
buição geográfica dos pesquisadores. Ou seja, observa-se que a comunidade científica tem-se
articulado de maneira que as pesquisas sejam conduzidas conjuntamente por pesquisadores
pertencentes a diferentes e diversas instituições. Com isso, observa-se também a necessidade
da proposição e disponibilização de mecanismos que possibilitem e facilitem a colaboração e a
troca de informação entre pesquisadores, tanto aqueles pertencentes ao projeto quanto aque-
les que tenham interesse nas linhas de pesquisa investigadas no projeto.
Assim, o principal objetivo deste trabalho é apresentar uma rede de colaboração dispo-
nibilizada por meio de um portal web e que tenha a possibilidade de agregar conhecimento e
a troca de informações de caráter científico entre pesquisadores. Especificamente, essa rede,
chamada de RIPSEC (Rede de Inovação e Prospecção em Sistemas Embarcados Críticos)1, foi
desenvolvida no contexto do INCT-SEC e, portanto, possibilitando a colaboração de pesquisa-
dores ligados às pesquisas em Sistemas Embarcados Críticos (SEC). Vale destacar também que
essa rede foi concebida inteiramente baseada na filosofia de software livre [FSF, 2010], visando
seu uso futuro em outras áreas de pesquisa.
O restante do artigo está organizado da seguinte forma: na Seção 2 é apresentado o
contexto em que se insere este trabalho; na Seção 3 é apresentada a RIPSEC; na Seção 4 é feita
uma breve discussão sobre as expectativas e limitações da RIPSEC; por fim, na Seção 5 são
apresentadas as conclusões e os trabalhos futuros.
2. Contexto
Visando à troca de informação e disseminação de conhecimento, atualmente encontram-se
largamente disseminadas as comunidades virtuais que possibilitam o estabelecimento de re-
lações entre pessoas num espaço virtual por meio, principalmente, da Internet. Observa-se
que essas comunidades têm-se potencializado em função da dispersão geográfica de seus
membros, a possibilidade de colaboração, de cooperação e de aprendizado. Como exemplos
dessas comunidades, podem-se citar aquelas criadas por meio de redes de relacionamento.
Contudo, observa-se que essas geralmente não possuem moderação ou hierarquização de usu-
ários, não sendo, muitas vezes, objetivo dessas comunidades terem alguma moderação. Além
disso, outras importantes comunidades podem ser identificadas, tais como aquelas que são
estabelecidas em torno do desenvolvimento de softwares livres, tais como Apache2. Contudo,
quando se trata de conteúdos científicos, no qual o rigor é ponto chave, comunidades sob essas
perspectivas não são as mais indicadas.
Em outra perspectiva, pode-se encontrar a RIPA3 (Rede de Inovação e Prospecção para
o Agronegócio), um portal que constitui um ambiente colaborativo desenvolvido numa parceria
entre a IEA/USP4 (Instituto de Estudos Avançados da Universidade de São Paulo) e a Embrapa5 e
1 http://143.107.231.105/drupal
2 http://www.apache.org/
3 http://www.ripa.com.br/
4 http://www.sc.usp.br/ieasc/
5 http://www.embrapa.br/
 108 que objetiva maximizar a canalização de conhecimento tácito e explícito das organizações e es-
timular as ações integradas entre instituições do governo, do setor produtivo e do terceiro setor
XI Worshop sobre Software Livre
relacionados ao Agronegócio. Apesar de sua relevância, no tocante ao portal em si, observa-se
que esse não é caracterizado como software livre, pois seu código não está disponível para a
comunidade.
Destaca-se também que este trabalho está sendo desenvolvido no contexto do INCT-
SEC, um projeto financiado pelo CNPq, FAPESP e pelo Ministério da Ciência e Tecnologia e
que tem como principal objetivo elevar o nível de conhecimento, competência e qualidade
no país no tocante ao desenvolvimento de SEC, incluindo veículos autônomos móveis e
robôs móveis. Essas tecnologias têm grande importância para apoiar o desenvolvimento
de áreas estratégicas do país, como a do meio ambiente, a de segurança e defesa e a de
agricultura. O INCT-SEC possui um portal6 para o relacionamento de seus membros pesqui-
sadores, visando à organização do andamento do projeto; contudo, não é objetivo desse
portal estender-se à comunidade como um todo.
3. Desenvolvimento da RIPSEC
A RIPSEC foi concebida motivada pela falta de mecanismos que pudessem tratar de conte-
údos científicos, mais especificamente, conteúdos ligados às pesquisas em SEC. Destaca-se
que a ideia de um portal web para prospecção de conhecimento com possibilidade de rela-
cionamento entre os usuários é inédita no contexto de SEC.
É importante ressaltar que existem projetos similares ao apresentado neste traba-
lho, tais como o próprio portal do INCT-SEC. No entanto, o conteúdo encontrado nesses
portais é específico para uma determinada parcela da comunidade (muitas vezes, somente
aos membros pesquisadores do projeto em si). Assim, com o desenvolvimento da RIPSEC,
espera-se a disseminação de conhecimento para toda a comunidade não restringindo so-
mente aos membros pesquisadores de um dado projeto de pesquisa.
Além de viabilizar a disseminação e agregação de informações para a comunidade
em geral, o projeto RIPSEC tem a iniciativa de disponibilizar seu código fonte como software
livre, sob licença GPL (General Public License) [FSF, 1999], o que possibilita ser modificado
e reutilizado em outras áreas de conhecimento. Ainda seguindo a filosofia de software livre,
todo o desenvolvimento do portal é baseado em ferramentas e tecnologias livres, que é uma
prática comum no desenvolvimento de softwares livres.
3.1. Tecnologias Utilizadas
Por ser um portal no qual o requisito principal é a atualização constante de conteú-
dos, optou-se pela utilização de um Content Management System (CMS) [DocForge, 2010],
o que facilita as customização e disponibilização de conteúdos. Diversos CMS livres foram
avaliados, sendo escolhido o Drupal7, por esse estar sendo largamente utilizado e contar
com uma diversidade de material de apoio, o que pode ser apontado como um ponto posi-
tivo em um projeto de software livre. Além disso, o Drupal é considerado um CMS estável,
6 http://www.inct-sec.org/
7 http://drupal.org/
com atualizações constantes e, um ponto importante, possuir uma comunidade ativa de 109
desenvolvedores. Esse CMS fornece diversas ferramentas para a criação de um portal web.
Um Portal Web Livre para Disseminação de Informações sobre Sistemas Embarcados Críticos
Fornece também suporte aos Sistemas de Gerenciamento de Banco de Dados (SGBD), tais
como o MySQL8, que foi adotado como SGBD da RIPSEC, por ser também largamente dis-
seminado entre a comunidade de desenvolvimento web. Por ser um portal web, há a neces-
sidade de um servidor web. Assim, dentre as diversas opções de servidores web avaliados,
foi escolhido o Apache, uma vez que é considerado um servidor estável e confiável, além de
oferecer constantes atualizações pela sua comunidade de desenvolvedores.
3.2. Funcionalidades da RIPSEC
A identificação das funcionalidades, bem como o layout da RIPSEC, foi realizada por
meio de reuniões com a participação de diversos membros pesquisadores do INCT-SEC, bem
como um jornalista que tem a específica função de postar conteúdos por meio da RIPSEC.
Vale também destacar que o desenvolvimento foi realizado de forma incremental, ou seja, à
medida que os requisitos surgiam, esses eram implementados. Essa abordagem de desen-
volvimento teve bons resultados e parece ser adequada para o desenvolvimento de portais
web, pelo menos aqueles com as características apresentadas pela RIPSEC. O desenvolvi-
mento foi realizado em um período de quatro meses, acompanhado de reuniões semanais
e com a participação de uma pesquisadora coordenadora do portal, um desenvolvedor, um
jornalista e membros do INCT-SEC que atuaram como usuários do portal.
Na Figura 1 é mostrada a página principal da RIPSEC. Vale destacar que as opções do
menu, destacadas à esquerda, foram resultado de uma discussão aprofundada sobre quais
funcionalidades deveriam estar disponíveis em um portal com essa finalidade. Dessa forma,
por meio do portal, podem-se disponibilizar, entre outros, notícias, publicações, eventos e
outras informações diretamente relacionadas aos SEC. Na Figura 2, é mostrada em mais
detalhes, as possibilidades desse menu. Além disso, o portal possibilita livre acesso aos
conteúdos sobre SEC à comunidade, possibilitando inclusive aos interessados cadastro no
portal, o que possibilita o mapeamento da distribuição geográfica de pessoas interessadas
em nível nacional e até internacional.
Para mapear essa distribuição, está sendo utilizada a Árvore Hiperbólica9, uma fer-
ramenta livre que tem por finalidade exibir de maneira interativa, por meio de grafos, o
relacionamento entre os integrantes da RIPSEC cadastrados no portal. O portal também
disponibiliza informações sobre os relacionamentos dos integrantes da rede por meio do
ScriptLattes10 [Mena-Chalco, 2009]. Essa ferramenta, também um software livre, possibi-
lita, dentre outras funcionalidades, a extração e compilação de produções bibliográficas,
produções técnicas, orientações de alunos, bem como a geração do grafo de colaborações
para os integrantes da rede que estejam cadastrados na plataforma Lattes11. A critério de
ilustração, na Figura 3 é mostrado o grafo de colaboração dos integrantes da RIPSEC. Os
nós do grafo correspondem a cada pesquisador e as ligações, a indicação das publicações
que ocorreram em conjunto. Com a disponibilização da Árvore Hiperbólica e o grafo de co-
laboração gerado pelo ScriptLattes, a ideia é ter uma visão dos pesquisadores e integrantes
envolvidos e interessados na área de SEC.
8 http://www.mysql.com/
9 http://christ.bouthier.free.fr/
10 http://scriptlattes.sourceforge.net/
11 http://lattes.cnpq.br/
 110 4. Breve Discussão 111
XI Worshop sobre Software Livre

Um Portal Web Livre para Disseminação de Informações sobre Sistemas Embarcados Críticos
Atualmente, a RIPSEC encontra-se em fase final de implementação e já está disponibilizada
para a comunidade em geral. Uma vez que houve um estudo minucioso sobre o conteúdo a ser
disponibilizado por esse portal, espera-se que ele venha a atender a todas as necessidades de
uma comunidade virtual que possa se formar e que queira compartilhar conhecimento sobre as
pesquisas, desenvolvimento e utilização de SEC.
Quanto às limitações, há ainda a necessidade de uma investigação mais detalhada
sobre o impacto da RIPSEC para a comunidade de interessados no tema em questão. Há tam-
bém a necessidade de utilizar esse portal em outros contextos, ou seja, em outras áreas de
pesquisa, para observar a viabilidade e facilidade de reuso do código fonte dessa rede, que é
disponibilizada como software livre.

5. Conclusão

Figura 1: Página principal da RIPSEC
A principal contribuição deste trabalho foi apresentar o portal RIPSEC que visa a viabilizar e
facilitar a troca de informações e conhecimento no domínio de SEC a toda a comunidade in-
teressada no tema, inclusive pesquisadores, alunos de graduação e mesmo alunos do ensino
médio. Por utilizar somente tecnologias livres em seu desenvolvimento, bem como por ser um
software livre, a RIPSEC poderá contribuir e facilitar a replicação dessa experiência em outras
áreas de conhecimento.
Como trabalhos futuros, pretende-se conduzir estudos de modo a observar o impacto
da RIPSEC quanto ao seu uso e seu objetivo, bem como o seu reuso e configuração para outros
contextos, mostrando sua relevância e contribuição para a comunidade de software livre com
um portal web livre.

Agradecimentos

Os autores gostariam de agradecer ao CNPq e à FAPESP pelo financiamento ao INCT-

Figura 2: Funcionalidades disponíveis na RIPSEC SEC (processos 573963/2008-8 e 08/57870-9) e aos membros do INCT-SEC que auxiliaram na
concepção da RIPSEC.

Referências

[DocForge, 2010] DocForge, Content Management System. Disponível em: <http://docforge.

com/wiki/Content_management_system> Acesso em: 31.05.2010.
[FSF, 1999] Free Software Foundation, GNU General Public Licence, In: Open Sources: Voices
from Open Source Revolution. Beijing, 1999, v.1, p. 258–262.
[FSF, 2010] Free Software Foundation, The Free Software Definition. Disponível em: <http://
www.gnu.org/philosophy/free-sw.html> Acesso em: 31.05.2010.
[INCT-SEC, 2009] Instituto Nacional de Ciência e Tecnologia em Sistemas Embarcados Críticos. Institu-
to de Ciências Matemáticas e de Computação - ICMC/USP, São Carlos, SP. 2009-2014. (Projeto de
pesquisa financiado pelo CNPq e FAPESP e coordenado pelo Prof. Dr. José Carlos Maldonado).
[Mena-Chalco, 2009] Mena-Chalco, J. P. And Cesar Junior, R. M.; ScriptLattes: an open-source
knowledge extraction system from the Lattes platform, Journal of the Brazilian Computer
Figura 3: Mapa de relacionamento dos pesquisadores com base em suas publicações Society, V. 15, N. 4, Dezembro, 2009.
 112
XI Worshop sobre Software Livre
XadrezLivre: Proposta de Arquitetura de Ambiente
de Jogos baseado em XMPP com clienteWeb
Rubens Massayuki Suguimoto1, Luis Carlos Erpen de Bona1, Alexandre Direne1
1
Departamento de Informática – Universidade Federal do Paraná
Caixa Postal 19.081 – CEP 81.531-980 – Curitiba – PR – Brasil
frubensm, bona, alexdg@c3sl.ufpr.br
Abstract. Chess board game has served as an entertainment, it has strengths in devel-
opment of logical reasoning, learning and decisions making. Within this context of learning was
developed the project Apoio Computacional ao Ensino de Xadrez nas Escolas and as develop-
ment’s result of the project came XadrezLivre gaming environment. Currently the environment
supports more than 80.000 users and approximately 1.500 matches per day. This paper pres-
ents the architecture, implementation of the gaming environment and the Open Source tools
used and developed.
Resumo. O xadrez além de servir como entretenimento, apresenta pontos positivos no
desenvolvimento do raciocínio lógico, no aprendizado e na tomada de decisões. Dentro desse
contexto de aprendizado foi desenvolvido o projeto Apoio Computacional ao Ensino de Xadrez
nas Escolas e como resultado do desenvolvimento do projeto surgiu o ambiente de jogo Xa-
drezLivre. Atualmente o ambiente suporta mais de 80.000 usuários e aproximadamente 1.500
partidas por dia. Esse trabalho apresenta a arquitetura e a implementação do ambiente assim
como as ferramentas em Softwares Livre utilizadas e desenvolvidas.
1. Introdução
O xadrez é um jogo de tabuleiro que existe desde a antiguidade. Além de servir como
entretenimento, apresenta pontos positivos no desenvolvimento do raciocínio lógico, no apren-
dizado e na tomada de decisões. Com a popularização da Internet, surgiram servidores de
xadrez que permitem pessoas geograficamente distantes jogarem xadrez via web utilizando
um tabuleiro eletrônico.
Dentro desse contexto de aprendizado foi desenvolvido o projeto Apoio Computacional
ao Ensino de Xadrez nas Escolas [DIRENE et al. 2004]. O objetivo do projeto é permitir que uma
significativa parcela da classe estudantil, dos níveis fundamental e médio, tenham acesso de
forma rápida e frequente a efeitos positivos que o jogo de xadrez oferece. Para isso foi usado o
“estado da arte” em termos de Tecnologia Educacional baseada em Software Livre, para desen-
volver novos módulos e dar manutenção as ferramentas de Software responsáveis por auxiliar
o ensino de xadrez nas escolas.
1
http://xadrezlivre.c3sl.ufpr.br
Como resultado do desenvolvimento do projeto surgiu o ambiente de jogo XadrezLivre1. 113
O XadrezLivre é a implementação de uma arquitetura de jogo que inclui ambiente de comu-
XadrezLivre: Proposta de Arquitetura de Ambiente de Jogos baseado em XMPP com clienteWeb
nicação baseado no protocolo XMPP[Saint-Andre 2004], os componentes de jogo e a interface
usuário. Atualmente o ambiente conta com mais de 80.000 usuários e aproximadamente 1.500
partidas por dia [C3SL 2010].
Esse trabalho apresenta a arquitetura, descreve a implementação do ambiente e as
ferramentas utilizadas para seu desenvolvimento. Na seção 3 é detalhada a arquitetura de uma
forma bem geral. Os trabalhos relacionados são apresentados na seção 2. Na seção 4 contém
os detalhes de implementação do XadrezLivre e a conclusão e trabalhos futuros na seção 5.
2. Trabalhos relacionados
O Free Internet Chess Server (FICS) [FICS 2010], é uma implementação em software
livre de servidor de xadrez. O servidor é o mais conhecido e antigo no mundo e atualmente con-
tém mais de 300.000 usuários cadastrados. Nele há muitas funcionalidades implementadas. É
responsável por controlar a interação e comunicação entre os usuários, as funções administra-
tivas e, principalmente, por processar os estados das partidas. Todas as mensagens seguem o
padrão do próprio FICS.
O ChessD[ChessD 2007] é uma versão reestruturada e reescrita do servidor FICS com
uso de banco de dados para armazenar informações e jogos dos usuários. O protocolo de co-
municação usado é o FICS.
No entanto ambas as soluções apresentadas estão com o desenvolvimento descontinu-
ado. Além disso, a necessidade de instalação de software adicional para substituir a interface
do usuário por linha de comando torna o uso do sistema mais restrito.
A proposta de arquitetura do trabalho se baseia em utilizar um protocolo de comunica-
ção robusto e padronizado, um servidor de processamento de jogo, no caso o jogo de xadrez, e
uma interface usuário que torne o acesso ao sistema menos restrito. Nesse sentido as soluções
apresentadas poderiam ser incorporadas nessa nova arquitetura, sendo necessário fazer a tra-
dução do protocolo FICS para o protocolo utilizado na arquitetura.
3. Arquitetura do ambiente de jogo
O ambiente de jogo provê meios de interação entre usuários no qual os participantes
podem conversar, iniciar partidas de um determinado jogo, acompanhar partidas em andamen-
to, conectar em salas de conversas, entre várias outras funcionalidades. Para isso é necessário
um sistema robusto para troca de mensagens entre os jogadores e o servidor de jogo.
Com as necessidades apresentadas foi proposta uma arquitetura de ambiente de jogo
baseado no modelo cliente-servidor que inclui três módulos principais: o ambiente de comu-
nicação, os componentes de jogo e a interface usuário. Essa arquitetura está representada na
figura 1. A figura apresenta clientes ou interface do usuário que se conectam ao ambiente de
comunicação. Na parte à direita se encontram os vários componentes que cuidam das funcio-
nalidades de jogo como o analisador de partidas e o gerenciador de desafios.
O ambiente de comunicação é responsável por todas as trocas de mensagens existen-
tes dentro do sistema. A principal funcionalidade desse módulo é encaminhar as mensagens de
uma entidade, seja usuário ou servidor, para outra entidade. Para isso é necessário mecanis-
mos de autenticação e controle de acesso. Como estamos tratando de um ambiente de jogo é
 114 desejável que esse ambiente ofereça meios para os usuários interagirem uns com outros para o EjabberD oferece interfaces para ligar componentes externos que estendem as funcionalidades 115

que possam iniciar partidas. do sistema. Neste trabalho, o servidor de jogo é considerado um componente do servidor.
XI Worshop sobre Software Livre

XadrezLivre: Proposta de Arquitetura de Ambiente de Jogos baseado em XMPP com clienteWeb

Para identificar as entidades (usuários, salas de conversa, componentes), o servidor
utiliza o Jabber Id (JID). Com o JID, o EjabberD consegue gerenciar todas as mensagens que
trafegam no ambiente. No entanto, para obter um identificador é necessário passar por um
processo de autenticação.

4.2. Componentes do servidor de xadrez

O servidor de jogo ou servidor de xadrez usado é o novo ChessD[ChessD 2007] que foi
totalmente desenvolvido dentro do escopo do projeto. O servidor de xadrez2 foi implementado
em linguagem C++ como um componente do EjabberD. O mesmo recebe um estado de tabu-
Figura 1. Arquitetura geral leiro e o movimento que será realizado e retorna um novo estado para os jogadores, caso o
movimento esteja de acordo com as regras do jogo.
Os componentes de jogo ficam responsáveis por tratar todas as requisições relacio- Atualmente não existe um protocolo definitivo para jogos de xadrez sobre XMPP. Uma
nadas às partidas. Isso inclui todas as mensagens relacionadas aos desafios, as partidas em proposta de protocolo foi definida no JEP-xxxx3, entretanto este protocolo é usado para partidas
andamento, partidas adiadas, funções administrativas de xadrez dentre outras funcionalidades entre jogadores sem um controle intermediário, por exemplo, o servidor de xadrez. Devido a
presente no jogo. Como o ambiente de comunicação já oferece um mecanismo de comunicação isso foi criado um protocolo de xadrez específico4 para a implementação onde existe um servi-
robusto, os componentes ficam totalmente responsáveis pelas partidas sem se preocupar em dor que interpreta e responde sobre este protocolo.
tratar o tráfego de mensagens. Um fluxo de mensagens de desafio pode ser mostrado nas mensagens a seguir.
A quantidade de componentes no sistema pode variar de acordo com as necessidades.
Na figura 1 existem componentes que cuidam somente dos desafios, outro que gerencia os
torneios, outro que analisa partidas e assim por diante. Com isso é possível inserir e remover
componentes sem afetar outras funcionalidades.
A interface usuário é o módulo cliente. O cliente provê meios de enviar e receber mensa-
gens do ambiente de forma amigável ao usuário. A interface tem que ser projetada e implementa-
da para que o usuário faça uso do ambiente de forma transparente. O ideal é que o cliente possa
ser desenvolvido em qualquer linguagem de programação e funcione em qualquer plataforma. O jogador “raphaelr” envia um desafio para o jogador “eduari”. No entanto a requisição
Toda a arquitetura faz um uso intensivo de troca de mensagens entre as entidades. é enviada ao servidor para que o mesmo possa autorizar o desafio. Caso esteja autorizado, o
Devido a essa necessidade é preciso utilizar protocolos robustos de comunicação que tratem servidor envia uma requisição de desafio para “eduari”:
mensagens de requisições, confirmações e erros. Alguns protocolos de comunicação como o
HyperText Transfer Protocol (HTTP)[Fielding et al. 1999] ou eXtensible Messaging and Presence
Protocol (XMPP)[Saint-Andre 2004] são exemplos de protocolos robustos de comunicação que
podem ser usado nessa arquitetura.

4. XadrezLivre

O XadrezLivre é o ambiente de jogo que implementa a arquitetura proposta. Nessa se- O jogador “eduari” aceita o desafio enviando a mensagem:
ção está descrito os detalhes de implementação, ferramentas usadas e soluções aplicadas para
implantação do sistema. Cada módulo será descrito nas subseções seguintes.

4.1. Comunicação

O componente de comunicação usado é o servidor EjabberD[EJabberD 2010] que imple-

menta o protocolo XMPP[Saint-Andre 2004] e é uma aplicação em Software Livre. A escolha de tal
ferramenta foi feita por ter uma boa implementação do XMPP e por cuidar de muitos requisitos de 2
http://git.c3sl.ufpr.br/gitweb?p=chessd/chessd.git
3
http://www.xmpp.org/extensions/inbox/chess.html
comunicação entre usuários, como manter listas de contatos e salas de conversas. Além dessas, 4
http://git.c3sl.ufpr.br/gitweb?p=chessd/chessd.git;a=blob plain;f=chessd protocol doc.txt
 116 Essas três mensagens são o suficiente para iniciar uma partida no ChessD. Repare
que existem várias informações nas mensagens como a categoria de jogo (“standard”),
XI Worshop sobre Software Livre
identificador da partida (“match”), tempo da partida (“time”), cor das peças dos jogadores
(“color”), etc.
Para cada funcionalidade adicionada é necessário gerar uma mensagem nova no pro-
tocolo. Por isso é necessário refinar esse protocolo para que o mesmo possa ser estendido
facilmente. Um exemplo de refinamento que pode ser feito sobre o protocolo são os desafios
cobrirem as partidas em categorias que têm mais de dois jogadores como Bughouse.
4.3. Interface usuário
A interface do usuário foi desenvolvido baseada em estudos de
homemcomputador[Picussa et al. 2008a][Picussa et al. 2008b]. A implementação da interface
utiliza padrões web para facilitar o acesso e aumentar a interoperabilidade entre as plataformas
e sistemas. Com essa solução implementamos a interface usando Javascript e Cascading Style
Sheets (CSS). As figuras 2(a) e 2(b) mostram respectivamente a interface do usuário após logar
no ambiente e uma partida em andamento.
Figura 2. Interface web do XadrezLivre.
Um problema que surge ao utilizar interface web é a criação de conexão com o Ejab-
berD. Para solucionar esse problema foi necessário criar um proxy HTTP que gerencia as cone-
xões do cliente web com ambiente. Felizmente existe uma especificação de como implementar
esse proxy que é o Bidirectional-streams Over Synchronous HTTP[Saint-Andre and Paterson
2009] (BOSH).
O BOSH é responsável por interpretar mensagens com cabeçalho HTTP e extrair do con-
teúdo a mensagem XMPP para o EjabberD. O caminho inverso também é feito. Com essa ideia,
o BOSH mantém um controle sobre as seções abertas com os clientes. Através dessa estrutura
de controle, o programa saberá para qual cliente web enviar as mensagens e possivelmente
detectar se algum cliente se desconectou sem aviso prévio. Para o XadrezLivre foi desenvolvido
uma implementação do BOSH5 em C e o código está disponível para acesso.
5
http://git.c3sl.ufpr.br/gitweb?p=chessd/bosh.git
5. Conclusão 117
XadrezLivre: Proposta de Arquitetura de Ambiente de Jogos baseado em XMPP com clienteWeb
Este trabalho apresentou uma arquitetura para ambiente de jogo baseado no modelo
cliente-servidor. A arquitetura é composta de três módulos que consiste em um ambiente de
comunicação, os componentes de jogo e interface usuário.
Com a implementação dessa arquitetura foi desenvolvido o XadrezLivre que utiliza o
protocolo XMPP para comunicação. Como servidor de jogo foi desenvolvido o ChessD para pro-
cessar todas as requisições das partidas de xadrez e como interface do usuário foi desenvolvido
um cliente web para diminuir os esforços do usuário ao usar o sistema.
Ainda é necessário muito estudo e trabalho para desenvolvimento de um protocolo de
xadrez baseado em XMPP apropriado e que prevê todos os casos dentro das regras e categorias
interface do xadrez.
Referências
C3SL (2010). Xadrez livre: 80 mil usuários, 1500 partidas por dia. http://www.c3sl.ufpr.br/page/
news/id/68, Acesso em: Junho, 2010.
ChessD (2007). Chessd. http://chessd.sourceforge.net/index-br.html. Acesso em: Junho, 2010.
DIRENE, A. I., BONA, L. C. E., SILVA, F., SANTOS, G., GUEDES, A. L. P., CASTILHO, M. A., SUNYE, M.
S., HARTMANN, C. M., ANDRADE NETO, P. R., and MELLO, S. (2004). Conceitos e ferramentas
de apoio ao ensino de xadrez nas escolas brasileiras. In X WIE - Workshop sobre Informática
na Escola. Anais do X Workshop sobre Informática na Escola. Sociedade Brasileira de Com-
putação, pages 183–192.
EJabberD (2010). Ejabberd. http://www.process-one.net/en/ejabberd. Acesso em: Junho, 2010.
FICS (2010). Free internet chess server. http://www.freechess.org/. Acesso em: Junho, 2010.
Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and Berners-Lee, T. (1999).
Hypertext Transfer Protocol – HTTP/1.1. RFC 2616 (Draft Standard). Updated by RFCs 2817,
5785.
Picussa, J., Garcia, L., Bueno, J., Ferreira, M., Direne, A., de Bona, L., Silva, F., Castilho, M., and
Sunye, M. (2008a). A user-interface environment solution for an online educational chess
server. In Research Challenges in Information Science, 2008. RCIS 2008. Second Interna-
tional Conference on, pages 179 –186.
Picussa, J., García, L. S., Bueno, J., Ferreira, M. V. R., Direne, A. I., Bona, L. C. E. D., Silva, F., Casti-
lho, M. A., and Sunyé, M. S. (2008b). A user-interface environment solution as an educational
tool for an online chess server on the web. In ICEIS (5), pages 262–267.
Saint-Andre, P. (2004). Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
and Presence. RFC 3921 (Proposed Standard).
Saint-Andre, P. and Paterson, I. (2009). Xep-0206: Xmpp over bosh.
 119

Sessão V
Software Básico e Sistemas Operacionais

120 Análise Experimental Comparativa de Algoritmos de

Alocação de Memória de Código Aberto

Rivalino Matias Jr. (UFU), Autran Macêdo (UFU), Tais Ferreira

(UFU)

126 Avaliação Experimental do Índice de Carga Usado no Ker-

nel Linux

Rivalino Matias Jr. (UFU), Leonardo Alt (UFU), Otávio Augusto

(UFU)

132 MDM: Um Software Livre para Configuração de Ambien-

tes Multiterminais

Francisco Kaseker (UFPR), Aramis Stach Haiduski Fernandes

(UFPR), Lucas Ferreira (UFPR), Paulo Zanoni (UFPR), Pedro Eu-
genio Rocha (UFPR), Eduardo Todt (UFPR)

138 WFS: Um Sistema de Arquivos FUSE-Linux Baseado na

Política Write-Once Read-Many

Tiago Falcão (UFPE), Ermeson Andrade (UFPE), Rubens Matos

(UFPE), Paulo Maciel (UFPE), Stephen Worth (EMC Corporation),
Paul Malenfant (EMC Corporation)
 120
XI Worshop sobre Software Livre
Análise Experimental Comparativa de Algorit-
mos de Alocação de Memória de Código Aberto
Rivalino Matias Jr.1, Autran Macêdo1, Taís Borges Ferreira2
1
Faculdade de Computação – Universidade Federal de Uberlândia
2
Curso de Bacharelado em Ciência da Computação - Faculdade de Computação –
Universidade Federal de Uberlândia
{rivalino,autran}@facom.ufu.br, taisbferreira@comp.ufu.br
Abstract. Memory allocations are one of the most ubiquitous operations in computer
programs. The performance of the allocators that implement these operations is very important
for the overall performance although it is very often negligenced. This paper presents a com-
parative study of five general purpose and open source memory allocators. Unlike other related
works, based on benchmark tests that are difficult to generalize to real-world applications, this
work evaluates the selected allocators’ performance combined with the MySQL software. The
results demonstrate that MySQL shows the best performance when using the jemalloc allocator,
especially when it is compared with the standard glibc allocator.
Resumo. Operações de alocação de memória estão entre as mais ubíquas em progra-
mas de computador. O desempenho dos alocadores que implementam essas operações é de
suma importância para o desempenho global da aplicação, embora muitas vezes seja negligen-
ciado. Esse trabalho apresenta um estudo comparativo entre cinco alocadores de memória de
propósito geral e de código aberto. Diferente de outros trabalhos na área, baseados em testes
de benchmark com difícil generalização para aplicações reais, esse trabalho avalia o desem-
penho dos alocadores no software MySQL. Os resultados mostram que o MySQL apresentou
melhor desempenho em conjunto com o jemalloc, especialmente quando comparado com o
alocador padrão da glibc.
1. Introdução
Durante a execução de um programa de computador, a eficiência no uso da memória
principal tem impacto significativo no desempenho do programa. De forma geral, aplicações
do mundo real necessitam alocar e desalocar porções de memória, de tamanhos variados, por
inúmeras vezes durante suas execuções. Essas operações de alocação e desalocação são comu-
mente realizadas com grande frequência em programas mais sofisticados, o que faz com que o
desempenho dessas operações influencie significativamente no desempenho global do sistema.
As operações de alocação de memória existem em dois níveis. No nível do núcleo do
sistema operacional (kernel level) e no espaço do usuário (user level). No kernel level elas são
implementadas por um alocador de memória chamado genericamente de KMA (kernel memory
allocator) [Vahalia 1995], o qual tem como função o gerenciamento da memória para atender
as necessidades dos subsistemas do próprio sistema operacional. No user level essas ope-
rações são implementadas por um alocador que fica armazenado em uma biblioteca padrão 121
que é ligada ao programa durante a geração do seu código executável. No Linux, a glibc1 é a
Análise Experimental Comparativa de Algoritmos de Alocação de Memória de Código Aberto
biblioteca que armazena as rotinas e estruturas de dados do alocador de memória padrão em
nível de usuário, genericamente chamado de UMA (user-level memory allocator). Os alocadores
investigados nesse trabalho são do tipo UMA e serão chamados, desse ponto em diante, de
alocador de memória ou simplesmente alocador.
Um alocador de memória tem como função primária o gerenciamento do heap [Vahalia
1995]. Heap é uma porção de memória localizada na região de dados do processo, a qual é
usada para atender requisições de alocações dinâmicas de memória. Essas requisições são
usualmente realizadas por meio das funções malloc(), realloc() e free(), que são implementa-
das como parte do alocador. Nos casos onde a requisição ultrapassa o tamanho disponível no
heap do processo, o alocador pode solicitar mais memória para o sistema operacional a fim de
atender a requisição. Essa porção de memória adicional é incorporada ao conjunto de páginas
de memória do processo que é gerenciado pelo alocador. Desse modo, as rotinas e estruturas
de dados do alocador são partes do processo e, portanto, podem ser substituídas pelo progra-
mador da aplicação.
Diversos sistemas não usam o alocador de memória disponível na biblioteca padrão,
trazendo em seu código uma implementação própria de alocador. Isso ocorre porque usual-
mente a biblioteca padrão implementa um alocador de propósito geral, não sendo esse algo-
ritmo otimizado para contemplar características específicas de cada aplicação que o utiliza.
Dependendo da aplicação, as necessidades de alocação dinâmica de memória são bastante
específicas e o alocador padrão não oferecerá um bom desempenho. Aspectos como o uso de
múltiplos processadores e múltiplas threads de controle são exemplos de características que
têm impacto significativo no desempenho das operações realizadas pelo alocador de memória
[Berger et al. 2000]. Aplicações sofisticadas tais como o servidor web Apache, gerenciador de
banco de dados PostgreSQL, e o navegador Firefox, são exemplos de programas que trazem seu
próprio alocador em alternativa ao disponível na biblioteca padrão.
Atualmente, existem diversos algoritmos e implementações de código aberto para alo-
cadores de memória, os quais podem ser usados como alternativa ao alocador da biblioteca
padrão. A escolha de qual alocador oferece os melhores resultados para uma determinada apli-
cação deve ter com base uma avaliação experimental. Vários trabalhos (ex. [Zorn e Grunwald
1994], [Attardi e Nadgir 2003] [Masmano, Ripoll e Crespo 2006]) têm apresentado estudos
sobre o desempenho de algoritmos de alocação dinâmica de memória. Contudo, a maioria dos
trabalhos nessa área avalia os alocadores com base em programas de teste (ex. mtmalloctest
[Attardi e Nadgir 2003]) que realizam diferentes operações de alocação de memória a fim de
exercer, muitas vezes de forma aleatória, as rotinas e estruturas de dados do alocador avaliado.
O problema com essa abordagem é que os resultados obtidos nesses testes dificilmente podem
ser generalizados para uso em aplicações do mundo real. Nesse contexto, esse trabalho apre-
senta um estudo que compara, experimentalmente, cinco alocadores de memória de código
aberto. Ao contrário dos trabalhos citados, nesse estudo foi utilizada uma aplicação real para
avaliar o desempenho dos alocadores. A aplicação escolhida foi o gerenciador de banco de
dados MySQL. A motivação para essa escolha é que gerenciadores de banco de dados são apli-
cações com exigentes requisitos de gerenciamento de memória dinâmica e também pelo fato
do MySQL ser atualmente muito usado em aplicações web que exigem elevado desempenho.
O restante do artigo está organizado como descrito a seguir. A Seção 2 apresenta os
alocadores selecionados para o estudo. Na Seção 3 são apresentados os detalhes envolvidos
1
www.gnu.org/software/libc/
 122 na etapa de experimentação, enfatizando a metodologia e os planos experimentais adotados.
A Seção 4 apresenta uma análise dos principais resultados obtidos na etapa experimental. Fi-
XI Worshop sobre Software Livre
nalmente, na Seção 5 são apresentadas as conclusões desse trabalho.
2. Alocadores Investigados
Este trabalho compara o desempenho de cinco implementações de alocadores de me-
mória de propósito geral: Hoard (versão 3.8), ptmalloc (versão 2), TCMalloc (versão 1.5), je-
malloc (versão linux_20080827) e nedmalloc (versão 1.05). Esses alocadores foram selecio-
nados devido à disponibilidade de código fonte, além de alguns deles terem sido usados em
trabalhos correlatos que demonstram seu melhor desempenho frente a diversos outros aloca-
dores, que por esse motivo foram desconsiderados nesse estudo.
O Hoard [Berger et al. 2000] foi desenvolvido com o principal objetivo de se ter aloca-
ção com alto desempenho em programas com múltiplas threads executando em computadores
com múltiplos processadores. Esse algoritmo implementa uma área de heap global para todas
as threads, além de uma área privativa para cada uma delas. Essas duas áreas possibilitam
ao Hoard minimizar os efeitos de contenção de heap (múltiplas threads concorrendo pela mes-
ma área de memória), além de um tipo específico de fragmentação de memória denominado
blowup [Berger et al. 2000]. O Hoard também é reconhecido pela redução nos efeitos do falso
compartilhamento de memória (isto é, quando threads executando em diferentes processado-
res compartilham equivocadamente a mesma linha de cache).
O ptmalloc [Gogler 2006] é um algoritmo baseado no DLMalloc [Lea 1996]. O ptmalloc
incorpora recursos voltados para multiprocessadores executando programas com múltiplas
threads de controle, os quais não eram amplamente utilizados quando seu antecessor DLMalloc
foi desenvolvido. Tal qual o Hoard, o ptmalloc implementa múltiplas áreas de heap para diminuir
a contenção de memória em programas multithreaded. Diferente do Hoard, esse não trata o
problema de falso compartilhamento de memória. Atualmente, existem três versões do pt-
malloc. A versão 2, que é o padrão na glibc do Linux, é o alocador considerado nesse trabalho.
O TCMalloc [Ghemawat e Menage 2010], diferente dos antecessores, busca minimizar
a contenção de acesso ao heap usando uma abordagem híbrida. Para objetos pequenos (_
32K), sua abordagem é similar aos anteriores, onde cada thread possui sua própria porção do
heap. Contudo, para objetos grandes (_ 32K) o TCMalloc utiliza um heap global, minimizando
a contenção entre as múltiplas threads por meio de spin-locks de fina granularidade. Segundo
Ghemawat e Menage (2010), algoritmos baseados apenas em heaps locais por threads sofrem
com excessiva utilização de memória e fragmentação.
O jemalloc [Evans 2006] foi desenvolvido para ser o alocador padrão no FreeBSD em
substituição ao seu antecessor PHKalloc [Kamp 1998], que como o DLMalloc foi criado quando
sistemas multiprocessados e multithreading não eram populares. Um dos principais objetivos
desse alocador é reduzir a contenção de bloqueio em aplicações multithreaded executando em
múltiplos processadores. Similar aos demais algoritmos, esse usa múltiplas porções do heap
(arenas), por padrão quatro vezes o número de processadores. Cada thread é associada a um
conjunto de arenas, onde uma arena é escolhida seguindo uma política round-robin, reduzindo
assim a probabilidade de contenção. Os metadados de alocações muito grandes (_ 1M) são
armazenados em uma única estrutura de árvore rubro-negra (red-black tree), e a suposição
adotada pelos autores desse algoritmo é que por não ser freqüente esse tamanho de alocação,
a manutenção de uma única estrutura para todas as threads não seria um problema para a
escalabilidade do algoritmo.
O alocador nedmalloc [Douglas 2010], assim como o ptmalloc2, é baseado no DLMalloc. 123
A diferença é que o ptmalloc2 é baseado na versão dlmalloc 2.7.0 enquanto o nedalloc é base-
Análise Experimental Comparativa de Algoritmos de Alocação de Memória de Código Aberto
ado na dlmalloc 2.8.3. O nedalloc estende o dlmalloc basicamente encapsulando um cache por
thread (per-thread lookaside cache) para melhorar os acessos concorrentes ao heap.
3. Estudo Experimental
O plano experimental utilizado nesse estudo considera a execução de 30 replicações
por teste, onde cada replicação tem duração de 10 minutos. Para eliminar os efeitos dos
erros experimentais [Montgomery 2005], utilizou-se a média aritmética das replicações.
O instrumental usado contou com uma bancada de teste com a seguinte configura-
ção: 3 computadores, onde um executa o MySQL versão 5.0.41 e os outros dois o software
db_Stress [Kravtchuk 2007], o qual foi utilizado para gerar cargas de trabalho no servidor.
O db_Stress foi desenvolvido para auxiliar na avaliação de desempenho de gerenciadores
de banco de dados por meio da realização de diferentes tipos de transações em intervalos
de tempo pré-determinados. As transações geradas pelo db_Stress são submetidas a um
banco de dados constituído de cinco tabelas que simulam uma aplicação convencional.
Essas tabelas possuem relacionamento entre si, índices e uma população de milhões de
linhas. As transações utilizadas consistem em operações select, insert, delete e update. No
total, são cinco transações que são executadas ininterruptamente por um período definido
pelo usuário no momento da sua execução. Maiores detalhes sobre o modelo de dados e as
transações utilizadas pelo db_Stess podem ser obtidos em [Kravtchuk 2007].
Ao final do período definido para o teste, o db_Stress reporta a quantidade de tran-
sações realizadas, e o tempo demandado por cada transação. O computador do servidor de
banco de dados (Intel Core 2 Duo 2.40 GHz; 2 GB RAM) e os computadores clientes (Pen-
tium 4 3.4 GHz; 1 GB RAM) executando o db_Stress foram interconectados por uma rede
100 Mbps. Tanto nos clientes quanto no servidor adotou-se o sistema operacional Linux
Debian 5, kernel 2.6.26-1-686, executando em runlevel 3. A versão da glibc usada foi 2.7-
18lenny2.
O MySQL foi testado com cada um dos cinco alocadores selecionados (ver Seção 2).
Para isso, em cada teste do MySQL o ligador dinâmico (dynamic linker) do Linux foi instruído
a carregar um dos alocadores avaliados. Isso é realizado usando a variável de ambiente
LD_PRELOAD (ex. export LD_PRELOAD= libjemalloc_mt.so.0). Como resultado, o MySQL pas-
sa a usar as funções (malloc(), free(), etc.) de alocação da biblioteca compartilhada e não
da glibc. Alternativamente, pode-se ligar (linking) estaticamente o alocador de interesse ao
código do MySQL. Em ambos os casos, o desempenho do MySQL é influenciado pelo algorit-
mo de alocação ligado a ele no momento dos testes.
4. Análise dos Resultados
As Tabelas 1 a 4 apresentam a classificação do desempenho dos alocadores com respei-
to aos principais testes realizados. Os alocadores estão ordenados com o melhor desempenho
no topo. Verifica-se que em todos os casos avaliados, a ordem de classificação foi a mesma.
Como descrito na Seção 3, essa análise considera os valores médios das 30 replicações, onde
cada replicação (teste) teve duração de 10 minutos.
 124 com difícil generalização para aplicações do mundo real, esse trabalho comparou o desem- 125
Tabela 1. Transações Tabela 2. Total Tabela 3. Total de Tabela 4. Tempo
para segundo de Transações Leituras/Escritas Médio de select penho dos alocadores avaliados com o popular gerenciador de banco de dados MySQL, muito
XI Worshop sobre Software Livre

Análise Experimental Comparativa de Algoritmos de Alocação de Memória de Código Aberto

Alocador Total Alocador Total Alocador Total Alocador Total usado em inúmeras aplicações reais. Verificou-se que a influência dos alocadores tanto na
jemalloc 2615,13 jemalloc 1569416,00 jemalloc 784708,23 jemalloc 1187,23 capacidade total de processamento de transações quando no tempo de operações individuais
Hoard 2605,73 Hoard 1563745,00 Hoard 781872,50 Hoard 1193,67 (ex. select) foi significativa, com destaque para o jemalloc, o qual ofereceu um aumento na
TCMalloc 2602,07 TCMalloc 1561580,87 TCMalloc 780790,43 TCMalloc 1196,67 capacidade de transações por segundo (TPS) na ordem de 15 TPS em relação ao ptmalloc2,

nedmalloc 2600,33 nedmalloc 1560463,60 nedmalloc 780231,80 nedmalloc 1196,77

utilizado atualmente pela glibc como alocador padrão no Linux.

ptmalloc2 2600,13 ptmalloc2 1560408,20 ptmalloc2 780204,10 ptmalloc2 1198,13

A Tabela 1 refere-se ao número de transações executadas por segundo durante um tes-
te. Nesse teste são realizadas todas as operações (select, insert, delete e update). Na Tabela 2
tem-se o número total de transações executadas por teste, considerando as quatro operações
citadas anteriormente. A Tabela 3 mostra a quantidade de operações de leitura (select) reali-
zadas por teste. O db_Stress reportou os mesmos valores para operações de escrita (insert,
delete e update). A Tabela 4 lista os tempos médios para operações do tipo select. Para as de-
mais operações, as diferenças nos tempos das operações individuais não foram significativas,
sendo o melhor algoritmo (jemalloc), em média, 2,5 microssegundos mais rápido do que o pior
resultado (ptmalloc2).
Dentre os cinco alocadores avaliados, o jemalloc apresentou os melhores resultados em
praticamente todos os testes. Em especial, sua maior influência no desempenho do MySQL se
deu no número total de transações realizadas. Já o pior desempenho ficou com o ptmalloc2, o
atual alocador padrão na glibc. Considerando que a maioria dos usuários utilizam o MySQL com
o alocador padrão da glibc, esses resultados sugerem que uma melhor alternativa seria a uti-
lização do jemalloc. O jemalloc realizou 15 transações por segundo a mais do que o ptmalloc2
(ver Tabela 1). Essa diferença em um período de operação, por exemplo, de 24 horas, seria de
aproximadamente um milhão e trezentas mil transações. Considerando uma aplicação real,
trata-se de uma diferença importante. Esse maior desempenho do jemalloc sobre o número de
transações também explica os resultados das Tabelas 2 e 3. Com relação a operações individu-
ais, vale destacar o resultado obtido para as operações de consulta (select). O jemalloc sobres-
saiu com uma diferença para o ptmalloc2 de aproximadamente 11 microsegundos por consulta
(ver Tabela 4). Isso significa que em um segundo, o jemalloc consegue realizar 7,6 transações
de consulta a mais do que o ptmalloc2. Ao final de 24 horas, por exemplo, essa diferença per-
mitiria ao MySQL (com o jemalloc), executar aproximadamente 662,000 transações a mais do
que com o ptmalloc2.
Referências
Attardi, J. and Nadgir, N. (2003) “A Comparison of Memory Allocators in Multiprocessors”, http://
developers.sun.com/solaris/articles/multiproc/multiproc.html
Berger, E. D., McKinley, K.S., Blumofe, R.D. and Wilson, P.R. (2000) “Hoard: a scalable memory
allocator for multithreaded applications”, 9th Int’l conf. on architectural support for program-
ming languages and operating systems ACM SIGARCH Computer Architecture News, v.28:5,
p.117-128
Douglas, N. (2010) “nedmalloc”, www.nedprod.com/programs/portable/nedmalloc.
Evans, J. (2006) “A Scalable Concurrent malloc() Implementation for FreeBSD”.
Ghemawat, S. and Menage, P. (2010) “TCMalloc: Thread-Caching Malloc”, http://goog-perftools.
sourceforge.net/doc/tcmalloc.html.
Gloger, W (2006) “ptmalloc”, http://www.malloc.de/en/
Kamp PH (1998) “Malloc(3) revisited”. USENIX and FREENIX, p. 193–198.
Kravtchuk, D. (2007) “db_Stress Benchmark”, http://dimitrik.free.fr/db_STRESS.html
Lea, D. (1996) “A Memory Allocator,” http://gee.cs.oswego.edu/dl/html/malloc.html
Lever, C. and Boreham, D. (2000) “malloc() Performance in a Multithreaded Linux Environment”,
In: Usenix 2000, p.301-311.
Masmano, M., Ripoll, I. and Crespo, A. (2006) “A comparison of memory allocators for real-time
applications”, Proc. of 4th Int’l workshop on Java technologies for real-time and embedded
systems, ACM Int’l Conference Proceeding Series, vol. 177, p.68-76
Montgomery, D.C. (2005) Design and Analysis of Experiments, 6 ed., J. Wiley & Sons.
Vahalia, U. (1995) UNIX Internals: The New Frontiers, Prentice Hall.
Zorn, B. and Grunwald, D. (1994) “Evaluating models of memory allocation”, ACM Transactions
on Modeling and Computer Simulation (TOMACS), vol.4:1,p.107-131

5. Conclusão

O desempenho de operações de alocação de memória tem significante influência no

desempenho global da maioria das aplicações computacionais. Nesse sentido, a seleção de
um alocador de memória é um importante requisito no projeto de sistemas mais sofisticados,
sendo muitas vezes negligenciada pelos projetistas de software. A forte correlação entre o perfil
de uso dinâmico da memória com o desempenho do alocador exige que a seleção do alocador
ocorra por meio de um estudo experimental.
Nesse trabalho foi apresentado um estudo experimental comparativo entre cinco dos
principais alocadores de memória, de propósito geral e de código aberto, disponíveis atualmen-
te. Diferente de inúmeros trabalhos na área, os quais são baseados em testes de benchmark
 126 o recurso (ex. CPU) está com sua utilização próxima ou igual a 100%. Nesses casos, o tamanho 127

da contenção (número de processos aguardando pelo recurso) não é considerado, mas apenas
XI Worshop sobre Software Livre

Avaliação Experimental do Índice de Carga Usado no Kernel Linux

Avaliação Experimental do Índice
de Carga Usado no Kernel Linux
Rivalino Matias Jr, Leonardo Alt, Otávio Augusto
Faculdade de Computação – Universidade Federal de Uberlândia (UFU) –
38400-902 – Uberlândia – MG – Brasil
rivalino@facom.ufu.br, {leonardoalt,octopos}@comp.ufu.br
Abstract. In this paper we experimentally evaluate the quality of loadavg index avai-
lable at Linux kernel. The research hypothesis is that loadavg is not adequate to characterize
scenarios with considerable kernel-level activity. For specific classes of Linux-based systems
(e.g., firewalls), the system load in kernel level may be significantly higher than in user level.
The experimental results indicate that loadavg is not able to appropriately represent scenarios
of high kernel-level workload, what confirms the evaluated hypothesis.
Resumo. Neste artigo avaliamos experimentalmente a qualidade do loadavg imple-
mentado no kernel Linux. A hipótese de pesquisa é de que esse índice de carga não é adequado
para caracterizar cenários com significante atividade em nível de kernel. Para alguns tipos de
sistemas baseados em Linux (ex. firewals), a carga em nível de kernel pode ser significante-
mente maior do que em espaço de usuário. Os resultados experimentais mostraram que o
loadavg não é capaz de representar apropriadamente cenários com carga elevada em nível de
kernel, confirmando a hipótese de pesquisa avaliada.
a ocupação do recurso. Por exemplo, dois sistemas idênticos apresentam 100% de utilização
de CPU. Um índice baseado na utilização da CPU indicaria que os dois sistemas têm o mesmo
nível de carga. Já um índice baseado no número de tarefas aguardando na fila da CPU permitiria
concluir que uma nova tarefa deve ser alocada no sistema com menor fila de espera. Ferrari
e Zhou também observaram que uma melhor caracterização da carga é obtida com valores
médios do tamanho de filas, para períodos curtos (ex. 10 segundos), em alternativa ao uso de
valores obtidos de forma instantânea.
Atualmente, o índice de carga usado em sistemas Linux (e também Unix) é o loadavg
(load average) [Gunther 2004], o qual segue a abordagem de filas de recursos descrita ante-
riormente [Ferrari e Zhou 1987]. Por ser uma métrica de carga tradicional, o loadavg é usado
por diversas aplicações legadas. Além disso, vários trabalhos acadêmicos (ex. [Ferrari e Zhou
1986], [Zhou 1988], [Chen et al. 2006], [Broberg et al. 2006]) utilizam os valores do loadavg.
Nesse contexto, esse estudo avalia a qualidade das caracterizações fornecidas pelo loadavg no
kernel Linux. Durante o levantamento bibliográfico, verificou-se que a maioria dos trabalhos
relacionados se concentra em cenários de carga de trabalho predominantemente exercida no
espaço do usuário. Portanto, esse estudo considera tanto cargas de trabalho em nível de usu-
ário quanto em nível de kernel, com foco para o segundo tipo, já que não foram encontrados
trabalhos voltados para esse tipo de caracterização. Cenários com carga elevada em nível de
kernel são freqüentes em sistemas especializados, tais como sistemas embarcados para aplica-
ções de rede (ex. roteadores), os quais passam a maior parte do tempo executando atividades
em nível de kernel.
O restante do artigo está organizado como descrito a seguir. A Seção 2 descreve o
modelo de índice de carga do loadavg e sua implementação no kernel Linux. Na Seção 3 são
apresentados os detalhes envolvidos na etapa de experimentação, enfatizando a metodologia
e os planos experimentais adotados. A Seção 4 apresenta uma análise dos principais resultados
obtidos no estudo experimental. Finalmente, na Seção 5 são apresentadas as conclusões desse
trabalho.

1. Introdução
2. Índice de Carga no Linux
Índices de carga são informações de estado mantidas pelo kernel de um sistema ope-
racional. Esses índices indicam a carga corrente do sistema e são muito usados para decidir
Como discutido na Seção 1, o loadavg é o índice de carga padrão do kernel Linux
sobre a capacidade e disponibilidade de um sistema em receber novas tarefas, ou mesmo da
[Gunther 2004]. De fato, o loadavg foi um dos conceitos de instrumentação implementados
necessidade de remanejar tarefas de um sistema para outro. Atualmente, uma das aplicações
no Multics [Saltzer e Gintell 1970], sistema operacional predecessor da família de sistemas
práticas dos índices de carga é o balanceamento de carga em sistemas distribuídos. A literatura
operacionais Unix. Sistemas Unix-like implementam essa métrica e a disponibilizam por meio
cita suas aplicações no escalonamento de tarefas em clusters de computadores [Sit et al. 2004]
de programas utilitários (ex. uptime) e, no caso do Linux, também via procfs (/proc/loadavg).
e Grids Computacionais [Payli et al. 2004].
O loadavg é composto por três valores que caracterizam a carga do sistema em intervalos de
De forma geral, o conceito de carga (load) diz respeito ao uso dos recursos de processa-
1, 5 e 15 minutos. Esses valores iniciam em zero, variando de acordo com a carga do sistema.
mento de um sistema. Na literatura, existem diversos trabalhos que investigam diferentes abor-
Considerando a carga do último minuto, loadavg_1, um valor de 0.5 indica que o sistema tem
dagens para quantificar a carga de um sistema. Dentre eles, destaca-se o trabalho de Ferrari e
uma carga que, em média, ocupa 50% da sua capacidade de processamento. Por conseguin-
Zhou (1987) que realiza uma comparação entre diversas abordagens para cálculo do índice de
te, um valor de 1.5 indica uma carga adicional de 50% além da capacidade de processamento
carga em sistemas Unix. São comparados índices baseados apenas na utilização de CPU com
do sistema.
índices baseados no tamanho de filas de tarefas aguardando por CPU, I/O de disco, e recursos
No Linux, o loadavg é implementado como um vetor de três elementos do tipo unsigned
de memória. Os autores concluem que índices baseados no tamanho de filas são melhores do
long. Cada posição do vetor armazena um número, em notação de ponto fixo, representando um
que apenas na utilização de recursos. Índices baseados apenas no uso de recursos não conse-
valor real, e correspondendo a um dos três intervalos descritos anteriormente. Como exemplo, a
guem quantificar o tamanho da contenção que ocorre em casos de alta carga de trabalho, onde
função que calcula o loadavg_1 segue o modelo apresentado na Equação 1 [Gunther 2004].
 128 load(t) = load(t –1)e-5/60 + n(1-e-5/60), (1) utilizam cargas em nível de usuário: T2 (1 processo), T3(5), T4(10), T5(15). Já T6 até T9 adotam 129

cargas em nível de kernel: T6(1 work), T7(5), T8(10), T9(15). Os demais tratamentos implemen-
XI Worshop sobre Software Livre

Avaliação Experimental do Índice de Carga Usado no Kernel Linux

onde n é o número de processos ativos, ou seja, na fila de execução (TASK_RUNNING) ou taram carga variável, onde T10 utilizou uma carga em nível de usuário iniciando em 1 processo
bloqueados em eventos “não interruptíveis” (TASK_UNINTERRUPTIBLE) [Bovet e Cesati 2005]. e incrementando 5 processos a cada 5 minutos. Em T11, repetiu-se o mesmo procedimento de
No Linux o valor de n é amostrado a cada 5 segundos. Portanto, conclui-se que (1) é uma T10, contudo para cargas em nível de kernel (works). A próxima seção apresenta os resultados
média móvel exponencial onde a carga corrente, load(t), é igual ao último valor calculado de obtidos.
loadavg_1 multiplicado por uma constante de suavização exponencial, e-5/60, e somado ao
número de processos ativos ponderado pela constante de suavização apropriada ao período de
1 minuto. O mesmo algoritmo é usado para o cálculo de loadavg_5 e loadavg_15, mudando-se 4. Análise dos Resultados
apenas as constantes de suavização para e-5/300 e e-5/900, respectivamente. Maiores detalhes
sobre essas constantes estão disponíveis em [Gunther 2004]. O propósito desse modelo de Para cada tratamento calculou-se a média aritmética das 10 replicações. Também, cal-
média móvel não é apenas suavizar exponencialmente os extremos, mas também reduzir a culou-se o desvio padrão da amostra (médias das 10 replicações) para se observar a variabi-
importância dos valores menos recentes em relação aos novos valores de carga, visto que eles lidade dos dados. Devido à limitação de espaço, serão apresentados apenas os resultados do
têm maior influência no estado corrente do sistema. Como pode ser observado em (1), o mode- loadavg_1. Os demais valores (5 e 15 min.) corroboram o padrão apresentado pelo loadavg_1.
lo de carga do loadavg considera apenas a quantidade (n) de atividades que são executadas em O valor médio para o loadavg_1 com o sistema sem carga foi de 0,1057. Idealmente, esse valor
contexto de processos. O número de atividades aguardando para executar tarefas do kernel, deveria ser zero, contudo os diversos processos (ex. agetty) e threads (ex. ata/0) do sistema,
principalmente em bottom halves [Love 2003] e usualmente no contexto de interrupções, não presentes em qualquer cenário, influenciam nesse valor. As Tabelas 1 e 2 apresentam os resul-
são consideradas. No kernel Linux, diversos mecanismos são usados para executar tarefas bot- tados dos tratamentos T2 a T9.
tom halves, a saber: work queues, tasklets, softirqs, e timers [Wilcox 2003]. Esses mecanismos
Tabela 1. Workload Constante em user level Tabela 2. Workload Constante em kernel level
são usados principalmente por controladores de dispositivos, onde alguns desses mecanismos
(ex. timers e work queues) possuem filas de execução próprias e que não são consideradas no Trat. Média do loadavg_1 D.P. Trat. Média do loadavg_1 D.P.
cálculo do loadavg. Como citado anteriormente, cargas de trabalho consideráveis, em nível de T2 1,0697 0,0161 T6 4,5333 0,1169
kernel, estão presentes em sistemas especializados, tais como bridges, filtros de pacotes, con- T3 5,1478 0,0899 T7 4,3739 0,0919
troladores de banda, dentre outros. Adicionalmente, sistemas com funcionalidades como NFS T4 10,4412 0,1149 T8 4,1501 0,0656
e RAID, implementadas no kernel, também apresentam elevadas cargas em nível de kernel.
T5 15,7251 0,2137 T9 3,8855 0,0489
Com base nessa análise teórica do loadavg, a etapa experimental desse estudo investiga tanto
cargas de trabalho em nível de usuário quanto de kernel.
Na Tabela 1, o valor do loadavg_1 acompanha linearmente o incremento da carga de
trabalho no nível de usuário. Já o incremento da carga no nível de kernel não foi caracterizado
3. Estudo Experimental adequadamente, pois o loadavg_1 não acompanha o crescimento da carga de trabalho (ver
Tabela 2). Por exemplo, T9 adota 15 works e T6 apenas uma. O valor de 4,5 para T6 é explicado
Nessa etapa avaliou-se a qualidade do índice loadavg no kernel Linux. A metodologia pelo acúmulo de processos do sistema (em nível de usuário) aguardando para executar. Esses
adotada baseou-se na realização de experimentos controlados, utilizando 10 replicações para processos devem aguardar a execução da work criada em T6, pois a thread de kernel, events/0,
cada tratamento [Montgomery 2005]. Dessa forma, buscou-se reduzir a influência dos efeitos quem executa o código da work, é enfileirada na mesma fila de processos. Diferentemente das
experimentais presentes em cada execução. Cada replicação de um tratamento executa por works, as tasklets, softirqs e timers não são servidas por uma thread de kernel e, portanto, são
um período de 20 minutos. O plano experimental contou com tratamentos que testa o loadavg totalmente transparentes para o índice de carga loadavg, reduzindo ainda mais a sua capacida-
em diferentes cenários de carga, tanto em nível de usuário quanto de kernel. Para o nível de de de caracterização de carga em nível de kernel. Observa-se nas Tabelas 1 e 2 que os valores
usuário, implementou-se um programa de multiplicação de matrizes. Para o nível de kernel de desvio padrão (D.P.) indicam uma baixa variabilidade entre as replicações.
foram usadas works executando uma espera-ocupada de 10ms e, posteriormente, se auto re- Outra avaliação do loadavg foi quanto à sua capacidade de capturar cargas incremen-
escalonando (schedule_work()). Além disso, foram avaliadas cargas de trabalho constante e va- tais. As Figuras 1 e 2 apresentam os resultados para os tratamentos T10 e T11. Verifica-se que
riável, sendo essa última implementada como um incremento do número de processos/works. para cargas em nível de usuário, o loadavg acompanhou o crescimento dinâmico da carga, ao
Todos os testes foram realizados com um número reduzido de processos padrões do sistema contrário do cenário para cargas em nível de kernel, onde o valor do loadavg não acompanhou
(runlevel 3). O ambiente de teste foi um computador com processador Intel Core 2 Quad de o crescimento a partir dos primeiros cinco minutos.
2.66 GHz e 2 Gb RAM, usando apenas um núcleo habilitado, sendo os demais desativados [Raj Como osbervado, o loadavg mostrou-se inadequado para cenários de carga em nível de
2010]. A versão de kernel usada foi a 2.6.33.3, obtida em www.kernel.org e compilada com as kernel. A fim de identificar os subsistemas que mais agendam atividades de computação em
configurações padrões. A seguir uma descrição dos tratamentos. nível de kernel, realizou-se uma pesquisa no código fonte do kernel usado nos experimentos, a
No primeiro tratamento (T1), o loadavg foi monitorado com o sistema em repouso (sem fim de localizar chamadas de criação de work queues, tasklets, softirqs, e timers. Verificou-se
carga de trabalho). Os próximos 9 tratamentos adotaram cargas constantes, onde T2 até T5 que 96,49% de todas as chamadas concentramse em três subsistemas: device drivers (76,9%),
 130 network (16,23%), filesystem (3,37%). Nesses três subsistemas, fica claro que o mecanismo
mais usado são as work queues (46,31%), seguido de timers(37,66%) e tasklets(16,03%), como
XI Worshop sobre Software Livre
apresentado na Figura3.
Figura 1. Carga incremental em nível de usuário (user level)
Figura 2. Carga incremental em nível de kernel (kernel level)
Figura 3. Distribuição dos mecanismos de execução em nível de kernel
No total de 1571 chamadas, apenas 4 são relativas a softirqs, e nenhuma localizada nos
três subsistemas citados anteriormente. Esse resultado confirma a tendência em se usar work
queues para agendamento de tarefas bottom halves. Apesar disso, salienta-se que tasklets são
construídas sobre a infra-estrutura de softirqs.
5. Conclusão 131
Avaliação Experimental do Índice de Carga Usado no Kernel Linux
A utilização de índices de carga em áreas como balanceamento e escalonamento de
tarefas é de grande importância no contexto de sistemas computacionais distribuídos. Estudos
preliminares comprovam que índices baseados não apenas no uso da CPU, mas principalmente
no tamanho de filas de recursos (ex. CPU e I/O), possuem melhor desempenho para a caracte-
rização de carga em sistemas computacionais. Nesse trabalho, verificou-se experimentalmente
que o modelo implementado pelo índice de carga loadavg, extensivamente usado em sistemas
operacionais da família Unix e Linux, não é capaz de capturar, de forma adequada, cenários de
carga em nível de kernel. Já para cenários de cargas predominantemente em nível do usuário,
esse índice mostrou-se satisfatório. Verificou-se também que, atualmente, tem-se uma maior
utilização de work queues como mecanismo de agendamento de tarefas em nível de kernel no
Linux. Essas evidências motivam aprofundar a investigação de modelos de índices com capa-
cidade de caracterização acurada para cargas em ambos cenários, com ênfase para o nível de
kernel, já que não foram encontrados estudos específicos para esse problema.
Desse modo, encontra-se em andamento um trabalho que estende o presente estudo,
visando implementar um índice de carga específico para o nível de kernel, o qual tem sido cha-
mado de kloadavg. Esse novo índice pode ser usado em conjunto com o loadavg padrão. Alter-
nativamente, pode-se incorporar o cálculo do kloadavg no próprio modelo do loadavg. Ambas
alternativas estão sendo implementadas para avaliação.
Referências
Bovet, D. P., Cesati, M. (2005) Understanding the Linux Kernel, 3rd ed., O’Reilly Media.
Broberg , J., Tari, Z., Zeephongsekul, P. (2006) “Task assignment with work-conserving migra-
tion”, Parallel Computing archive, vol. 32, ed. 11-12, pp. 808-830.
Chen, X., Quan, Q., Jia, Y., Cai, K. (2006) “A Threshold Autoregressive Model for Software Aging”,
IEEE Int’l Symp. on Service-Oriented System Engineering, China.
Ferrari, D., Zhou, S. (1986) “A load index for dynamic load balancing”, Proc. of 1986 ACM Fall
joint computer conference, Dallas/TX, USA.
Ferrari, D., Zhou, S. (1987) “An empirical investigation of load indices for load balancing ap-
plications”, In Proc. of Int’l Symp. on Computer Performance Modeling, Measurement and
Evaluation, The Netherlands.
Gunther, N. J. (2004) “Linux Load Average Revealed”, CMG 2004, Las Vegas, USA.
Love, R. (2003) Linux Kernel Development, 2nd ed., Sams.
Montgomery, D.C. (2005) Design and Analysis of Experiments, 6 ed., J. Wiley & Sons.
Payli, R. U., Yilmaz, E., Ecer, A., Akay, H. U., Chien, S. (2004) “DLB-A Dynamic Load Balancing
Tool for Grid Computing”, Proc. of Parallel CFD Conf., Can. Island.
Raj, A., “CPU hotplug Support in Linux Kernel”. Disponível em: www.kernel.org/doc/Documenta-
tion/cpu-hotplug.txt. Acessado em 24/10/2010.
Saltzer, J. H., Gintell, J. W. (1970) “The Instrumentation of Multics”, Communications of the ACM,
vol. 13, nr. 8, USA.
Sit, H. Y. et al. (2004) “An Adaptive Clustering Approach to Dynamic Load Balancing”, Int’l Symp.
on Parallel Architectures, Algorithms and Networks, China.
Wilcox, M. (2003) “I’ll Do It Later: Softirqs, Tasklets, Bottom Halves, Task Queues, Work Queues
and Timers”, Proc. of Linux Conference Australia, Perth.
Zhou, S. (1988) “A Trace-Driven Simulation Study of Dynamic Load Balancing”, IEEE Transac-
tions on Software Engineering, pp. 1327-1341.
 132
XI Worshop sobre Software Livre
MDM: Um Software Livre para Configuração
de Ambientes Multiterminais
Aramis Stach Haiduski Fernandes, Francisco Panis Kaseker, Lucas Nascimento
Ferreira, Paulo Ricardo Zanoni, Pedro Eugenio Rocha, Eduardo Todt*
*Departamento de Informática – Universidade Federal do Paraná
Caixa Postal 19.081 – CEP 81.531-980 – Curitiba – PR – Brasil
fashf03, fpk07, lnf07, paulo, pedro, todtg@c3sl.ufpr.br
Abstract. One of the main problems in automatic hardware configuration for multiseat
environments is the process of hardware detection and association. This process must be as
automatic as possible, aiming to minimize the installation and maintenance costs. The devices
present on a machine must be detected and associated to workstations, in a way that each one
has at least a mouse, keyboard and monitor. This paper describes these problems and their
main solutions, and also presents the Multiseat Display Manager (MDM), an open source tool
that performs multiseat automatic configuration.
Resumo. Um dos principais problemas na configuração automática de ambientes mul-
titerminais é o processo de detecção e associação de hardware. Este processo deve ser o mais
automático possível, visando minimizar os custos de instalação e manutenção. Os dispositivos
presentes em uma máquina devem ser detectados e associados a pontos de trabalho de forma
que cada um possua ao menos um mouse, teclado e monitor. Este artigo descreve tais proble-
mas e suas principais soluções, além de apresentar o Multiseat Display Manager (MDM), uma
ferramenta de código aberto que realiza a configuração automática de multiterminais.
1. Introdução
Um multiterminal ou multiseat é um computador que possui múltiplos dispositivos de
entrada e saída, como monitores, mouses e teclados, agrupados em pontos de trabalho1 inde-
pendentes. Esse modelo possibilita o acesso ao computador para vários usuários simultanea-
mente [Oliveira et al. 2006]. Entre as vantagens no uso de multiterminais estão a maximização
do uso de recursos computacionais, redução de custos e de consumo elétrico devido à economia
de hardware, facilidade de manutenção e economia de pontos de rede. Essas vantagens são
medidas em relação ao número de usuários por computador. Por exemplo, em um laboratório
de informática que utiliza multiterminais, é possível atender a um mesmo número de usuários
de um laboratório composto por monoterminais, porém utilizando menos computadores.
Atualmente existem diversas maneiras de criar ambientes multiterminais, todas elas de-
vem levar em consideração que os computadores pessoais possuem uma estrutura desenhada
para atender apenas um usuário. Como exemplo, em ambientes Linux, toda a entrada referente
1
Comumente chamado de estação de trabalho, cabeça, terminal, head ou seat.
a mouses e teclados é diretamente repassada ao servidor de janelas Xorg, que as transmite 133
às aplicações. Disso decorrem dois problemas fundamentais para uma solução multiterminal:
MDM: Um Software Livre para Configuração de Ambientes Multiterminais
detecção e associação dos dispositivos de entrada e saída. O problema de detecção consiste
em identificar e ler cada dispositivo separadamente, para que suas entradas sejam repassadas
somente às aplicações que devem recebê-las. A associação de dispositivos é o problema de
agrupar os conjuntos de dispositivos em pontos de trabalho independentes.
Esse artigo apresenta o Multiseat Display Manager (MDM) [C3SL 2009], um software
livre baseado em Linux e no X Window System. O MDM configura automaticamente um con-
junto básico de dispositivos: mouses, teclados e placas de vídeo. Ele também dá suporte à im-
plementação de diversas soluções multiterminais, como as baseadas em servidores de janelas
aninhados (Xnest, Xephyr), múltiplas instâncias do Xorg dentre outras [Oliveira et al. 2006]. O
MDM utiliza o conceito de módulos de execução para sua integração com as diversas soluções
multiterminais. Os módulos definem funções de gerenciamento dessas soluções. Por exemplo,
iniciar o servidor de janelas Xorg e as diversas instâncias de Xephyr.
O restante deste artigo está organizado da seguinte maneira: a seção 2 apresenta os
problemas relacionados à detecção de dispositivos. A seção 3 apresenta os problemas relacio-
nados com a associação de um conjunto de dispositivos em ambientes multiterminais. A seção
4 explica como o MDM soluciona os problemas apresentados e mostra como é a estrutura e a
implementação de um módulo. Por fim, a seção 5 apresenta as considerações finais e os tra-
balhos futuros.
2. Detecção de dispositivos
Um dos desafios na configuração de ambientes multiterminais é detectar e separar
corretamente os dispositivos de entrada e saída para que seja possível associá-los a estações
de trabalho. Em ambientes monoterminais não há a necessidade de realizar uma detecção tão
precisa, pois todos os dispositivos são diretamente atribuídos ao único usuário do sistema.
A detecção consiste em decidir quais dispositivos serão utilizados a partir de um con-
junto de hardware já detectado pelo sistema operacional, obtendo as informações necessárias
para, posteriormente, realizar a associação dos dispositivos.
Em ambientes Linux monoterminais, todas as entradas referentes aos mouses e tecla-
dos são diretamente repassados ao servidor de janelas Xorg, que as transmite às aplicações. Já
em multiterminais cada dispositivo deve ser identificado e lido separadamente, pois é necessá-
rio descobrir se há um conjunto de dispositivos básicos para formar uma estação de trabalho.
Na configuração de multiterminais devem ser identificados ao menos os dispositivos
básicos de uma estação de trabalho. O restante dessa seção explica como é feita a detecção
em cada caso. O sistema também pode prover suporte a outros tipos de dispositivos, como
pendrives, placas e caixas de som, dispositivos de armazenamento externos etc.
2.1. Dispositivos de vídeo:
Os dispositivos de vídeo são reconhecidos da mesma forma pelo Kernel Linux, indepen-
dentemente do barramento utilizado (PCI, PCI Express ou AGP). Nestes ambientes, é possível
obter a lista dos dispositivos de vídeo através do sysfs, que é um sistema de arquivos virtual
que exporta informações sobre drivers e dispositivos de dentro do kernel para o espaço do
usuário [Patrick 2005]. Como o Kernel Linux exporta informações sobre dispositivos da mesma
forma, a detecção de dispositivos de vídeo pode abstrair o barramento utilizado pela placa.
 134 Um problema exclusivo de dispositivos de vídeo é a associação entre hardware e driver.
A maioria dos drivers de vídeo utilizados hoje em sistemas Linux faz parte do Xorg, e não do
XI Worshop sobre Software Livre
kernel. Por este motivo, o Xorg é responsável por fazer esta associação. Todo driver possui uma
lista de dispositivos que suporta, utilizada pelo Xorg para descobrir a qual driver associar deter-
minado dispositivo de vídeo. O driver fornece também informações sobre o número de saídas
de vídeo que cada placa possui.
2.2. Dispositivos de Entrada:
Nem sempre é possível identificar com precisão a função de um dispositivo de entrada,
pois as informações fornecidas pelo hardware podem não ser suficientes para identificá-la. Os
dispositivos podem não reportar o que realmente são informando apenas como deve ser rea-
lizada a interação entre o hardware e o sistema [Zeuthen 2009]. Alguns teclados multimídia,
por exemplo, possuem diversas funcionalidades e podem mostrar-se ao sistema operacional
como sendo um conjunto de dispositivos de diversas funcionalidades. Em ambientes Linux, este
problema é tratado associando as informações fornecidas pelo hardware a listas predefinidas
de informações de dispositivos. Uma das principais ferramentas utilizadas para detecção é o
Hardware Abstraction Layer (HAL) [Zeuthen 2009]. O HAL é um software que obtém informa-
ções do kernel e provê a descrição de todo o hardware presente no sistema a aplicações em
modo usuário.
3. Associação de dispositivos
Realizar a associação de hardware em ambientes multiterminal é agrupar os dispositi-
vos existentes fazendo-os trabalhar em conjunto, formando pontos de trabalho. A partir do mo-
mento em que estão associados, esses dispositivos são destinados a atender um único usuário,
independentemente dos outros dispositivos e pontos de trabalho presentes na máquina.
Um problema especial na associação de hardware são os dispositivos hotplug, que são
os que podem ser conectados ao sistema sem necessitar reiniciá-lo, como pendrives, telefones
celulares, MP3 players, mouses e teclados USB. Para reconhecer esses dispositivos são neces-
sários mecanismos de associação que possibilitem que ela seja feita não somente de maneira
estática, antes de configurar os pontos de trabalho, mas à medida que os dispositivos são
inseridos e retirados da máquina.
Existem duas maneiras principais de realizar a associação de dispositivos: agrupar con-
juntos de dispositivos em hubs USB, formando uma hierarquia USB e por request/reply.
3.1. Associação por Hierarquia USB
Uma solução adotada para realizar a associação de dispositivos é dividi-los por hubs
USB. Cada hub USB é associado a uma placa de vídeo (monitor), formando um ponto de traba-
lho. Todos os dispositivos conectados em um determinado hub serão associados ao ponto de
trabalho correspondente.
Esta abordagem simplifica a utilização de quaisquer dispositivos USB, como pendrives,
placas de som USB e dispositivos hotplug em geral, permitindo que sejam associados direta-
mente ao ponto de trabalho que utiliza o hub USB ao qual o dispositivo foi ligado. Apesar disso,
são necessários tantos hubs USB quantos pontos de trabalho, e a associação de outros tipos de
dispositivos, como PS/2 ou PCI, não é tratada.
3.2. Associação por request/reply 135
Outra solução é a associação por request/reply. Neste tipo de associação, é exibido
MDM: Um Software Livre para Configuração de Ambientes Multiterminais
um request em cada monitor, por exemplo, o pedido de acionamento de determinada tecla ou
botão do mouse. Cada monitor exibe um request diferente, de forma que ao receber o reply,
enviado manualmente pelo usuário, o sistema possa reconhecer qual foi o monitor que o requi-
sitou e associá-lo ao dispositivo.
Um dos problemas da associação por request/reply é que após configurado um ponto de
trabalho, não é possível trocar, remover ou adicionar dispositivos já associados, a menos que o
sistema forneça uma forma de retornar à interface de configuração. Esta abordagem não per-
mite também a associação de determinados tipos de dispositivos, como placas de som, devido
à dificuldade em implementar resposta do usuário para associação.
4. O Multiseat Display Manager
Multiseat Display Manager (MDM) [C3SL 2009] é um software que configura automatica-
mente computadores multiterminais. Ele foi elaborado para suportar diversos tipos de soluções
multiterminais para Linux. Para tal suporte, oMDMutiliza módulos de execução que fazem a
integração entre ele e o tipo de solução multiterminal utilizada.
A detecção de dispositivos de vídeo é feita através das informações device id e vendor
id fornecidas pelos dispositivos. Esses identificadores são localizados em listas preexistentes,
fornecidas pelo pacote de software discover [Stefan 2010], que informam quais drivers de vídeo
suportam quais dispositivos. O problema desse método é que ele exige que as listas estejam
corretas, e por isso será futuramente substituído por outro método que delegue toda a respon-
sabilidade de detecção de drivers para o servidor de janelas Xorg.
O MDM detecta os dispositivos de entrada através do HAL; entretanto essa detecção
não é completamente precisa. Um dispositivo físico com múltiplas funcionalidades, como por
exemplo, um teclado multimídia, pode ser mostrado pelo HAL como sendo mais de um disposi-
tivo de entrada. Esse tipo de dispositivo faz o MDM interpretar que há mais dispositivos que os
realmente existentes no computador. Porém, detectar mais dispositivos de entrada não é um
problema, pois o MDM considera que o número de pontos de trabalho é igual à quantidade de
dispositivos de vídeo detectados, e não de mouses ou teclados.
A associação de dispositivos é feita pelo método request/reply. Esse método é vantajoso,
pois ele independente de hardware adicional aos básicos de uma estação de trabalho. É importante
também ressaltar que o MDM detecta e configura apenas mouses, teclados e placas de vídeo. Ou-
tros dispositivos como pendrives, placas de som e leitores de CD não são afetados pelo MDM.
Uma solução multiterminal deve, além de detectar e associar os dispositivos, prover
uma forma de interação com os diversos usuários de maneira independente. O método utili-
zado consiste em abrir diversas telas de login, de um Display Manager, para cada usuário. Um
Display Manager é um gerenciador gráfico de login e os mais populares são: Gnome Display
Manager (GDM), KDE Display Manager (KDM) e o X Display Manager (XDM) [Jeff 2010]. O MDM
não implementa um Display Manager, ele apenas utiliza os já existentes para abrir as diversas
interfaces de login para os diferentes usuários. Devido à grande variedade de Display Mana-
gers, o MDM provê uma forma de integração (módulos) entre ele e os gerenciadores de login.
4.1. Módulos
As funções essenciais do MDM são detectar e associar os diversos dispositivos conec-
 136 tados ao sistema para prover um ambiente multiterminal. O MDM não implementa um Display é um software de detecção automática de dispositivos que provê um mecanismo dinâmico de 137

Manager para que os usuários façam login no sistema. Ele também não restringe de que forma nomeação dos mesmos. Dentre os trabalhos futuros está a substituição do HAL pelo udev como
XI Worshop sobre Software Livre

MDM: Um Software Livre para Configuração de Ambientes Multiterminais

será integrado o Display Manager ao ambiente gráfico do sistema. Por exemplo, o GDM pode novo método de detecção de hardware. Essa alteração será feita para colocar o MDM nos novos
ser executado em diversos Xephyrs sobre um mesmo servidor de janelas Xorg, ou sobre di- padrões do Xorg.
versas instâncias do Xorg diretamente. Cada solução multiterminal utiliza métodos diferentes O MDM utiliza soluções exclusivamente através de software para o processo de de-
para prover uma interface de login no sistema. Para facilitar a integração com essas soluções, tecção e associação dos dispositivos. Esse tipo de solução multiterminal provê otimização de
o MDM utiliza o conceito de módulos. Módulos são um conjunto de funções que disponibilizam recursos de hardware e grande economia de energia. Portanto essa ferramenta pode ser muito
ao usuário uma forma de fazer login através de um Display Manager. O módulo é quem define interessante para o processo de inclusão digital.
a forma como o Display Manager será integrado com o ambiente gráfico. Essa arquitetura do
MDM facilita a inserção de novos módulos, pois basta escrever funções que implementam uma
solução para o Display Manager desejado. Referências
Para implementar um módulo é necessário criar no mínimo quatro funções:
C3SL (2009). Multiseat Display Manager. http://wiki.c3sl.ufpr.br/multiseat/index.php/Mdm. Aces-
1. Display manager init: essa função deve executar todas as tarefas anteriores ao sado em 14 de abril de 2009.
início do Display Manager. Por exemplo, verificar se o Display Manager utilizado já Jeff, C. (2010). GNOME Display Manager. http://live.gnome.org/GDM. Acessado em 03 de junho
está em execução. de 2010.
2. Display manager start monoseat: inicia o Display Manager normalmente em Keith, P. (2010a). X Display Manager Control Protocol. http://www.xfree86. org/current/xdmcp.
caso do sistema possuir apenas uma placa de vídeo. pdf. Acessado em 03 de junho de 2010.
3. Display manager start seat: inicia os diversos servidores X com as telas de login Keith, P. (2010b). Xorg 1.8.0 Release. http://lists.freedesktop.org/archives/xorg/2010-
do Display Manager. Caso o módulo utilize servidores X aninhados, essa função April/049784.html. Acessado em 03 de junho de 2010.
deve iniciá-los e iniciar as telas de login neles. Oliveira, A. C., Vignatti, T., Weigaertner, D., Silva, F., Castilho, M., and Sunye, M. (2006). Um
4. Display manager stop: termina a execução do Display Manager e, consequente- modelo de computação multiusuário baseado em computadores pessoais. VII Workshop de
mente, de todas as estações de trabalho. Software Livre, pages 135–140.
Patrick, M. (2005). The sysfs Filesystem. Proceedings of the Linux Symposium.
Uma função adicional, chamada display manager start undeneath xserver, deve ser Stefan, K. (2010). Hardware Identification System. http://wiki.debian.org/discover. Acessado em
criada no caso do módulo utilizar servidores X aninhados. Essa função deve ser responsável por 03 de junho de 2010.
abrir o servidor X que os servidores aninhados vão utilizar como base para execução. Zeuthen, D. (2009). HAL 0.5.10 Specification. http://people.freedesktop. org/˜david/hal-spec/
Atualmente, existem dois módulos implementados: xephyr-xdmcp e xephyr-gdm. O pri- hal-spec.html. Acessado em 14 de abril de 2009.
meiro utiliza diversas instâncias do Xephyr para fazer conexões com um Display Manager remo-
to através do protocolo XDMCP. O XDMCP é um protocolo que provê um mecanismo uniforme
para um display autônomo requisitar serviço de login a um hospedeiro remoto [Keith 2010a].
O módulo xehyr-gdm também utiliza instâncias do Xephyr, porém são abertas telas de login do
GDM sobre cada Xephyr.

5. Conclusão e trabalhos futuros

Este trabalho analisa os problemas relacionados à detecção e associação automática

de hardware em ambientes multiterminais, bem como descreve suas principais soluções. Além
disso, foi apresentado o MDM, um software livre responsável por configurar automaticamente
computadores multiterminais, implementando algumas das soluções apresentadas.
Devido a sua arquitetura modular, é possível desenvolver outros módulos para o MDM.
Por exemplo, um módulo para uma solução multiterminal baseada em KDM e LTSP2, para efetu-
ar login em uma área de trabalho remota.
O servidor de janelas Xorg, em sua versão 1.8.0, passou a utilizar o udev como o meca-
nismo padrão para configuração automática de dispositivos de entrada [Keith 2010b]. O udev

2 Linux Terminal Server Project