2004 - Wiki-SL - Software Livre Brasil

Transcrição

5o Workshop sobre Software Livre - WSL 2004
5o Fórum Internacional Software Livre - FISL 2004
Porto Alegre, RS - Brasil
2, 3, 4 e 5 de junho de 2004
Anais
Editores
Alexandre Moretto Ribeiro
Celso Maciel da Costa
Edgar Meneguetti
Lisandro Zambenedetti Granville
Organização
ASL-PSL/RS
PUC-RS
UCS
UFRGS
UNISINOS
Apoio
Sociedade Brasileira de Computação - SBC
Capa
Bankorp - Estratégia e Tecnologia.
Impressão
Editora Evangraf Ltda.
Tiragem
5.000 exemplares
5o Workshop sobre Software Livre - WSL 2004
5o Fórum Internacional Software Livre - FISL 2004
(5. : 2004 junho: Porto Alegre, RS)
Anais / 5o Workshop sobre Software Livre - WSL 2004 / 5o Fórum
Internacional Software Livre - FISL 2004; editores Alexandre Moretto
Ribeiro, Celso Maciel da Costa, Edgar Meneguetti e Lisandro
Zambenedetti Granville. - Porto Alegre. Apoio: Sociedade Brasileira de
Computação, 2004.
310p.; 23cm
1. Software 2. Software Livre 3. Programa I. Título II. Ribeiro, Alexandre
Moretto. III. Costa, Celso Maciel da. IV. Meneguetti, Edgar. V. Granville,
Lisandro Zambenedetti.
Endereço:
Editora Evangraf Ltda
Rua Waldomiro Schapke, 77 - Porto Alegre, RS - Brasil
Telefone (51) 3336-2466
5° WSL / 5° FISL
3
Prefácio 5º WSL
O Workshop sobre Software Livre (WSL) é um evento que ocorre junto ao
Fórum Internacional de Software Livre (FISL) e tem como principal objetivo criar
um espaço para apresentação de trabalhos de pesquisa e desenvolvimento envolvendo
software livre. Neste contexto, o WSL desempenha um papel fundamental pois
permite o encontro de professores, pesquisadores, estudantes e a comunidade de
software livre, possibilitando a troca de experiências entre aqueles que contribuem
para o efetivo desenvolvimento e amadurecimento desta área.
Em sua 5ª edição o número de artigos submetidos ao WSL superou em mais
de 50% o evento anterior, o que atesta a importância e o crescimento do evento.
Foram recebidos para avaliação 93 artigos, dos quais 43 foram selecionados para
apresentação. Os processos de submissão, avaliação e seleção foram realizados de
forma eletrônica, com o uso de um sistema de gerência de eventos totalmente
desenvolvido com software livre. Cada artigo submetido foi avaliado por pelo menos
dois membros do comitê de programa, composto por professores e pesquisadores de
diversas universidades.
O espectro dos artigos selecionados cobre desde o uso de software livre na
educação, passando por experiências acadêmicas com o uso de software livre,
chegando até a pesquisa em software livre propriamente dita.
Gostaríamos de agradecer aos membros do comitê de programa e do comitê de
organização do WSL pela dedicação e pelas muitas horas de trabalho voluntário, e aos
membros do comitê de organização do FISL, sempre prontos a atender as nossas
necessidades. Estas pessoas são as responsáveis pelo sucesso do evento.
Estes anais contêm os 43 artigos selecionados e que serão apresentados nas
sessões técnicas do WSL 2004. Acreditamos que estes trabalhos representam um
panorama fiel do desenvolvimento da área, e contribui de forma significativa para a
disseminação do conhecimento de software livre na sociedade.
Porto Alegre, junho de 2004
Celso Maciel da Costa, PUC-RS
Coordenador do Comitê de Organização
Alexandre Moretto Ribeiro, UCS
Coordenador do Comitê de Programa
4
5° WSL / 5° FISL
5° WSL / 5° FISL
Prefácio 5º FISL
O Projeto
O Projeto Software Livre, no âmbito nacional, é uma iniciativa não
governamental, que reúne instituições públicas e privadas do Brasil: poder público,
universidades, empresas, grupos de usuários, hackers e outras organizações do
Terceiro Setor.
Nosso principal objetivo, é a promoção do uso e do desenvolvimento de
software livre como uma alternativa econômica e tecnológica. Estimulando o uso de
software livre, o projeto investe na produção e qualificação do conhecimento local, a
partir de um novo paradigma de desenvolvimento sustentado e de uma nova postura,
que insere a questão tecnológica no contexto da construção de mundo com inclusão
social e igualdade de acesso aos avanços tecnológicos.
Estamos articulados em vários estados do país, através dos PSL's Estaduais,
que são partes integrantes do PSL-Brasil. Temos também, uma articulação horizontal
nacional de gênero chamada de PSL-Mulheres, PSL-Jurídico, PSL-Militares e
Policiais.
O Projeto Software Livre RS, em conjunto com PSL-BR, é promotor do
Fórum Internacional de Software Livre, desde o ano 2000, que acontece
anualmente em Porto Alegre. No ano passado realizamos o 4º FISL com a presença de
mais de 4.000 pessoas.
Uma história de sucesso
O Fórum Internacional Software Livre é um evento internacional, organizado
pelo Projeto Software Livre RS, membro do Projeto Software Livre Brasil, que
propicia discutir os aspectos técnicos, éticos, sociais, econômicos, filosóficos,
políticos e educacionais através da reunião da comunidade de informática e uma
aproximação da mesma com a sociedade, visando discutir e apresentar aos mais
diversos segmentos do mercado alternativas de soluções tecnologicamente modernas e
seguras.
O Fórum Internacional Software Livre, em sua 5ª edição, será um sucesso.
Realizado desde o ano 2000 em Porto Alegre, caracteriza-se pelo aumento
progressivo do número de participantes atingindo a marca de 4.265 participantes em
2003, 42,5% a mais que em 2002. Além disso, a página do evento na Internet foi
visitada mais de trinta mil vezes, o que demonstra a sua aceitação e popularidade,
capazes de impulsionar negócios e definir tendências. Devido a sua grande capacidade
de adequação, empresas de todos os portes, governos e universidades estão se
beneficiando das vantagens de seu uso, desenvolvimento e comercialização,
conhecidos os conceitos do Software Livre.
5
6
5° WSL / 5° FISL
No 5º Fórum Internacional Software Livre - 5º FISL - serão apresentadas
palestras técnicas, painéis e casos nas áreas corporativa, governos, pesquisas
acadêmicas e os últimos avanços da comunidade internacional de Software Livre,
bem como, uma análise das tendências.
Para o 5º Fórum Internacional Software Livre, a estimativa de público é
superior a 4.000 pessoas, que compõem o seguinte perfil: diretores e executivos do
ramo da informática, gerentes de tecnologia, desenvolvedores de sistemas, analistas,
professores, pesquisadores, estudantes de Tecnologia da Informação, gestores
públicos, empresários e empreendedores.
Porto Alegre, junho de 2004
Coordenação ASL-PSL/RS
5° WSL / 5° FISL
Comitê de Organização
Alex Fábio Pellin, UCS
Alexandre Moretto Ribeiro, UCS
Celso Maciel da Costa, PUC-RS - coordenador
Denise Bandeira da Silva, UNISINOS
Edgar Meneghetti, UCS
Filipi Vianna, PUC-RS
Heitor Strogulski, UCS
Comitê de Programa
Alex Fábio Pellin, UCS
Alexandre Moretto Ribeiro, UCS - coordenador
Andrea Schwertner Charão, UFSM
Antônio Marinho Pilla Barcelos, UNISINOS
Benhur Stein, UFSM
Celso Maciel da Costa, PUC-RS
César De Rose, PUC-RS
Cirano Iochpe, UFRGS
Cláudio Fernando Resin Geyer, UFRGS
Cristina Moreira Nunes, La Salle
Daniel Nehme Muller, ULBRA
Daniel Notari, UCS
Denise Bandeira da Silva, UNISINOS
Edgar Meneghetti, UCS
Fernando Santos Osório, UNISINOS
Francisco Assis Moreira do Nascimento, ULBRA
Gerson Geraldo Homrich Cavalheiro, UNISINOS
Heitor Strogulski, UCS
João Cesar Netto, UFRGS
João Ricardo Bittencourt, UNIFRA/RS
Julio Bertolin, UPF
Leonardo Rodriguez Heredia, UFRGS
Lisandro Zambenedetti Granville, UFRGS
Luciana Porcher Nedel, UFRGS
Luciano Paschoal Gaspary, UNISINOS
Luciano Porto Barreto, UFBA
Marcelo Pasin, UFSM
Roland Teodorowitsch, ULBRA
Simone André da Costa, UNISINOS
7
8
5° WSL / 5° FISL
Sociedade Brasileira de Computação
Diretoria
Presidente:
Vice-Presidente:
Administrativa e Finanças:
Eventos e Comissões Especiais:
Educação:
Publicações:
Planejamento e Programas Especiais:
Secretarias Regionais:
Divulgação e Marketing:
Regulamentação da Profissão:
Eventos Especiais:
Cláudia Maria B. Medeiros, UNICAMP
José Carlos Maldonado, ICMC - USP
Carla Maria Dal Sasso Freitas, UFRGS
Karin Breitmann, PUC-Rio
Marcos José Santana, USP - São Carlos
Ana Carolina Salgado, UFPE
Robert Carlisle Burnett, PUC-PR
Edson Norberto Cáceres
Sérgio Cavalcante, UFPE
Roberto da Silva Bigonha, UFMG
Ricardo de Oliveira Anido, UNICAMP
Conselho
Mandato 2001-2005
Paulo Cesar Masiero, USP/São Carlos
Rosa Maria Vicari, UFRGS
Sergio de Mello Schneider, UFU
Tomasz Kowaltowski, UNICAMP
Ricardo Augusto da Luz Reis, UFRGS
Mandato 2003 - 2007
Flávio Rech Wagner, UFRGS
Luiz Fernando Gomes Soares, PUC-Rio
Siang Wun Song, USP
Ariadne Carvalho, UNICAMP
Taisy Silva Weber, UFRGS
Suplentes - Mandato 2003-2005
Daniel Schwabe, PUC-Rio
Marcelo Walter, UNISINOS
André Carvalho, ICMC - USP
Raul Sidnei Wazlawicki, UFSC
Secretaria Regional Rio Grande do Sul
Secretário: Álvaro F. Moreira , UFRGS
5° WSL / 5° FISL
Associação Software Livre.Org
A Associação Software Livre.Org foi fundada no dia 11/09/2003, na Av.
Ipiranga, 1200 - Porto Alegre, RS, em reunião/assembléia, com representantes de
empresário, profissionais liberais, estudantes, servidores públicos e outros presentes,
com a finalidade de fundar uma Associação para representá-los, bem como, tratar de
seus interesses junto aos órgãos públicos e privados, conforme Ata da Assembléia
Geral de nº 001, arquivada e registrada no dia 30/09/2003, no Serviço de Registro de
Títulos e Documentos e Registro Civil das Pessoas Jurídicas de Porto Alegre.
Conselho Geral
Coordenador Geral:
Marcelo D’Elia Branco
Coordenador Adjunto: Ronaldo Cardozo Lages
Coordenador Financeiro: Lourdes Tassinari
Suplentes
1º Suplente: Denise Bandeira da Silva
2º Suplente: Deivi Lopes Kuhn
3º Suplente: José Eduardo Bueno de Oliveira
Conselho Fiscal
Titulares
1º Conselheiro: Raquel Soares Wiesel
2º Conselheiro: Deobrandino Ninrod Borges
3º Conselheiro: Ricardo de Moura Rivaldo
Suplentes
1º Suplente: Hilton Dias
2º Suplente: Luciana Porcher Nedel
3º Suplente: Eugenio Carlos Gallicchio Hansen
Associação Software Livre.Org
Endereço: Rua Cunha Neto, 293 - Nonoai
90.840-270 - Porto Alegre, RS
Caixa Postal nº 443
90001-970 - Porto Alegre, RS
Escritório Contábil
L & C Auditoria e Assessoria Contábil Ltda.
Porto Alegre, RS
Fones: 55(51) 3225.8766 / 3286.6504 / 9946.9566
Contato: Jane Eunice Fragozo dos Santos ([email protected])
9
10
5° WSL / 5° FISL
5° WSL / 5° FISL
Sumário
Sessão Técnica 1: SÓCIO POLÍTICO ECONÔMICO...................................................... .15
Software livre numa perspectiva sociotécnica: um estudo preliminar das
controvérsias para a resolução de disputas políticas
Adalto Guesser, Tamara Benakouche (UFSC),
Ricardo Moraes (Universidade do Porto).................................................................. .17
Software Livre na Universidade: Aprendizado, Economia,
Segurança e Desempenho
Adilson Bonifácio (Universidade Estadual de Londrina) .......................................... .21
Rybená: a Free Source Project for Digital Inclusion of Persons with Special
Needs, Through Mobile Communication
Daniel de Oliveira (Instituto Centro de Pesquisa e Desenvolvimento em
Tecnologia de Software), José Carlos Waeny (Brasilia Java Users Group),
Elcio Queiroz (IBM do Brasil), Edilson Ferneda (Universidade Católica de
Brasília), Evandro Costa (UFAL), Hyggo Almeida (UFCG),
Thiago Figueiredo (Universidade Católica de Brasília)............................................. 25
Sessão Técnica 2: WEB............................................................................................... .29
Tecnologias de SW livre para análise de mensagens em chats e recomendações
online de documentos eletrônicos
Rodrigo Kickhofel, Stanley Loh, Daniel Lichtnow,
Ramiro Saldaña, Thyago Borges, Tiago Primo, Gabriel Simões,
Gustavo Piltcher (Universidade Católica de Pelotas)................................................. 31
Implementando Web Services com Software Livre
Claudimir Zavalik, Guilherme Lacerda,
José Palazzo Moreira de Oliveira (UFRGS).............................................................. 35
VRaptor - Simple And Quick Web Framework
Alexandre Freire da Silva, Paulo Silveira (USP)....................................................... 39
Sessão Técnica 3: SOFTWARE EDUCACIONAL .......................................................... .43
Vale4 - Software Livre para Ensino
Simão Toscani (PUCRS e UNILASALLE)................................................................ 45
AdaptWeb:Ambiente de Ensino-Aprendizagem Adaptativo na Web
Daniela Musa, Mariusa Warpechowski,
José Palazzo Moreira de Oliveira (UFRGS).............................................................. 49
AVALWEB Sistema interativo para gerência de questões
Carlos Morais, José Valdeni de Lima, Sérgio Franco (UFRGS)............................... 53
Sessão Técnica 4: SEGURANÇA ................................................................................. .57
Detectando Intrusões na Máquina Virtual User-Mode Linux
Marcos Aurelio Laureano, Carlos Maziero, Edgard Jamhour (PUCPR) .................. 59
TuxGuardian: Um firewall de host livre voltado para o usuário final
Bruno Silva (UFRGS) ................................................................................................. 63
11
12
5° WSL / 5° FISL
Uma Solução de IPS Baseada na Integração SNORT e IPTABLES
Rivalino Jr. (Universidade do Vale do Itajaí - São José),
Jaime Miranda Jr. (Grupo Stela)................................................................................ 67
Sessão Técnica 5: REDES........................................................................................... .71
Desenvolvimento de um Sistema Livre para Simulação de Tráfego Baseada em
Modelos Microscópicos
Bruno Silva, Ana Bazzan, Denise de Oliveira,
Paulo Roberto Ferreira Jr., Filipe Lopes, Gustavo Andriotti,
Thiago M. Papageorgiou (UFRGS) ........................................................................... 73
Um framework baseado em Software Livre para diminuir a probabilidade de
falhas e para balanceamento de carga nas conexões à Internet
Marcelo Kwecko, Rafael Moita, Jorge Guedes, Ricardo Balbinot (PUCRS) ............ 77
Terminais Inteligentes: alternativa estratégica para otimização de recursos
computacionais
Reinaldo Moreira (FIC), Hebert Costa (Doctum Tecnologia),
Jailton Caldeira Jr. (FIC), Gicele de Souza, Ulisses Leitão (Doctum Tecnologia)... 81
Sessão Técnica 6: GERENCIAMENTO DE REDES & B2B............................................. .85
Um Sistema Simples de Gerenciamento Integrado de Diretórios
Online - OpenLDAP, NIS, Samba
Diego Kreutz (UFSM)................................................................................................. 87
Uma Ferramenta para a Administração de Serviços de Diretório Distribuído
Baseado no OpenLDAP
Fernando Cruz, Giovanni Santos, Raissa Medeiros, Lucas Pereira, Márcio
Braga, Roberto Diener (Universidade Católica de Brasília) ..................................... 91
Projeto e-market: Implementando comércio eletrônico de empresa para empresa
usando software livre
Francisco Assis Moreira do Nascimento (ULBRA), Diogo Santinon,
Gabriel David, Lucas Parlatto (Faculdades de Taquara)........................................... 95
Sessão Técnica 7: TOLERÂNCIA A FALHAS & EDUCAÇÃO ........................................ .99
Validação experimental de sistemas de arquivos baseados em journaling para o
sistema operacional Linux
Leonardo Mello (Ministério Público Federal) .......................................................... 101
GroupPac: Um Suporte Livre Para Tolerância a Faltas
Alysson Bessani, Eduardo Alchieri, Joni da Silva Fraga (UFSC),
Lau Lung (PUCPR), Luciana Souza, Ricardo Padilha (UFSC)............................... 105
International Master Program in Free Software: a higher education experience
David Megias, Rafael Macau, Jordi Mas (Universitat Oberta de Catalunya).......... 109
Sessão Técnica 8: DESENVOLVIMENTO I ................................................................. .113
AbsTK: uma biblioteca para desenvolvimento unificado de aplicações em modo
texto e gráfico
Hisham Muhammad, André Detsch (UNISINOS).................................................... 115
5° WSL / 5° FISL
Desenvolvendo Jogos Computadorizados Multiplataforma com Amphibian
João Bittencourt, Lúcia Giraffa (PUC-RS) .............................................................. 119
ArchGenXML - Uma ferramenta CASE para Desenvolvimento de
Aplicações de Gerenciamento de Conteúdo para o Plone
Fabiano Weimar dos Santos (UCS).......................................................................... 123
Sessão Técnica 9: DESENVOLVIMENTO II ................................................................ .127
Considerações sobre controle de grupos em repositórios CVS durante a evolução
de uma ferramenta web
Daniel Junqueira, Renata Fortes (USP)................................................................... 129
Lições Aprendidas na criação de uma Fábrica de Software Open-Source
Alexandre Alvaro, Thiago Santos, João Marcos Vasconcelos,
Paulo Andrade, Jones Albuquerque, Silvio Meira (UFPE) ...................................... 133
OConGra: Ferramenta para Geração de Grafos de Controle de Fluxo de Objetos
Paulo Nunes (USP) ................................................................................................... 137
Sessão Técnica 10: DESENVOLVIMENTO III.............................................................. .141
Plataforma Mono: Visão geral da estrutura .NET para LINUX
Queli Giaretta, Jacques Brancher (URI).................................................................. 143
Mico - University Schedule Planner
Alexandre Freire da Silva, Christian Asmussen, Fabio Kon,
Alfredo Goldman, Carlos Eduardo Ferreira (USP) ................................................. 147
TerraLib: The Architecture of an Open Source GIS
Gilberto Câmara (INPE) .......................................................................................... 151
Sessão Técnica 11: APLICAÇÕES............................................................................. .155
Software Livre na Informatização de Acervos Históricos
Elisa Nakagawa (USP) ............................................................................................. 157
WebMaterioteca Sistema de Informação de Cadastro e Recuperação de Materiais
Juliano Carvalho (FEEVALE) ................................................................................. 161
Tecnologia Adaptativa e Síntese de Voz: Primeiros Experimentos
Felipe Zuffo, Hemerson Pistori (Universidade Católica Dom Bosco) ..................... 165
Sessão Técnica 12: ELÉTRICA .................................................................................. .169
Desenvolvimento de Simulador de Ondas eletromagnéticas
usando ferramentas livres
João Santanna Filho (Instituto de Estudos Superiores da Amazônia) ..................... 171
FCA: Uma Ferramenta Livre para Análise de Circuitos Elétricos
Pablo Grigoletti, Graçaliz Pereira Dimuro, Luciano Barboza,
Renata Reiser, José Ubirajara de Nunes (UCPel).................................................... 175
Utilização do GNU/Linux e outros Softwares Livres na Instrumentação
Eletrônica e de Aquisição de Dados por computador
Daniel Gomes (UFPE) .............................................................................................. 179
13
14
5° WSL / 5° FISL
Sessão Técnica 13: BIOLÓGICAS & BD..................................................................... .183
Um Sistema Baseado em Software Livre para Anotação
Automática de Genomas e Proteínas
Ana Bazzan, Bruno Savegnago Fajardo, Leonardo Vianna do Nascimento,
Cassia Trojahn dos Santos, Vitorio Sassi (UFRGS) ................................................ 185
Ferramenta de Telemedicina em Software Livre para
Monitoração de Sinais Vitais
Heloisa Hertzog, Jorge Guedes, Rafael Rehm, Fernando Thiesen,
Francisco Souza, Luciano Azevedo (PUC-RS)......................................................... 189
MOTV: Uma Extensão ao Modelo de Dados Orientado a Objetos
com Suporte a Tempo e Versão
Eduardo Bastos, Antônio Costa (UCPel) ................................................................. 193
Sessão Técnica 14: ENGENHARIA DE SOFTWARE ................................................... .197
Utilizando o Paradigma de Software Livre para Definir Melhores Práticas em
Engenharia de Software
Eduardo Filgueiras, Mateus Mota (ULBRA) .......................................................... 199
SAFE - Software Engineering Available for Everyone
Renata Fortes, Marco Silva, Andre Freire, Daniel Junqueira (USP) ...................... 203
Levantamento sobre Processo de Software Livre
Renata Fortes, Marco Silva (USP), Christian Reis (Async Open Source) .............. 207
Integração dos Ambientes Livres WEKA e ImageJ na Construção de Interfaces
Guiadas por Sinais Visuais
Hemerson Pistori, Mauro Pereira (Universidade Católica Dom Bosco)................. 211
5o FISL - Mostra de Soluções em Software Livre (resumos)....................................... .215
5o FISL - Palestras (resumos) .................................................................................... .223
5° WSL / 5° FISL
Sessão Técnica 1
SÓCIO POLÍTICO ECONÔNICO
15
16
5° WSL / 5° FISL
5° WSL / 5° FISL
Software livre numa perspectiva sociotécnica:
um estudo preliminar das controvérsias para
a resolução de disputas políticas
Adalto Herculano Guesser1, Tamara Benakouche1, Ricardo Alexandre Reinaldo de Moraes2
1
NETEC – Núcleo de Estudos em Tecnologia, Educação e Cultura – Programa de PósGraduação em Sociologia Política – Universidade Federal de Santa Catarina (UFSC)
Caixa Postal 476 – 89.040-900 – Florianópolis – SC – Brasil
2
Programa de Doutoramento em Engenharia Eletrotécnica e de Computadores –
Universidade do Porto (UP)
Rua Dr. Roberto Frias – 4200-465 – Porto - Portugal
{adalto,tamara}@cfh.ufsc.br, [email protected]
Abstract.. This paper describes a sociotechnique analysis about the controversies of
the free software, presenting them as political disputes. We relate theoretical
contemporaries references in the study of technoscientific controversies and try to
identify, from the actor network-theory, the sociotechnique network that if formed, as
well as the motivations of the disputes among the actors (human and non-human), the
causes that generate the conflicts and their possible resolutions.
Resumo. Este artigo realiza uma análise sociotécnica das controvérsias acerca do
software livre, apresentando-as como disputas políticas. Relaciona referências
teóricas contemporâneas no estudo de controvérsias tecnocientíficas e busca
identificar, a partir da teoria do ator-rede [actor network-theory], a rede
sociotécnica que se forma, bem como as motivações das disputas entre os atores
(humanos e não humanos), as causas geradoras dos conflitos e suas possibilidades
de resoluções.
1. Ciência e sociedade: uma relação ambivalente
A crescente utilização de projetos tecnocientíficos nas mais diferentes áreas sociais em nossa
atualidade tem demonstrado uma forte associação entre técnica, ciência e sociedade. Esta
interconexão tem levado muitos teóricos a procurar os elementos constitutivos desta relação.
Esta interrogação não é nova; ao contrário, é fundadora do pensamento filosófico acerca da
técnica e da ciência. Mas, à medida que os recursos técnicos e científicos vão, cada vez mais,
ocupando um lugar inseparável no dia-a-dia das pessoas, uma re-elaboração da sociabilidade
passa a ser perceptível, originando novas formas de interação, de cooperação e de conflitos
(Callon, 1997).
A partir da modernidade e com o avanço da ciência e da tecnologia tais questões foram
incorporadas definitivamente na agenda das pesquisas sociais. Hoje, é difícil pensar qualquer
realidade social, qualquer instituição presente na sociedade, prescindindo do uso da tecnologia
ou ignorando o conhecimento científico. Para estudar o mundo em que vivemos é necessário,
inevitavelmente, defrontar-se com este binômio complexo que, de tão íntimos, chegam a
fundirem-se num só; ciência e tecnologia podem ser designados pelo termo de “tecnociência”
(Latour, 2000), pois suas relações e interconexões não permitem uma dissociação possível.
Pensar o desenvolvimento da ciência é pensar concomitantemente o desenvolvimento da técnica
em nossas sociedades, e vice e versa.
17
18
5° WSL / 5° FISL
As controvérsias em torno de temas tecnocientíficos e suas conseqüências para a sociedade,
sejam positivas ou negativas, têm mobilizado um crescente número de estudos. Elas refletem o
relacionamento ambivalente entre ciência e outras instituições sociais como os meios de
comunicação, o sistema regulatório, o corpo legislativo e a justiça. Elas destacam divergências
políticas sobre o papel dos governos, preocupam-se com o aumento da importância da opinião
dos peritos para a sociedade e causam desconforto com o instrumental valorativo fundamental
para o desenvolvimento científico (Nelkin, 1984).
2. Controvérsias tecnocientíficas: uma perspectiva analítica
Desde a antigüidade os homens vêm se deparando com grandes temas polêmicos, envolvendo
conflitos entre ciência e sociedade. A ciência sempre enfrentou atitudes públicas ambivalentes.
A aceitação da autoridade do parecer científico sempre coexistiu com a desconfiança e o medo,
revelados, por exemplo, na resposta às inovações tais como métodos de vacinação ou de
pesquisa com uso de animais. A visão romântica do cientista retratado pela literatura e pelo
cinema também contribuiu para esta percepção. A personagem do cientista é freqüentemente
apresentada como "o mágico moderno” ou um homem maravilhoso capaz de fazer coisas
inacreditáveis (Nelkin, 1984, 1995).
Recentemente, algumas controvérsias que extrapolaram o campo técnico-científico e dividem
opiniões tantos de especialistas quanto de leigos e ativistas são o uso e a produção de alimentos
geneticamente modificados, o uso de antenas de microondas para celulares, as recentes
descobertas da biogenética e a manipulação de material genético humano, como o caso dos
clones e novas formas de fertilização in vitro com novas possibilidades de contracepção.
Os estudos das controvérsias desenvolvidos até o presente momento sugerem que as disputas
que se travam entre temas tecnocientíficos e suas implicações sociais possuem sua origem numa
escala de interesses políticos, econômicos e éticos. Os temas que movem controvérsias estão
ligadas a questões que contradizem princípios e interesses pessoais ou coletivos. A controvérsia
será maior ou menor, dependendo do tamanho do público que afetar e da influência que este
público exerce sobre o restante do corpo social (Bijker, 1997).
No entanto, a grande motivadora de controvérsias acerca da ciência e da tecnologia são questões
morais e políticas (Nelkin, 1984). Os avanços científicos e tecnológicos produzem uma série de
problemas éticos, sociais e políticos, cada qual com seus valores e interesses. Tais conflitos
tendem a ser discutidos fora do âmbito restrito da ciência, uma vez que acarretam riscos para as
demais estruturas do corpo social (Wynne, 1995). A noção de risco (Giddens, 1995) faz com
que ocorra uma maior participação em torno de questões controversas, açambarcando os
principais espaços de tomada de decisão. Embora o peso do discurso técnico científico ainda
seja muito grande em nossa sociedade, em geral as decisões tomadas acabam sendo fruto de
uma negociação envolvendo diferentes setores sociais (Touraine, 1998). As controvérsias sobre
ciência e tecnologia estão freqüentemente focalizadas em questões de controle político sobre o
desenvolvimento e aplicação da ciência (Nelkin, 1995). Portanto, pode-se dizer que as
controvérsias tecnocientíficas são sempre controvérsias políticas e que tendem a ser resolvidas
no âmbito das negociações do fórum político.
A presença de “grupos sociais relevantes” (Bijker, 1997) é essencial para este processo. Ou seja,
aquele conjunto de atores que contribuem para o desenvolvimento de um artefato e agem
segundo padrões específicos. Estes grupos sociais são responsáveis pela geração de conflitos e
negociações no decorrer do processo. As posições destes grupos são motivadas por suas
crenças, seus valores e pela sua capacidade de argumentação. Neste caso a retórica é um recurso
poderoso (Callon, 1997).
Dependendo do grupo, pode haver uma ou outra interpretação do processo, de seu
desenvolvimento e progresso, de sua utilidade e riscos. Estes diferentes tipos de interpretações
5° WSL / 5° FISL
são caracterizados pela “flexibilidade interpretativa” (Bijker1997), que deve ser sempre
considerada como elemento fundamental da construção social dos artefatos. Outro fator a ser
considerado é que uma mesma controvérsia poderá atingir públicos diferentes, com interesses e
valores distintos, aumentando desta forma sua abrangência e importância (Latour, 2000).
3. Uma controvérsia tecnocientífica atual: o caso do software livre
A construção de softwares livres apresenta-se como um excelente exemplo de uma controvérsia
tecnocientífica contemporânea, pois seu processo constitui-se atualmente de um amplo e
conflituoso debate que extrapola o domínio dos peritos técnicos, envolvendo todas as esferas da
sociedade, do simples consumidor ao produtor, da iniciativa privada aos governos, do diletante
ao especialista. Possui ainda a especificidade de ser um processo em curso, ou seja, que se
encontra ainda no estágio de desenvolvimento, sem tornar-se ainda uma caixa preta (Latour,
2000).
4. As motivações de disputas sobre o software livre: um caso político
As motivações das disputas que animam as controvérsias acerca do software livre giram em
torno das questões polêmicas de propriedade intelectual, de direito de produção,
comercialização e de posse. “Liberdade” é a palavra chave que designa a maioria das disputas
empreendidas pelos seus defensores, “propriedade” é a palavra chave de seus opositores
(Castells, 2003). No entanto, estas questões se multiplicam numa variedade de outras questões
que derivam desta causa central. As disputas presentes nas controvérsias do software livre
refletem os interesses dos atores envolvidos nos conflitos e nas negociações.
Parte das controvérsias são motivadas por ideologias políticas que pregam o fim de monopólios
hegemônicos, maior autonomia nacional na produção e difusão de inovações tecnológicas,
otimização e prestação de contas do serviço público, etc. Outras controvérsias privilegiam
argumentos econômicos, como as possíveis economias que se podem realizar pelo não
pagamento de royalties, baixo custo de implementação, etc. Existem aqueles que se preocupam
em defender a possível superioridade técnica do software livre ou mesmo aquelas controvérsias
que privilegiam valores éticos, derivados da lógica meritocrática (Castells, 2003) desenvolvida
pelas academias universitárias de todo o mundo, etc.
Os atores envolvidos nas disputas são os mais variados. Desde aqueles ligados diretamente ao
mundo político formal – funcionários públicos, políticos, assessores, etc – e também partidos
políticos e ativistas de movimentos sociais empenhados em fiscalizar atos dos governos e
contribuir para uma maior participação cidadã nos processos decisórios. Tais grupos estão
articulados em rede de relações, de acordo com as atividades que exercem na sociedade, e de
acordo com seus interesses específicos (Touraine, 1998). A mobilização destes atores nem
sempre é coordenada por uma autoridade central, podendo os indivíduos agirem
independentemente de grupos os associações formais.
5. Considerações finais: a resolução dos conflitos
O caráter ambivalente das controvérsias tecnocientíficas sobre o software livre permite perceber
a grande movimentação de atores que se agrupam de acordo com interesses específicos. Em
função disso, formam-se complexas redes de relações, ligando participantes diversos, que
envolvem, basicamente, o que Latour (2000) chama de “tradução” de interesses, ou seja, trata-se
de relações em que interesses distintos de diferentes participantes são reciprocamente reforçados
num certo contexto de construção e circulação de um produto "tecnocientífico". A tradução diz
respeito à capacidade de um ator “decodificar” os anseios do outro autor. Nessa perspectiva, os
atores – tanto humanos como não-humanos; individuais ou coletivos – estão permanentemente
traduzindo suas ações, linguagens, identidades e desejos tendo em vista as mesmas
19
20
5° WSL / 5° FISL
manifestações em outros atores. A tradução não é fixa, ou seja, muda de acordo com as ligações
estabelecidas dentro da rede sociotécnica .
Os estudos sobre controvérsias nunca podem ser conclusivos, podem apenas apontar os limites
provisórios a que chegam tais disputas no momento em que algumas posições passam a ser
aceitas como verdadeiras (Latour, 2000). Diante desta perspectiva, percebe-se que as
controvérsias que envolvem a temática do software livre somente serão resolvidas quando um
determinado grupo vier a dominar a retórica argumentativa em detrimento dos demais, tornando
a questão uma caixa-preta. Neste momento, ainda é impossível estabelecer um discurso
dominante, capaz de vencer as disputas. Ainda são muitas as questões que se impõem e a
solução dos conflitos ainda estão longe de serem alcanças. Os interesses dos diferentes lados,
dos defensores e opositores do uso de software livre ainda são bastante contraditórios e
irredutíveis. Cabe aos estudos sobre esta temática identificar os atores constituinte desta rede
complexa e os discursos empreendidos na defesa ou na recusa deste tipo de tecnologia. Somente
desta maneira será possível realizar uma análise sociotécnica, identificando o processo que irá
determinar a hegemonia de um ou de outro lado da controvérsia.
Nota: Este trabalho é parte integrante da pesquisa intitulada “Software livre e controvérsias
tecnocientíficas: uma análise sociotécnica no Brasil e em Portugal”, desenvolvida numa cooperação
entre o Programa de Pós-Graduação em Sociologia Política (PPGSP) da Universidade Federal de Santa
Catarina, o Centro de Investigação em Sociologia Económica e das Organizações (SOCIUS), do
Instituto Superior de Economia e Gestão, da Universidade Técnica de Lisboa e o Programa de
Doutoramento em Engenharia Eletrotécnica e de Computadores, da Universidade do Porto. A pesquisa
conta com recursos financeiros da CAPES/MEC, a quem agradecemos pelo apoio.
6. Referencias
BIJKER, W., (1997) “The social construction of facts and artifacts: or how the sociology of
technology might benefit each other”, in BIJKER, W. E.; HUGHES, T. P.; PINCH, T.J.
“The social construction of technological systems”, 6 ed., Mit Press, Cambridge
(Massachusetts), 1997, p. 17-50.
CALLON, M. (1986) “Some elements of a sociology of translation: domestication of the
scallops and fishermen of St. Brieuc Bay”, in LAW, J. “Power, action and belief: a new
sociology of knowledge?”, (Sociological review monograph n 32), Rontledge & Kejan Paul,
London.
CASTELLS, M. (2003), “A galáxia da Internet”, tradução de Maria Luiza X. de A. Borges,
Jorge Zahar, Rio de Janeiro.
GIDDENS, A. (1991) “As conseqüências da modernidade”, 2. Ed., UNESP, São Paulo.
LATOUR, B. (2000) “Ciência em ação”, Tradução de Ivone C. Benedetti, UNESP, São Paulo.
NELKIN, D. (1984) “Science, technology, and political conflict: analyzing the issue”, in
“Controversy”, 2 ed., SAGE, London/Beverly Hills/New Delhi,p. 09-24.
______ . (1995), “Science Controversies: the dynamics of public disputes in te United States”,
in JASANOFF, S.; MARKLE, G.; PETERSEN, J.; PINCH, T., “Handbook of science and
technology studies”, SAGE, London/Beverly Hills/New Delhi, p. 444-456.
TOURAINE, A. (1998), “Critica da modernidade, 5. ed., Vozes, Petrópolis.
WYNNE, B. (1995), “Public understanding of science”, in JASANOFF, S.; MARKLE, G.;
PETERSEN, J.; PINCH, T., “Handbook of science and technology studies”, SAGE,.
Londres, p. 361-388.
5° WSL / 5° FISL
Software Livre na Universidade: Aprendizado, Economia,
Segurança e Desempenho
Davi T. Santos½ , Adilson L. Bonifácio½
½ Departamento de Computação – Universidade Estadual de Londrina
Rodovia Celso Garcia Cid/PR, Km 380, Campus Universitário – 86051-990 Londrina, PR
[email protected], [email protected]
Abstract. Nowadays, free software is one at the areas of major interest in computer science. This
paper presents works performed on the dissemination of free software culture and implantation of
free solutions at university. On the initial stage of implantation is a remote boot system, viewing
for reduction in costs by use of low-cost equipment. An alliance with private companies is also
being formed looking forward a software engineering laboratory using free software.
Resumo. Atualmente, o software livre é uma das áreas de maior interesse dentro da computação.
Este artigo apresenta trabalhos realizados na disseminação da cultura do software livre e na
instalação de soluções livres em laboratórios. Em fase inicial de implantação está um sistema de
boot remoto, visando economia com o uso de equipamentos de baixo custo. Também está sendo
firmada uma parceria com a iniciativa privada para montar um laboratório de Engenharia de
Software utilizando software livre.
1. Introdução
Com o aumento da demanda por software, instituiç ões de ensino e até mesmo comerciais, têm adotado
o software livre como opção para reduzir custos com software. A adoção de softwares que seguem esta
filosofia têm aumentado nos últimos anos, principalmente nas universidades. A dificuldade na aquisição de
licenças de software proprietário é um dos principais motivos que levam as instituiç ões a migrarem para o
software livre.
Outro aspecto importante na utilização de soluções livres é a melhor compreensão proporcionada
a quem as utiliza sobre as tecnologias empregadas no software. Estes softwares abrangem várias áreas de
aplicação, permitem adaptação e redistribuiç ão, visando melhorias contı́nuas no software.
Este artigo apresenta estudos e pesquisas realizados pelo Departamento de Computação (DC) da
Universidade Estadual de Londrina (UEL) na área de software livre, apresentando os resultados obtidos
em: implantação de sistemas livres comutados com softwares proprietários; adoção do sistema de terminal
remoto; instalação de softwares livres nos laboratórios; e uma parceria firmada com a iniciativa privada para
instalação de um laboratório de engenharia de software utilizando plataforma livre.
2. Histórico do Software Livre
O conceito de software livre surgiu na década de 80, criado por Richard Stallman, um de seus precursores
com o projeto GNU1 . Em 1984 Stallman fundou a Free Software Foundation2 , uma ONG que promove a
disseminação e o uso do software livre [Reis, 2003].
Essa disseminação deu inı́cio a formação de uma comunidade atuante que, se comunicando principalmente através da Internet, desenvolve uma grande variedade de softwares. O Linux, um dos principais
1
2
GNU’s Not Unix (GNU não é Unix), um sistema operacional totalmente baseado em software livre.
Disponivel em: http://www.gnu.org/
21
22
5° WSL / 5° FISL
representantes do software livre, foi lançado em 1991 e licenciado por seu criador, Linus Torvalds, com
a licença GPL3 . Com isso, a comunidade conseguiu desenvolver um sistema operacional estável, seguro,
escalável e, principalmente, livre.
Com todos estes atributos, a fama do linux cresceu rapidamente, fazendo com que surgissem diversas distribuiç ões que agregaram ao sistema operacional vários outros softwares livres. Atualmente, existem
milhares de projetos de software livre em diferentes domı́nios de aplicação, como softwares de escritório,
servidores e programação.
No cenário mundial do software livre, o Brasil tem posição de destaque, sendo um dos grandes
expoentes da área. Essa condição foi conquistada através de um processo iniciado com os desenvolvedores
independentes e as universidades que, posteriormente, foram apoiados pelos governos estaduais e federal.
Devido ao envio de receitas elevadas ao exterior [Lemes, 2003], pela compra de softwares proprietários, o
governo brasileiro decidiu investir na indústria nacional de software, visando reduzir custos e estimulando
o desenvolvimento interno.
3. Software Livre e a Universidade
Diversas universidades brasileiras têm adotado software livre como solução em tecnologia da informação.
Uma das universidades que possui grande tradição na utilização de software livre é a Univates, que também
oferece cursos de especializaç ão e mestrado nesta área. Outra universidade que adotou soluções em plataforma livre foi a UFPR, estruturando laboratórios com terminais remotos.
Na UEL a estrutura computacional é formada por cerca de 2600 computadores interligados em rede,
incluindo outros centros como o Hospital das Clı́nicas e o Hospital Universitário. Devido ao gasto elevado
com licenças de software proprietário, o DC/UEL decidiu iniciar os projetos de adoção de soluções livres
para, futuramente, implantá-las em toda a universidade.
Neste contexto foram definidos dois principais focos de trabalho. O primeiro compreendeu a
definição de estratégias e ações de divulgação do software livre na região através da Internet, minicursos, palestras e um grupo de usuários. O segundo foco concentrou esforços para disponibilizar uma infra-estrutura
computacional de laboratórios através da instalação e configuração do sistema operacional GNU/Linux e
diversas ferramentas livres.
3.1. Disseminação do Software Livre na UEL e Região
Para que as idéias do software livre tivessem maior abrangência foram definidas algumas estratégias, como
a criação de um grupo de usuários, estágios desenvolvidos por alunos do curso de Ciência da Computação, a
realização de palestras abertas ao público e a participaç ão de alunos e professores em congressos com temas
relacionados ao software livre.
A criação do grupo de usuários foi iniciada com os estagiários realizando tarefas de implantação e
manutenção da plataforma livre nos laboratórios, sob a supervisão dos professores do DC. Para a divulgação
foram criadas uma página na internet e um fórum4 , onde os membros participam enviando suas dúvidas,
sugestões e notı́cias.
Foram realizadas, também, palestras periódicas sobre os mais diversos tópicos envolvendo software livre, como a instalação e o funcionamento do sistema Linux, ferramentas de escritório e desenvolvimento, segurança em redes, jogos para Linux e muitas outras. Os coordenadores do grupo também
ministraram minicursos [Bonifácio, 2003c, Bonifácio, 2003b], palestraram sobre adoção de software livre
[Bonifácio, 2003a], assim como participaram em conferências internacionais5 e seminários de desenvolvimento6 .
3
GNU Public License: licença de software livre.
Red Foot - Grupo de Usuários de Software Livre, disponı́vel em: http://www.dc.uel.br/redfoot/
IV Fórum Internacional de Software Livre, disponı́vel em: http://www.softwarelivre.org/
6
II Seminário de Desenvolvimento em Software Livre, disponı́vel em: http://rau-tu.ccuec.unicamp.br/sdsl/index.php
4
5
5° WSL / 5° FISL
O objetivo dessas ações foi a formação de uma massa crı́tica na região capaz de utilizar software
livre e difundir esta filosofia. Particularmente ao DC, o objetivo foi capacitar os alunos do curso de Ciência
da Computação a utilizar e desenvolver soluções em plataforma livre.
3.2. A Infra-estrutura para Software Livre
O processo de adoção nos laboratórios do DC ocorreu com a implantação de ambos os sistemas, o proprietário que vinha sendo utilizado e a nova solução em plataforma livre. O objetivo foi manter os laboratórios operando nos dois sistemas, realizando uma migração gradual. Essa estratégia, chamada Dual Boot,
permite ao usuário a escolha entre os sistemas Linux e Windows. Dessa forma, os laboratórios continuaram
com os habituais softwares proprietários e com as novas aplicações livres no sistema operacional Linux.
Dentre as aplicaç ões instaladas pode se destacar as ferramentas de desenvolvimento e as ferramentas de escritório7 , além de softwares que passaram a ser utilizados em disciplinas do curso de Ciência da
Computação como PostgreSQL, Apache, PHP e Eclipse.
4. Economizando com Terminais Remotos
Em busca de soluções alternativas para oferecer serviços aos usuários da rede do DC foi iniciado um projeto para a implantação de um sistema com terminais remotos. Este sistema, usualmente chamado de Boot
Remoto [McQuillan, 2000, Nemkin, 2001], permite uma economia considerável em se tratando de investimento em equipamentos.
O funcionamento dessa solução se dá com a utilização de terminais remotos no laboratório obtendo
o sistema operacional, dados de usuário e softwares diretamente de um servidor, sem armazenamento ou
processamento de dados local. Este processo acontece de forma transparente, de modo que o usuário não
percebe a diferença entre usar uma estação de trabalho ou um terminal de servidor remoto.
Um fator que tem dificultado a administração dos laboratórios do departamento tem sido o tempo
gasto em suas manutenç ões. Esta tarefa será facilitada com o boot remoto, visto que, a manutenção necessária ocorrerá, basicamente, no servidor, sem a necessidade de muitos ajustes individuais nas máquinas.
As manutenções individuais se resumirão a pequenos reparos, considerando que os terminais remotos deverão possuir poucos componentes fı́sicos.
Para que o projeto se torne realidade será necessário uma reestruturaç ão da infra-estrutura de rede do
departamento. O tráfego gerado pelo sistema na rede será maior do que aquele gerado pelos atuais serviços,
como as autenticaç ões e transferências menos intensa de dados de usuário. No esquema de terminais remotos
todo processamento requisitado pelo usuário será efetuado no servidor, fazendo com que o tráfego na rede
se torne constante e intenso.
Outro aspecto importante a ser observado para a implantação do boot remoto está relacionado com
o desempenho do servidor. Devido ao grande volume de processamento requisitado, o servidor deverá ter
alto poder de processamento, exigindo um maior investimento em seu hardware, se comparado com os
servidores de estações de trabalho. Entretanto, o investimento no servidor será inferior ao investimento que
seria necessário para colocar a mesma quantidade de máquinas e serviços em funcionamento.
O fator segurança é outro aspecto pertinente na implantação do sistema de terminais remotos. Com
a utilização do boot remoto será suficiente manter as estratégias de segurança numa única máquina, já que
o servidor realizará todo processamento. As dificuldades encontradas na administração de uma rede, como
evitar ataques, perdas de dados e instalações despadronizadas, serão evitadas com o uso deste sistema.
Não obstante a todos os aspectos abordados, o maior ganho com a utilização de terminais remotos
está na reutilização de equipamentos ultrapassados, considerados sucatas tecnológicas. Na universidade, a
renovação do parque de máquinas é um processo lento e o sucateamento dos equipamentos é inevitável.
Dessa forma, pode-se observar duas importantes vantagens no uso de terminais remotos. A primeira está
na utilização de uma plataforma livre que suporta o boot remoto, economizando com licenças e compra de
7
OpenOffice, StarOfice, GCC e FreePascal.
23
24
5° WSL / 5° FISL
software proprietário. A segunda, e talvez mais importante, está no reaproveitamento das máquinas, atuando
no caráter social e financeiro da universidade, evitando grandes investimentos na compra de equipamentos.
5. O Software Livre aproximando Universidade e Empresa
Recentemente, outro projeto foi iniciado envolvendo a implantação de um laboratório de engenharia de software, visando a melhoria de produtividade e qualidade no desenvolvimento de sistemas [Raymond, 2001].
Para a implantação deste laboratório está sendo firmada uma parceria com a iniciativa privada que irá prover
a infra-estrutura. O projeto deverá englobar as mais diversas áreas de conhecimento dentro da engenharia
de software com os trabalhos de pesquisa, conclusão de curso e estágios desenvolvidos pelos alunos.
A aproximação da academia com a iniciativa privada irá proporcionar a formação de profissionais
para suprir as necessidades da região. Alguns trabalhos que já estão em andamento abordam assuntos, como
processos de desenvolvimento de software, arquitetura de software, framework, modelagem e especificação
de sistemas, entre outros.
Além da proposta de interação das empresas com a academia, um dos principais objetivos do projeto
é manter o laboratório em plataforma livre. Com o progresso dos trabalhos, sejam eles em desenvolvimento,
pesquisa ou suporte, e com a participação da universidade, o projeto funcionará como um meio disseminador
da filosofia de software livre e impulsionará a utilização de soluções livres pelas empresas.
6. Resultados
Um dos resultados obtidos com os trabalhos é o aumento substancial no número de usuários de software
livre, especialmente o Linux, na região de Londrina. O principal indicador do crescimento é a expansão do
grupo de usuários que utiliza como meio de comunicação o fórum.
Com relação a adoção do software livre no DC percebeu-se um ganho significativo no tempo de
manutenção dos laboratórios. Os problemas, até então existentes com a plataforma proprietária, foram
reduzidos drasticamente. Entre eles pode se destacar os vı́rus, a degradação do sistema e de softwares.
Nos cursos ministrados utilizando softwares livres, tanto alunos quanto professores perceberam
um maior rendimento no aprendizado e uma melhor compreensão das tecnologias estudadas. Além disso,
observou-se uma redução nos gastos com licenças de software, mantendo a universidade na legalidade.
Com a compra de um servidor de alto desempenho está sendo dado continuidade ao projeto de
implantação de um laboratório com terminais remotos. O DC/UEL possui um número elevado de máquinas
com baixo poder computacional que serão reaproveitadas como terminais do servidor adquirido.
Em relação à parceria, firmada com a iniciativa privada, espera-se conseguir uma melhor interação
da academia com as empresas. Esta parceria deve colaborar com a indústria de software da região, aumentando a qualidade do desenvolvimento de softwares livres e aproximando os alunos do mercado de trabalho.
Referências
Bonifácio, A. L. (2003a). Adoção Linux e Soluções Livres na Universidade. Palestra: Semana do Software
Livre na UNILINS.
Bonifácio, A. L. (2003b). Curso do S. O. Linux. Techinpar, Ponta Grossa.
Bonifácio, Adilson Luiz e Kaster, D. d. S. (2003c). Introdução ao Linux. Secomp, Londrina.
Lemes, L. (2003). Relato: O Software Livre e o Desenvolvimento do Brasil. Disponı́vel em:
http://www.inf.unisinos.br/instituto/Brasilia.pdf.
McQuillan, J. (2000). The Linux Terminal Server Project: Thin clients and Linux.
Nemkin, Robert e Vasudevan, A. (2001). Diskless nodes how-to document for linux. Disponı́vel em:
http://www.linuxdocs.org/HOWTOs/Diskless-HOWTO.html.
Raymond, E. S. (2001). The Cathedral and the Bazaar. O’Reilly, Sebastapol, CA, 2 edition.
Reis, C. (2003). Software Livre. Disponı́vel em: http://www.async.com.br/ kiko/MinicursoUSP2003/.
5° WSL / 5° FISL
Rybená: a Free Source Project for Digital Inclusion of
Persons with Special Needs, Through Mobile Communication
!""
#$%&'"()"
!"
#$%"
$
&
$'"()*'"(
+
$,$
) !"*.
/0/1!"*
)(
23!452503!6233!
2)33!
32)3!0523!7423
)*
.0888350$6()05
$(/!09!-:9!;9-00)$60<=0
>6<=>0&9?0$6)))0@@
0))000
@0A$B.0>.)+!88!
0$60C
)A8+&-6A$B.0
D) 0 5 0 0 0
))003!)!3500)$6
!
88E ,6! 88E )! 88&E *! 88& * ! 0 *.A$B. )4
! 88&! 00 )) 0 ) !)
0)03))
3000)4*
0)!0))00
) 0 34 > 0 0 )4 ) 35 0 05 ) 0 * "5 .F < A! 88! 00
))@A)!,.=/,.
!;;9!;;:!88!00))
05>000!0)4)35
0$'"()*'"(!00)0''0
0))0)00))G
0G)
H003
A$B.0050005300
)0 0) 0 0 0 0 )0 3 ))0
A$B.I$6A
25
26
5° WSL / 5° FISL
0B53J)4)350*'"(05))350
B0)05
!0"5$%"$!0
0 "5 $ "
$ 0 * "5 . "*.A )0500)
!)5030400)40
))0B53J)4')!
03
!
0$G53$A
0))0)4)50
000)00)))0)
0D))00
)&'+,-./
.3)0000
D0,@0)5)3!00
05)+00)
* 0 ! 0 ) 0 ' ) '
5 0! 00 ) 3 30
!3.00))3!
0!000))!00
A$B.!0353-8?0$6
5
.00))0)43500*'"(
03!0*'"(00
)05
5)!0))!0
>000!G3)00"
$!0"$
0"*.A
00)4)033
30 0034F ! )
)5)0! ! )',! ! G
A$B.35 3! ! ) 0 B53J 0 )0 !)5A$B.)0>!88&
0 )4H 34 G @)0 3 0 0 3 5 E 0 ,30)33
)0&E!5!G)033
3+
0H3330
000)00)4G0000
0))35!))
0G00)0)0
)00KKG0D00
A$B.)G)3!0530
0,,K!88!<!88!880A$B.
*06!)A$B.
0H)00)53
0,! 035 )0
3* 005353GG!0
0000)0
5° WSL / 5° FISL
! 0 0 0 )4H )! 0 0 ) LA$B.
")B53J4.0
)
5!030)3540
0 ) ' )! B53J! 00 A$B. 5 ) >! 88& " 5! 0 ) 5060)5!
0 A$B. 0 3 ) 6
>00))05
)! D 6 0 )
A$B.3.0!0)
050300)0
0)033)0)0
!50G43
A$B.3)
0))0)03
3)0500D!5!
G0! D)00 03M )N0000)G3050
5))D000G
!00350000
0 0 ) 0 )35 D) 0
)) 0 0 0 3 0 )00030))
A$B.0))35)0!0
+;$600<33&90)0I0
398!88850I0
)0 )) )0))0 0 0)
00G
#01"$
0)4)5))350
B0)
05<G0G0
0)4F
1
6!
! ' B ! ' / $3! .1 .!
B6$!B3BC
27
28
5° WSL / 5° FISL
+2
$!.88
@
5B0
0)FLL3LL))L8+@3))
!.
B!!(!88.<@$.))0A
!"#!K;:!))8@89!)
! / $ ! ;;9 ,.=/,.F . 3 @
0!"#!K;;!))+@98!)
! / $ ! ;;: * G @
5!"#!K88!))-@O!)
!/$!88 0535
3@))0!$
%
&
! A)!$6!))-O@-8
!KM.,3$GN!(<G!4,".F"5
$%L$$L$,$!388&)
>!!88&M ))1
#N! $
#'(#)* +,#-.//0! >!!88&M"3)6<3))
A$IA$B.M %1!K!-!388&
0)FLL3L3L-LD0
*!,(!88&2
#3
"
! !$6
A!
!88<F.<3/))"
!
$
&,.//.
,6!*A!882&
,2
42&%3
"/
!4%!$6
,@=!BE
0))!!88563)".F>PB5
G!!;;+#
3+
6%
!<,Q
!BA!88&)00!D)
)0 A3! ! $ % %
7%%.//0!4%!$6
6!K
E!
!88& <3,F.<3
000$6AIA$B.! $
%
&
!B'!$6!))+@+&8
K!
/!88
4
0)FLL@8-3L)GL
3L35L@34)LD0
<!R!888
$0)FLLLL&;:0
<! R! 88 &9 * 0 ,5SA! ;;:& * 0 >B.
A/
0)FLLLL&;:0
5° WSL / 5° FISL
Sessão Técnica 2
WEB
29
30
5° WSL / 5° FISL
5° WSL / 5° FISL
Tecnologias de SW livre para análise de mensagens em chats e
recomendações online de documentos eletrônicos
Rodrigo Branco Kickhöfel1, Stanley Loh1,2, Daniel Lichtnow1, Ramiro Saldaña1, Thyago
Borges1, Tiago Primo1, Gabriel Simões1, Gustavo Piltcher1
1
2
Universidade Católica de Pelotas (UCPEL) – Escola de Informática
Rua Felix da Cunha, 412 – Pelotas – RS – Brasil
Universidade Luterana do Brasil (ULBRA) – Faculdade de Informática
R. Miguel Tostes, 101, Canoas, RS – Brasil
{rodrigok,lichtnow,rsaldana,thyago,gustavopil}@ucpel.tche.br,
[email protected], [email protected], [email protected]
Abstract: This paper describes a recommender system to support collaboration using open
source technologies. The system consists on a WebChat that using text mining techniques
identifies the subject of the messages and selects items from a digital library to recommend
to the chat participants. The system allows knowledge exchange among members of virtual
communities. The results and the advantages of using open source technologies for that
purpose are presented and discussed.
Resumo. Este artigo apresenta um sistema de recomendação para apoio à colaboração
utilizando tecnologias de software livre. O sistema consiste em um chat Web que, a partir
de técnicas de text mining, identifica o assunto das mensagens e gera recomendações a
partir de uma base de dados própria (uma Biblioteca Digital, contendo documentos
eletrônicos, links par páginas web e referências bibliográficas). O sistema permite a troca
de conhecimento entre os membros de comunidades virtuais. São apresentados os
resultados obtidos e as vantagens da utilização da tecnologia de software livre para estes
propósitos.
1. Introdução
A geração de novos conhecimentos é desencadeada em parte pela troca de conhecimento
entre as pessoas, por exemplo, através de chats na Web. Então com o objetivo de valorizar a troca do
conhecimento, surgiram os sistemas de recomendação (Recommender Systems). Um sistema de
recomendação tem por finalidade auxiliar no processo social de indicar ou receber indicação, seja esta
indicação referente a livros, artigos, discos, restaurantes, ou informações (RESNICK & VARIAN,
1997).
Este artigo discute o uso de tecnologias de software livre para auxiliar ou suportar um sistema
de recomendação para apoio à colaboração em comunidades virtuais.
2. O Sistema SisRecCol
O SisRecCol (Sistema de Recomendação para apoio a Colaboração) consiste em um chat Web
onde os usuários trocam mensagens e recebem recomendações conforme o assunto identificado nas
mensagens. Essa identificação é realizada através de técnicas de text mining apoiadas em uma
ontologia desenvolvida para o sistema. As recomendações são de documentos eletrônicos e links para
sites Web (armazenados numa Biblioteca Digital privada do sistema), de autoridades nos assuntos
(identificados pelo próprio sistema) e de discussões anteriores sobre o mesmo tema. O objetivo é
apoiar a troca de conhecimento entre os usuários. Dessa forma a ferramenta pode ser utilizada em
31
32
5° WSL / 5° FISL
grupos que pertençam a um domínio específico, como turmas de ensino a distância, auxiliando
inclusive na avaliação dos alunos, permitindo analisar a interação de cada um e seus assuntos de
interesse. O sistema pode ser adaptado para ser utilizado em diferentes áreas, bastando incluir uma
nova ontologia, referente ao novo domínio. O protótipo do sistema está disponível em
http://gpsi.ucpel.tche.br/sisrec.
2.1 Funcionamento
O sistema utiliza uma ontologia de domínio para classificar os documentos na biblioteca
digital, para traçar o perfil dos usuários e para identificar temas nas mensagens (através de técnicas de
text mining). Uma ontologia do domínio (domain ontology) é uma descrição de “coisas” que existem
ou podem existir em um domínio (SOWA, 2002) e descreve o vocabulário relacionado ao domínio em
questão (GUARINO, 1998).
No SisRecCol a ontologia é apresentada como uma hierarquia de conceitos e cada conceito
contém uma lista de termos associada. No momento, há somente uma ontologia no Sistema, pertinente
à área da Ciência da Computação e contendo termos em Inglês e Português, o que permite discussões
em ambas as línguas.
O módulo de text mining é responsável pela identificação dos assuntos das mensagens. Essa
identificação não ocorre apenas individualmente nas mensagens, mas sim analisando um contexto (se
várias mensagens tratam do mesmo assunto e com um grau de importância acima de um determinado
parâmetro, a probabilidade desse assunto ser o tópico da discussão é alta, sendo esse então
identificado como assunto principal desse conjunto de mensagens).
Biblioteca Digital é uma coleção de recursos digitais, organizados sob uma certa lógica,
acessíveis para recuperação sobre uma rede de computadores (KOCHTANEK; HEIN e KASSIM,
2001). A Biblioteca Digital do SisRecCol contém documentos eletrônicos e links para páginas Web,
no momento. Este conteúdo é previamente indexado com ferramentas de software que realizam o
processo de forma automática com base nos mesmos métodos usados para identificar os assuntos das
mensagens do chat. O processo de indexação determina o grau de relacionamento dos documentos,
(artigo ou site) aos conceitos existentes na ontologia.
A inclusão dos documentos na Biblioteca Digital pode ser feita pelos usuários, num processo
independente da sessão do chat. O material disponibilizado pelos usuários passa pela revisão do
administrador do sistema, que verifica a qualidade do material e também avalia a indexação produzida
pelo sistema. Uma vez aprovado, o documento passa a estar disponível para utilização, podendo ser
recomendado durante as sessões do chat, ou também ser consultado utilizando palavras-chaves ou a
estrutura hierárquica da ontologia.
A base de perfis do sistema se assemelha aos chamados Mapas do Conhecimento ou Páginas
Amarelas (Yellow Pages), que servem para indicar que pessoas possuem determinados
conhecimentos. Ela contém dados de identificação dos usuários e suas áreas de conhecimento,
representadas pelos conceitos presentes na ontologia. A definição do perfil é dinâmica, ou seja,
conforme o usuário utiliza o sistema, ele é pontuado em determinados assuntos (conceitos) conforme
suas ações. A base de perfis é utilizada na definição dos itens que serão recomendados para cada
usuário, e também é útil na avaliação dos membros do grupo.
A partir do assunto identificado nas mensagens do chat, o módulo de recomendação
proativamente sugere uma lista de conteúdos relevantes, vindos da Biblioteca Digital (documentos
eletrônicos, sites Web ou referências bibliográficas) aos usuários, de acordo com o perfil de cada um
(content-based recommendation) ou avaliando as ações das autoridades no sistema (collaborative
filtering). Essa recomendação é apresentada em uma área separada, não interferindo no decorrer da
discussão, e permitindo ao usuário acessar o conteúdo (por exemplo, ler um documento, abrir um site
Web ou ver dados das autoridades no conceito identificado).
5° WSL / 5° FISL
2.2 Tecnologias Utilizadas
O custo de aquisição de software e a facilidade para encontrar documentação detalhada,
principalmente do sistema operacional do servidor e o banco de dados é um importante fator a favor
do software livre. Optou-se por utilizar a plataforma Linux para o desenvolvimento do sistema. Como
ele consiste em um chat, que precisa ser acessado via Web, a escolha mais natural é o Apache como
servidor Web, por estar diretamente associado ao Linux, além de ser um dos mais difundidos e de fácil
utilização.
O SisRecCol utiliza um banco de dados para armazenar a ontologia, as informações da
Biblioteca Digital, os perfis de usuário bem como todas as informações referentes as sessões do chat.
Em função da adoção do Linux, duas opções principais de banco de dados livre atenderiam as
necessidades do projeto, MySQL ou PostgreSQL. Apesar do intenso uso do banco de dados, não se
trata de uma aplicação crítica. A velocidade é um fator importante e por isso se optou pelo MySQL,
que, apesar de ter menos recursos que o PostgreSQL, é um banco bem ágil, muito difundido e atendeu
perfeitamente as necessidades do sistema. Utilizando tabelas do tipo MyISAM, o desempenho do
MySQL favoreceu o suporte a um grande número de conexões simultâneas, fundamental para a
proposta do sistema. Como este tipo de tabela não implementa integridade referencial ou controle de
transações, as respostas do banco ficaram extremamente rápidas. Só para se ter uma idéia, a cada
mensagem enviada por um participante do chat, o sistema precisa:
1) comparar esta mensagem com todos os conceitos presentes na ontologia (lembrando que cada
conceito é representado por uma lista de palavras e pesos associados), para identificar o assunto;
2) avaliar se o assunto é válido, analisando o contexto (um grupo de mensagens mais recentes);
3) recuperar da Biblioteca Digital, os itens classificados a este assunto identificado;
4) avaliar, para cada usuário, se os itens serão recomendados ou não, já que o usuário pode já ter
“baixado” o documento ou “acessado” o site
5) então apresentar para cada usuário individualmente a lista de recomendações
6) além disto, o usuário pode simultaneamente abrir ou “baixar” os documentos recomendados
7) e ainda cada usuário recebe pontos por participar do chat, por enviar mensagens, por baixar
documentos, etc.
A linguagem de programação utilizada foi o PHP. Ela se mostrou a melhor opção no
momento, pois em termos gerais (e se tratando de aplicações Web) tem um bom desempenho
comparado a outras linguagens como Java, e é de fácil utilização tendo uma boa documentação. Outra
vantagem é que funciona em várias plataformas, tornado o sistema mais portável. Como o sistema
trabalha com processamento de textos, o desempenho é uma questão importante ainda mais se
tratando de um chat em tempo real. Nos testes realizados com até 10 usuários o PHP apresentou um
bom resultado de resposta, gerenciando bem as diversas conexões e não prejudicando a discussão no
chat. Além disso, PHP possui suporte nativo ao banco MySQL, como já citado, o SGBD utilizado
pelo SisRecCol.
O ambiente de chat necessita de algumas validações, além disso, precisa enviar e mostrar
vários dados sem que o conteúdo desapareça da tela do usuário no momento da submissão. Sendo
assim, o SisRecCol utiliza uma série de scripts em JavaScript para validar, enviar e receber dados do
servidor. Essa tecnologia foi amplamente utilizada já que a maioria dos browsers atuais possui
suporte nativo, eximindo o usuário da tarefa de instalar qualquer API ou virtual machine para utilizar
o sistema.
3. Experimentos
Foram realizados experimentos de discussões com grupos utilizando o sistema proposto. As
pessoas do grupo foram convidadas a entrar no chat num horário determinado e realizar uma reunião
33
34
5° WSL / 5° FISL
online real. Em uma das sessões, que durou aproximadamente 1 hora, o sistema registrou 374
mensagens (uma média de 6,23 mensagens por minuto, e quase uma mensagem a cada 10 segundos).
Uma avaliação formal do método de identificação de assuntos registrou uma precisão de 85,7% (ou
seja, porcentagem de assuntos corretamente identificados) e uma abrangência de 85,7% (ou seja,
porcentagem de assuntos que deveriam ter sido identificados), o que leva a crer que, além de rápido, o
sistema consegue um bom nível de acerto na análise das mensagens.
Até então, nos testes realizados com até 10 usuarios, o ambiente de chat, assim como o
módulo de recomendação mostraram-se totalmente estáveis, apresentando em alguns momentos
delays, referentes a instabilidades na rota de rede utilizada pelo cliente. Uma biblioteca digital com
um número maior de documentos ou um volume de usuários maior pode causar alguma perda de
desempenho, visto que a recomendação é complexa (as mensagens são analisadas em função da
ontologia, e, além disso, é preciso analisar o perfil dos usuários, os itens que serão recomendados para
cada usuário e então gerar a recomendação nas telas desses usuários).
Notaram-se também algumas incompatibilidades com browsers mais antigos, os quais não
suportam algumas implementações DOM (Document Object Model) utilizadas nas atuais versões de
JavaScript.
4. Conclusão
As tecnologias de software livre se mostraram totalmente adequadas ao propósito do sistema
desenvolvido e por isso a escolha foi correta. Os resultados obtidos foram muito bons tanto em
rapidez quanto em consistência e confiabilidade. Uma possível alteração para o futuro seria a
utilização da linguagem Java para criação de novas funcionalidades, devido a sua grande quantidade
de recursos, como por exemplo, multithreading para o gerenciamento das várias conexões. A troca do
banco de dados talvez seja necessária conforme aumente a quantidade de informações armazenadas.
Vale ressaltar que as tecnologias baseadas em software livre utilizadas no SisRecCol
adaptam-se completamente também a outros ambientes operacionais, alguns até mesmo proprietários,
sem significativa perda de performance ou necessidade de instalação de pacotes ou frameworks
adicionais, favorecendo assim, a disponibilidade do sistema pare uma gama muito grande de usuários,
espalhados por todos os nodos da rede.
Agradecimentos
O presente trabalho foi realizado com o apoio do CNPq, uma entidade do Governo Brasileiro
voltada ao desenvolvimento científico e tecnológico.
Referências Bibliográficas
GUARINO, Nicola (1998) Formal Ontology and Information Systems. In: International Conference
on Formal Ontologies in Information Systems - FOIS'98, Trento, Itália, Junho de 1998. p.3-15
KOCHTANEK T.R.; HEIN K.K., KASSIM A. R. C. (2001) “A digital library resource Web site:
Project DL”, Online Information Review, v.25, n.1.
RESNICK, P. & VARIAN, H. (1997) Recommender systems. Communications of the ACM, v.40,
n.3, Março, p.56-58.
SOWA, J. F. (2002) “Building, sharing, and merging ontologies”, AAAI Press / MIT press, p.3-41.
5° WSL / 5° FISL
Implementando Web Services com Software Livre
Claudimir Zavalik1, Guilherme Lacerda1, José Palazzo M.de Oliveira1
1
Instituto de Informática – Universidade Federal do Rio Grande do Sul (UFRGS)
Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brasil
[email protected],
guilherme@apoenasofwarelivre,com.br, [email protected]
Abstract. This paper illustrates the main concepts about Web Services
technology, it's architecture, and the description of the implementation
process from a Web Service under Free Software platform, using NuSOAP.
Resumo. Este trabalho apresenta os principais conceitos da tecnologia Web
Services, sua arquitetura e a descrição do processo de implementação de um
Web Service sob plataforma de Software Livre, usando NuSOAP.
1. Introdução
Existe atualmente uma grande variedade de sistemas de informações, distribuídos em
diferentes plataformas e usando várias tecnologias distintas em sua implementação.
Várias são as tecnologias desenvolvidas para a integração de sistemas de informação,
como comunicação por sockets, RMI e RPC. Com a popularização da linguagem XML,
tornou-se possível trocar informações de uma forma mais clara entre os aplicativos.
XML (eXtensible Markup Language) descreve uma classe de objetos chamados
"documentos XML" e parcialmente descreve o comportamento de programas de
computador que processam estes documentos (XML 2003). Como alternativa aos
métodos existentes para integração de sistemas, surgiu o conceito de Web Services.
Um Web Service é um sistema de software, identificado através de uma URI, na qual
interfaces públicas e contratos são definidos e descritos em XML. Estas definições
podem ser descobertas por outros sistemas de software. Estes sistemas podem então
interagir com o Web Service em uma maneira prescrita pela sua definição, usando
mensagens baseadas em XML e transportadas por protolocos da Internet (WSA 2003).
Entre as principais vantagens do uso de Web Services, podem ser citadas:
- Interface abstrata: os Web Services fornecem uma interface abstrata para acesso aos
métodos disponibilizados, ocultando detalhes de implementação do usuário do
serviço;
- Semântica acompanha dados: Ao invés de trafegarem somente os dados, a
comunicação entre o servidor e o cliente carrega consigo metadados;
- Portabilidade: Por se tratar de um padrão aberto, baseado em XML, garante-se a
portabilidade das mensagens mesmo sob diferentes plataformas de operação;
- Segurança: Opcionalmente, as informações trafegadas podem ser criptografadas;
- Utilização de recursos: Os Web Services são sistemas não invasivos, pois não
consomem recursos de comunicação enquanto em estado de espera.
O funcionamento de um Web Service presume que devam existir, no mínimo, dois
agentes trocando informações (um solicitante do serviço e um provedor do serviço).
35
36
5° WSL / 5° FISL
Existem também agentes de descobrimento de Web Services disponíveis na Web, que
funcionam como verdadeiros catálogos de serviços disponíveis. A Figura 1 apresenta a
arquitetura básica de Web Services, onde é percebida a interação que ocorre entre os
agentes citados.
Figura 1. Arquitetura básica de Web Services
A integração dos Web Services se dá sob vários protocolos abertos, em diferentes níveis
de abstração. Os protocolos utilizados para realizar esta comunicação entre diferentes
agentes estão dispostos em cinco camadas, conforme apresentado na Figura 2.
Figura 2. Protocolos de comunicação de Web Services
2. Bibliotecas para Web Services em Software Livre
Existem algumas bibliotecas que permitem o desenvolvimento de Web Services que são
distribuídas na modalidade Software Livre.
Entre as bibliotecas existentes, destacam-se a biblioteca PEAR (http://pear.php.net) e a
NuSOAP (http://dietrixh.ganx4.com/nusoap/index.php), ambas desenvolvidas em
linguagem PHP. NuSOAP é um grupo de classes PHP que permite aos desenvolvedores
criar e consumir serviços Web usando SOAP. NuSOAP não requer nenhuma extensão
especial de PHP, o que a torna utilizável por todos desenvolvedores PHP (NuSOAP
2003). Devido a sua facilidade de uso, os exemplos apresentados foram criados
utilizando a biblioteca NuSOAP. Para usar a biblioteca NuSOAP, é necessário
incorporar ao código da aplicação a vinculação do módulo nusoap.php.
5° WSL / 5° FISL
3. Web Services
Antes de descrever os Web Services, é necessário que se tenha uma clara definição de
quais serviços poderão ser disponibilizados, bem como as restrições de segurança que
devem ser aplicadas. Outro fator que deve ser modelado ao se desenvolver um Web
Service é o tratamento de exceções. Havendo qualquer erro, o Web Service deve
disparar uma falha SOAP, identificando a causa do problema.
Usando NuSOAP, a criação do Web Service é muito simples. Para tanto, é necessário
somente incluir a biblioteca e escrever o método de implantação. A Figura 3 apresenta o
exemplo de um simples Web Service, que recebe um valor e retorna o seu fatorial.
<?php
require_once('nusoap.php');
$s = new soap_server;
$s->register('fatorial');
function fatorial($numero){
// Valida o parâmetro recebido
if($numero < 1 ){
return new soap_fault('Client','','O número deve ser maior que zero.');
}
// Calcula o fatorial
$fatorial = 1;
for ($i = (int) $numero; $i>0; $i--)
$fatorial = $fatorial * $i;
return $fatorial;
}
$s->service($HTTP_RAW_POST_DATA);
exit();
?>
Figura 3. Web Service desenvolvido com PHP e NuSOAP
3.1 Acessando um Web Service com SOAP
Sabendo qual o Web Service que se deseja acessar e sua interface de comunicação, é
possível então acionar o serviço. É importante destacar que a implementação do acesso
não precisa ser desenvolvido necessariamente na mesma tecnologia que o Web Service.
A Figura 4 apresenta um simples cliente de Web Service, desenvolvido em PHP, usando
o pacote NuSOAP para acessar o Web Service fatorial.
<?php
require_once('nusoap.php');
$parametros = array('numero'=>5);
$clientesoap = new soapclient('http://192.168.1.1/test/fatorial.php');
$resultado
= $clientesoap->call('fatorial',$parametros);
if ($clientesoap->fault)
echo "Ocorreu um erro no Web Service - " . $clientesoap->faultstring;
else
echo "O fatorial do número é = ". $resultado;
?>
Figura 4. Cliente SOAP do Web Service fatorial
No exemplo apresentado, é fornecido o parâmetro "5" para o Web Service fatorial.
Alguns provedores de Web Services fornecem uma API específica para uso dos serviços,
com a finalidade de descrever os métodos e assinaturas, bem como fazer validações
prévias no cliente SOAP.
37
38
5° WSL / 5° FISL
4. Usando WSDL como linguagem de definição
WSDL (Web Services Description Language) fornece um modelo e um formato XML
para descrição de serviços Web. WSDL possibilita uma separação da descrição das
funcionalidades abstratas oferecidas por um serviço dos detalhes concretos da descrição
de um serviço, como "onde" e "como" as funcionalidades são oferecidas (WSDL 2003).
Com o uso de WSDL, o cliente não precisa saber qual a linguagem de programação ou
plataforma de execução em que o provedor de serviços está baseado.
A Figura 5 apresenta as mensagens trocadas em WSDL para o exemplo fatorial.
<message name="recebeNumero">
<part name="numero"
type="xsd:integer"/>
</message>
<message name="enviaResposta">
<part name="fatorial" type="xsd:float"/>
</message>
<portType name="fatorial_PortType">
<operation name="fatorial">
<input message="tns:recebeNumero"/>
<output message="tns:enviaResposta"/>
</operation>
</portType>
Figura 5. Especificação de mensagens em WSDL
5. Considerações Finais
O uso de Web Services permite um significativo ganho de produtividade, à medida que
permite que sistemas legados possam se integrar ao ambiente Web, disponibilizando
informações antes restritas ao seu ambiente de operação. São inúmeras as possibilidades
que se vislumbram com a utilização de Web Services. Eles podem ser utilizados,
também, como mecanismos de integração de sistemas que não estão necessariamente
disponibilizados para usuários na Web. A adoção da linguagem WSDL como padrão de
descrição de serviços que envolvam troca de informações entre sistemas Web garante a
transparência necessária para que os clientes do serviço implementem a interface,
conhecendo detalhes significativos para acesso ao serviço e omitindo detalhes do
funcionamento da aplicação provedora do serviço.
O desenvolvimento de Web Services usando ferramentas de Software Livre concede ao
desenvolvedor uma liberdade ampla, à medida que este dispõe de todo o código-fonte
da bilbioteca utilizada e pode incluir modificações nestas, customizando seus resultados
ou analisando transações solicitadas e realizadas em tempo de execução.
Referências
NuSOAP - SOAP Toolkit for PHP (2003), http://sourceforge.net.projects/nusoap/,
Outubro 2003.
Web Services Architecture
20021114/, Outubro 2003.
(2003),
http://www.w3.org/TR/2002/WD-ws-arch-
Web Service Description Language (2003), http://www.w3.org/TR/2003/WD-wsdl1220030303, Outubro 2003.
XML - eXtensible Markup Language 1.0 (2003), http://www.w3.org/TR/2000/RECxml-20001006, Outubro 2003.
5° WSL / 5° FISL
VRaptor - Simple And Quick Web Framework
Alexandre Freire , Paulo Silveira
1
Department of Computer Science
Institute of Mathematics and Statistics
University of São Paulo
{alex,paulo}@arca.ime.usp.br
vraptor.org
Abstract. This paper describes the development of VRaptor, a framework that
allows developers to create dynamic web applications quick and easily. Developed by Arca, VRaptor is free software, available under the Apache 2.0 license.
We will present motivations behind Arca’s undertaking to create yet another
web development framework for the J2EE specification. We will then describe
the framework’s architecture and it’s usage patterns. We will justify our architectural decisions based on our main objectives: keeping the framework simple,
clean, and easy to learn and use. We will briefly mention other free software
tools and frameworks that interact with VRaptor in some way .
1. Introduction
Web Application development has been the focus of many businesses and institutions
since only after a couple of year’s of the advent of the Internet. Today, many web application frameworks [7] are available to developers. Choices exist in various languages and
“flavors”. There is an overwhelming number of free software projects providing us with
tools for web development. When faced with the task of adopting an alternative to develop a system, an architect may have to consider solutions ranging from containers and
application servers to programming languages and frameworks. Some of the most known
open source and free software projects available today are PHP, Struts, WebWorks, Zope,
Tomcat, Jetty, and JBoss. Also, an even number of commercial offerings for frameworks
and application servers exists as well. This miscellanea of options makes it hard to decide
which project to use when it comes the time to develop a system.
“Arca” [1], a group of free software developers fostered by the Department of
Computer Science at IME/USP, has focused on web development since it’s foundation.
Having worked on many end user applications like Panda, Texugo, and Mico, Arca’s
developers have experimented with most of the choices in tools available today . During
the creation of these applications we strived to learn more about all of these technologies.
Together, the members of our group have developed for all of the most known frameworks
nowadays.
These frameworks all have very nice features and patterns, however, many of them
lean more to a declarative approach on programing instead of an imperative one. This
choice means using lots of configuration files (mostly XML metadata descriptors), which
in our opinion ends up cluttering the developers perception of what is really happening
in his application, increasing the learning curve for new comers to the framework, and
making applications harder to debug.
39
40
5° WSL / 5° FISL
Throughout our existence, our group has studied and discussed most of these
frameworks. We have had many ideas on how to make things quicker and easier for the
developer. “eXtreme Programming’ [4]’, our favorite methodology, influenced us when
idealizing what a framework had to do, since much of our development focus on XP practices. Faced with many choices we decided to create our own framework, one that had to
be agile, allowing it’s developers to test their code easily and refactor it mercilessly, and
at the same time had to be simple to understand and easy to learn.
Earlier this year we had the opportunity to develop a portal for SINAPE [2], the
National Symposium on Probability and Statistics organized by the Brazilian Association
for Statistics (ABE). We then decided to use the funds from this contract to sponsor the
development of this new framework. We also decided to use some XP practices when
developing the framework, adding features as the need for them arose in the portal.
And so VRaptor was born. Our main objectives with this framework are to keep
the code simple and clean, so as to encourage outside contribution, but most importantly,
to keep it simple to learn and use, so that new developers can choose to use it over all
the other available choices. Particularly, we want to provide good documentation in portuguese, to help the brazilian free software community.
2. Development
VRaptor was created to solve our development needs for the SINAPE portal. We developed the portal using the eXtreme programming methodology, therefore VRaptor had to
facilitate the practices we were following. We needed a framework that would grow organically from our “real-world” needs. We knew that our end-user portal would have to
accommodate changes easily, we knew that we would do the simplest thing we possibly
could to solve a particular problem and we knew that our code had to be kept consistent,
simple and clear.
We took all these premises in consideration when choosing how the developer
would use VRaptor, favoring a more imperative approach over the declarative one that
most frameworks today seem to prefer. We decided to keep configuration down to one
XML file, where the user coupled the components. Components themselves would be
completely decoupled, so as to facilitate testing.
New features were added added to the framework when the need for them arose,
keeping the design clean and easy to understand and use. We made a conscious effort
to postpone development of features we did not really need, therefore VRaptor does not
suffer from a flaw common to many frameworks, known as “feature overflow”. We believe
this makes the learning process much easier for a new developer.
Refactoring code created for VRaptor should also be easy, so we chose to use symbols from objects created by the programmer, like method and class names, in the configuration XML file. These symbols can easily be altered by an automated tool. Avoiding
much use of meta-data we empower the developer to welcome change, for he does not
have to modify lot’s of configuration files by hand when deciding to add new parameters
to a method, or to change a method name.
3. Objectives
We strived to achieve many objectives in VRaptor, we shall briefly discuss these goals
and why we chose them.
5° WSL / 5° FISL
3.1. Simplicity and ease of use
VRaptor does not offer many choises to the developer, we made this decision to avoid
confusing new users of the framework with configuration options. The XML configuration file is clean and consistent, there are not many ways to do the same thing, only
one “right” way. This reduces a common confusion, of how things work “under the covers”, that is present in the minds of many developers that are trying to learn how to use a
unfamiliar framework.
VRaptor has few main abstractions, Interceptors, Domains, Chains, and Views.
With a couple of these objects a developer can deliver complex logic in dynamic web
applications. By use of introspection in the framework’s engine we can allow these components to be loosely coupled, this permits easy component reuse and “on-the-fly” configuration.
Because components are decoupled from web-specific objects as well, tests are a
whole lot easier to write.
3.2. Avoiding “too much magic”
One of our main objectives is to avoid the known anti-pattern, present in many frameworks available today, called “too much magic” [5]. This anti-pattern states that when
a developer cannot understand how the framework interacts with his code he is awed by
what “seems to be the magic” that makes his application work.
This makes it really hard for the developer when a new bug is found in his application, most times he feels that things were working before and he doesn’t know what
changed that made the application behave differently.
In VRaptor it is clear when and where the framework will instantiate objects declared in the application, the developer knows how the framework will call the methods
defined in in his objects and how their lifecycle is controlled, he also knows how to get
instances of objects he needs.
3.3. A national alternative
Another of our objectives was to create a national alternative to all the international web
application frameworks available. We are currently working on documentation in portuguese and have recently made our first public release. The framework has been used to
develop a couple of “real-world” applications, including GUJ’s [3] new website.
4. Patterns and Paradigms
Applications developed with VRaptor follow a couple of architectural patterns and
paradigms, making the developer’s life easier [9].
4.1. Model View Controller
Model View Controller [6] breaks the application into three: the user input and output,
the modeling of our business logic and the application controller. These are well defined
parts in a VRaptor application.
VRaptor has built-in support for well know, free software, web view layers:
Velocity[?], Freemarker [?] and JSP. the model classes are written by the developer, and
the controller is VRaptor itself.
41
42
5° WSL / 5° FISL
4.2. Interceptors and Aspects
All application have some aspects that do not really belong to the core business logic.
Commonly known aspects are logging, security and persistency. Programming code related to these aspects should not be mixed with code that deals with business logic. In
VRaptor, the developer can choose to put this type of code in interceptors. Interceptors
are also responsible for the components dependecy configuration, as we will see in the
next section.
VRaptor provides some default interceptors, but the developer will also need to
write his own interceptors to make his application more robust.
4.3. Inversion Of Control
Inversion of Control addresses a component’s configuration and dependency resolution:
there is no need for a component to know exactly with which other components it will be
dealing with[8] . This configuration will be handled by the framework, VRaptor acts as a
component container, managing their lifecycle.
Newer web and Inversion of Control frameworks (like Apache Avalon, PicoContainer, or SpringFramework) support inversion of control through dependency injection,
writting some descriptors (mostly hard to read and long XML files) to tell the container
how it shall create and manage components. This is the declarative approach, as mentioned before.
VRaptor uses an imperative approach: dependency configuration must me done in
plain java code. This code goes inside the interceptors, which are responsible for preparing components that will be used by the business logic code. Note that the configuration
is still decoupled from the components themselves, if we need to change a component
that is being used by our business logic, we simply change the interceptor. There is no
need to touch the business logic at all.
5. Conclusion
We believe VRaptor is a real contender when considering a good framework for web application development. We are committed to providing a real alternative for the Brazilian
market and welcome any contributions from the community.
References
[1] Arca project - http://www.arca.ime.usp.br
[2] http://www.abe.org/sinape
[3] Grupo de Usuarios Java - http://www.guj.com.br
[4] [Beck 1999] - Extreme Programming Explained.
[5] Too-much magic anti-pattern - http://lsd.student.utwente.nl/jicarilla/TooMuchMagic
[6] [Model 1988] - ”The Model-View- Controller (MVC) ParadigmUser Interfaces” OOPSLA’88 Tutorial, ACM.
[7] Ralph E. Johnson. Components, Frameworks, Patterns. In ACM SIGSOFT Symposium
on Software Reusability, 1997.
[8] C. Szyperski, Component Software: Beyond Object-Oriented Programming, AddisonWesley, 1998.
[9] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of
Reusable Object-Oriented Software, Addison-Wesley, 1995.
5° WSL / 5° FISL
Sessão Técnica 3
SOFTWARE EDUCACIONAL
43
44
5° WSL / 5° FISL
5° WSL / 5° FISL
Vale4 - Software Livre para Ensino
Simão Sirineo Toscani
Faculdade de Informática – PUCRS
Departamento de Computação – UNILASALLE
[email protected]
Resumo. A linguagem Vale4 (V4) é distribuída como software livre e destina-se ao
ensino de programação concorrente. Ela permite praticar com os principais
mecanismos de sincronização e comunicação e pode ser instalada em praticamente
qualquer microcomputador. O artigo faz um contra-ponto entre V4 e as linguagens Java
e C, que também são usadas no ensino de programação concorrente.
Abstract. The Vale4 language (V4) is a free software conceived to be a concurrent
programming educational tool. V4 allows the practice with the main synchronizing and
communicating tools, can be ported to practically any microcomputer and offers good
debugging facilities. This paper contrasts the V4 language with Java and C, which are
also used to teach concurrent programming.
1. Introdução
Para ser considerada uma boa ferramenta de ensino, uma linguagem de programação concorrente
deve permitir a prática com os principais mecanismos de sincronização e comunicação existentes,
os quais vão desde operações básicas do tipo lock/unlock e block/wakeup, para sincronização em
baixo nível, até monitores e tasks, para sincronização em alto nível. Além disso, é importante que a
linguagem ofereça boas facilidades de depuração. A linguagem V4 satisfaz estes requisitos.
As outras linguagens disponíveis no mercado não oferecem este leque de ferramentas e,
além disso, não podem ser consideradas didáticas. A linguagem SR [Andrews 91], muito usada no
ensino de concorrência, não implementa o conceito de monitor. A linguagem Ada [Taft 97],
embora muito poderosa, se limita aos conceitos de task e rendezvous. Na linguagem Java fica
“tudo escondido” e, segundo Brinch Hansen, parece que seus projetistas ignoraram os resultados
das pesquisas em programação concorrente [Brinch Hansen 99]. As extensões da linguagem C
tampouco são satisfatórias; a biblioteca Pthreads [Costa 02], por exemplo, deixa muito a desejar
quanto ao nível e à segurança das construções oferecidas.
Este artigo faz uma breve apresentação das diferentes versões da linguagem V4, ilustrando
com exemplos as versões que implementam monitores e tasks. A clareza dos programas V4 é
realçada através de um pequeno contra-ponto com as linguagens Java e C.
A sintaxe da linguagem V4 é Pascal-like. O ambiente de programação foi implementado
por um compilador que gera código para uma máquina virtual e por um simulador dessa máquina.
A máquina virtual implementa por hardware (virtual) um conjunto apropriado de instruções e um
kernel de sistema operacional. Todo o sistema foi programado em SWI-Prolog [Wielemaker 97] e,
como tal, pode ser portado facilmente para diversas plataformas.
2. As versões da linguagem
A linguagem V4 oferece uma grande variedade de mecanismos. Embora o programador possa
utilizar simultaneamente (em um mesmo programa) todos os recursos da linguagem, é conveniente
vê-la, do ponto de vista didático, como se oferecesse 6 versões de uso.
Versão básica
Um programa V4 básico é um conjunto de variáveis globais, um conjunto de procedimentos
globais e um conjunto de processos. Não há mecanismo de sincronização. Como tal, os problemas
de sincronização e comunicação têm que ser resolvidos manualmente. Esta versão é útil para
45
46
5° WSL / 5° FISL
alertar o aluno sobre o problema das condições de corrida (race conditions) e ensinar os algoritmos
clássicos de exclusão mútua.
Versão básica++
É a versão anterior aumentada com as operações lock/unlock e block/wakeup(p), mais o tipo queue
e suas operações insert(p,Q), empty(Q) e first(Q), onde p é um inteiro e Q é uma variável tipo
queue. Os mecanismos desta versão permitem caracterizar muito bem as sincronizações
elementares, voltadas para compartilhamento de recursos e para comunicação.
class mesa
{ private int[] garfos = new int[5];
mesa()
// constructor
{ for (int i=0; i<=4; i++) garfos[i]=0; }
synchronized public boolean pega_garfos(int filosofo)
{ int lado;
if (filosofo==4) lado=0;
else lado=filosofo+1;
if (garfos[filosofo]==0 && garfos[lado]==0)
{ garfos[filosofo]=1;
garfos[lado]=1;
return true;
}
else return false;
}
synchronized public void libera_garfos(int filosofo)
{ int lado;
if (filosofo==4) lado=0;
else lado=filosofo+1;
garfos[filosofo]=0;
garfos[lado]=0;
}
}
class filosofo extends Thread
{ private int numero;
mesa m;
filosofo (int numero, mesa m)
{ this.numero=numero;
this.m=m;
this.setName("filosofo num " + numero);;
}
public void run()
{ while (true)
{ if (m.pega_garfos(this.numero))
{ System.out.println("filosofo num "+ numero + "comendo");
try{ Thread.sleep(Math.round(Math.random()*4000)); }
catch (InterruptedException e){}
m.libera_garfos(this.numero);
System.out.println("filosofo num "+ numero + "pensando");
}
else
{ System.out.println("filosofo num "+ numero + "faminto");
}
}
}
}
class fil
{ public static void main(String[] args)
{ mesa m = new mesa();
Thread f0 = new filosofo(0,m);
f0.start(); f1.start();f2.start();f3.start();f4.start();
}
}
Figura 1 - Jantar dos filósofos em Java
Versão com semáforos
É a versão básica aumentada com semáforos. Nessa versão, um programa é formado por um
conjunto de variáveis globais, incluindo variáveis semáforas, um conjunto de procedimentos e um
conjunto de processos. Os processos se sincronizam e formam filas através das operações P e V.
5° WSL / 5° FISL
47
Versão com operações send e receive
É a versão básica desprovida de variáveis globais e de procedimentos globais, mas aumentada com
um mecanismo para troca de mensagens. A comunicação pode ser síncrona ou assíncrona. Nesta
versão deixa de haver memória compartilhada entre os processos e cada processo passa a ter uma
caixa postal para comunicação com os demais.
Versão com monitores
Nesta versão, um programa é formado por procedimentos globais, um conjunto de monitores e um
conjunto de processos. Os monitores são implementados usando a sintaxe e a semântica definida
por Hoare [Hoare 74].
Versão multithread com tasks e rendezvous
Nesta versão, um programa é formado por um conjunto de tasks similares às tasks da linguagem
Ada [Taft 97]. A comunicação é realizada por rendezvous em procedimentos do tipo entry. Toda
task tem uma thread, denominada main, que pode criar novas threads através de comandos fork.
Qualquer thread pode “aceitar” (através de comandos accept) chamadas de entries, originando
esperas condicionais de múltiplas threads. O comando accept de V4 permite programar
comunicação síncrona não determinística, dispensando o uso de comandos tipo select.
3. Programas exemplos
Esta seção apresenta dois programas que permitem comparar V4 com as linguagens Java e C.
O jantar dos filósofos
O jantar dos filósofos é um problema clássico que ilustra situações de deadlock e de postergação
indefinida em sistemas concorrentes [Dijkstra 68]. As figuras 1 e 2 apresentam, respectivamente,
programas Java e V4 equivalentes, que simulam o comportamento de 5 filósofos. Ambos os
programas utilizam o conceito de monitor. Conforme referido, a linguagem V4 implementa o
conceito de monitor (sintaxe e semântica) tal como ele foi formalizado por Hoare [Hoare 74]. Por
seu lado, Java deixa muito a desejar a esse respeito [Brinch Hansen 99].
V4program
monitor mesa;
garfos: array[5] of integer init 0;
procedure pega_garfos(i:integer) returns boolean;
j: integer; % j é o vizinho da direita
{ if i=5 then j:=1 else j:=i+1;
if garfos[i]=0 & garfos[j]=0
then { garfos[i]:=1;
garfos[j]:=1;
pega_garfos:=true
}
else pega_garfos:=false
};
procedure libera_garfos(i:integer);
j: integer;
{ if i=5 then j:=1 else j:=i+1;
garfos[i]:= 0;
garfos[j]:= 0
}
end monitor;
process filosofo(i:= 1 to 5);
k: integer;
do forever
if mesa.pega_garfos(i)
then { nl; write('filosofo '); write(i); write('
k:=random(10); hold(k); % espera de 0 a 9
mesa.libera_garfos(i);
nl; write('filosofo '); write(i); write('
k:=random(10); hold(k)
}
else { nl; write('filosofo '); write(i); write('
k:=random(10); hold(k)
}
endprogram
Figura 2 - Jantar dos filósofos em V4
comendo');
unidades de tempo
pensando');
faminto');
48
5° WSL / 5° FISL
Busca do maior elemento de um vetor
O programa da fig. 3 permite comparar V4 com C estendido com threads. O programa é similar ao
apresentado em [Costa 02], o qual utiliza a biblioteca Pthreads. Por falta de espaço, o programa C
não é transcrito aqui. O que ele faz é buscar o maior elemento de um vetor criando threads
recursivamente. Cada thread recebe um vetor de tamanho n' e cria duas threads filhas, as quais
recebem um vetor de tamanho n'/2. Isto é feito até que um tamanho limite seja atingido. A fig. 3
mostra uma task V4 que utiliza o mesmo método. Esta task apresenta os mesmos conceitos
importantes apresentados no programa C (uso da técnica de divisão e conquista e criação dinâmica
de threads), porém de forma mais didática.
task xmax is
vet: array[10] of integer;
Imax: integer init 0;
% Índice do maior elemento do vetor
procedure getmax(i:integer; j:integer) returns integer;
dif, m, m1, id1, id2, max1, max2: integer;
{ dif:=j-i;
if dif=0 then getmax:=i
else if dif=1 then if vet[i]>vet[j] then getmax:=i else getmax:=j
else { m:=(i+j)/2; m1:=m+1;
id1:=fork;
if id1=myself then {max1:=getmax(i,m); quit};
id2:=fork;
if id2=myself then {max2:=getmax(m1,j);quit};
join(id1); join(id2);
if vet[max1] > vet[max2] then getmax:=max1
else getmax:=max2
}
};
thread main is
{ vet[1]:=1; vet[2]:=10; vet[3]:=3; vet[4]:=100; vet[5]:=2;
Imax:=getmax(1,5);
nl; write('Vmax = '); write(vet[Imax])
}
end xmax
Figura 3 - Busca do maior elemento de um vetor em V4
4. Conclusão
Este artigo apresentou uma ferramenta gratuita que parece ser adequada para o ensino de
programação concorrente. O kit de instalação do ambiente V4 pode ser obtido através da internet
[Vale4 04]. Na comparação com Java e C, os exemplos evidenciam que a linguagem V4 origina
programas mais simples e claros (portanto, mais didáticos). E simplicidade e clareza são itens
muito importantes, já que os conceitos e mecanismos da programação concorrente são complexos e
difíceis por si só. Certamente, a dificuldade de aprendizado aumenta quando os conceitos ficam
entremeados com detalhes de programação irrelevantes.
Referências
Andrews, G. Concurrent Programming: Principles and Practice. Benjamin Cummings, 1991.
Brinch Hansen, P. Java’s Insecure Parallelism. ACM SIGPLAN Notices 34, 4 (April), 1999.
Costa, C.; Stringhini, D.; Cavalheiro, G. Programação Concorrente: Threads, MPI e PVM. In:
Anais II Escola Regional de Alto Desempenho, São Leopoldo, 2002.
Dijkstra, E.W. Cooperating sequential processes. In Programming Languages. Ac. Press, 1968.
Hoare, C.A.R. Monitors: an operating system structuring concept. Comm. ACM 17, 10, 1974.
Taft, S.T., Duff, R.A. Ada 95 Reference Manual: language and standard libraries. SpringerVerlag, 1997. (Lecture Notes in Computer Science, Vol. 1246)
Vale4. Kit de instalação. Março de 2004. Disponível em www.inf.pucrs.br/~stoscani/V4.
Wielemaker, J. SWI-Prolog 2.7 Reference Manual. University of Amsterdam, Dept. of Social
Science Informatics. Amsterdam, The Netherlands, 1997.
5° WSL / 5° FISL
AdaptWeb : Ambiente de Ensino-Aprendizagem
Adaptativo na Web
José Palazzo M. de Oliveira1, Mariusa Warpechowski1, Daniela Leal Musa1,
Maria Angélica C. Brunetto2, Mario Lemes Proença Jr.2, Marcelo S. Pimenta1,
Cora H. F. Pinto Ribeiro1, José Valdeni de Lima1, Veronice de Freitas1,2, Viviane P.
Marçal1,2, Isabela Gasparini1,2, Marília Abrahão Amaral1,2
1
Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil
2 Departamento de Computação – Universidade Estadual de Londrina (UEL), Campus
Universitário, Londrina, PR, Brasil
{palazzo, mariusa, musa}@inf.ufrgs.br
Abstract. This paper presents the AdaptWeb® - Adaptive Web Learning
Environment - project. This project is intended to support the adaptive
authorship and presentation for Web-based courses. The used technology is
based in PHP and MySQL and the project is offered as free software licensed
under the GNU General Public License Version 2. The source code is
available at SourceForge. This open software may be used for new modules
development and research purposes. The AdaptWeb® environment was
validated by a real case study in a mathematics course at the State University
of Londrina. Now it is being released for academic use at UFRGS.
Resumo. Este artigo apresenta o ambiente AdaptWeb® - Ambiente de EnsinoAprendizagem Adaptativo na Web, voltado para a autoria e apresentação
adaptativa de disciplinas integrantes de cursos na Web. A tecnologia usada
para o desenvolvimento faz uso de software livre empregando PHP e MySQL
e está regido pela GNU General Public License Version 2. O seu código-fonte
está disponível no SourceForge e pode ser utilizado para desenvolvimento de
novos módulos e pesquisa. O AdaptWeb® foi validado através de estudo de
caso real, envolvendo uma disciplina da UEL (Universidade Estadual de
Londrina) e atualmente está sendo liberado para uso acadêmico na UFRGS.
1. Introdução
A utilização de aplicações hipermídia com diversas finalidades, tem-se difundido cada
vez mais. Entretanto, considerando que estas aplicações podem ser utilizadas por
usuários com características diferentes, em diversas condições de ambiente, torna-se
extremamente importante que exista a possibilidade de personalizar estas aplicações,
levando em conta as especialidades dos ambientes e principalmente do usuário. A
utilização da hipermídia adaptativa vem sendo proposta como meio de satisfazer
usuários com diferentes níveis de conhecimento, objetivos, background, experiências no
hiperespaço e preferências [Brusilovski 1998].
O ambiente AdaptWeb® foi motivado pela necessidade de oferecer uma ferramenta,
desenvolvida totalmente em software livre, que facilite a tarefa de organização e
49
50
5° WSL / 5° FISL
estruturação do material instrucional para a Web por parte dos professores [Freitas
2003]. No ensino superior é fato que muitas disciplinas são ofertadas para diferentes
cursos, porém com diferentes enfoques. O estudo de caso desenvolvido no AdaptWeb®
aborda a disciplina de Métodos Numéricos. Esta disciplina foi escolhida pois está
presente em diversos cursos superiores da área de exatas, sendo os interesses dos alunos
diferentes de acordo com a natureza do curso.
Este artigo encontra-se assim organizado: na seção 2 é descrito o ambiente AdaptWeb®,
a seção 3 apresenta a tecnologia utilizada para implementação do software e sua forma
de distribuição, na seção 4 é descrito o estudo de caso realizado e as conclusões são
apresentadas na seção 5.
2 – Ambiente AdaptWeb®
O Ambiente AdaptWeb® é voltado para a autoria e apresentação adaptativa [Freitas 03]
de disciplinas integrantes de cursos EAD na Web. O objetivo deste ambiente é permitir
a adequação de táticas e formas de apresentação de conteúdos para alunos de diferentes
cursos e com estilos distintos de aprendizagem, possibilitando diversas formas de
apresentação de cada conteúdo, de forma adequada a cada curso e às preferências
individuais dos alunos participantes. A figura 1 apresenta a arquitetura do ambiente.
Figura 1 - Arquitetura do Ambiente
1. Autoria: este módulo consiste na estruturação e organização do conteúdo
instrucional a ser disponibilizado para o usuário, conforme mostra a Figura 2. O
conteúdo de uma disciplina é organizado através de tópicos, de forma
hierárquica, em uma única estrutura adaptada para diferentes cursos. Desse
modo, para cada tópico, deve ser informado o nome do tópico, a descrição
resumida, os pré-requisitos, para qual curso este tópico será apresentado, bem
como o arquivo HTML correspondente.
2. Armazenamento: este módulo é responsável pelo armazenamento da estrutura de
dados resultante da fase de autoria, em arquivos no formato XML (Extensible
Markup Language) [W3C 04]. É criado um arquivo XML para a estrutura de
conceitos e um arquivo XML para a estrutura do material relacionado a cada
conceito.
3. Adaptação do Conteúdo: neste módulo o conteúdo é adaptado de acordo com as
características (curso, preferência pelo modo de navegação e o histórico da
navegação) do modelo do aluno.
5° WSL / 5° FISL
Figura 2 – Ferramenta de Autoria
4. Interface Adaptativa: responsável pela adaptação da navegação (tutorial ou livre)
e da apresentação do ambiente.
3 - Tecnologias utilizadas e distribuição do AdaptWeb®
Procurando tornar os resultados da pesquisa um elemento de difusão destas novas
metodologias, o ambiente foi desenvolvido totalmente em software livre e com
tecnologia voltada para a Web. O AdaptWeb® pode ser instalado em qualquer servidor
Web e foi implementado em PHP, banco de dados MySQL e linguagem XML. Estas
tecnologias foram escolhidas por serem de fácil aprendizado e também as mais usadas
no desenvolvimento de ferramentas para EAD. Além disso, por serem software livre
permitem a divulgação dos códigos-fonte, o que facilita o desenvolvimento e
aprimoramento do ambiente, permitindo que módulos já desenvolvidos sejam
incorporados diretamente em novas ferramentas.
A versão 0.9 beta do AdaptWeb® está instalada em Servidor Web Apache em ambiente
GNU/Linux e pode ser acessada em: http://adaptweb.homelinux.org/adaptweb/. Além
disso, o AdaptWeb® está disponibilizado para download no SourceFourge
[SourceFourge 2004], o qual já alcançou o segundo lugar em números de acessos e
downloads, na categoria “Computer Aided Instruction”. A disponibilização do código
fonte do AdaptWeb® no SourceForge permite que a comunidade usufrua do ambiente
AdaptWeb® e colabore no desenvolvimento de novos módulos e funcionalidades. O
código fonte em PHP, o script para criação do banco de dados em MySQL, bem como
uma disciplina exemplo, estão disponíveis no servidor CVS (Concurrent Versions
System) do SourceFourge. O CVS é um software criado para gerenciar as alterações
realizadas por múltiplos desenvolvedores em um mesmo conjunto de arquivos-fonte e
garante a integridade do código-fonte, ao mesmo tempo em que permite
desenvolvedores trabalhando de forma independente sobre o mesmo código.
O ambiente AdaptWeb® faz parte de um projeto em parceria com o Uruguai e
Argentina para desenvolvimento de adaptabilidade multicultural. Além disso, no
próximo semestre o AdaptWeb® será utilizado por professores do Instituto de
Informática - UFRGS, os quais participaram de uma apresentação do software e
mostraram-se bastante entusiasmados.
51
52
5° WSL / 5° FISL
4 – Estudo de Caso
Visando validar a funcionalidade do Ambiente AdaptWeb® foi realizado um estudo de
caso com um tópico da Disciplina de Computação Algébrica e Numérica do curso de
Bacharelado em Ciência da Computação da UEL [Brunetto 03]. Os cursos de
Matemática e Engenharia possuem a disciplina de Cálculo Numérico, cujo conteúdo
apresenta grande intersecção com o conteúdo da disciplina de Computação Algébrica e
Numérica. O tópico selecionado foi “Resolução de Sistemas Lineares”.
Uma avaliação do ambiente foi realizada com 31 participantes, alunos do quarto ano do
curso de Ciência da Computação da Universidade Estadual de Londrina. A metodologia
utilizada foi o questionário de satisfação e a análise de log do usuário gerado no
AdaptWeb®. Após a quantificação dos dados dos alunos, foram obtidos os seguintes
resultados: a) 90,32% acharam que a utilização do ambiente é fácil; b) 100%
consideram que o processo de aprendizagem dos comandos não é demorado; c) 61,29%
consideram que as informações existentes na tela atendem as suas necessidades; d)
93,55% acham fácil de lembrar como realizar ações no ambiente; e) 90,32% acreditam
que sabem navegar pelo ambiente.
Os resultados obtidos demonstraram que o ambiente foi planejado de forma a prover
facilidade de utilização e navegação, pois a aprendizagem do aluno é proporcional a sua
capacidade de navegar e utilizar o ambiente.
5 – Conclusões
A utilização de tecnologias baseadas em software livre é uma ótima escolha para o
desenvolvimento de sistemas pois permite a liberação do sistema e do seu código-fonte,
motivando a participação da comunidade em melhorias no desenvolvimento e
crescimento do software. O AdaptWeb® proporciona uma maior facilidade ao professor
na tarefa de organização e estruturação do material instrucional para a Web. Como
resultado, o conteúdo do curso é adaptado e apresentado aos alunos de acordo com o seu
perfil (nível de conhecimento, preferência de navegação, etc).
Referências
Brusilovski, Peter. Methods and Techniques of Adaptive Hypermedia. Adaptive
Hypertext and Hypermedia, Kluwer Academic Publishers, pp.1-43, 1998.
Extensible Markup Language-XML. Disponível em: http://www.w3.org/TR/REC-xml/.
Freitas, Veronice. Autoria Adaptativa de Hipermídia Educacional. Dissertação de
Mestrado. 2003. Instituto de Informática, UFRGS, Porto Alegre.
Freitas, Veronice et al. AdaptWeb: an Adaptive Web-based Courseware. In: ICTE 2002:
20-23 Nov. 2002, Badajoz, Espanha.
SourceFourge. Disponível em https://sourceforge.net/projects/adaptweb/, maio 2004.
Brunetto, Maria Angélica C. et al. AdaptWeb: um Ambiente para Ensino-aprendizagem
Adaptativo na Web. Educar em Revista, ISSN 0104-4060, n. 107, p. 175-198,
Curitiba, 2003.
5° WSL / 5° FISL
AVALWEB – Sistema interativo para gerência de questões e
aplicação de avaliação na Web
Carlos Morais 1, 2 , Jose Valdeni de Lima 1, 2 , Sérgio Roberto Kieling Franco 2.
1
Caixa Postal 15.064 – 91.501-970 – Porto Alegre – RS – Brazil
2
Programa de Pós-Graduação de Informática na Educação (PPGIE/UFRGS),
{cmorais, valdeni}@inf.ufrgs.br, [email protected]
Abstract. This paper introduces open source software for studying assessment
process for distance learning students. Many assessment tools available in the
market were analyzed for. Based on this analysis, a query and assessment
application was proposed which allows the student to realize self -evaluation,
immediate feedback from the results and integration with the questions
management system. When accessing this module, the student may reach
information such as explanations when a mistake is perceived during the
answering process. We emphasize more the learning/teaching process then the
assessment process. Finally, a prototype was implemented to evaluate the
viability of the ideas proposed for this evaluation model. The background
concepts are far broader and pliable then the existing version of the
actual implementation.
Resumo. Este artigo apresenta uma ferramenta desenvolvida com software livre aplicado
ao estudo dos processos de avaliação de alunos em ambiente de Ensino a Distância. Para
tanto, foram analisadas várias ferramentas de avaliação disponíveis no mercado. Com
estas análises, foi modelado o sistema de gerência de questões e avaliações. O sistema
permite ao aluno a auto-avaliação, com retorno imediato do resultado, integrando o
sistema de gerência de questões com explicações do sucesso ou erro nas respostas, dando
ênfase mais no processo de ensino/aprendizagem do que na avaliação propriamente dita.
Enfim, foi implementado um protótipo demonstrando a viabilidade das idéias presentes no
modelo de avaliação aqui apresentado. A proposta conceitual estabelecida para o modelo
é bem mais ampla e flexível do que a atual versão da implementada.
1. Introdução
O apelo do uso da tecnologia na área de educação é tão marcante que alguns observadores
arriscam afirmar que o e-learning ou ensino eletrônico é a mais nova onda da Internet, depois
do comércio eletrônico. O IDC (International Data Corporation) estima que o mercado de
treinamento à distância por meio digital vai crescer mundialmente cerca de 69% ao ano. Com
esse fator de crescimento, o setor deve sair de um patamar de modestos 2 bilhões de dólares
em 1999 para 23 bilhões de dólares em 2004. De acordo com estas previsões, a demanda atual
e futura desta área justifica a criação de ferramentas que possam ser aplicadas neste contexto
[MOR 2001]. Além do enorme crescimento previsto para ensino a distância, a necessidade do
desenvolvimento de novas ferramentas decorre da constatação de que as idéias por trás dos
sistemas ainda não estão consolidadas e o número de boas experiências no uso do computador
no processo de ensino/aprendizagem é menor do que a sociedade poderia esperar. Em vista dos
53
54
5° WSL / 5° FISL
benefícios que podem ser obtidos, fica evidente a necessidade e oportunidade do
desenvolvimento de técnicas e ferramentas que proporcionem a elaboração de avaliações por
parte dos professores de forma que possam ser colhidos melhores resultados através de sua
aplicação. O tempo e esforço necessários para produzir ferramentas de aprendizado e
avaliações on-line podem ser substanciais. Esta dificuldade está presente especialmente em
determinadas áreas, porque técnicas de avaliação não podem ser extraídas diretamente de livros
texto e materiais de cursos [REN 2000].
2. Estado-da-arte
Existem diversos ambientes e ferramentas específicas que abordam como complemento ou de
forma única o aspecto de avaliação dos alunos. Para melhor embasamento, foram analisados
produtos considerados líderes em seu segmento de mercado com fortes características
avaliativas. Através dos ambientes e ferramentas apresentados, pode -se observar que existem
diversos enfoques sobre a questão da avaliação, mas de todas as formas, também há
determinado padrão nas avaliações, como os tipos de questões apresentadas para os alunos. Os
principais sistemas existentes de avaliação computadorizada são parte de ambientes Computer
Based Training (CBT) e pacotes de autoria multimídia como o Asymetrix Toolbook [TIN 97].
Estes sistemas normalmente vêm com interface gráfica de autoria e suporte a bancos de dados
de cursos, no entanto, cada um destes sistemas possui seus próprios “padrões” (por exemplo,
plataformas, linguagens de autoria, representação interna dos dados). Além disto, são muito
caros para serem utilizados em larga escala, como no ambiente universitário e seus custos de
desenvolvimento também são excessivamente altos.
2.1 Avaliação em ambientes completos
Para validar as idéias propostas e pesquisar os ganhos obtidos com a utilização de uma
ferramenta com abordagem educacional, inicialmente foram analisados aspectos que tratam da
avaliação de alunos, tanto em ambientes completos de educ ação à distância (Aulanet, WebCt e
TopClass) como em ferramentas específicas para avaliação (Question Mark Perception, Hot
Potatoes e Quiz Center) [CAR 2001] [MOC 2002] e uma ferramenta de autoria multimídia que
possibilita a criação de questionários na Web (Asymetrix Toolbook ). As comparações entre as
ferramentas acima citadas foram realizadas em [CAR 2001] [MOC 2002].
3. Ferramenta AvalWeb
Este seção apresenta a seguir alguns conceitos e a metodologia do sistema apresentado,
naturalmente, não é necessário usar equipamentos de processamento de dados para organizar,
selecionar e arquivar questões. Estas tarefas são rotineiras e podem ser feitas à mão [BLO 83].
Entretanto, há um ponto – que deve ser determinado em cada situação – em que a economia de
tempo e o aumento no nível de exatidão no arquivamento e na manutenção da ordem tornam o uso
de computadores um instrumento auxiliar precioso a um sistema de avaliação. Seu uso elimina a
dificuldade ou o desconforto que muitos professores sentem quando solicitados a realizar a análise
estatística dos testes. A máquina altera o papel do professor, que passa de produtor a consumidor
de dados de análise de testes e de itens [BLO 83]. O AvalWeb é um sistema que possui como foco
principal o gerenciamento de questões e aplicação de avaliações via Web com base em requisições de
professores. Também possui um módulo de auto-avaliação, com retorno imediato para o aluno, que
integra o sistema de gerência de questões dando ênfase mais no processo de ensino/aprendizagem
do que na avaliação propriamente dita.
O ensino resultante de autênticas tarefas em um ambiente aberto não é fácil de avaliar com testes
tradicionais ou instrumentos existentes, portanto uma das preocupações do AvalWeb é fornecer
5° WSL / 5° FISL
subsídios para ajudar o proces so de avaliação através de dados estatísticos [SAF 2000]. A avaliação
inclui uma grande variedade de dados, superior ao rotineiro exame escrito final [HAY 97]. Por este
motivo, o AvalWeb também procura colher diversas informações adicionais que colaboram para
este propósito como, por exemplo, o tempo gasto pelo aluno para responder uma ou um conjunto
de questões. O modelo proposto é baseado em uma ferramenta e não possui nenhum tipo de
característica que irá assegurar automaticamente a qualidade dos cursos que serão oferecidos
através de sua utilização. Existem diversas ferramentas e serviços disponíveis para finalidades
correlatas mais abrangentes e que podem ser agregados, complementados e adaptados ao cenário
obtido como resultado deste trabalho de pesquisa [CAR 2001].
3.1 Arquitetura do Sistema
A arquitetura proposta utiliza tecnologia de software livre para o AvalWeb é mostrada
graficamente na figura 1. O acesso para alunos e professores ocorre através de requisições http
para o servidor, que interage com o código PHP, que por sua vez faz o acesso aos dados
armazenados no banco de dados Mysql [CAR 2001], ambos estão relacionados com .
Figura 1. Arquitetura do Sistema AvalWeb
O modelo proposto está baseado na arquitetura do tipo cliente-servidor, onde o servidor Web
representa a figura do banco de questões e alunos e professores são representados através de
clientes utilizando seus navegadores. O código PHP está mesclado com códigos HTML, no
entanto, o conteúdo em PHP não é visível ao usuário, sendo processado no servidor [CAR
2001]. Não é razoável esperar que os professores tenham tempo ou treino estatístico necessário
à consecução de uma análise de itens e de testes. Além disso, muitos deles não estão,
justificadamente, interessados em adquirir esta habilidade. Portanto, de maneira geral, os
professores não submetem seus testes a uma análise técnica, apesar de um sistema formal de
avaliações exigir que esta análise seja feita. O acesso à ferramenta via WEB e as informações
relativas aos alunos, professores e demais tabelas do sistema são armazenada no servidor.
3.2. Público envolvido
O AvalWeb pode ser aplicado aos dois últimos cenários sugeridos anteriormente, podendo ser
utilizado como ferramenta de apoio para professores do ensino tradicional ou como complemento
a cursos fornecidos totalmente via WEB [CAR 2001].
Apesar de já ter sido testada em alguns casos reais, a utilização da metodologia deve ser
intensificada para melhor avalia ção e refinamento. Para isso, é imprescindível realizar a
55
56
5° WSL / 5° FISL
validação com professores e também com um maior número de alunos. Com base na estrutura
dos documentos e nos contextos, é definida a estrutura de navegação do sistema, especificando
o relacionamento entre documentos e os caminhos de acesso às funções, permitindo ao sistema
interagir com outros sistemas. Estando definidas as estruturas de dados e de navegação do
sistema, com isso serão analisados o comportamento dinâmico de documentos e links e como
será realizada a integração entre documentos e bancos de dados. Para que todo esse processo
aconteça no plano operacional, há necessidade de que, a partir de fundamentos teóricos
claramente identificados e de mecanismos de exercícios e avaliações coerentes e eficazes, se
promova à necessária mudança de consciência, de métodos, de instrumentos e de perspectivas.
Isto implica, além de análise crítica, capacidade de formular propostas alternativas. Pretende-se
efetuar uma integração do AvalWeb com outros Sistemas na Web utilizando os tradicionais links
de interesses dos usuários, o que torna o acesso à informação uma tarefa difícil e demorada. A
principal causa desta situação é a falta de estruturação dos dados e a ausência de uma
representação semântica dos mesmos. A Web Semântica surge para facilitar o acesso à
informação através da estruturação e da representação semântica dos dados, aumentando assim
a eficiência e precisão nas pesquisas efetuadas pelos usuários. Neste sentido, esta é uma
proposta alternativa , que, aplicável para o ensino, e para um projeto EAD, pode ser considerada
também uma visão de avanço do aprendizado, e uma alternativa para contribuir na busca de
novos caminhos no contexto da pesquisa e inovação.
References
[BLO 83]
BLOOM, Benjamim S. et al. Manual de avaliação formativa e somativa do
aprendizado escolar. 1 ed. São Paulo: Pioneira, 1983. 307 p.
[CAR 2001]
CARDOSO, Rodrigo Ferrugem. AvalWeb - Sistema interativo para gerência de
questões e aplicação de avaliações na Web 2001. Dissertação (Mestrado em
Ciência da Computação) – Instituto de Informática, Universidade Federal do Rio
Grande do Sul, Porto Alegre.
[HAY 97]
HAYDT, Regina Cazux. Avaliação do processo Ensino -Aprendizagem. São
Paulo: Ática. 1997.
[MOC 2002] MORAIS, Carlos Tadeu Q. de, Hyper-Automaton: Avaliação Interativa de
Alunos em Cursos na WEB Baseado em Autômatos Finitos 2002. Dissertação
(Mestrado em Ciência da Computação) – Instituto de Informática, Universidade
Federal do Rio Grande do Sul, Porto Alegre.
[MOR 2001] MOREIRA, Maria Isabel. “O tema de hoje é e-learning”. Info. Exame. N. 181.
Abril de 2001. p. 78.
[REN 2000]
RENSHAW, Anthony A. et al. An Assessment of On-line Engineering Design
Problem Presentation Strategies. IEEE transactions on education. New York. v.
43, n. 2, p. 83-91. May 2000.
[SAF 2000]
SAFOUTIN, Michael J. et al. A Design Attribute Framework for Course
Planning and Learning Assessment. IEEE transactions on education. New
York. v. 43, n. 2, p. 188-194. May 2000.
[TIN 97]
TINOCO, Lúcio C. et. al. On-line evaluation in WWW-based Courseware. In:
Communications of ACM. p. 194-198.SIGCSE 97. 1997.
5° WSL / 5° FISL
Sessão Técnica 4
SEGURANÇA
57
58
5° WSL / 5° FISL
5° WSL / 5° FISL
Detectando Intrusões na Máquina Virtual User-Mode Linux
Marcos Laureano, Carlos Maziero, Edgard Jamhour
Programa de Pós-Graduação em Informática Aplicada
Pontifícia Universidade Católica do Paraná
80.215-901 Curitiba – PR, Brasil
{laureano,maziero,jamhour}@ppgia.pucpr.br
Resumo: Os sistemas de detecção de intrusão monitoram continuamente a atividade de
um sistema ou rede, buscando evidências de intrusões. Entretanto, detectores de
intrusão baseados em host podem ser adulterados ou desativados por invasores bem
sucedidos. Este trabalho apresenta uma arquitetura que visa proteger detectores de
intrusão baseados em host através de máquinas virtuais. A proposta aqui apresentada
usa o isolamento de espaços de execução provido por um ambiente de máquinas
virtuais para separar o detector de intrusão do sistema a monitorar. Em conseqüência,
o detector de intrusão torna-se invisível e inacessível a eventuais intrusos. Os testes
realizados mostram a viabilidade dessa solução.
Palavras-chave: detecção de intrusão, máquinas virtuais, segurança, sistemas
operacionais de rede.
Abstract: Intrusion detection systems continuously watch the activity of a network or
system, looking for intrusion evidences. However, host-based intrusion detectors may
be tampered or disabled by successful intruders. This work presents an architecture
aimed to protect intrusion detectors by means of virtual machines. The proposal
presented here uses the execution space isolation provided by a virtual machine
environment to separate the intrusion detector from the system to monitor.
Consequently, the intrusion detector becomes invisible and inaccessible to intruders.
The evaluation tests showed the viability of the proposal.
Keywords: intrusion detection, virtual machines, operating systems, security.
1. Introdução
Diversas ferramentas contribuem para aumentar a segurança de um sistema de computação,
entre as quais se destacam os sistemas de detecção de intrusão. Tais sistemas monitoram
continuamente a atividade de um ambiente computacional, buscando evidências de intrusões.
Máquinas virtuais podem ser usadas para melhorar a segurança de um sistema computacional
contra ataques a seus serviços [Chen 2001]. O conceito de máquina virtual foi definido nos anos 60; no
ambiente IBM VM/370, uma máquina virtual propiciava um ambiente de execução exclusivo para cada
usuário [Goldberg 1973]. O uso de máquinas virtuais vem se tornando interessante também em
sistemas computacionais modernos, devido a suas vantagens em termos de custo e portabilidade
[Blunden 2002]. Exemplos de ambientes de máquinas virtuais de uso corrente incluem o sistema
VMWare [VMWare 1999] e o UML – User-Mode Linux [Dike 2000]. Um uso freqüente de sistemas
baseados em máquinas virtuais é a chamada consolidação de servidores: ao invés de usar vários
equipamentos fisicamente separados, faz-se uso de apenas um equipamento, sobre o qual várias
59
60
5° WSL / 5° FISL
máquinas virtuais isoladas entre si hospedam diferentes sistemas operacionais convidados, com suas
aplicações e serviços.
Este trabalho apresenta a proposta e implementação de uma arquitetura destinada a proteger
detectores de intrusão baseados em host, através da aplicação do conceito de máquina virtual. A
proposta faz uso do isolamento de espaços de execução provido por um ambiente de máquinas virtuais
para separar o detector de intrusão do sistema a monitorar. Essa separação protege o detector de
intrusão, tornando-o invisível e inacessível aos processos dos sistemas operacionais convidados (e,
portanto, a eventuais intrusos).
2. Detecção de intrusão
Um sistema de detecção de intrusão (IDS – Intrusion Detection System) continuamente
coleta e analisa dados de um ambiente computacional, buscando detectar ações intrusivas. Em relação
à origem dos dados analisados, existem duas abordagens básicas para a detecção de intrusão [Allen
1999]: detectores baseados em rede (NIDS – network-based IDS), que analisam o tráfego de rede
dos sistemas monitorados, e detectores baseados em host (HIDS – host-based IDS), que monitoram a
atividade local em um host, como processos, conexões de rede, chamadas de sistema, arquivos de log,
etc. A maior deficiência dos detectores baseados em host é sua relativa fragilidade: para poder coletar
dados da atividade do sistema, o detector (ou um agente do mesmo) deve ser instalado na máquina a
monitorar. Esse software pode ser desativado ou modificado por um intruso bem sucedido, para
esconder sua presença e suas atividades.
As técnicas usadas para analisar os dados coletados buscando detectar intrusões podem ser
classificadas em dois grupos: detecção de assinatura, quando os dados coletados são comparados
com uma base de padrões (assinaturas) de ataques conhecidos, e detecção de anomalia, quando os
dados coletados são comparados com dados previamente obtidos sobre o comportamento normal do
sistema. Desvios da normalidade são então tratados como ameaças. Uma forma de detectar intrusões
é através da análise de seqüências de chamadas de sistema executadas pelos processos, pois estas
constituem uma rica fonte de informação sobre a atividade de um sistema. Vários trabalhos científicos
descrevem técnicas para detecção de anomalias usando esse tipo de informação. Nessa proposta foi
utilizado o algoritmo apresentado em [Forrest 1996, Hofmeyr 1998].
3. Alterações Propostas
Através de modificações no monitor de máquinas virtuais é possível coletar, de forma
transparente, informações sobre a atividade de cada sistema operacional convidado, incluindo seus
usuários, processos, conexões de rede, etc. Essa informação é então enviada para um IDS externo ao
ambiente, executando fora do sistema operacional convidado. Fazendo uso de dados previamente
armazenados sobre o comportamento do sistema (criados a partir de execuções anteriores), o IDS
pode detectar comportamentos anômalos em usuários e/ou processos, ou detectar indícios claros de
atividades suspeitas. Se há suspeita de uma intrusão, um sistema de resposta pode agir de forma a
impedi-la ou neutralizá-la. Essa funcionalidade pode ser facilmente implementada interceptando as
chamadas de sistema emitidas pelos processos do sistema operacional convidado.
4. Implementação e resultados
Um protótipo da arquitetura proposta foi implementado em uma plataforma Linux, usando o
monitor de máquinas virtuais UML – User-Mode Linux [Dike 2000]. O UML foi modificado para
permitir extrair dados detalhados do sistema convidado, como as chamadas de sistema emitidas pelos
processos convidados. A comunicação entre o monitor UML e os processos externos foi implementada
por pipes nomeados (desta forma o sistema operacional hospedeiro controla o fluxo de dados entre o
monitor e os demais módulos). O hardware usado nos experimentos foi um sistema PC com CPU
5° WSL / 5° FISL
61
Athlon XP 1600 e 512 MBytes de RAM. O sistema hospedeiro usado o Suse Linux Professional 9.0
(kernel 2.4.21), e como sistema convidado foi usado um Debian GNU/Linux 2.2 com kernel 2.6.1.
O sistema proposto tem dois modos de operação: um modo de aprendizagem e um modo de
monitoração. Quando operando no modo de aprendizagem, todos os processos executando no sistema
convidado e seus respectivos usuários são registrados como usuários e processos autorizados, assim
como as seqüências de chamadas de sistema. Quando operando no modo monitoração, o módulo de
detecção de intrusão recebe dados sobre o sistema convidado do monitor de máquina virtual e os
compara com os dados previamente armazenados.
Algumas medidas de tempo foram efetuadas sobre comandos básicos de usuário no sistema
convidado, para permitir avaliar o impacto da arquitetura sobre o desempenho do sistema. O tempo de
execução dos comandos ps, find, ls e who foram medidos em quatros situações distintas: a) no
sistema hospedeiro, b) no sistema convidado original, c) no sistema convidado em modo aprendizagem
e d) no sistema convidado em modo monitoração. Cada experimento foi repetido 10 vezes, com
coeficientes de variação inferiores a 5% em todas as medidas.
A tabela 1 apresenta os tempos médios de execução para cada comando e seus custos
relativos. O número de chamadas de sistema invocadas por cada processo também é apresentado.
Observa-se que os tempos de execução no sistema convidado (linha b) são muito superiores aos
observados no sistema hospedeiro (linha a); essa diferença é devida ao alto custo de virtualização
apresentado pelo UML. Também são significativos os custos impostos pelas modificações no monitor
de máquina virtual para interagir com os mecanismos externos de aprendizagem, monitoração e
resposta (linhas c e d). Esse custo é devido à implementação realizada não estar otimizada.
Tabela 1. Tempos médios de execução (em milissegundos)
Comando
ps –ef
# chamadas de sistema
(a) sistema
tempo
hospedeiro
tempo
(b) sistema
custo
convidado
relativo a (a)
tempo
(c) modo
custo
aprendizado
relativo a (b)
tempo
(d) modo
custo
monitoração
relativo a (b)
925
22
find /
>/dev/null
6958
41
ls -laR / >/dev/null
who –B
18096
224
166
2
40
146
371
13
82%
256%
123%
550%
67
355
797
33
67%
143%
115%
154%
70
388
819
16
75%
166%
121%
23%
Adicionalmente, para avaliar qualitativamente a efetividade da arquitetura em detectar e
bloquear intrusões, alguns testes foram realizados usando rootkits populares na Internet (disponíveis
em http://www.antiserver.it/Backdoor-Rootkit/).
Os rootkits modificam comandos do sistema operacional para impedir a detecção de intrusos
(ocultando os processos, arquivos e conexões de rede do intruso) e para roubar informações digitadas
como logins e senhas (através de modificações em comandos como telnet, sshd e login).
Todas as ferramentas disponíveis em todos os rootkits indicados foram executadas com parâmetros
default e foram detectadas em todas as execuções. Os testes evidenciaram a efetividade e
complementaridade de ambos os mecanismos implementados pelo sistema: o mecanismo de detecção
de intrusão detecta e impede a execução de programas conhecidos, mas adulterados, enquanto o
controle de acesso impede a execução de programas desconhecidos, ou de programas lançados por
usuários desconhecidos ou não-autorizados.
62
5° WSL / 5° FISL
5. Trabalhos relacionados
A referência [Dunlap 2002] descreve uma experiência de uso de máquinas virtuais na
segurança de sistemas. A proposta define uma camada intermediária entre o monitor e o sistema
hospedeiro, denominada Revirt. Essa camada captura os dados enviados pelo processo syslogd (o
daemon padrão Unix que gerencia mensagens de log) do sistema convidado e os envia ao sistema
hospedeiro para armazenamento e futura análise. Entretanto, se o sistema convidado for invadido, o
processo syslogd pode ser terminado ou subvertido e as mensagens de log podem ser manipuladas
para ocultar o invasor, tornando o sistema sem efeito.
O trabalho que mais se aproxima de nossa proposta está descrito em [Garfinkel 2003]. Ele
define uma arquitetura para a detecção de intrusão em máquinas virtuais denominada VMI-IDS
(Virtual Machine Introspection Intrusion Detection System). Nossa proposta permite analisar
processos isolados, detectando comportamentos anômalos e bloqueando intrusões provindas de
processos comprometidos. Dessa forma, perturbações nos demais processos convidados são
minimizadas. Além disso, não é necessário suspender ou reiniciar a máquina virtual em caso de
intrusão. Outra característica exclusiva de nossa proposta é o uso de um modelo de autorização (ACL)
para usuários e processos construído automaticamente durante a fase de aprendizado do sistema.
6. Conclusão
O objetivo principal do projeto, restringir a execução de processos suspeitos na máquina virtual
e conseqüentemente evitar o comprometimento do sistema, foi alcançado com o protótipo atual.
Todavia, trabalhos complementares devem ser realizados para melhorar o desempenho dos
mecanismos atuais de detecção e resposta, e diminuir o custo imposto às aplicações. No momento
estamos estudando melhorias no código do UML e nos algoritmos implementados.
Refe rências
Allen J. et al. State of the Practice of Intrusion Detection Technologies. Technical Report
CMU/SEI-99-TR028. Carnegie Mellon University, 1999.
Blunden B. Virtual Machine Design and Implementation in C/C++. Wordware Publ. Plano, Texas
– USA, 2002.
Chen P., Noble B. When Virtual is Better than Real. Proceedings of the Workshop on Hot Topics in
Operating Systems – HotOS, 2001.
Dike J. A User-mode port of the Linux Kernel. Proceedings of the 4th Annual Linux Showcase &
Conference. Atlanta – USA, 2000.
Dunlap G. et al. ReVirt: Enabling Intrusion Analysis through Virtual-Machine Logging and
Replay. Proceedings of the Symposium on Operating Systems Design and Implementation, 2002.
Forrest S., Hofmeyr S., Somayaji A. A sense of self for Unix processes. Proceedings of the IEEE
Symposium on Research in Security and Privacy, 1996.
Garfinkel T., Rosenblum M. A Virtual Machine Introspection Based Architecture for Intrusion
Detection. Proceedings of the Network and Distributed System Security Symposium, 2003.
Goldberg R. Architecture of Virtual Machines. AFIPS National Computer Conference. New York –
NY – USA, 1973.
Hofmeyr S., Forrest S., Somayaji A. Intrusion Detection using Sequences of System Calls. Journal
of Computer Security, 6:151–180, 1998.
VMware Inc. VMware Technical White Paper. Palo Alto – CA – USA, 1999.
5° WSL / 5° FISL
TuxGuardian: Um firewall de host livre voltado para o
usuário final
Bruno Castro da Silva
Instituto de Informática – Universidade Federal do Rio Grande do Sul
Caixa Postal 15064 – 90501-970 Porto Alegre, RS
[email protected]
Abstract. This article describes the implementation of TuxGuardian, a host firewall developed after the observation that Linux security applications were not
tailored for lay users. By using the security mechanisms adopted in the Linux kernel 2.6, TuxGuardian is able to implement access control policies to the
network resources, controlling every application that tries to transfer data over
the network. This firewall has been developed in a three-layered architecture of
independent modules and is able to operate with or without user intervention.
Also, TuxGuardian’s modular design eases the task of adding new features and
functionality, specially since it’s distributed under the GNU/GPL license.
Resumo. Este artigo descreve a implementação do TuxGuardian, um firewall
de host desenvolvido a fim de possibilitar a gerência de segurança por parte de
usuários leigos. Através da utilização de mecanismos de segurança presentes
no kernel 2.6 do Linux, o TuxGuardian possibilita a implementação de políticas
de controle de acesso aos recursos de rede. Desta maneira, é capaz de identificar e gerenciar aplicações que tentam acessar a rede, impedindo que aplicativos maliciosos possam gerar ou receber tráfego pela Internet. O firewall
foi desenvolvido na forma de módulos independentes, em uma arquitetura de
três camadas, e é capaz de operar com ou sem o auxílio do usuário. O design
modular do TuxGuardian, licenciado pela GNU/GPL, também permite a fácil
expansão de suas funcionalidades.
1. Introdução
A crescente popularização da Internet e dos serviços disponibilizados através da rede fez
com que a busca por sistemas seguros se tornasse uma necessidade indiscutível. Prova
disso é a ampla difusão de mecanismos de controle de tráfego, tais como firewalls e sistemas de detecção de intrusão. Recentemente um novo mecanismo de segurança, conhecido
pelo nome de “Firewall de Host”, passou a ser adotado em inúmeras situações. Um firewall de host nada mais é do que um mecanismo de fácil operação desenvolvido com o
intuito de proteger individualmente cada computador. Em oposição aos dispositivos convencionais de segurança, como aqueles baseados na filtragem de pacotes, os firewalls de
host tornam o computador seguro através do controle de quais aplicações têm autorização
para receber e transmitir dados pela rede.
Através de um estudo envolvendo os aplicativos de segurança existentes para Linux, constatou-se que não existem soluções satisfatórias que atendam às expectativas do
usuário final ([Silva, 2004]). Por essa razão, foi dado início ao desenvolvimento um firewall de host extensível e de fácil utilização, chamado TuxGuardian.
63
64
5° WSL / 5° FISL
O TuxGuardian foi desenvolvido para plataforma Linux e é software livre.
Para download ou informações mais detalhadas sobre o projeto, consulte o site
http://www.inf.ufrgs.br/˜bcs/tuxguardian.
2. Descrição da ferramenta implementada
2.1. Arquitetura de três camadas
O TuxGuardian foi desenvolvido de maneira modular, o que significa que existem várias
componentes que cooperam para que a funcionalidade do firewall seja obtida. Foram
especificadas três camadas distintas, cada uma com uma tarefa bem determinada, assim
como um protocolo de comunicação utilizado na troca de informações entre essas camadas.
O módulo de segurança é a camada do TuxGuardian que opera em mais baixo
nível, fornecendo ao firewall a capacidade de monitorar aplicações que tentam acessar a
rede, tanto como clientes quanto como servidoras.
A segunda camada é implementada na forma de um daemon, e é responsável por
armazenar as informações a respeito de quais aplicativos são considerados confiáveis para
acessar a rede. O daemon é um programa de usuário que é contatado pelo módulo de
segurança sempre que alguma decisão crítica de segurança precisa ser tomada.
O frontend é a terceira camada do TuxGuardian, e seu objetivo principal é fornecer
os meios necessários para que possa haver interação em tempo real com o usuário. O
frontend é uma peça opcional para o funcionamento do firewall de host, e seu uso é
determinado pelas necessidades de cada usuário ou administrador.
2.2. O módulo de segurança
O módulo de segurança nada mais é do que um módulo carregável convencional do Linux.
A principal função do módulo de segurança é detectar e tratar certos eventos de rede considerados importantes para a segurança da máquina. Note que o TuxGuardian não analisa
diretamente o tráfego de rede, e sim as operações que ocorrem no nível do aplicativo. Por
uma decisão de projeto, as operações monitoradas são aquelas que envolvem a criação e
utilização de sockets.
O monitoramento destas operações é possível devido à utilização do framework
LSM (Linux Security Modules). O LSM consiste em uma ferramenta recentemente adotada no kernel mainstream do Linux, e que foi desenvolvida a fim de facilitar a criação de
políticas de controle de acesso [Wright and Cowan, 2003]. O LSM insere várias callbacks
em pontos estratégicos do código do kernel, de maneira que funções podem ser chamadas
no momento em que ocorrerem acessos a determinados objetos internos do kernel.
As duas principais callbacks definidas no módulo de segurança do TuxGuardian
são socket_create e socket_listen. Ambas são utilizadas a fim de mediar operações sobre
sockets da família de protocolos IPv4 e IPv6. Comunicações locais via sockets não são
verificadas.
Sempre que o módulo detecta um evento de rede suspeito, são utilizadas rotinas
auxiliares que transmitem informações de contexto para o daemon e aguardam uma resposta acerca de como agir, ou seja, uma resposta que informe se esta aplicação deve ou
não ter acesso a rede.
2.3. O daemon
O daemon corresponde à camada do TuxGuardian responsável por manter atualizadas
todas as informações de segurança do firewall de host. Para isso, um arquivo de configu-
5° WSL / 5° FISL
ração é lido e seus dados são transferidos para uma tabela hash mantida em memória. Esta
tabela hash também é responsável por armazenar permissões de segurança transitórias, ou
seja, permissões de acesso que são válidas somente durante a execução atual do firewall.
O daemon consiste em uma aplicação servidora capaz de receber conexões do
módulo de segurança sempre que este necessitar de alguma informação crítica, e é o
responsável por garantir a integridade das aplicações que possuem direitos de acesso à
rede. Isso evita que aplicações maliciosamente alteradas possam acessar a rede.
Até o momento, o controle de permissões existente permite que se especifique se
determinado aplicativo poderá ou não ter acesso à rede como cliente e se este aplicativo
poderá ou não atuar como um servidor.
2.4. Protocolo de comunicação intercamadas
A troca de dados que ocorre entre as camadas do TuxGuardian segue o padrão definido
pelo protocolo TGP (TuxGuardian Protocol), o qual utiliza mensagens de tamanho fixo.
Este protocolo é utilizado a fim de requisitar e transmitir informações entre os módulos.
Isso é necessário, por exemplo, devido ao fato de que todas as informações de segurança
estão concentradas no daemon, e também devido à independência do frontend. O detalhamento dos pacotes utilizados por este protocolo pode ser encontrado em [Silva, 2004].
2.5. O frontend
A última parte que compõe o TuxGuardian, e que na verdade é opcional para o seu funcionamento, é o frontend. O frontend nada mais é do que um aplicativo utilizado para obter
a opinião do usuário nos casos em que o daemon não é capaz de agir de forma autônoma.
A tarefa do frontend é traduzir queries TGP para o usuário final, de modo que possa haver interação em tempo real. Note que, nos casos onde o frontend não estiver disponível
ou não estiver sendo utilizado, o TuxGuardian irá operar apenas com as regras definidas
estaticamente no seu arquivo de configuração.
Figura 1: O frontend (desenvolvido em QT) solicitando intervenção do usuário.
3. Exemplos de uso
São descritas a seguir, em uma lista não exaustiva, algumas situações nas quais o uso do
TuxGuardian é aconselhado:
• proteção adicional, em nível de aplicativos, para máquinas onde já existem mecanismos de segurança de mais baixo nível, como um filtro de pacotes;
65
66
5° WSL / 5° FISL
• identificação e isolamento de aplicações mal-intencionadas no exato momento em
que elas tentam agir (ex: um spyware tentando transmitir dados confidenciais pela
internet);
• proteção contra alterações intencionais em aplicativos que acessam a rede, a fim
de garantir a integridade e confiabilidade de todos programas utilizados para transmissão de dados pela internet;
• criação de uma camada extra de proteção na rede, adicionalmente àquela geralmente provida pelo firewall da rede ou gateway. Essa proteção, por estar localizada individualmente em cada host, seria inerentemente distribuída e teria impacto
direto sobre a carga imposta ao firewall institucional.
Tendo em vista que o desenvolvimento do TuxGuardian ainda não está concluído,
algumas tarefas pendentes devem ser desenvolvidas em um futuro próximo. Entre elas,
destacamos a necessidade de desenvolvimento de métodos que garantam a integridade do
módulo de segurança e do arquivo de configuração do daemon; o desenvolvimento de
rotinas que permitam a análise de integridade de aplicativos linkados dinamicamente; e
a identificação e tratamento de recursos de rede alocados antes da inicialização do TuxGuardian.
4. Conclusões
Com o avanço do Linux Desktop e dos sistemas baseados em software livre para o público
leigo, é essencial que haja disponibilidade de mecanismos de segurança que possam ser
configurados por usuários finais. A gerência de aplicações confiáveis proporciona uma
boa solução para este problema, na medida em que constitui um mecanismo que não
exige amplo conhecimento acerca do modo como as redes operam. O TuxGuardian é
um firewall de host desenvolvido levando-se em conta exatamente essa filosofia, e que é
efetivamente capaz de fornecer uma camada extra de segurança, em adição àquela provida
por mecanismos clássicos de segurança.
Devido à falta de ferramentas deste tipo para plataforma Linux, o TuxGuardian dá
o primeiro passo no sentido de disponibilizar mecanismos de segurança fáceis de usar e
que visem exclusivamente o usuário final. A distribuição através da licença GNU/GPL,
o desenvolvimento modular e a utilização de frameworks genéricos de segurança contribuem para que o TuxGuardian possa ser aperfeiçoado e adaptado para fins diversos.
Referências
Biondi, P. (2002). Security at kernel level. In Proceedings of the Free and Open source
Software Developers’ European Meeting, Bruxelas, Bélgica.
Corbet, J. M. (2003). Porting drivers to the 2.5 kernel. In Proceedings of the Linux
Symposium, Ottawa, Canada.
Silva, B. C. (2004). Estudo e desenvolvimento de um firewall de host. Trabalho de
Conclusão de Curso, Universidade Federal do Rio Grande do Sul.
Wright, C. (2002). Linux security module framework. In Proceedings of the Linux Symposium, Ottawa, Canada.
Wright, C. and Cowan, C. (2003). Linux security modules: General security support for
the linux kernel. In 11th USENIX Security Symposium, San Francisco, USA.
5° WSL / 5° FISL
Uma Solução de IPS Baseada na Integração SNORT e
IPTABLES
Rivalino Matias Jr.1, Jaime Miranda Jr.2
1
Universidade do Vale do Itajaí (UNIVALI)
São José – SC – Brasil
2
Grupo Stela – Universidade Federal de Santa Catarina (UFSC)
Florianópolis – SC – Brasil
Abstract. This work presents the implementation of an IPS solution (Intrusion Prevention
System) based on the integration of Snort and Iptables. This integration was accomplished
through the implementation of a communication protocol, so that both technologies can
communicate in order to compose a whole security solution. Besides the specification of the
protocol, this work extended the Snort IDS functionality. The results of the work are presented
together with its limitation and future extensions.
Resumo. Este trabalho tem como objetivo apresentar a implementação de uma solução de IPS
(Intrusion Prevention System) baseada na integração Snort e Iptables. Esta integração foi
realizada através da implementação de um protocolo de comunicação, de forma que ambas
tecnologias possam se comunicar compondo uma única solução de segurança. Além da
especificação do protocolo, este trabalho estendeu a funcionalidade da plataforma Snort. Os
resultados do trabalho são apresentados, juntamente com suas limitações e trabalhos futuros.
1. Introdução
Atualmente os ataques eletrônicos (cyberattacks) têm crescido tanto em diversidade quanto em
complexidade [CERT 2003]. Neste contexto, tecnologias de segurança tais como firewall, ids, dentre
outras, devem ser utilizadas de forma integrada, visando atingir um nível de serviço que atenda aos atuais
requisitos de segurança digital.
Este trabalho apresenta a implementação de uma solução de IPS (Intrusion Prevention System),
baseada em um protocolo de integração Snort [Roesch 2003] e netfilter/Iptables[Coulson 2003]. O artigo
está organizado como descrito a seguir. Na seção II são apresentados alguns conceitos de sistemas de
detecção e prevenção de intrusão. O protocolo de integração está descrito na seção III. A seção IV
apresenta alguns detalhes da implementação do protótipo utilizado para validar o trabalho. Os resultados
alcançados, juntamente com as conclusões são apresentados na seção V.
2. Sistemas de Detecção e Prevenção de Intrusão
Desde a década de 80 os sistemas de detecção de intrusão tem sido utilizados, sendo o modelo de Denning
[Denning, 1987] o precursor para o desenvolvimento de arquiteturas de IDS. Esse modelo foi aplicado na
construção de um IDS chamado IDES (Intrusion Detection Expert System) e descrito em [Denning, 1987].
Outras implementações baseadas neste modelo podem ser encontradas em [Cooper 2002] e [Lunt 1993].
Uma evolução no conceito de IDS tem sido proposta, originando uma nova classe de aplicações
chamada de sistemas de prevenção de intrusão (IPS - Intrusion Prevention System) [Dinesh 2002]. Um
IPS herda todas as características e funcionalidades do IDS, contudo, agrega um comportamento ativo, ao
67
68
5° WSL / 5° FISL
contrário do modelo passivo inerente ao IDS. Desta forma, um IPS além de detectar eventos suspeitos,
toma decisões em forma de contramedidas ao concluir que o ambiente protegido está sob ataque [Bobbi
2003]. Atualmente, soluções de IPS são compostas de filtro de pacotes (firewalls) e mecanismos de
detecção de intrusão (ids), ambos trabalhando de forma integrada. Com isso, ao detectar eventos
considerados nocivos, o IPS pode usar as funcionalidades de bloqueio, presente no seu firewall, para
interromper o progresso de uma invasão/ofensiva [Timothy 2003].
A fim de criar uma solução de IPS baseada em software livre, implementou-se um protocolo de
comunicação cujo objetivo foi a integração do Snort com Iptables, compondo uma única solução de
segurança que contemple as funcionalidades presentes em um IPS.
3. Protocolo de integração Snort e Iptables (FWIDSP)
O propósito do protocolo implementado (fwidsp) é suportar as principais mensagens utilizadas para
integrar Iptables e Snort para fins de IPS. Sua representação de dados foi especificada em linguagem
ASN.1 (Abstract Syntax Notation One) [ITU-T | ISO/IEC 2002], a mesma utilizada nas IETF/RFCs
(request for Comments). O modelo de comunicação definido é não-orientado a conexão com confirmação,
utilizando o UDP como protocolo de transporte. A comunicação inicia-se sempre a partir do Snort, através
de uma pdu fwidsp endereçada ao Iptables.
A detecção de uma tentativa de ataque/invasão em curso, por parte do Snort, é o evento que inicia
esta comunicação. Neste caso, o Snort envia uma pdu fwidsp com comandos de configuração para o
Iptables a fim de conter ou mitigar o ataque/intrusão em progresso. Abaixo um exemplo de uma PDU do
protocolo, descrita em linguagem ASN.1:
REQUEST_PDU
IMPORTS RFC 11551
request_pdu ::= SEQUENCE { OP_ID, PORT, TIMER, INTERFACE, IP_ADDR, FORWARD_IP_ADDR,
NAT_IP_ADDR }
OP_ID ::= INTEGER;
PORT ::= INTEGER;
TIMER ::= UTCTIME;
INTERFACE::= OCTET STRING;
IP_ADDR ::= SEQUENCE OF { IPADDRESS SIZE 4..16 };
FORWARD_IP_ADDR::= SEQUENCE OF { IPADDRESS SIZE 4..16 };
Descrição dos campos:
OP_ID = Identificador da requisição fwidsp.
PORT = Armazena uma determinada porta TCP/UDP para bloqueio/liberação (ex. 80 – http).
TIMER = Armazena o tempo em segundos para a validade da regra definida em OP_ID. Este parâmetro é
opcional, sendo que um valor NULL representa uma regra sem tempo de expiração.
INTERFACE = Identifica a interface associada ao Firewall, na qual deve ser aplicada tal regra (Ex. Saída,
Entrada, DMZ, etc.).
IP_ADDRESS = Armazena o endereço IP a ser bloqueado/liberado. Este endereço suporta tanto IPv4 quanto
IPv6.
FORWARD_ADDRESS = Armazena um endereço de redirecionamento. Este endereço suporta tanto IPv4
quanto IPv6.
A implementação do fwidsp buscou ser a menos intrusiva possível, evitando a necessidade de
modificações tanto no Snort quanto no Iptables. Para isso, dois componentes de software foram
implementados, os quais permitiram esta desejada transparência. São eles:
1
RFC utilizada como módulo de importação que possui tipos de dados primitivos e estruturados usados pela
especificação do fwidsp.
5° WSL / 5° FISL
•
•
Plugin: responsável por enviar requisições fwidsp para o Iptables em resposta a eventos de intrusão
detectados pelo Snort;
Agente fwidsp: responsável pela recepção das pdus, provenientes do Snort/Plugin, e execução de
comandos no Iptables. O modelo arquitetural do IPS está apresentado na Figura. 1.
Figura 1. Arquitetura proposta
4. Prototipação e avaliação
Para validar a arquitetura de IPS proposta, um protótipo foi implementado de forma a verificar sua
efetividade. Para tanto, foi criado um cenário de teste contendo quatro componentes básicos: atacante
(win98), alvo (PWS/win98), roteador/Firewall (Linux/Iptables) e IDS (Linux/Snort). Na estação atacante
foram usadas ferramentas disponíveis na Internet (ex. Brutus2) para a geração de ataques variados. Como
sistema alvo foram utilizados um servidor web PWS (personal web server) com Windows 98.
A integração do plugin fwidsp ao Snort se deu através de uma interface unix socket3 chamada
spo_alert_unixsock(), disponibilizada pelo Snort para a sua comunicação com programas externos. A
Figura 2 apresenta o fragmento do código do arquivo snort.c4 que define esta interface. Um alarme é
gerado nesta interface quando da ocorrência de eventos que caracterizem tentativas de intrusão.
...
switch (pv.alert_mode){
...
case ALERT_UNSOCK:
AddFuncToOutputList(SpoAlertUnixSock, NT_OUTPUT_ALERT, NULL);
OpenAlertSock();
break;
}
...
Figura 2. Interface Unix Socket do Snort
Para implementar o agente no firewall um processo daemon5 foi implementado no Linux, o qual
monitora continuamente a porta de comunicação (udp:999) reservada para o fwidsp.
A validação do protótipo se deu realizando tentativas de invasão através de três tipos de ataques
atualmente usados, os quais são: portscan, ataque de senha e buffer overflow (IIS:cmd.exe). A fim de
avaliar o desempenho da solução, usou-se como critério o tempo de reação a estas tentativas de ataques,
registrando-se os tempos de saída do pacote do sistema atacante, sua passagem pelo Snort e chegada até o
alvo. Complementarmente, foram monitorados os tempos de saída da requisição fwidsp do Snort e sua
chegada no Iptables, bem como o tempo de finalização das novas regras criadas. Para tanto, todos os
sistemas envolvidos tiveram seus clocks sincronizados.
Foram realizadas três replicações para cada experimento de invasão, totalizando nove ensaios.
Verificou-se em todos os resultados que entre a detecção do ataque e o seu bloqueio o tempo foi menor do
que um (1) segundo. A boa performance do protocolo ficou comprovada pelo bloqueio do atacante de
2
Disponível em http://www.hoobie.net/brutus/ .
Mecanismo de comunicação entre processos (ipc local) em sistemas operacionais baseados no UNIX.
Arquivo disponível na instalação do código fonte do Snort (http://www.snort.org).
5
Processo que executa em segundo plano (backgound).
3
4
69
70
5° WSL / 5° FISL
forma eficaz, o que evitou a passagem de mais do que três pacotes no caso do portscan e apenas do
primeiro nos demais ataques. Em todos os nove ensaios o atacante não obteve nenhuma resposta
proveniente do sistema alvo em resposta aos ataques. Apesar das respostas terem sido enviadas pelo
sistema alvo, o endereço do destinatário já tinha sido bloqueado como efeito da comunicação Snort e
Iptables.
5. Conclusões
Como descrito na seção anterior, o protótipo implementado obteve sucesso em todos os testes ao qual foi
submetido. Porém, vale destacar que nestes testes não foram tratadas aquelas situações consideradas como
“alarmes-falso”. Em testes complementares foram injetadas, propositalmente, condições para a geração de
“alarme-falso”, o que se pôde constatar uma ineficiência do Snort no tratamento destas condições. Como
conseqüência, foram realizados bloqueios de estações não nocivas ao ambiente monitorado. Como
conseqüência a esta deficiência do Snort, ataques de negação de serviço podem ser explorados.
Também, vale destacar uma limitação desta proposta que reside na segurança do tráfego entre o
plugin e o agente fwidsp. No protótipo implementado não foram utilizados mecanismos para a garantia da
confidencialidade e integridade das pdus trocadas entre os dois sistemas. Duas abordagens que poderiam
ser usadas seria a utilização de criptografia (ex. SSL) ou de uma VPN (ex. ipsec) entre os dois pontos
finais de comunicação. Em ambos os casos têm-se a proteção das mensagens, porém faz-se necessário um
estudo do impacto de tais mecanismos sobre o desempenho do protocolo, haja vista que qualquer
acréscimo no tempo de reação da solução pode comprometer a sua eficácia.
6. Referências
Bauer, D. and Koblentz, M. (1988) “NDIX - An Expert System for Real-Time Network Intrusion
Detection” Proceedings of the IEEE Computer Networking Symposium, pp. 98-106, April.
Bobbi, Spitzberg (2003) “Intrusion Prevention – Part of Your Defense in Depth Architecture” SANS
GSEC Practical, April, 2003. http://www.sans.org/rr/papers/30/1063.pdf
CERT Coordination Center. Estados Unidos
<http://www.cert.org/stats/cert_stats.html>.
da
América,
2003.
Disponível
em:
Cooper, M. (2002) “An Overview of Intrusion Detection Systems. Washington” XINETICA. Disponível
em: < http://www.xinetica.com>.
Coulson, David (2003) LinuxPro – Network Security IpTable – Part 01. Março. Disponível em:
<http://www.iptables.org>
Denning, Dorothy E. (1987) “An Intrusion-Detection Model. Transactions on Software Engineering”, vol.
se-13, no. 2, february, 222-232.
Dinesh Sequeira (2002) “Intrusion Prevention Systems – Security´s Silver Bullet” SANS GSEC,
(http://www.sans.org/rr/papers/30/366.pdf)
ITU-T | ISO/IEC Abstract Syntax Notation One (ASN.1): Specification of Basic Notation, ITU-T Rec.
X.680 (2002) | ISO/IEC 8824-1:2002 Standards, 2002.
Lunt, Teresa F. (1993) "Detecting intruders in computer systems". Conference on Auditing and Computer
Technology, 1993.
Roesch, Martin. Snort Users Manual. Snort Release: 1.9.x 2002. Disponível em: <http://www.snort.org>.
Timothy, D. Wickham(2003) “Intrusion Detection is Dead. Long Live Intrusion Prevention” SANS
GIAC: Research on Topics in Information Security, April.(http://www.sans.org/rr/papers/30/1028.pdf)
5° WSL / 5° FISL
Sessão Técnica 5
REDES
71
72
5° WSL / 5° FISL
5° WSL / 5° FISL
Desenvolvimento de um Sistema Livre para Simulação de
Tráfego Baseada em Modelos Microscópicos∗
Gustavo K. Andriotti, Ana L.C. Bazzan, Paulo R. Ferreira Junior, Filipe Lopes,
Denise de Oliveira, Thiago M. Papageorgiou, Bruno Castro da Silva†
1 Instituto
de Informática – Universidade Federal do Rio Grande do Sul
{fgka,bazzan,prferreiraj,filipe,edenise,tmpapageorgiou,bcs}@inf.ufrgs.br
Abstract. This paper describes a tool for traffic simulation – both urban and highway
– which is based on a microscopic simulation model. The project is under development
and is licensed as free software. Moreover, it is the basis for a driver information system
and will be freely available for traffic engineers and urban planning experts.
Resumo. Este artigo descreve uma ferramenta para simulação de tráfego – urbano e
em autoestradas – baseado em modelo microscópico de movimentação. O projeto está
sendo desenvolvido com base em software livre e é a base de um sistema de informação
para motoristas. Além disso, será disponibilizado livremente para usuários da área de
engenharia de tráfego e de planejamento urbano.
1. Introdução
Problemas relacionados ao trânsito são uma constante nas grandes cidades do mundo inteiro e
tendem a agravar-se com o crescente aumento da demanda por mobilidade. As ações adotadas para
minimizar o problema visam a melhoria da malha viária através da construção de novas vias ou da
otimização do fluxo de tráfego na malha existente. Esta última opção, além de economicamente
mais viável, também é a alternativa preferida por sociedades nas quais o fator meio-ambiente é
uma questão chave.
Os sistemas computacionais que atualmente tentam resolver problemas de tráfego são, em
geral, isolados, podendo ser considerados “caixas-pretas” devido à inacessibilidade ao seu código
fonte. Isso inviabiliza modificações, extensões e a integração com outros sistemas de logística e
planejamento urbano. Além disso, outra questão relevante é a do custo destes sistemas, geralmente
na ordem de milhares de dólares. Estes problemas se tornam ainda mais críticos no momento
em que passamos a considerar a utilização destes softwares em universidades e órgãos públicos
voltados para as áreas de circulação e transportes, como secretarias municipais de transporte,
órgãos de planejamento urbano e de engenharia de tráfego.
Por todos esses motivos, decidiu-se desenvolver um simulador de tráfego dentro do projeto
SISCOT (Sistema Integrado de Simulação, Controle e Otimização de Tráfego, iniciado em 1999),
através do qual se busca atacar a falta de ferramentas livres e fornecer alternativas economicamente
viáveis aos softwares comerciais disponíveis, como o Paramics, EMME2, VISIM e Dracula.
Além de resolver o problema do custo, o desenvolvimento baseado em software livre permite que o simulador possa ser modificado pelos integrantes das equipes de pesquisa que compõe
∗
†
Projeto parcialmente apoiado pelo CNPq
Autores parcialmente apoiados pelo CNPq
73
74
5° WSL / 5° FISL
o projeto: físicos, como fornecedores do modelo de movimentação dos veículos; cientistas da
computação, como fornecedores dos modelos de motoristas e desenvolvedores da ferramenta; e
engenheiros de tráfego, como usuários desta.
O presente projeto objetiva, em resumo, a construção de um software para simulação e
otimização de tráfego urbano e em auto-estradas que seja livre e de código aberto.
2. Simulação de Tráfego
O simulador desenvolvido no projeto é baseado em um modelo microscópico de movimentação
física1 . Este tipo de modelo leva em consideração veículos individualmente e é relativamente
mais complexo que um modelo macroscópico. Uma exceção é o modelo de Nagel-Schreckenberg
[Nagel and Schreckenberg, 1992], baseado em um autômato celular, o qual divide um trecho qualquer de uma via em partes elementares de comprimento fixo (células) e executa simulações em
passos discretos de tempo (iterações). Neste modelo, cada veículo possui uma velocidade v e
se movimenta de acordo com relações bastante simples, envolvendo principalmente a sua velocidade e a posição relativa entre os carros (gap). O modelo utilizado no SISCOT é baseado no
autômato de Nagel-Schreckenberg, mas inclui algumas extensões ao modelo original, as quais são
detalhadas em [Bazzan et al., 1999, Andriotti and Bazzan, 2002].
As quatro regras principais que guiam a movimentação física de cada veículo, neste modelo microscópico, são:
1.
2.
3.
4.
aceleração: incrementa v de uma unidade, caso v seja menor que gap;
interação: decrementa v de um unidade caso o veículo vizinho esteja muito próximo;
randomização: decrementa v de uma unidade com probabilidade p;
movimentação: atualiza a posição de cada veículo, fazendo-o avançar v células.
Com estas regras é possível simular situações clássicas como acidentes e outras perturbações sobre a via, bem como o que atualmente é conhecida como a causa mais freqüente de
congestionamentos que surgem sem um motivo aparente: o fato de que, seguindo-se uma desaceleração randômica (alguém que observa a paisagem, telefona ao volante, etc.), ocorre uma reação
em cadeia de desacelerações, cada uma mais forte que a que a causou, de modo que em pouco
tempo se forma um congestionamento de grandes proporções.
3. Descrição do Projeto
No projeto do sistema estão previstos os seguintes módulos:
• aquisição de dados
• simulação microscópica
• visualização
3.1. Aquisição de dados
O módulo de aquisição e manutenção de dados se baseia em uma interface gráfica acessada via
web, a qual interage com um banco de dados remoto. Este banco de dados armazena informações
relativas à topologia das malhas viárias, dados dos semáforos e informações dinâmicas, como
contagens de fluxo de veículos. As tecnologias envolvidas são todas baseadas em software livre:
PHP e servidores Apache e Postgres rodando em máquinas Linux com Debian.
1
A escolha de um modelo microscópico se justifica devido a sua eficiência computacional, indispensável devido à
necessidade de se produzir uma predição do estado das vias em um horizonte de tempo da ordem de 15 a 30 minutos
5° WSL / 5° FISL
Os dados utilizados para a tarefa de gerência de tráfego urbano provêm de diversas fontes
(ex: EPTC/SMT), e atualmente são coletados de forma offline. Entre estes dados incluem-se
informações a respeito da sinalização, volume de tráfego e dados topológicos.
Adicionalmente às funcionalidades básicas da interface e do banco de dados, estão sendo
desenvolvidas ferramentas para geração de estatísticas e geração automatizada de dados para os
demais módulos, assim como algorítmos de sumarização de dados.
3.2. Módulo de simulação
Este módulo é implementado em C++ e é o responsável por gerar os dados relativos à simulação
de determinada malha viária. As informações a respeito da topologia são oriundas do banco de
dados, e a saída pode assumir vários formatos, dependendo da necessidade do usuário. Entre estes
formatos, os mais usados são o mapa de células e taxa de ocupação por via.
O modelo utilizado no módulo de simulação é uma extensão do autômato de NagelSchreckenberg, na qual a tomada de decisão dos motoristas ocorre em duas etapas. A movimentação dos carros na malha viária é função tanto da decisão do respectivo motorista quanto das
limitações e restrições do veículo e do cenário sendo simulado.
Foram implementados vários mecanismos de ajuste do funcionamento da topologia, tais
como sources e sinks (elementos que inserem e removem carros da simulação, de acordo com
taxas constantes ou variáveis), semáforos, etc. Além disso, o simulador prevê o funcionamento de
vários tipos de sensores, que são elementos passivos cuja função é coletar certos tipos de dados da
simulação. Estes dados podem ser analisados offline ou utilizados para realimentar o simulador de
forma a otimizar o tráfego, como poderá ser visto na seção 4.
3.3. Visualização
Este módulo ainda está em fase de implementação. A visualização dos resultados pode se ocorrer
tanto em modo gráfico quanto em modo textual, e pode ser disponibilizada via web (visualização
simplificada) ou localmente (visualização detalhada).
O visualizador gráfico disponibilizado via web foi implementado em Java e apresenta os
dados de forma 2D, tanto em escala de veículo quanto em nível estatístico (macroscópico). O
visualizador local, por sua vez, foi desenvolvido em C/C++ e utiliza a biblioteca gráfica OpenGL.
Desta maneira, visualizações bem mais realistas e detalhadas são possíveis, as quais incluem a
possibilidade de navegação 3D na topologia.
4. Cenário testado
Um exemplo da utilização do SISCOT é apresentado em [Oliveira et al., 2004], e corresponde a
uma tentativa de reduzir os congestionamentos através da sincronização de semáforos em uma
abordagem baseada em insetos sociais. Ao tratar cada semáforo como um inseto submetido a
estímulos, é possível evitar a necessidade de um controle de tráfego centralizado e estático, possibilitando com que a escolha de planos semafóricos ocorra de forma automática e auto-ajustável.
O cenário utilizado foi um trecho da rede viária de Porto Alegre (vide figura 1), sendo que
foram simulados os fluxos de veículos na via principal e nas secundárias em diferentes situações:
sem nenhuma sincronização entre os semáforos; com coordenação fixa; e com a abordagem inspirada nos insetos sociais. Os resultados mostraram que a abordagem inspirada em insetos sociais
é mais flexível e que os semáforos se adaptam ao fluxo corrente selecionando o plano semafórico mais apropriado. Desta forma, é possível reduzir a densidade e os congestionamentos na via
principal de forma automática e descentralizada.
75
76
5° WSL / 5° FISL
Figura 1: Visualização 3D de uma simulação de tráfego
5. Conclusões
Do ponto de vista prático, o principal resultado obtido com o projeto foi a implementação de
um protótipo para análise, simulação e controle do tráfego para a cidade de Porto Alegre. Este
protótipo foi licenciado pela GNU/GPL, constituindo uma alternativa livre e gratuita aos softwares proprietários que atualmente dominam o mercado. Além disso, o SISCOT permite o rompimento da dependência tecnológica e o não comprometimento de recursos financeiros na compra
de softwares comerciais. Isso é especialmente importante tendo em vista que o SISCOT poderá
ser usado por órgãos governamentais de planejamento e de pesquisa, diretamente em benefício da
população.
Espera-se que, a partir dos resultados obtidos, seja possível alcançar uma melhora no
gerenciamento de semáforos e no planejamento e otimização de tráfego. Adicionalmente, deverá
ser oferecido um serviço de divulgação via internet ou rádio das condições do trânsito, o que
terá impacto sócio-econômico direto para motoristas e usuários em geral do transporte urbano
na cidade. Com isso, será possível diminuir o tempo de viagens e atrasos, e conseqüentemente
melhorar a qualidade de vida da população.
Referências
Andriotti, G. K. and Bazzan, A. L. C. (2002). An object-oriented microscopic traffic simulator. In
Proceedings of the XXVIII Latin-American Conference on Informatics (CLEI 2002), Montevideo, Uruguay.
Bazzan, A. L. C., Wahle, J., and Klügl, F. (1999). Agents in traffic modelling – from reactive to social behaviour. In Advances in Artificial Intelligence, number 1701 in LNAI, Berlin/Heidelberg.
Springer. Also appeared as Proc. of the U.K. Special Interest Group on Multi-Agent Systems
(UKMAS), Bristol, UK.
Nagel, K. and Schreckenberg, M. (1992). A cellular automaton model for freeway traffic. J. Phys.
I France, 2:2221.
Oliveira, D., Ferreira, P., and Bazzan, A. (2004). Reducing traffic jams with a swarm-based
approach for selection of signal plans. In Proceedings of Fourth International Workshop on Ant
Colony Optimization and Swarm Intelligence - ANTS 2004., Bruxelas, Bélgica.
5° WSL / 5° FISL
Um Framework baseado em Software Livre para diminuir
a probabilidade de falhas e para balanceamento de carga nas
conexões à Internet
Marcelo Rios Kwecko1, Raphael Lucas Moita1,Jorge Guedes Silveira1, Ricardo Balbinot1
1
Faculdade de Engenharia Elétrica – Pontifícia Universidade Católica (PUCRS)
Av Ipiranga 6681 – Prédio 30 – 90.619-900 – Porto Alegre – RS – Brasil
{mkwecko,rmoita,jguedes,rbalbinot}@gparc.org
Resumo. A comunicação através da Internet vem sendo cada vez mais usada pelas
empresas para realizar suas transações. Transações estas que devem ser garantidas
por um serviço de conexão de qualidade e confiável, onde a indisponibilidade do
mesmo pode trazer prejuízos incalculáveis a tais empresas. O presente artigo
apresenta um modelo de sistema que foi desenvolvido, com código aberto, tendo
como objetivos principais o controle de links redundantes de acesso a Internet e o
Balanceamento da Carga.
Abstract. The communication via Internet has become each time more and more used
for the corporative transactions. Those transactions must be guaranteed by a high
quality service and fault tolerant systems since the unavailability of any service might
cause incalculable lost revenue to these companies. This paper presents a system
modeling that has been implemented, with open sources, having as main goals the
links control of redundant accesses to the world Internet as well as the load
balancing on those links.
1. Introdução
Atualmente a comunicação via Internet vem sendo usada por muitas empresas na realização de
transações que devem ser garantidas por um serviço de conexão confiável e de qualidade, onde
a indisponibilidade deste pode trazer, em muitos casos, prejuízos incalculáveis a tais empresas.
Este artigo descreve um método que foi implementado sobre uma plataforma de software livre
para diminuir a probabilidade de falhas nas conexões devido a erros nos provedores de serviço,
bem como a possibilidade de balancear o tráfego da rede. Por estas razões o sistema
implementado foi especificado com links redundantes de acesso. No testbed foram utilizados,
no acesso, dois tipos de tecnologias distintas (tecnologia ADSL e Cable Modem) e na
montagem do modelo de rede é utilizado um roteador open source Linux para gerenciar as
conexões com a Internet.
2. Aspectos Importantes
No momento de se planejar uma alternativa com conexões redundantes, alguns aspectos devem
ser analisados para que a solução apresente uma maior confiabilidade e imunidade contra
possíveis falhas nas conexões. A primeira delas é a escolha de diferentes tecnologias de
conexão, por exemplo, usar um link ADSL e outro Cable Modem, ou também, um link dedicado
e outro ADSL ou um link Cable Modem e outro discado, etc. Desta forma é menor a
probabilidade das duas fornecedoras de conexão Internet pararem ao mesmo tempo. Pode-se ter
duas conexões com a Internet e utilizando a mesma tecnologia, desde que a estrutura destas
conexões seja com operadoras diferentes, como por exemplo, dois links ADSL, um fornecido
pela Operadora “A” e o outro pela Operadora “B”. Esta é uma medida clássica, em termos de
77
78
5° WSL / 5° FISL
confiabilidade, cuja redundância permite diminuir muito a probabilidade que ambos sistemas de
conexão venham a falhar simultâneamente. No entanto alguns outros aspectos complementares
a serem analisados sobre o funcionamento das tecnologias escolhidas, podem determinar o que
pode deixar a conexão fora de funcionamento, e até mesmo descobrir se existem pontos em
comuns, os quais podem fazer com que parem de funcionar as duas tecnologias de conexão
escolhidas, como por exemplo, o mesmo provedor de serviços de Internet (ISP).
Analisando as características específicas de cada tecnologia, podemos observar que a estrutura
ADSL especifica um endereço IP da própria fornecedora do serviço, usando apenas o ISP para
autenticação do usuário. Já a tecnologia Cable Modem é dependente do ISP para fornecer um
endereço IP para conexão. Com isso, caso o ISP apresente problemas, a conexão através do
Cable Modem também irá apresentar, enquanto que o ADSL não, pois como já foi dito, só
utiliza o ISP para autenticação. Diante desses aspectos pode ser utilizado o mesmo provedor de
acesso tanto na estrutura ADSL quanto para a estrutura Cable Modem.
O balanceamento do tráfego é então viabilizado devido à disponibilidade de duas conexões, pois
seria um desperdicio usar-se apenas uma das conexões para o acesso à Internet, deixando a
outra apenas como um link stand by de conexão. O modelo especificado faz com que o tráfego
prioritário utilize sempre a conexão de maior velocidade de comunicação.
3. Testbed e Estrutura da Rede de Teste
A figura 1 ilustra a topologia utilizada como testbed e a estrutura da rede com conexão
redundante. A rede possui um roteador Linux e duas conexões com a Internet, uma através da
tecnologia ADSL e outra através da tecnologia Cable Modem. O roteador Linux gerencia as
conexões de forma que se possa acessar a Internet tanto pelo link ADSL como pelo link Cable
Modem. Ainda permite que o tráfego da rede local seja balanceado, ou seja, parte do tráfego é
direcionada para um dos links, e o restante é escoado pelo outro. No entanto, se alguma das
conexões apresentar problema, todo o tráfego da rede local é imediatamente encaminhado para
a outra conexão.
Figura 1. Estrutura da Rede
4. Descrição do Sistema
O sistema foi desenvolvido utilizando-se apenas ferramentas disponíveis na maioria das
distribuições atuais do Linux, entre elas podemos citar: Iproute2, IPTables, ping, Shell Script,
etc.
Conforme definido em [SHE 04], Shell é o interpretador de linha de comando do Linux e Shell
Script é uma linguagem de programação que interpreta e executa comandos no Shell. Com esta
linguagem é possível o desenvolvimento de aplicativos de forma rápida.
5° WSL / 5° FISL
4.1 Iproute2
Segundo [FRE 02], o Kernel do Linux, a partir da série 2.2, evoluiu para um subsistema de rede
completamente novo e remodelado. O código deste subsistema é extremamente flexível e
robusto, graças a funções especiais contido nele. Tais funções existentes neste subsistema do
Linux incluem diretivas diversas de roteamento, controle, filtragem e priorização de tráfego.
Embora o Linux possua tanta flexibilidade, perdemos o uso de tais funções pelo simples fato de
que na maior parte dos sistemas a configuração é baseada em utilitários presentes em toda base
UNIX, nos quais a configuração e uso das funções especiais do Kernel do Linux não são
acessíveis, como os comandos arp, ifconfig e route. Estes comandos, embora utilizem syscalls
adaptadas ao novo subsistema, fazem as chamadas passando diversos argumentos com valores
padrões, perdendo-se a flexibilidade de configuração neles existente. Contudo, um pacote
chamado iproute2 liberta o poder do subsistema de rede do Linux, permitindo a configuração de
sistemas com toda a flexibilidade existente no Kernel, de forma poderosa, sem perder a
facilidade de uso das ferramentas anteriores. Portanto o iproute2 disponibiliza um maior poder
de “roteamento” ao sistema Linux, como, por exemplo, permitir a criação de várias tabelas de
roteamento, especificar regras de roteamento para os pacotes de redes que chegam no sistema
entre outros [LIN 04].
4.2 IPTables
Como nossa rede local utiliza IPs com endereços não roteaveis é preciso fazer o NAT (Network
Address Translation). NAT não é um protocolo nem um padrão, e sim uma série de tarefas que
um roteador, ou equipamento equivalente, deve realizar para converter endereços IPs entre
redes distintas [ROD 03]. Um equipamento que tenha o recurso de NAT deve ser capaz de
analisar todos os pacotes de dados que passa por ele e trocar os endereços desses pacotes de
maneira adequada. Para realizar o NAT nos pacotes que trafegam entre uma rede e outra, foi
adicionado nas distribuições Linux que usam kernel 2.4 a ferramenta IPTables, a qual trabalha a
nível de pacotes baseado no endereço/porta de origem/destino [SIL 03]. Em Kernels anteriores
ao 2.4 este mesmo recurso poderia ser alcançado com uma ferramenta semelhante chamada
IPChains
4.3 Descrição do Funcionamento
No roteador Linux foram criadas duas tabelas de roteamento, uma para cada link de conexão.
Nestas tabelas estão definidas as informações para o roteamento, a interface de rede usada bem
como o gateway das conexões. Além das tabelas são também criadas regras de roteamento,
através do conjunto de ferramentas IPRoute2, mais especificamente a ferramenta “IP”, para os
pacotes que chegam ao roteador.
Uma dessas tabelas de roteamento é definida como “padrão”. O endereço de origem do pacote,
ao chegar no roteador Linux, é analisado para que seja definido, de acordo com as regras
previamente configuradas, o que deve ser feito com o pacote. As regras se resumem em definir
a direção dos pacotes entre o link1 e link2. O balanceamento de carga pode se dar de forma
estática, ou seja, o administrador determina qual o caminho dos pacotes de um determinado host
deve usar para acessar a Internet ou o sistema pode determiná-la de forma dinâmica a partir de
uma máquina de estados finitos controlada pelas regras de decisão.
Para o monitoramento do estado dos links, de tempos em tempos, é enviado um pacote ICMP ao
gateway do provedor de conexão de cada link. Caso não houver um pacote de retorno, o link em
questão é considerado inativo, e o tráfego da rede é encaminhado imediatamente para o outro
link de acesso.
Como o sistema de configuração é desenvolvido em Shell Script, o administrador pode
facilmente modificar conforme as necessidades de sua rede apenas editando arquivos texto.
79
80
5° WSL / 5° FISL
A figura 2 ilustra o funcionamento do sistema proposto por completo.
Figura 2 – Funcionamento do Sistema
5. Conclusão
Empresas que possuem conexões fornecidas por operadoras de serviços de Internet, muitas
vezes ficam de mãos atadas e tendo que arcar com os inúmeros prejuízos em seus negócios
devido às falhas no serviço de comunicação.
Este artigo apresentou uma forma de conexão alternativa, possibilitando que as redes das
empresas fiquem menos vulneráveis aos problemas que podem ocorrer com os fornecedores de
serviço de comunicação. Além de demonstrar que é possível desenvolver ferramentas simples e
eficiente no sentido de resolver os mais variados problemas nos sistemas de informação, apenas
usando software livre. Em nossas redes de teste o sistema desenvolvido apresentou ótimos
resultados, tanto no sentido da conexão com a Internet, pois dificilmente a rede local ficou sem
conexão, e na melhora do tráfego dos dados, devido ao balanceamento das informações pelos
dois links.
[FRE 02] FREITAS, Allan E. S. “Roteamento avançado com Linux”. 2002, Disponível em:
<http://www.rnp.br/newsgen/0201/roteamento_linux.html>, Acesso em 07 Maio 2004.
[SIL 03] SILVA, Gleydson M. “Guia Foca GNU/Linux”. 2003 Disponível em:
<http://focalinux.cipsga.org.br/guia/avancado/index.htm >, Acesso em 07 Maio 2004.
[ROD 03] RODRIGUES, Marcelo L. “Protocolo NAT”. 2003. Disponível em:
<http://www.networkdesigners.com.br/Artigos/NAT/nat.html>, Acesso em 07 Maio 2004.
[LIN 04] Linux HOWTO, “Linux Advanced Routing & Traffic Control HOWTO”. Disponível
em: <http://lartc.org/howto/>,Acesso em 07 Maio 2004.
[SHE 04] Shell Script, “How to write a shell script”. Disponível
<http://vertigo.hsrl.rutgers.edu/ug/shell_help.html>, Acesso em 07 Maio 2004.
em:
5° WSL / 5° FISL
Terminais Inteligentes: alternativa estratégica para otimização
de recursos computacionais
Reinaldo J. Moreira , Hebert Luiz A. Costa, Jailton C. Junior, Gicele M. T. de Souza,
Ulisses A. Leitão
Faculdades Integradas de Caratinga, Instituto Doctum – Educação e Tecnologia
Pç. Cesário Alvim, 110 – 35.300-036 Caratinga – MG - Brasil
Abstract. This paper describes the Smart Clients Approach as a strategic solution in order
to optimize computational resources. The Smart Clients are similar to the Thin Clients but,
on the other hand, they have a reasonable local processing and RAM memory capabilities.
We argue that, in this case, it is a resource wasting to use a fat server to do what the station
can do. A new instalation script was developed to carry out a sistematic use of local
applications, making possible a full control of load balacing within the local network.
Resumo. Este artigo descreve a abordagem de Terminais Inteligentes como solução
estratégica visando a otimização de recursos computacionais. Terminais Inteligentes são
similares a Thin Clients. Entretanto, possuem razoável capacidade de processamento e de
memória RAM locais. Neste caso, é um desperdício de recursos utilizar o servidor para
realizar tarefas que podem rodar nas estações. Um novo script de instalação foi
desenvolvido para realizar o uso sistemático de aplicações locais permitindo o pleno
controle de balanceamento de carga na rede local.
1. Introdução
O termo Terminais Inteligentes (em inglês Smart Clients) se refere a estações de trabalho com
supressão de hardware, mas com poder de processamento local. São estações tipo thin clients, sem
HD, que executam tarefas como uma estação desktop padrão. Entretanto, ao contrário das estações
thin clients tradicionais, os Terminais Inteligentes têm capacidade de processamento local, o que
permite ao projetista do sistema computacional a utilização de técnicas de balanceamento de carga
entre o servidor e a estação como estratégia de otimização de recursos computacionais.
Tais estações se apresentam como ideais para a criação de diversos ambientes
computacionais, em especial para laboratórios de inclusão digital, pois agregam duas características
essenciais: economia e flexibilidade. A economia é conseguida com a simplificação do hardware. A
flexibilidade vem do uso de processamento local, tornando a estação capaz de executar diversas
tarefas sem a sobrecarga da rede ou do servidor, além de facilitar enormemente a administração do
sistema.
O presente artigo apresenta a solução de Terminais Inteligentes desenvolvida dentro do
projeto LibertasBR1 e tem como objetivo implementar uma solução de boot remoto com
balanceamento de carga entre o servidor e as estações remotas. Concebido como uma personalização
da distribuição GNU/Linux-Debian voltada para o setor público, o LibertasBR, desenvolvido pela
UFMG, Faculdades Doctum e Prodabel, permite a instalação e configuração de Terminais Inteligentes
de forma simples e prática. Em uma de suas utilizações mais relevantes, o LibertasBR está
1 www.libertasbr.dcc.ufmg.br
81
82
5° WSL / 5° FISL
viabilizando a implantação de noventa e quatro Telecentros de Inclusão Digital em comunidades
carentes do norte e nordeste de Minas, projeto Cidadão.NET.
2. Abordagens tradicionais
Em ambientes, corporativos ou educacionais, de uso intensivo de recursos computacionais sem,
entretanto, necessidade de alto poder de processamento, soluções do tipo Network Computer tem-se
tornado gradativamente predominantes. Duas são as estratégias de abordagem comumentemente
apresentadas neste caso.
2.1 Soluções baseadas em Terminais X
A solução mais popular e que tem sido responsável por um crescente interesse na utilização
do Linux em diversos setores, é a solução baseada em terminais X. Diversos projetos de software livre
são dedicados a implementar soluções que fazem amplo uso das capacidades intrínsecas de protocolo
de acesso remoto à interface gráfica de usuário Xwindow, veja [Leung(2004) , Brin(2004)]. Todos
estes projetos podem ser caracterizados pela implementação de thin clients, em que todos os
aplicativos são configurados para rodarem em servidores remotos. Talvez o projeto mais ativo com
esta abordagem seja o LTSP – Linux Terminal Server Project (http://www.ltsp.org). Uma introdução
ao projeto estará sendo apresentada no atual Fórum [McQuillan, 2004]. Entretanto, projetos
alternativos estão em atividade: o Projeto Netstation, (http://netstation.sourceforge.net); o projeto
Thinstation (http://thinstation.sourceforge.net), o projeto Diet-PC (http://diet-pc.sourceforge.net), o
DRBL -Diskless Remote Boot in Linux, [Blake 2004], dentre outros. Utilizando soluções de boot via
rede, como p.ex. a solução do projeto Netboot (http://netboot.sourceforge.net), Etherboot
(http://sourceforge.net/projects/etherboot) ou, ainda, implementando soluções próprias, todos estes
projetos possibilitam a utilização de estações sem disco de pouca memória RAM, deixando todos os
aplicativos rodando no servidor.
2.2 Solução baseada em servidores VNC
Uma solução menos tradicional foi recentemente relatada por Yu e Cimafranca [Yu et al.,
2004]. A solução proposta consiste no desenvolvimento de uma distribuição Linux reduzida, com a
implementação
do
sistema
VNC
–
Virtual
Network
Computing
(veja
http://www.csd.uwo.ca/staff/magi/doc/vnc/index.html). Baseado no protocolo RFB – Remote
Framebuffer, o VNC é, em essência, um sistema de terminal remoto, o qual propicia o acesso
interativo ao ambiente de desktop de qualquer máquina na rede local ou pela Internet. Além disto,
tanto os servidores como os visualizadores VNC estão portados para diferentes arquiteturas e sistemas
operacionais. Assim o VNC permite a implementação de um sistema computacional multiplataforma
inteiramente transparente. Rodando sob protocolo TCP-IP, o VNC pode ainda ser visualizado em
máquina virtual java e mesmo browsers tradicionais. O VNC se comporta, para uma aplicação Linux,
como se fosse o próprio servidor X, podendo, entretanto, ser visualizado remotamente, por uma
máquina de arquitetura e sistema operacional diferentes, desde que esteja rodando o aplicativo de
visualização do VNC adequado. Esta tecnologia é a base de soluções de integração de sistemas
operacionais por metaframe, como a proposta proprietária recentemente ofertada no mercado pela
Syst International (http://www.metasys.com.br).
3. Metodologia
Existe uma desvantagem comum às estratégias de solução apresentadas acima. Ambas soluções são
ancoradas na utilização de thin clients como Terminais Burros. Em muitos casos, entretanto, temos
estações de trabalho com poder de processamento e disponibilidade de memória locais razoavelmente
5° WSL / 5° FISL
bons. Nestes casos é um enorme desperdício utilizar estas estações apenas como terminais burros2,
rodando apenas o Kernel do Linux, a biblioteca SVGA e o servidor X. Assim, a estratégia utilizada
pelo presente trabalho foi a de adaptar o script DRBL, disponível para as distribuições Debian e Red
Hat, visando:
(a) Simplificar o script, retirando os ítens relacionados à configuração de cluster para processamento
paralelo, já que esta funcionalidade não estava entre as especificações do projeto;
(b) Criação de uma interface de instalação mais amigável, utilizando Dialog e Xdialog;
(c) Implementação de opção para utilização do LDAP como alternativa ao NIS.
4. A implementação de Terminais Inteligentes
A estrutura Cliente/Servidor é a base para a implementação de Terminais Inteligentes empreendida. O
Servidores provêem os serviços DHCP, TFTP , NFS e LDAP ou NIS. O DHCP fornece aos clientes
um endereço IP para a sua identificação na rede. O TFTP disponibiliza a imagem do Kernel bootável,
possibilitando que as estações clientes inicializem o sistema operacional. O NFS exporta o sistema de
arquivos e o NIS (LDAP) fornece os serviços de autenticação de usuários. Com a disponibilização
desses serviços conseguimos um servidor que atenda um sistema computacional robusto e eficiente.
Através dos serviços disponibilizados pelo servidor, cada estação cliente adquire sua própria
configuração mantida no servidor para leitura e escrita. O Servidor disponibiliza um sistema
GNU/Linux básico, usando apenas alguns arquivos compartilhados, incluindo as pastas /bin, /sbin, /
usr e /lib.
O sistema passou a ser denominado RBL, Remote Boot LibertasBR. Sua instalação é feita
através de telas simples e intuitivas, onde o usuário pode fazer toda configuração, seguindo apenas um
manual simples e prático. Foi desenvolvido um live CD como base de instalação, como a que foi feita
pelo sistema Pequinzilla [Blake, 2004], onde as imagens das estações e do servidor são criadas
automaticamente, com uma configuração personalizada para o LibertasBR. Os scripts do RBL tem por
finalidade montar os seguintes componentes:
RBL Server
Servidor provê os serviços de DHCP, TFTP, NFS e NIS (LDAP). Os clientes, através do
endereço IP, carregam o kernel e suas configurações através da rede. Durante o procedimento de boot,
o cliente monta o RBL Client Template usando o serviço de NFS e o NIS (LDAP) para a autenticação
e manipulação das informações dos usuários.
RBL Client
Cada estação da rede RBL tem sua própria configuração, mantida em seus diretórios
específicos /etc, /root e /var, armazenada no servidor para leitura e escrita de seus clientes.
RBL Client Template
Nada mais é que um sistema Debian básico criado através do comando debootstrap, usando
apenas alguns arquivos compartilhados, incluindo as pastas /bin, /sbin, /usr e /lib. Ele cria o template
dos clientes copiando toda árvore de diretórios do servidor e utiliza o comando chroot para instalar os
pacotes necessários para os clientes. Como o servidor e os clientes não têm a mesma árvore e
configurações do sistema Debian, os computadores não necessitam ter a mesma configuração de
hardware.
2 Tal fato foi reconhecido pelos desenvolvedores do LTSP. Assim, um dos pontos que mereceu maior atenção dos
desenvolvedores do LTSP na elaboração de sua versão 4.0 foi exatamente o de tornar mais fácil a instalação de aplicativos
locais. Entretanto, as opções da estrutura de sistemas de arquivos propostas pelo projeto tornam esta tarefa
desnecessariamente complexa.
83
84
5° WSL / 5° FISL
5. Análise de Resultados
Uma das principais características apresentadas é a flexibilidade oferecida pelo RBL para a criação e
administração de ambientes computacionais. Assim , pode-se conceber desde ambientes onde todas as
aplicações sejam executadas nas estações, até sistemas onde todas as aplicações rodam remotamente
no servidor. Ambientes com balanceamento de carga, com algumas aplicações rodando no servidor e
outras nas estações, são configurados pela simples instalação de aplicativos em diretórios compartilhados ou não, respectivamente.
Aplicações exclusivamente locais são instaladas e configuradas em diretórios específicos das
estações, como /etc, /root, /var e, em especial, /usr/local. Aplicações remotas são executadas a partir
de diretórios comuns a todas as estações, como é o caso do /opt, /bin, /sbin, /usr/bin. Um exemplo
pode ser dado com a utilização de dois aplicativos muito comuns: Mozilla e OpenOffice. O primeiro
deles pode ser executado remotamente a partir do diretório /usr/sbin, comum a todas as estações. O
segundo pode ser instalado localmente no diretório /usr/local/openoffice, pois se trata de um
aplicativo pesado, podendo aumentar o tráfego da rede, prejudicando a performance do sistema.
6. Conclusão
A estratégia de terminais inteligentes traz diversas vantagens para o planejamento de um ambiente
computacional, em especial para atender a atual demanda de instalação de Telecentros e laboratórios
educacionais. O script RBL é mais uma alternativa em Software Livre possibilitando a criação de
ambientes computacionais baratos, funcionais e eficientes, capazes de atender com qualidade as
necessidades dos mais diversos segmentos.
7. Referências
McQuillan, Jim, (2004) “Introduction to the Linux Terminal Server Projet (LTSP)”, In: V Fórum
Internacional do Software Livre, palestra agendada para 3/6/2004. Veja também
http://www.ltsp.org
Yu, William and Cimafranca, Dominique (2004) “Desktop Guerrilla Tactics: a Portable Thin Client
Approach”, http://www.linuxjournal.com/article.php?sid=7109, Abril.
Leung, C. T., (2004), “A computer Lab with no Windows, part I”, http://www.linuxjournal .
com/article.php?sid=7418. Fevereiro.
Leung, C. T., (2004), “A computer Lab with no Windows, part II”, http://www.linuxjournal .
com/article.php?sid=7419. Fevereiro.
Brin, Leon (2004) “Linux-based X Terminals with XDMCP” http://www.linuxjournal .
com/article.php?sid=6713. Maio.
Blake, kuo-Lien Huang, Steven Shiau and H. T. Wang, “Diskless Remote Boot Linux” , (2004)
http://drbl.nchc.gov.tw/
Agradecimentos
Trabalho de desenvolvimento tecnológico realizado em colaboração com a equipe LibertasBR, sob a
coordenação dos profs. Wagner Meira, Dorgival Neto e Renato Ferreira, DCC-UFMG. Suporte
financeiro: Instituto Doctum - Educação e Tecnologia e CNPq -Conselho Nacional de Pesquisa.
5° WSL / 5° FISL
Sessão Técnica 6
GERENCIAMENTO DE REDES & B2B
85
86
5° WSL / 5° FISL
5° WSL / 5° FISL
Um Sistema Simples de Gerenciamento Integrado de
Diretórios Online — OpenLDAP, NIS, Samba
Diego Luı́s Kreutz1∗, Cleverton Marlon Possani2
1 Núcleo
de Ciência da Computação — NCC
2 Laboratório
de Sistemas de Computação — LSC
Universidade Federal de Santa Maria — UFSM
CT, Campus Universitário – 97105-900 Santa Maria, RS
{kreutz,possani}@inf.ufsm.br
Abstract. The network administration is an important task every time more present in almost
any organization. Services like user data and authentication systems management are essential parts of the networks. The goal of this work is present a simple and practical system for
an integrated and sinchonized management of various information databases, as OpenLDAP,
NIS and Samba.
Resumo. A administração de redes é uma tarefa importante e cada vez mais presente em
praticamente qualquer organização. Serviços como o gerenciamento de dados de usuários e
sistemas de autenticação são partes essenciais das redes. O objetivo desse trabalho é apresentar um sistema simples e prático que possibilita o gerenciamento integrado e sı́ncrono de
diversas bases de informação, como o OpenLDAP, NIS e Samba.
1. Introdução
A administração de redes é uma tarefa importante e presente em praticamente qualquer curso ou laboratório de ensino de computação. Ao longo dos tempos inúmeras ferramentas e utilitários foram
desenvolvidos com o intuito de tornar o gerenciamento mais simples e prático.
O gerenciamento de sistemas de autenticaç ão e controle de usuários são algumas das partes
crı́ticas e normalmente dinâmicas em redes locais. Em uma rede local podem existem diretórios online
como o LDAP1 e o NIS2 . Além disso, é comum existir uma base de informações Samba, que realiza a
integração e unificação entre sistemas Unix e Windows.
Com o passar do tempo, inúmeras ferramentas e utilitários de administraç ão de serviços como
o LDAP, NIS e Samba foram criados. Alguns baseados em linha de comando e outros em interfaces
gráficas. Todos esses sistemas possuem suas particularidades. No entanto, poucos são os sistemas que
prezam pela simplicidade, facilidade de uso e adaptação e integração do gerenciamento desses sistemas.
O objetivo é apresentar um sistema simples, prático e que possibilita um gerenciamento integrado de diretórios online como o LDAP, NIS e Samba. Sua concepção foi baseada em necessidades
de laboratórios de ensino e pesquisa. Estes têm normalmente uma dinamicidade relativamente grande
de manutenção desses serviços. A cada semestre, por exemplo, é comum a necessidade de cadastro de
novos grupos de usuários. O sistema aqui apresentado possui alguns recursos e funcionalidades que
facilitam o cadastro e manutenção de bases de informação de usuários em ambientes desse gênero.
As seções seguintes apresentam uma breve abordagem sobre ferramentas de administração de
serviços de informação sobre usuários de redes locais, o sistema criado e a conclusão.
2. Ferramentas de gerenciamento do LDAP, NIS e Samba
O gerenciamento de diretórios online é uma necessidade antiga entre administradores de redes. Ferramentas como o Swat3 [Team, 2004], Webmin [Cameron et al., 2004], gerenciador de cadastros LDAP4
∗
Bolsista CNPq.
Lightweight Directory Access Protocol (protocolo leve de acesso a diretórios)
Network Information Service (serviço de informação de rede)
3
Samba Web Administration Tool (ferramenta Web de administração do Samba)
4
LDAP Account Manager (gerenciador de registros LDAP)
1
2
87
88
5° WSL / 5° FISL
[Duergner et al., 2003], o pacote yp-tools [Kukuk, 2003], ferramenta gráfica de configuração do Samba5
[Sam, ], gsmb [[email protected], 1999] e JXplorer [Betts, 2002] auxiliam os administradores de
rede a realizar tarefas de manutenção em serviços como o Samba, NIS e LDAP. A maior parte destas ferramentas são gerenciáveis por interface gráfica. No entanto, elas carecem no que diz respeito a integração
e ao gerenciamento de ambientes como os que figuram em redes locais de laboratórios de computação.
Cada uma dessas ferramentas possibilita o gerenciamento de alguns serviços. Possuem caracterı́sticas distintas e bastante particulares. Utilitários como o JXplorer e o LDAP Account Manager
possibilitam o gerenciamento de hieraquias e contas de usuários em diretórios LDAP. Já ferramentas
como o Swat e o gsmb facilitam a manipulação de contas em servidores Samba. O pacote yp-tools inclui
ferramentas para gerenciar diretórios do NIS. Com excessão do yp-tools, as demais ferramentas possuem interfaces gráficas simples e amistosas. Porém, dependendo do tipo de operação desejada, essas
interfaces tornam-se pouco práticas e flexı́veis.
O Webmin é uma ferramenta mais completa. Ela disponibiliza uma série de funcionalidades
administrativas. Entretanto, no que diz respeito a gerenciamento de diretórios online, como as demais
ferramentas, carece de flexibilidade e agilidade em alguns casos.
É nesse sentido que surgiu a idéia de um sistema de gerenciamento integrado de contas de
usuários do LDAP, NIS e Samba. Além de possibilitar esse gerenciamento, de forma simples e prática,
disponibiliza funcionalidades extras que podem agilizar o cadastro de conjuntos de novos usuários. Devido a sua simplicidade, esse sistema também é facilmente extensı́vel e adaptável a variados tipos de
ambientes e especificidades de domı́nios administrativos.
3. O sistema de gerenciamento
As contı́nuas e muitas vezes aceleradas mudanças nos ambientes educacionais, comerciais, culturais, governamentais e outros, fazem crescer de forma praticamente exponencial a importância da
informação e do gerenciamento desses dados. Uma ferramenta de integração LDAP, NIS e Samba, para
a administração de redes, é essencial para organizar, distribuir e sincronizar de forma segura e rápida as
informações necessárias para uso ininterrupto dos sistemas e usuários da organização.
O sistema foi criado a partir de necessidades gerenciais do NCC. Como era necessário manter
duas bases independentes, porém iguais, de usuários e, além disso, em todo inı́cio de sementre havia a
tarefa de cadastrar uma nova turma de usuários, decidiu-se criar um sistema simples e prático, porém,
suficientemente capaz de facilitar a administração e sincronizaç ão dos dados do OpenLDAP e do Samba.
A figura 1 apresenta algumas possibilidades de estruturaç ão do sistema para o gerenciamento
de uma ou mais bases de dados, de forma integrada e sincronizada. Onde o OpenLDAP e o NIS são
utilizados para gerenciar e autenticar usuários em sistemas Unix, logo, são excludentes. O Samba é
utilizado para autenticar usuários e compartilhar dados em ambientes Windows.
OpenLDAP
A
Samba
OpenLDAP
Sistema
C
Samba
B
Sistema
Samba
D
NIS
Sistema
Sistema
OpenLDAP
E
Samba
Sistema
Figura 1: Ilustraç ão de algumas possibilidades de utilizaç ão e funcionamento: A) gerenciando
apenas a base de informaç ões do OpenLDAP; B) manipulaç ão somente da base de
informações do Samba; C) gerenciando de forma integrada e sincronizada os dados do
Samba e do OpenLDAP; D) administraç ão integrada e sı́ncrona de dados entre o NIS
e o Samba; E) gerenciamento integrado do OpenLDAP e do Samba, com integraç ão
parcial entre os dois.
5
Samba GUI Configuration Tool (ferramenta gráfica de configuração do Samba)
5° WSL / 5° FISL
As arquiteturas A e B representam o sistema sendo utilizado para gerenciar apenas uma base de
informação. Já as arquiteturas C e D ilustram sistemas paralelos sendo gerenciados de forma integrada e
sı́ncrona, ou seja, os cadastros e manipulaç ões de dados de usuários são propagados para as duas bases
de dados, independentes.
A arquitetura E é carasterizada por um pequeno diferencial em relação a arquitetura C. Nesse
caso, é também realizado um gerenciamento sı́ncrono das bases de informação. Porém, o Samba armazena seus dados na banco de dados do OpenLDAP. Essa arquitetura poderia ser reduzida ao exemplo A,
com apenas alguns ajustes do sistema de gerenciamento integrado. Mas, por conveniência, praticidade
e padronizaç ão de interface de gerenciamento, é interessante manter uma organizaç ão semalhante ao
esquema C. No entanto, uma entrada LDAP poderá ser editada e alterada normalmente, podendo afetar
indiretamente os dados visualizados pelo Samba, ou seja, é um caso onde a alteração ou inclusão de
dados no OpenLDAP poderá ser refletida automáticamente no Samba, pois este armazena seus dados no
OpenLDAP. Todas essas arquiteturas são configuráveis no sistema. Isso é facilitado devido ao fato da
concepção do sistema ter sido baseada em principios como simplicidade, legibilidade e documentação.
As duas próximas seções apresentam algumas das caracterı́sticas e funcionalidades do sistema.
A primeira apresenta as funcionalidades mais comuns e padrão, enquanto que a segunda apresenta algunas funcionalidades mais especı́ficas ao sistema.
3.1. Funcionalidades padrão
O sistema foi desenvolvido para gerenciar de forma integrada diferentes manipuladores de informação,
como o OpenLDAP e o Samba. O objetivo é integrar e sincronizar os dados de bases distintas. Unificar
senhas, logins e tornar o gerenciamento mais prático e simples estão entre as metas do sistema.
Entre as funcionalidade padrão do sistema podem ser citadas: inclusão e remoção interativa de
um usuário, alteração de dados cadastrais de um usuário, troca de senha, inclusão e remoção de grupos, listagem de usuários e grupos, listagem de dados especı́ficos de um determinado grupo ou usuário,
listagem dos usuários que pertencem a um determinado grupo (o que pode gerar mais de uma consulta
a uma base OpenLDAP), bloqueio e liberação de usuários, troca de login, troca de shell, listagem de
usuários bloqueados, listagem de usuários com senhas expiradas e inclusão e remoção de usuários em
grupos. Grande parte dessas funcionalidades estão presentes em praticamente qualquer sistema de gerenciamento de diretórios online como o OpenLDAP, NIS e Samba.
3.2. Funcionalidades extras
Esse sistema, além das funcionalidades apresentadas na seção anterior, possui ainda alguns recursos
extras. A inclusão de conjuntos de usuários, a geração de arquivos de configuração de leitores de email e a inclusão de dados e modelos padrões nas homes dos usuários figuram entre as funcionalidades
especiais.
A partir de um único arquivo de texto, simples, é possı́vel gerar o cadastro simultâneo de um
número qualquer de usuários. Para isso basta dados como login, nome completo, grupo e diretório base
da home.
Na sequência é apresentado um exemplo do como seria esse arquivo de entrada para o cadastro
de inúmeros usuários de forma rápida e simples.
# usuario | nome | grupo | diretório base
banana|Banana Verde|administrador|/home/admin
laranja|Laranja do Agreste|grp2004|/home/usuarios
mato|Gato do Mato|especial|/home/visitantes
Na sequência aparece um exemplo de um arquivo de saı́da do cadastro desses supostos usuários.
# identificador |
senha randômica
| identificador login
nome do usuário
---------------------------------------------------------------------------------------------|
01
|
YuI8JkH
|
01
banana
NOME: Banana Verde
|
---------------------------------------------------------------------------------------------|
02
|
MTb32YA
|
02
laranja NOME: Laranja do Agreste
|
----------------------------------------------------------------------------------------------
89
90
5° WSL / 5° FISL
|
|
03
mato
NOME: Gato do Mato
|
---------------------------------------------------------------------------------------------03
|
aPn9lgO
Esse resultado final será convertido em um arquivo ps6 , pronto para ser impresso. O impresso
será separado em dois. Uma parte contendo identificador e senha e a outra parte contendo identificador
e login e nome do usuário. Os dados estão organizados por ordem alfabética do login. Cada usuário
receberá a sua senha provisória. Para tanto, basta destacar a senha do identificador e entrega-lá ao
usuário.
O sistema, além de gerar a conta de um usuário e uma senha randômica, gera também o diretório
raiz (home) com algumas configurações e dados padrão. São criados os arquivos de configuração básica
do shell, com alguns exemplos de uso, o diretório public html com exemplos simples e documentados
de páginas em html e php, é enviado um e-mail de boas vindas e informações sobre o uso da rede, bem
como é criada uma configuração automática para leitores de e-mail como o pine. Desta forma o usuário
recebe instruções básicas e essenciais de utilização e normas da rede. O que pode reduzir sensivelmente
as questões e dúvidas remetidas aos administradores da rede por usuários leigos.
No processo de geração do cadastro será avaliado a validade dos grupos e logins. Caso algum
grupo ainda não esteja cadastrado, será indicado a necessidade de cadastro do mesmo. Se algum login estiver duplicado no sistema também será alertado a necessidade de modificar o(s) login(s) problemático(s).
O administrador pode ainda optar por uma geração automática de logins. Neste caso, o sistema tentará
formar um login a partir do sobrenome e das iniciais dos demais nomes. Caso não seja possı́vel, ele
tentará opções como apenas as inicias do nome ou apenas o primeiro nome.
4. Conclusão
Muitas vezes o gerenciamento de sistemas de informação e autenticaç ão de redes locais é uma tarefa
pouco prática. É comum haver mais de uma base de dados de usuários da rede. Isso por que normalmente
são utilizados sistemas como o NIS, ou o OpenLDAP, e o Samba para a autenticação de sistemas Unix e
Windows, respectivamente. Logo, um sistema que possibilite um gerenciamento sı́ncrono e integrado é
interessante em um ambiente desse gênero.
O presente artigo apresentou um sistema simples e prático para realizar o gerenciamento integrado de diferentes bases de informação, como o OpenLDAP, NIS e Samba. Além disso, foram mostradas algumas caracterı́sticas que podem ser interessantes e facilitar a vida de administradores de laboratórios de computação em perı́odos como o inı́cio de semestre, onde existe uma probabilidade bastante
grande de vários usuários novos terem de ser cadastrados. [Kreutz and Possani, 2004]
Referências
Samba GUI Configuration Tool 1.0 Beta. http://www.eatonweb.com/samba/.
Betts, C. (2002). JXplorer - Java LDAP Browser. http://jxplorer.org.
Cameron, J., Klein, G., Alikhodjaev, A., Egeling, J., Waasdorp, H., III, T. J. M., and Lo, K. (2004).
Webmin. http://www.webmin.com/.
Duergner, M., Gruber, R., Lutz, T., and Walchshäusl, L. (2003). LDAP Account Manager. http:
//lam.sourceforge.net/.
[email protected] (1999). Gsmb - provides a graphycal interface allowing simplified management
of smbpasswd. http://www.culte.org/projets/developpement/gsmb/.
Kreutz, D. L. and Possani, C. M. (2004). SuperSimples: Um Sistema Simples e Prático para o Gerenciamento Integrado de Diretórios Online, sob licença GPL. http://www.inf.ufsm.br/
˜kreutz/downloads/SuperSimples.tar.gz.
Kukuk, T. (2003). Linux NIS Tools: yp-tools. http://www.linux-nis.org/nis/yp-tools/.
Team, S. (2004). Swat - Samba Web Administration Tool. http://us2.samba.org/samba/
samba.html.
6
PostScript (linguagem de descrição em alto nı́vel de páginas/telas/imagens impressas)
5° WSL / 5° FISL
Uma Ferramenta para a Administração de Serviços de
Diretório Distribuídos Baseados no OpenLDAP
Fernando William Cruz, Giovanni Almeida Santos, Raissa Dantas Freire de Medeiros,
Lucas Araújo Pereira, Márcio Carlos Braga, Roberto Diener
Universidade Católica de Brasília - UCB
QS 07 Lote 01 – Águas Claras – 71966-700 – Taguatinga – DF – Brasil
{fwcruz,giovanni,raissad}@ucb.br, [email protected],
Abstract. The LDAP free administration tools present some limitations. In general,
they allow object management in a centralized directory server, but they do not
provide a suitable manner to deal with distributed directories. This paper proposes
a free administration tool for an OpenLDAP-based distributed directory service,
which allows the graphical management of objects, partitions, replicas, schemas
and ACLs, without the direct access to OpenLDAP configuration files by the service
administrator.
Resumo. As ferramentas livres para administração de serviços de diretório LDAP
atualmente existentes são bastante limitadas, permitindo apenas a gerência de
objetos em servidores isolados. Esse artigo propõe uma ferramenta para
administração de serviços de diretório distribuídos baseados no OpenLDAP. Seu
uso permite gerenciar graficamente não apenas objetos, mas também partições,
réplicas, esquemas e ACLs sem a necessidade de manipulação direta dos arquivos
de configuração do diretório.
1. Introdução
Serviço de diretório é uma tecnologia que serve como suporte para a realização de atividades tais
como nomeação, localização e segurança, dentre outras, relacionadas à gestão da infraestrutura de
recursos (usuários, impressoras, servidores, etc.) nas organizações.
Nesse contexto, é possível perceber diversos tipos de serviços de diretórios. Dentre esses,
destacam-se o X.500, que faz parte do modelo de referência OSI/ISO [1], e o LDAP [2], que é
considerado um padrão de facto para serviços de diretório na Internet. Esses protocolos ganharam
aceitação em relação aos demais pelo fato de serem padrões abertos e de permitirem a incorporação
completa de serviços que sempre foram realizados por sistemas operacionais de rede [8].
Existem diversas implementações desses protocolos disponíveis atualmente, mas, no mundo
do código aberto, a implementação do LDAP de maior aceitação é o OpenLDAP [3]. Tal
implementação é bastante utilizada em plataformas Linux para construção de serviços de diretório
distribuídos. Em comparação com outras soluções de diretórios, o OpenLDAP apresenta um bom grau
de tolerância a falhas e um bom desempenho [6].
Contudo, administrar um serviço de diretório baseado no OpenLDAP ainda é uma tarefa
complexa. Há diversas ferramentas disponíveis – dentre as quais se destaca o phpLDAPadmin [4] contudo, elas apresentam algumas limitações:
i. Não facilitam a configuração do serviço de diretório, a qual é feita diretamente via
arquivos que possuem uma sintaxe específica. Isso inclui a definição de esquemas,
configuração de ACLs (Access Control Lists), administração de réplicas e partições.
91
92
5° WSL / 5° FISL
ii. Em geral, as corporações possuem objetos espalhados fisicamente em diferentes
servidores, mas não há o suporte adequado para a administração gráfica de objetos
distribuídos. Não é possível, por exemplo, que um administrador altere, remova ou
acrescente objetos numa partição remota se ele não é usuário local daquela partição,
mesmo que ele tenha autorização para tal. Na verdade, essa é uma característica do LDAP,
mas há mecanismos para tornar a administração de objetos distribuídos transparente [3].
iii. Não suportam autenticação de usuários em um serviço de diretório distribuído.
Sendo assim, esse artigo propõe uma ferramenta gráfica para a administração de serviços de
diretório baseados no OpenLDAP, tendo como foco a gerência de objetos, partições, réplicas e
esquemas em um ambiente distribuído. Na próxima seção, será detalhada a arquitetura da solução
proposta. Nas seções 3 e 4, são descritos os módulos que compõem a solução e suas funcionalidades.
Na seção 5, são descritos trabalhos futuros já vislumbrados.
2. Arquitetura da Ferramenta de Administração de Diretórios Distribuída (ADD)
Visando resolver os aspectos abordados na seção anterior com relação à melhoria da administração do
OpenLDAP e a sua gestão em ambientes distribuídos, propõe-se o ADD1 , cuja arquitetura está descrita
na Figura 1.
Figura 1. Arquitetura da Ferramenta de Administração de Diretórios Distribuída
Na Figura 1, os objetos da árvore de diretório estão distribuídos em duas partições - 01 e 02,
cada uma suportada por um anel de réplica (que emprega um esquema de replicação single-master
1
O ADD faz parte do GATI (Gerência de Ambiente de Tecnologia da Informação), um ambiente de
administração integrado que inclui outros módulos (que não são objeto desse documento) e está sendo
desenvolvido pelo CESMIC/UCB em convênio com a Itautec.
5° WSL / 5° FISL
[5]), cujo controle está centralizado num único ponto. Em relação ao anel, um dos servidores
desempenha o papel de mestre (master), aceitando operações de escrita e leitura, e os demais
representam réplicas apenas de leitura (slaves). O mestre é responsável pela atualização das réplicas,
de forma a garantir a sincronização da base de objetos entre eles. Todos os servidores de cada anel de
réplica têm o OpenLDAP instalado.
A arquitetura proposta é formada por dois módulos principais, de acordo com o que está
descrito a seguir:
ADD ADMIN: Instalado num servidor que possibilita efetuar operações administrativas sobre
o serviço de diretórios via WEB. Composto de funcionalidades que tratam da interface com o
administrador (s1, s2 e s3) e por uma API de gerência (representada na Figura 1 por f1, f2 e
f3). As funcionalidades associadas a essa interface fazem chamadas ao ADD API em
atendimento às requisições do usuário. O ADD API, por sua vez, faz requisições aos
servidores de diretório via LDAP ou, quando isso não é suficiente, invoca o ADD CORE
diretamente.
ADD CORE: Composto de funções que executam do lado dos servidores de diretório. Seu
objetivo é realizar operações sobre o serviço OpenLDAP propriamente dito, envolvendo
tarefas como reinicialização do servidor OpenLDAP e modificação de arquivos de
configuração.
O ADD ADMIN usa a linguagem Java (e tecnologias associadas, como JSP e Servlets) na sua
implementação, enquanto o ADD CORE é baseado em C. A seguir, serão descritas as principais
funcionalidades do ADD ADMIN e ADD CORE.
3. ADD ADMIN
Além da interface com o administrador, o ADD ADMIN possui uma API que é composta por cinco
sub-módulos, a saber:
Objeto Admin - responsável pela administração dos objetos armazenados no diretório. Permite
que sejam feitas operações de inclusão, alteração e remoção de objetos, independente da
partição em que estejam localizados. Além disso, objetos podem ser copiados ou movidos
dentro da árvore, inclusive para pontos localizados em partições distintas.
Partição Admin – provê funcionalidades associadas à gerência de partições do serviço de
diretório. Esse sub-módulo permite a criação e remoção de partições, cuidando da
redistribuíção dos obje tos entre as mesmas.
Replica Admin – permite administrar os servidores que compõem os anéis de réplica que
suportam as partições, podendo incluir, remover e visualizar status dos servidores, converter
master em réplica e vice-versa, reiniciar o serviço OpenLDAP, entre outras atividades.
ACL Admin – facilita a administração das permissões que os usuários têm sobre os objetos
contidos no diretório. Tais permissões podem ser aplicadas num objeto específico, sendo
automaticamente propagadas para todas as sub-árvores ou sub-partições existentes,
promovendo a herança de direitos na árvore distribuída. Além disso, abstrai a sintaxe do
OpenLDAP para a configuração de ACLs.
Esquema Admin – provê a gerência de esquemas do serviço de diretório, permitindo que estes
possam ser incluídos, removidos ou modificados. As modificações somente podem ser feitas
na partição raiz do diretório e são automaticamente propagadas para as demais partições, com
o objetivo de manter a consistência das informações.
Nas funcionalidades acima, são resolvidas as questões inicialmente apontadas como restrições
das ferramentas administrativas disponíveis. Está embutido no ADD um mecanismo de localização de
objetos que permite o login do administrador num serviço distribuído, independente da partição da
qual ele faz parte. Operações sobre objetos de partições diferentes daquela em que o administrador foi
93
94
5° WSL / 5° FISL
inicialmente autenticado são possíveis via SASL Proxy Authorization [2] [5]. Os sub-módulos do ADD
API (em conjunto com o ADD CORE) também dispensam a manipulação direta dos arquivos de
configuração do OpenLDAP por parte do administrador. A lista completa das funcionalidades e um
protótipo da interface do ADD podem ser encontrados em [7].
4. ADD CORE
O ADD CORE interage diretamente com os servidores OpenLDAP, em atendimento a chamadas
remotas do ADD API. Nesse sentido, é ele quem efetivamente realiza modificações nos arquivos de
configuração do serviço de diretório.
Algumas de suas funcionalidades incluem: configurar partições, acrescentar servidores num
anel de réplica, incluir diretivas de esquemas e de ACLs no arquivo slapd.conf [3], dentre outras.
5. Trabalhos Futuros
Numa primeira fase a ser concluída em setembro próximo, todas as funcionalidades descritas neste
documento estarão implementadas. Além disso, alguns melhoramentos são vislumbrados desde já para
uma outra fase a ser iniciada em outubro. O principal deles é o suporte a várias partições em uma
única máquina servidora e à administração das mesmas. Com relação à gerência de esquemas, esta
deverá incluir checagem automática de integridade, evitando que o administrador realize operações
indevidas (por exemplo, a alteração de um esquema que afeta objetos já existentes no diretório). A
gerência de réplicas fornecerá suporte ao esquema multimaster [2] [5] em adição ao esquema single master.
6. Agradecimentos
Agradecemos ao SERPRO pelo provimento de informações indispensáveis à realização desse trabalho
durante a fase de levantamento de requisitos da solução aqui proposta. Agradecemos ainda a Itautec
pelo apoio financeiro e parceria junto a Universidade Católica de Brasília.
7. Referências Bibliográficas
[1] Yeong, W., Howes, T. and Kille, S. X.500 Directory Access Protocol, RFC 1487, IETF, July 1993.
[2] Wahl, M., Coulbeck, A., Howes, T. and Kille, S. Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions, RFC 2252, IETF, December 1997.
[3] The Open Source LDAP suite, http://www.openldap.org. Fevereiro, 2004.
[4] The phpLDAPadmin tool, http://phpldapadmin.sourceforge.net. Fevereiro, 2004.
[5] Howes, T. A., Smith, M. C., Good, G. S. Understanding and Deploying LDAP Directory Services,
2nd Edition, Addison-Wesley, 2003.
[6] Thornton, E. J., Mundy, D. and Chadwick, D. W. A Comparative Performance Analysis of 7
Lightweight Directory Access Protocol Directories, IS Institute, University of Salford, Inglaterra,
May 2003.
[7] Medeiros, R., Santos, G. , Cruz, F., Pereira, L. and Diener, R. Especificação Técnica – Serviço de
Diretórios, Relatório Técnico 04-002B, Centro de Excelência em Servidores de Missão Crítica
(CESMIC), Universidade Católica de Brasília, Abril 2004.
[8] Tanembaum A. S., Steen M. Distributed Systems Principles and Paradigms.Prentice Hall, 2002.
5° WSL / 5° FISL
Projeto e-market: Implementando comércio eletrônico
de empresa para empresa usando software livre
Francisco Assis Nascimento1, Diogo Santinon1, Gabriel David1, Lucas C. Parlatto1
Faculdades de Taquara - FACCAT
Faculdade de Informática de Taquara – FIT
95600-000 – Taquara – RS – Brasil
{assis,diogo,gabriel,parlatto}@e-market.org.br
Abstract. This work presents a business to business (B2B) electronic
commerce portal developed at the scope of the e-market project. The objective
of the project is to develop technologies and tools based on free software to be
used in the implementation of e-commerce. As a first stage of the project, it
was implemented a B2B portal using free tools (e.g. Apache, PHP, and
PostgreSQL. The portal is called e-market (www.e-market.org.br) and its
source code can be downloaded from it. The implemented features of the
portal already allows that some kind of transactions (e.g. direct and reverse
auctions) be performed electronically using the Internet as well as the
exposition of products.
Resumo. Este trabalho apresenta um portal para comércio eletrônico de
empresa para empresa (B2B) desenvolvido no escopo do projeto e-market. O
projeto tem como objetivo desenvolver tecnologias e ferramentas baseadas em
software livre para serem empregadas na implementação de comércio
eletrônico. Como uma primeira fase do projeto, foi implementado um portal
B2B usando ferramentas como Apache, PHP e PostgreSQL. O portal é
chamado e-market e o código fonte pode ser obtido diretamente a partir dele.
Os recursos oferecidos pelo portal já permitem que empresas possam expor
seus produtos e, principalmente, interagir, realizando alguns tipos de
transações comerciais eletronicamente via Internet.
1. Introdução
Como em qualquer região industrial, existe um grande volume de transações comerciais
entre as várias empresas da região do Vale do Paranhana, no estado do Rio Grande do
Sul. Muitas dessas transações fazem parte da cadeia do ciclo produtivo de várias
indústrias e envolvem desde os fornecedores de matéria-prima até os distribuidores e
vendedores dos produtos industrializados. Geralmente, essas transações são realizadas,
por meio de um processo manual demorado e pouco eficiente. A empresa que precisa de
um determinado produto recebe documentos dos representantes de vendas de seus
fornecedores, escolhe as ofertas que parecerem mais interessantes e encaminha papéis
com os pedidos de compra.
Durante esse processo, nem sempre as melhores decisões são tomadas, seja por
falta de melhores informações sobre os produtos, seja pela falta de uma maior
integração entre as empresas, o que não permite uma avaliação efetiva de todas as
opções disponíveis no mercado. Além disso, muitas pequenas empresas que poderiam
participar deste processo acabam por não fazê-lo devido a sua pouca visibilidade no
mercado.
95
96
5° WSL / 5° FISL
Com o surgimento de redes de computadores de baixo custo (mais
especificamente, da Internet) que oferecem recursos de comunicação e automação
bastante eficientes, tem-se uma interessante alternativa para a melhoria da infraestrutura do comércio de empresa para empresa: o comércio eletrônico (electronic
commerce) [2]. O comércio eletrônico de empresa para empresa (business-to-business
electronic commerce ou B2B e-commerce) usa os recursos da Internet para realizar a
integração da cadeia de fornecedores em um dado ramo de negócios, a propaganda
direta entre empresas e os mercados eletrônicos [5]. O e-commerce é também um meio
que possibilita a troca de informações entre a empresa e seus clientes e fornecedores,
beneficiando todos os envolvidos. [3]
O projeto e-market, realizado na FIT - Faculdade de Informatica de Taquara,
com financiamento da própria Faculdade e do Governo do Estado do Rio Grande do Sul
por meio da Secretaria de Ciência e Tecnologia, se propõe justamente a desenvolver e
disseminar tecnologias livres e abertas para a implementação de comércio eletrônico de
empresa para empresa.
Dessa forma, um dos principais objetivos do projeto e-market é a
implementação de um portal, onde todas as empresas participantes disponham de um
espaço para não somente exporem os seus produtos como principalmente interagirem,
realizando suas transações comerciais eletronicamente via Internet. Aliás ainda mais
importante, toda a tecnologia desenvolvida pelo projeto fica à disposição de todos para
que possam implantá-la onde e como desejarem, ou mesmo aprimorá-la.
Esse trabalho apresenta o portal do projeto e-market, seus recursos e como eles
podem ser utilizados pelas empresas, além do estado atual do projeto e as perspectivas
futuras.
2. Portal do projeto e-market
O portal do projeto e-market (disponível em http://www.e-market.org.br) é um mercado
eletrônico que se destina aos negócios entre empresas. As empresas interessadas em
participar do projeto acessam o portal, efetuam um cadastramento e automaticamente,
passam a dispor de uma página da empresa com os dados fornecidos no cadastro. Ela
possui uma vitrine para exibir seus principais produtos, além de um catálogo completo
de todos eles, onde podem ser registradas informações sobre cada produto, incluindo
fotos e com a opção de se incluir o preço ou deixar sob consulta. Há um espaço para que
a empresa insira seu logo e imagens de divulgação (banners), personalizando assim
ainda mais o seu espaço no e-market. A figura 1 a seguir mostra a página principal do
portal e-market.
Figura 1. Portal e-market
Figura 2. Cotações
5° WSL / 5° FISL
O portal e-market oferece recursos para empresas realizarem alguns tipos de
transações comerciais, dentre elas: cotação, leilões direto e reverso.
2.1 Cotações
Neste serviço, como mostra a figura 2 acima, a empresa precisa descrever o produto
desejado, a quantidade que precisa, a data limite que as empresas terão para dar suas
ofertas, também podendo restringir os pedidos por categoria, cidade, estado e país, de
tal maneira que as empresas que não se enquadrem nas restrições não terão acesso a
essa cotação.
Para responder a cotação, existe uma página onde cada empresa poderá fazer a
sua oferta para cada pedido de cotação disponível, informando o preço, as condições e
se necessário alguma observação adicional. A empresa que fez o pedido de cotação terá
o total controle sobre as respostas para seus pedidos: se alguma satisfaz a seu interesse,
ela poderá fechar negociação a qualquer momento. Caso decorrido o prazo limite e não
for fechada a negociação, esta será dada como não finalizada e assim não efetivada.
Efetuando-se qualquer operação será enviado uma mensagem via correio
eletrônico e uma mensagem via caixa postal do próprio portal e-market para todas
empresas que satisfazerem as opções de restrição, informando os dados da cotação. O
aviso sobre o fechamento de negociações também é realizado dessa maneira, sendo
avisadas as empresas compradora e fornecedora.
2.2 Leilões diretos e reversos
As empresas contam com duas opções de leilões no portal e-market: direto e reverso.
Para incluir uma oferta de leilão direto (venda de um produto através de leilão) a
empresa deverá selecionar um de seus produtos, a quantidade, o preço minímo, a data
limite e as restrições para o lance. Para efetuar os lances, as empresas deverão dar o
valor que pretendem pagar pela oferta, e se necessário podem preencher um quadro com
observações.
Para incluir uma oferta de leilão reverso (compra de um produto através de um
leilão), a empresa deverá descrever o produto, a quantidade e a data limite, e informar o
preço máximo. As empresas interessadas em dar algum lance reverso tem que fornecer
o valor para aquela oferta de leilão, e se quiser alguma observação adicional.
A empresa que fez a oferta de leilão poderá fecha-lo o leilão quando chegar a
data limite, escolhendo o melhor lance de acordo com sua análise. Como nas cotações,
as empresas terão o total controle sobre as ofertas do leilão, podendo visualizar todos os
lances dados. Mas, decorrido o prazo limite, a transação será dada como não realizada
caso não tenha sido fechada a negociação pela empresa que ofereceu o leilão. Também
como nas cotações, as comunicações são realizadas via correio eletrônico.
3. Implementação usando Software Livre
O portal do projeto e-market se encontra em funcionamento e está aberto para novas
parcerias que visem desenvolver novas ferramentas para comércio eletrônico.
Atualmente, o portal conta com 27 empresas parceiras, sendo que a FACCAT é uma das
empresas parceiras com um papel fundamental para o desenvolvimento do projeto, já
automatizando várias de suas compras através do portal.
Todo o desenvolvimento e implementação do portal e-market foi feito com software
livre e todo o código fonte pode ser obtido a partir do próprio portal. No projeto
adotou-se: o sistema operacional GNU/Linux nos servidores, incluindo uma máquina
97
98
5° WSL / 5° FISL
gateway com recursos de firewalling (usando iptables) e detecção de intrusão (com
Snort) [4], e em todas as máquinas de desenvolvimento; o servidor web Apache [6] com
suporte à linguagem PHP [1], que foi usada com seus recursos de orientação a objetos
na implementação das páginas do portal, rodando em um servidor em uma zona
desmilitarizada [4]; o gerenciador de banco de dados PostgreSQL [12] instalado em
uma máquina servidora protegida pelo firewall; a ferramenta IDE Eclipse [11] com
plugins para PHP [7] e CVS [9], que foi usado para trabalho cooperativo, instalado nas
máquinas de desenvolvimento; a ferramenta Poseidon para edição dos diagramas UML
[8] da modelagem da API desenvolvida para o portal; e a ferramenta DB Designer4 [13]
para os diagramas do banco de dados.
Atualmente, a equipe do projeto está trabalhando para acrescentar novos recursos:
• um histórico, onde as empresas terão várias informações sobre as negociações, sobre
transações realizadas ou não, relatórios sobre compradores e vendedores de
transações em que estiram envolvidas, etc.
• um sistema de avaliação, visando dar preferência às empresas melhor qualificadas,
podendo-se ao final da transação informar se esta foi efetivada positivamente ou
negativamente, comentando-a. Cada empresa terá um histórico das avaliações
realizadas e recebidas, disponível para consulta de qualquer empresa.
4. Conclusão
O portal e-market apresentado neste trabalho, tem sido usado como plataforma para a
pesquisa e o desenvolvimento de novas tecnologias voltadas para o comércio eletrônico
e espera-se que o projeto ajude a difundir o uso dos recurso da Internet nas várias
empresas da região de modo que, futuramente, se possa pensar em novas estratégias e
técnicas para as outras modalidades de comércio eletrônico, em particular, o comércio
eletrônico de empresa voltada para o setor público (B2G).
5. Referências
[1] SOARES, WALACE,. Crie um site B2C – Business to consumer: com PHP 4 e
MySQL. Segunda edição. São Paulo: Érica, 2001.
[2] MURTA, C.D. et al. Sistemas de comércio eletrônico projeto e desenvolvimento.
Rio de Janeiro: Campus, 2002.
[3] CUNNINGHAM , MICHAEL, J. B2B Business to Business: como implementar
estratégias de e-commerce entre empresas. Rio de Janeiro: Campus, 2000.
[4] TOXEN, B. Real world Linux security, Prentice Hall, 2001.
[5] LINTHICUM, D, S. B2B Application Integration. Addison-Wesley, Boston, 2001.
[6] HOLDEN, G. et al. Apache server, Makron Books, São Paulo, 2000.
[7] PHP Net. Disponível em <http://www.php.net>. Acessado em 6 maio 2004.
[8] CARLSON, D. Modelagem de aplicações XML com UML: aplicações práticas em
e-Business, Ed. Makron Books, São Paulo, 2002.
[9] CVS Home. Disponível em <http://www.cvshome.org>. Acessado em 6 maio 2004.
[10] Snort. Disponível em <http://www.snort.org>. Acessado em 10 abril 2004.
[11] Eclipse. Disponível em <http://www.eclipse.org> . Acessado em 15 abril 2004.
[12] PostgreSQL. Disponível em <http://www.postgresql.org>. Acessado em 06 maio
2004.
[13] DBDesigner 4. Disponível em <http://www.fabforce.net/dbdesigner4>. Acessado
em 6 maio 2004.
5° WSL / 5° FISL
Sessão Técnica 7
TOLERÂNCIA A FALHAS & EDUCAÇÃO
99
100
5° WSL / 5° FISL
5° WSL / 5° FISL
Validação experimental de sistemas de arquivos baseados em journaling para o sistema
operacional Linux
Leonardo Garcia de Mello
Caixa Postal 15.064 – CEP 91.501-970 – Porto Alegre – RS – Brazil
[email protected]
Abstract. Operating systems are important to high availability, and those that have secure
filesystems relatively independent of human actions for recovery should be preferred. One
of the approaches to gain high availability for filesystems are those based upon journaling,
or meta-data logging. There is a series of journaling filesystems for Linux operating system,
as ext3, JFS, ReiserFS and XFS. This works aims to propose a way to experimentally
validate journaling filesystems efficiency. To do so, the techniques of Software Fault
Injection are used for validation and the system target is an XFS implementation..
Resumo. Sistemas operacionais são importantes para alta disponibilidade, sendo preferível
o uso daqueles que possuam sistemas de arquivos seguros e relativamente independentes de
ações por agentes humanos para a recuperação. Uma das abordagens para obter-se uma
alta disponibilidade em sistemas de arquivos é a do tipo journaling, ou log de metadados.
Existem vários sistemas de arquivos para o Linux baseando-se nela, tais como ext3, JFS,
ReiserFS e XFS. Este artigo propõe uma metodologia de validação experimental para
avaliar a eficiência do mecanismo de journaling. As técnicas de Injeção de Falhas por
Sofware são utilizadas para validação e o sistema alvo é uma implementação do XFS.
1. Introdução
O termo comercialmente conhecido como “alta disponibilidade” (também referenciado como HA,
de High Availability) representa uma característica de sistemas computacionais projetados para evitar
ao máximo as interrupções, planejadas ou não, na prestação de serviços. Em alta disponibilidade, o
ideal é haver poucas falhas e, mesmo quando estas acontecerem, que o seu tempo médio de reparo (ou
MTTR, de Mean Time To Repair) seja tão pequeno quanto possível.
Atualmente o Linux é muito utilizado em servidores [BAR 2000], em um cenário onde os
requisitos quanto à disponibilidade geralmente são bastante elevados. Praticamente todas as
plataformas atuais dispõem de sistemas de arquivos com alta disponibilidade [SEL 2000], mas o ext2
(sistema de arquivos convencional para o Linux) não possui esta característica. Para uso em aplicações
críticas, existe uma série de sistemas de arquivos baseados em journaling para o Linux, tais como
ext3, JFS, ReiserFS e XFS.
Este trabalho propõe uma metodologia de validação experimental para avaliar a eficiência do
mecanismo de journaling para sistemas de arquivos. Para isso, a técnica de validação empregada é a
da injeção de falhas por software [HSU 97], e o sistema alvo é uma implementação do XFS.
No grupo de Tolerância a Falhas da UFRGS realiza-se a validação experimental de mecanismos
que permitam maior tolerância a falhas para sistemas operacionais. Desta maneira, este artigo
apresenta um trabalho sobre injeção de falhas em sistemas de arquivos baseados em journaling para o
Linux. É apresentado o modelo de falhas sob o qual foi feito o desenvolvimento de uma ferramenta
para injeção de falhas em sistemas de arquivos baseados em journaling – o FIJI.
2. Integridade para dados e metadados
No Unix, informações são organizadas em disco na forma de dados e metadados. Durante as
operações envolvendo dados e metadados, é preciso que a representação do sistema de arquivos nos
discos seja mantida consistente – isso mesmo após a ocorrência de falhas. Em sistemas de arquivos
como o ext2, construídos com alocação baseada em blocos, o sistema de arquivos pode ficar
inconsistente após a ocorrência de falhas porque dados e metadados são gravados em disco de forma
101
102
5° WSL / 5° FISL
assíncrona por razões de desempenho. Sempre que algo assim acontece, é preciso executar algum
utilitário de verificação - como o fsck [BAR 2000].
O fsck realiza uma série de passos ao longo de todo o sistema de arquivos de um dispositivo, para
validar as suas entradas e assegurar-se de que blocos alocados em disco estão todos sendo
referenciados corretamente. Mas infelizmente, para discos de tamanho muito grande, a execução do
fsck pode consumir um tempo bastante elevado. Em uma máquina com muitos gigabytes em arquivos,
por exemplo, a execução do fsck pode demorar até 10 horas ou mais [BAR 2000]. Além disso,
conforme a severidade do caso, pode ser necessária a presença física do administrador do sistema para
informar a senha do usuário root e executar manualmente o fsck.
Assim, levando-se em conta essas dificuldades, surgiram as propostas de sistemas de arquivos
para alta disponibilidade. Por meio deles, é possível diminuir a chance de serem introduzidas
inconsistências nos sistemas de arquivos e reduzir o tempo médio de reparo (ou MTTR) na ocorrência
de falhas. Atualmente as principais técnicas empregadas para auxiliar a obter alta disponibilidade em
sistemas de arquivos Unix são o journaling e o Soft Updates [SEL 2000].
Enquanto a técnica de Soft Updates apenas é utilizada em sistemas BSD, a técnica de journaling
baseia-se na redundância para aumentar a confiabilidade dos dados e metadados - mas sem aumentar
significativamente os custos de hardware. Ela já é adotada por sistemas de arquivos em sistemas
operacionais para plataformas diversas, tais como Solaris, AIX, Digital UNIX, HP-Ux, Irix e
Windows NT [SEL 2000]. Mas apesar de os sistemas de arquivos baseados em journaling haverem
sido adotados quase como um padrão pela indústria de software, atualmente não se encontram
publicações sobre avaliação de medidas da sua disponibilidade.
3. Sistemas de arquivos baseados em journaling
Sistemas de arquivos baseados em journaling fazem um controle sobre as mudanças realizadas ou
nos metadados (para JFS, ReiserFS e XFS), ou nos dados e metadados (para ext3) associados a um
sistema de arquivos. A idéia consiste em tratar diferentemente dados e metadados, usando uma área
dedicada em disco (o log, ou journal) para manter um histórico das mudanças.
Estes sistemas de arquivos implementam uma política de write-ahead logging, fazendo com que
registros sejam armazenados no log antes de as operações serem efetuadas [SEL 2000]. Este tipo de
sistema de arquivos pode ser empregado com desempenho ótimo para aplicações que lidem com
arquivos pequenos e façam uso freqüente da chamada de sistema sync. Isso acontece porque várias
alterações nos metadados são transferidas para o disco através de uma única operação, que acrescenta
várias transações em uma mesma área [SEL 2000].
Uma grande vantagem da abordagem baseada em journaling é de que ela facilita obter alta
disponibilidade em sistemas de arquivos já existentes. Exemplo disso é o resultado que pôde ser obtido
com o sistema de arquivos ext2, que pôde ser reimplementado como sendo o ext3 [TWE 2003].
Quanto aos tempo de recuperação, para sistemas de arquivos baseados em journaling eles são
bastante reduzidos. A tarefa de verificação consiste apenas em inspecionar as transações pendentes do
log - ao invés de percorrer todos os blocos buscando inconsistências. Com isso, na ocorrência de
defeitos, o sistema de arquivos pode ser levado a um estado consistente pela aplicação das transações
pendentes no log - ao invés de ser necessário inspecionar toda uma unidade de disco com o fsck.
3.1.
O sistema de arquivos XFS
O XFS possui uma grande confiabilidade, pois foi criado ainda em 1994 pela SGI para substituir o
EFS [XFS 2003]. Ele é o mais antigo entre os sistemas de arquivos conhecidos, e a ênfase do seu
projeto foi na capacidade de trabalhar com arquivos bastante grandes - da ordem de "terabytes".
O XFS pode trabalhar usando um tamanho de bloco variando entre 512 bytes e 64 kbytes,
provendo o suporte para sistemas de arquivos distribuídos (incluindo NFS versão 3), ACLs no padrão
POSIX 1003.e, e quotas para usuários e grupos.
O estado de um sistema de arquivos XFS é o resultado da combinação de informações localizadas
em três lugares diferentes: disco, memória e log do journaling. O sistema de arquivos XFS somente
estará em um estado consistente após ele ter sofrido shutdown, onde todos os dados residentes em
memória (buffers e cache) são gravados em disco e todas as entradas do log de transações são
aplicadas no sistema de arquivos.
5° WSL / 5° FISL
103
4. Injeção de falhas no XFS
Para a realização de um experimento de injeção de falhas, faz-se necessária a definição de um
modelo de falhas. Um modelo de falhas permite-nos repetir um experimento tantas vezes quantas
forem necessárias para atingir o objetivo. Para este caso, o objetivo é detectar erros que possam
ocorrer durante a utilização de um sistema de arquivos baseado em journaling.
A maioria dos mecanismos de tolerância a falhas disponíveis nos sistemas de arquivos baseados
em journaling consideram principalmente as falhas de hardware transientes (mais especificamente de
falta de energia), onde assume-se um modelo de crash para o sistema. Isto representa uma situação em
que o sistema de arquivos estaria sendo utilizado e ocorreria a falha, fazendo com que a máquina fosse
reiniciada sem que ocorresse um flush das informações em memória (tais como buffers e cache) ou das
transações no log (elementos que, conforme a Seção 3.1, definem o estado do sistema de arquivos).
Este modelo de falhas define o conjunto de falhas que deve ser gerado pela ferramenta FIJI.
5. FIJI
A ferramenta FIJI (Fault INjector for Journaling fIlesystems), desenvolvida no PPGC da UFRGS,
é baseada nos recursos de depuração do sistema operacional Linux (os quais permitem a interceptação
e manipulação de chamadas de sistema) para a implementação de um injetor de falhas específico para
sistemas de arquivos baseados em journaling. Manipular os parâmetros de chamadas de sistema (ou
system calls) equivale a alterar as requisições feitas ao sistema operacional.
O FIJI é implementado como um processo concorrente à aplicação alvo, usando os recursos
oferecidos pelo sistema operacional Linux através da chamada de sistema ptrace. A chamada de
sistema ptrace permite executar um processo de três maneiras: passo-a-passo, usando breakpoints ou
executá-lo até a próxima chamada de sistema.
Conceitualmente, o FIJI localiza-se entre a aplicação alvo e o sistema operacional. As falhas
injetadas pelo FIJI estão de acordo com o modelo de falhas descrito anteriormente, e encontram-se
especificadas no código-fonte da própria ferramenta.
Mais especificamente, o que procura-se fazer através do injetor de falhas FIJI é manipular uma
quantidade de informações diferente daquela que foi solicitada originalmente. Para isso, é feita uma
alteração nas chamadas de sistema write para mudar a quantidade de bytes que deve ser gravada
(registrador EDX). Um parâmetro deve ser informado para o FIJI pela linha de comando, informando
dentro de quantos segundos as chamadas de sistemas write deverão começar a ser suprimidas.
6. Arquitetura para injeção de falhas
Por meio do injetor de falhas FIJI, espera-se poder caracterizar um ambiente de falhas como o que
está definido na Figura 1. De acordo com esta figura, o sistema alvo é uma máquina com uma partição
Linux. Neste sistema alvo, foi criada uma partição para os testes. Esta partição deverá ser formatada
com o utilitário mkfs.xfs [XFS 2003].
Sistema para injeção de falhas
Operador
humano
Injetor de
Falhas
FIJI
Injetor de
Carga de
trabalho
Bonnie
Monitor
Ptrace
Coletor de
dados
Análise de
dados
Sistema alvo
Máquina Linux com
partição XFS
104
5° WSL / 5° FISL
Figura 1 – Ambiente ideal para injeção de falhas
O componente controle é um ser humano, quem coordena a realização dos experimentos. A
função de injetor de falhas é executada pela ferramenta FIJI. Desta maneira, é possível simular a
ocorrência de falhas do tipo crash.
A função de gerador de carga de trabalho é feita pelo utilitário bonnie, que deve gerar um
workload correspondente às aplicações reais - tais como arquivos muito grandes (mais de 130 Mb),
arquivos pequenos (menos de 600 Kb), servidor de arquivos, servidor de email, etc.
Espera-se poder determinar a cobertura de falhas e o tempo de recuperação para o sistema de
arquivos XFS.
7. Conclusões
Os trabalhos em andamento pelo grupo envolvem os sistemas de arquivos baseados em journaling
para uma validação de suas propriedades relacionadas com alta disponibilidade. Atualmente estão
sendo conduzidos experimentos para consolidar o ambiente de acordo com uma metodologia
desenvolvida pelo grupo de tolerância a falhas da UFRGS e aplicada com sucesso em sistemas de
banco de dados.
Os experimentos estão direcionados para XFS em Linux, mas espera-se que a metodologia seja
suficientemente genérica e portável para permitir a validação de uma vasta gama de sistemas de
arquivos baseados em journaling. Dados obtidos preliminarmente com os experimentos manuais
comprovam a redução do tempo de recuperação em pelo menos uma ordem de grandeza no tempo no
sistema XFS se comparado com sistemas de arquivos convencionais, como o ext2, sob uma mesma
carga de trabalho.
8. Referências bibliográficas
[BAR 2000] BAR, Moshe. Linux Kernel Internals. New York: McGraw-Hill, 2000, 351 p.
[HSU 97] HSUEH, Mei-Chen; TSAI, Timothy K.; IYER, Ravishankar K. Fault-Injection Techniques
and Tools. Computer, v. 30, n. 4, Apr 1997, p.75-82.
[SEL 2000] SELTZER, M. I.; et. al. Journaling versus soft-updates: Asynchronous meta-data
protection in file systems. In: USENIX ANNUAL TECHNICAL CONFERENCE, 2000.
Proceedings... San Diego, California, USA, 2000. Disponível em: < http://
www.lcs.ece.cmu.edu/~soule/papers/seltzer.pdf>. Acesso em: ago. 2003.
[TWE 2003] TWEEDIE, Stephen C. Ext3, Journaling Filesystem for Linux. In: OTTAWA LINUX
SYMPOSIUM,
2000.
Disponível
em:
Proceedings...
<http://olstrans.sourceforge.net/release/OLS2000-ext3/OLS2000-ext3.html>.
Acesso
em: out. 2003
[XFS 2003] Sistema de arquivos XFS para Linux. Disponível em: <http://xfs.sourceforge.net>.
Acesso em: ago. 2003.
5° WSL / 5° FISL
GroupPac: Um Suporte Livre Para Tolerância a Faltas ∗
Alysson Neves Bessani1†, Eduardo Adı́lio Pelinson Alchieri1‡,
Joni da Silva Fraga1 , Lau Cheuk Lung 2 ,
Luciana Moreira Sá de Souza1 , Ricardo Sangoi Padilha1
{neves,alchieri,fraga,luciana,padilha}@das.ufsc.br, [email protected]
1 DAS
- Departamento de Automação e Sistemas
UFSC - Universidade Federal de Santa Catarina
Campus Universitário, Caixa Postal 476 - CEP 88040-900 - Trindade - Florianópolis - SC
2 PPGIA
- Programa de Pós-Graduação em Informática Aplicada
PUC-PR - Pontifı́cia Universidade Católica do Paraná
R. Imaculada Conceição, 1155 - Prado velho - CEP 80215-901 - Curitiba -PR
Resumo. As pesquisas em tolerância a faltas em sistemas distribuı́dos têm um importante papel no desenvolvimento de aplicações confiáveis. Este trabalho apresenta a
ferramenta G ROUP PAC juntamente com seus serviços que incluem suporte à tolerância
a faltas na arquitetura CORBA fazendo uso de técnicas de replicação de objetos. O
G ROUP PAC é uma implementação de código aberto do padrão FT-CORBA produzida
nos laboratórios UFSC visando prover uma suporte de middleware tolerante a faltas
de alta qualidade.
Abstract. The research about fault tolerance in distributed systems take a important
role in the development of trustful applications. This paper presents the G ROU PAC tool
with the services that include fault tolerance support in the CORBA architecture using
replicated objects. The G ROUP PAC is a open-source FT-CORBA implementation created at UFSC labs with the main goal of provide a high quality fault-tolerant middleware
support.
1. Introdução
Visando definir uma arquitetura para objetos distribuı́dos tolerantes a faltas, a OMG
(Object Management Group) criou o padrão FT-CORBA (Fault-Tolerant CORBA)
[Object Management Group, 2002]. Este padrão introduz suporte à tolerância a faltas na
arquitetura CORBA fazendo uso de técnicas de replicação de objetos. Este suporte é construı́do a
partir de um conjunto de objetos de serviço usados no gerenciamento de objetos de aplicação que
são replicados usando abstraç ões de grupos. A tolerância a faltas fornecida usando os serviços
definidos pelo padrão está fundamentada em premissas de falhas de parada.
As implementaç ões do FT-CORBA se reduzem a poucas experiências acadêmicas: o
G ROUP PAC que será apresentado neste trabalho, o IRL desenvolvido na Università di Roma “La
Sapienza”, o DOOR S desenvolvido no Bell-Labs, e o E TERNAL desenvolvido originalmente pela
Universidade da Califórnia - Santa Bárbara e atualmente comercializado pela Eternal Systems.
Com relação ao G ROUP PAC, é a única implementação completa do padrão aberto FT-CORBA
desenvolvida dentro da filosofia de software livre. A implementação de uma plataforma de middleware deste porte, considerando a especificação FT-CORBA, envolvem pesquisas desenvolvidas
na UFSC desde 1999, quando as primeiras versões do G ROUP PAC foram lançadas.
Naturalmente, como o G ROUP PAC foi originado a partir de protótipos gerados em projetos
de pesquisa, ele ainda está longe da qualidade exigida de um software maduro, que possa ser usado
∗
†
‡
Realizado com recursos do CNPq (projeto número 401802/2003-5).
Bolsista PGI/CNPq.
Bolsista PIBIC/CNPq.
105
106
5° WSL / 5° FISL
em projetos reais. Esta situação se acentua se levarmos em consideraç ão o ambiente para o qual
o G ROUP PAC foi desenvolvido: software crı́tico. Desta forma, em dezembro do ano passado o
projeto foi contemplado com um aporte de recursos do CNPq (Projeto CT-INFO/Software Livre)
para sua transformaç ão de protótipo para um produto de qualidade, que possa ser usado pelos
diferentes setores da sociedade que necessitam desenvolver software de alta disponibilidade.
Este artigo traz uma breve introduç ão ao G ROUP PAC. Sua arquitetura básica e seus objetos
de serviço são descritos na seção 2, na seção 3 temos algumas consideraç ões a respeito de sua
implementação e na seção 4 são apresentadas as conclusões do artigo.
2. G ROUP PAC
O G ROUP PAC [Lung et al., 2001] é uma implementação completa do padrão FT-CORBA desenvolvida pelo grupo de sistemas distribuı́dos do LCMI/DAS/UFSC. Inicialmente desenvolvido para
dar suporte a sistemas de larga escala, o G ROUP PAC foi uma das primeiras implementações do
padrão FT-CORBA desenvolvidas, e ainda hoje é uma das poucas disponibilizadas livremente
(http://grouppac.sourceforge.net). A idéia básica é fornecer um conjunto de serviços e facilidades para a construção de aplicações tolerantes a falhas. Estes serviços estão representados na
arquitetura da figura 1.
Gerenciamento de
Replicação
notificação
Notificador de Falhas
Detector de Falha de Host
is_alive()
create_object()
Host 1
Host 2
Detector de Falha
de Processo
Processo 2
is_alive()
Fábrica
Host 3
Detector de Falha
de Processo
Processo 3
is_alive()
Fábrica
Processo 1
Objeto
Servidor 1
Cliente
Objeto
Servidor 2
Detector de
Falha de Objeto
Detector de
Falha de Objeto
is_alive()
ORB
is_alive()
ORB
ORB
Mecanismo
de Logging
Mecanismo de
Recuperação
Mecanismo
de Logging
Mecanismo de
Recuperação
Sistema de Comunicação de Grupo
Figura 1: Arquitetura FT-CORBA/G ROUP PAC.
O serviços apresentados na figura 1 fornecem toda a infraestrutura básica para o suporte a
tolerância a faltas em objetos distribuı́dos CORBA. Dentre estes serviços alguns merecem maior
destaque (para maiores detalhes veja [Lung et al., 2000]):
Serviço de Gerenciamento de Replicação - SGR: Para dar suporte a replicação de objetos,
um serviço de fundamental importância é o gerenciamento de grupos. Este serviço é
responsável pelo ciclo de vida dos grupos de réplicas. Duas funcionalidades básicas
são oferecidas pelo mesmo: Gerenciamento de Propriedades, onde as propriedades da
replicação (tipo de replicação usada, número mı́nimo de réplicas, etc.) são definidas e alteradas; e o Gerenciamento de Grupos, que oferece mecanismos para o controle da criação
e destruição de grupos, bem como de seus membros (réplicas). Outra caracterı́stica de
fundamental importância a cargo do gerenciador de replicação é a manutenção de uma
referência de grupo (que contém o endereço de todas as réplicas), cuidando das entradas
e saı́das de membros do grupo e mantendo uma lista atualizada das réplicas pertencentes
ao mesmo (membership).
5° WSL / 5° FISL
Serviço de Gerenciamento de Falhas - SGF:Envolve um conjunto de objetos que cooperam
na detecção, notificação, análise e diagnóstico de falhas. Quando uma falha é detectada
esta é repassada ao SGR para que este execute as ações necessárias e mantenha a lista de
membros sempre atualizada. Existem três nı́veis de detecção de falhas: objetos, processos
e hosts. A monitoração é realizada através do envio periódico de mensagens do tipo
is alive() aos objetos monitorados.
Serviço de Gerenciamento de Recuperação e Logging - SRL: O SRL é responsável pela consistência dos estados das réplicas. Este serviço define mecanismos para a recuperação
de réplicas e do próprio grupo, bem como da configuração de estados em membros que
entram no grupo após o serviço replicado já estar em funcionamento. Entre estes mecanismos está um suporte para construção de logs usados no armazenamento de requisiç ões
enviadas ao grupo e um mecanismo para atualização de membros através de checkpoints.
Além disso também é responsabilidade do SRL atuar na recuperaç ão de réplicas faltosas
através da atualização de seus estados.
Serviço de Comunicação de Grupo - SCG:Algumas atividades realizadas pelo G ROUP PAC,
em especial a replicação ativa [Schneider, 1990], necessita de serviços de comunicação
de grupo mais elaborados, usualmente disponibilizados por ferramentas de comunicação
de grupos. Diante disto foi criado o framework SCG (Suporte de Comunicação de Grupo)
[Bessani et al., 2004b], que define um mecanismo através do qual o G ROUP PAC interage com diferentes ferramentas de comunicação de grupo para utilizar os serviços de
comunicação necessárias a ele. Através deste mecanismo é possı́vel a integração de qualquer suporte de comunicação de grupo a arquitetura do FT-CORBA através da construção
de adaptadores que se integram como plugins no G ROUP PAC.
Atualmente
estão
implementados
plugins
para
as
ferramentas
ENSEMBLE
(http://www.cs.cornell.edu/Info/Projects/Ensemble/ )
e
JG ROUPS
(http://www.jgroups.org) e para o protocolo baseado em serviços do próprio ORB
[Bessani et al., 2002].
Existem ainda outros serviços no G ROUP PAC, como por exemplo o Serviço de
Inicialização, responsável pela criação e inicializaç ão dos demais serviços e o Serviço de Transferência de Estados, usado para a transferência de estado entre as réplicas em caso de falta ou
inclusão de novos membros em um grupo.
O G ROUP PAC conta ainda com ferramentas administrativas que permitem a criação e
gerenciamento de grupos de réplicas. Estes grupo podem ser especificados em arquivos XML
(respeitando uma sintaxe definida por um XML Schema) ou através de uma ferramenta gráfica.
Estes mecanismos são descritos com detalhes em [Bessani et al., 2004a].
3. Implementação
A implementação do G ROUP PAC vem sendo realizada desde 1999, e atualmente se encontra na sua
versão 3.0. O software está disponı́vel em seu sı́tio na Internet (http://grouppac.sourceforge.net)
sob licença GPL. As implementações são feitas utilizando a linguagem Java tendo como base o
ORB JAC ORB (http://www.jacorb.org). Tanto este ORB como todas as demais ferramentas e
pacotes de software utilizados também são livres.
Atualmente estão sendo desenvolvidos testes unitários para o G ROUP PAC, através da
ferramenta JU NIT (HTTP :// WWW. JUNIT. ORG)´. Além disso o projeto está sendo documentado
através da construção de javadocs e de um manual de referência.
4. Conclusão
Este trabalho apresentou brevemente o G ROUP PAC, um middleware que implementa as
especificações FT-CORBA e introduz suporte à tolerância a faltas na arquitetura CORBA fazendo
uso de técnicas de replicação de objetos. As vantagens de se ter um suporte a tolerância a faltas de
107
108
5° WSL / 5° FISL
alta qualidade aberto1 e desenvolvido no Brasil são muitas: a liberdade na construção de sistemas
crı́ticos (sempre necessários em setores delicados como saúde, militar, aeroespacial e finanças), a
facilidade em se alterar este software na medida das necessidades do projeto em questão, a não
dependência de pacotes de software comerciais de alto custo que desempenham a mesma função
(geralmente provenientes de empresas estrangeiras) e a geração de mão de obra qualificada neste
tipo de ambiente, são só algumas destas vantagens.
Construir uma aplicação tolerante a faltas a partir deste middleware é relativamente simples, uma vez que a complexidade inerente aos protocolos de comunicação e gerência de grupos
é toda encapsulada no suporte, deixando os desenvolvedores apenas com os aspectos funcionais
da aplicação. Nossas iniciativas atuais pretendem tornar esta tarefa ainda mais simples através da
integração dos serviços do GroupPac com ferramentas de desenvolvimento Java. Esta integração
se dará através de plugins para as ferramentas N ETBEANS (http://http.netbeans.org) e E CLIPSE
(http://http.eclipse.org).
Referências
Bessani, A. N., Alchieri, E. A. P., Lung, L. C., and da Silva Fraga, J. (2004a). GroupPac 3:
Estendendo o FT-CORBA para Gerenciamento e Replicação Ativa. In Anais do WTF 2004 (V
Workshop de Testes e Tolerância a Falhas) - SBRC’2004, Gramado, RS.
Bessani, A. N., da Silva Fraga, J., and Lung, L. C. (2002). MJaco: Integração do multicast IP
na arquitetura CORBA. In Anais do XX Simpósio Brasileiro de Redes de Computadores SBRC’2002, Buzios, RJ.
Bessani, A. N., Lung, L. C., Alchieri, E. A. P., and da Silva Fraga, J. (2004b). Replicação ativa
no CORBA: Padrões, protocolos e framework de implementação. In Anais do XXII Simpósio
Brasileiro de Redes de Computadores - SBRC’2004, Gramado, RS.
Lung, L. C., da Silva Fraga, J., de Souza, L. M. S., and Padilha, R. S. (2000). Grouppac: Um Framework para implementação de aplicações tolerantes a falhas. In Anais da XXVI Conferência
Latino Americana de Informática - CLEI’2000, Cidade do México, México.
Lung, L. C., da Silva Fraga, J., Padilha, R., and Souza, L. (2001). Adaptando as especificaç ões
ft-corba para redes de larga escala. In Anais do XIX Simpósio Brasileiro de Redes de Computadores - SBRC’2001, Florianópolis, SC.
Object Management Group (2002). The common object request broker architecture: Core specification v3.0. OMG Standart formal/02-12-06.
Schneider, F. B. (1990). Implementing fault-tolerant service using the state machine aproach: A
tutorial. ACM Computing Surveys, 22(4):299–319.
1
Software livre (portanto código aberto) e baseado em padrões aberto (definidos pela OMG).
5° WSL / 5° FISL
International Master Program in Free Software:
a higher education experience
David Megı́as, Rafael Macau, Jordi Mas
Estudis d’Informàtica i Multimèdia
Universitat Oberta de Catalunya
Av. Tibidabo 39–43, 08035 Barcelona
Tel. (+34) 93 253 7523, Fax (+34) 93 417 6495
{dmegias,rmacau,jmash}@uoc.edu
Abstract
The Universitat Oberta de Catalunya (Open University of Catalonia, UOC) offers an International Master Program in
Free Software (in Spanish). The first edition of this master program began on November 2003 and there are about 150
students currently enrolled at the different specialities offered by the program. In this paper, the design, the methodology
and the first few conclusions drawn from this higher education experience are discussed and summarized.
1
Introduction
The Universitat Oberta de Catalunya (UOC1 ) is internationally recognized as the first institution to offer distance education of university degrees using exclusively the Internet as the basis of the academic activity. Since the early foundation
of the UOC, in 1995, our educational system relays on a virtual campus platform which allows the students and the
lecturers to interact under the condition that no coincidence in time or space is assumed. Nowadays, there are more
than 25000 students registered in the different bachelor, master, postgraduate and PhD programs at the UOC. As a result
of our contributions to the distance education and e-learning initiatives, our institution has been awarded with the most
relevant international prizes in this field.
In addition, it must be taken into account that the UOC student profile is quite different from that of the “traditional”
universities. The standard UOC student is an adult person in his or her thirties or forties, with a family, employed, and
with very little time to study. Many of these students have other university degrees and they register at the UOC because
they are eager to acquire knowledge or skills in a new field. Thus, motivation is often one of their most remarkable
qualities.
It is well known that the free software (FS) and the open source movements have gained widespread acceptance
by both academia and industry in the last few years. As an academic institution, the UOC is deeply interested in this
movement and FS products are commonly used in several of our departments. However, we reckon that the free and open
source software technologies are still far from reaching a relevant position in the market compared to that of proprietary
software. We think that one of the reasons why FS is not more widely used is the short number of academic courses in
this technology. It is widely accepted that the people in the FS community usually acquire and exchange knowledge by
visiting different web pages and discussing in forums. However, many end users, and specially the typical Information
Technologies (IT) professionals, do not feel comfortable with this learning model and are discouraged to try FS. There
is a gap of guided and tutored education in this area which must be filled in.
For these reasons, we have decided to offer an International Master Program in Free Software (MPFS2 ) since
November 2003. This master degree, which is taught in Spanish, is devoted to provide with an integral education on
the different aspects related to the FS technology. Among others, the courses which have been designed for the master
degree are concerned with the philosophy and the history of the FS movement, GNU/Linux, computer networking, web
management, database management, software development, laws and licenses, etc. The student can choose among these
courses according to some suggested itineraries with four possible specializations: Network and systems administrator, Software developer, Web and e-business administrator and Information Systems manager, all of these, under
the master degree in FS.
1
2
http://www.uoc.edu
http://www.uoc.edu/masters/softwarelibre/esp/index.html
109
110
5° WSL / 5° FISL
2
Precedents and motivations of the master program
The UOC and, in particular, the Computing and Multimedia Department, has a wide experience in using and promoting
FS in an academic environment. For example, a GNU/Linux platform is used in the practical activities of the Operating
Systems and Networking subjects since 1997. In these subjects, the students needed a UNIX-like platform to carry out
their practical activities. However, the UOC is a distance university and it was required that the students could use the
UNIX-like system at home. There were two possibilities to achieve this aim. The first one was to log in a remote UNIX
server and work with a permanent (modem) connection. The alternative was to provide the students with a UNIX-like
system to work with their personal computer. After evaluating the pros and cons, this second possibility was chosen and
a Slackware3 distribution of GNU/Linux was sent to the students. At the same time, a virtual tutored lab to support the
students with installation problems, modem set up, etc. was created. Nowadays, Knoppix4 has replaced the Slackware
distribution.
Apart from this very early experience, FS products became a usual tool in several subjects of the official degrees in
Computer Science Engineering, for example:
• Dev-C++ (programming)
• MySQL, TOAD (databases)
• GnuPG (security)
• Eclipse (software engineering)
• Apache, Tomcat (computer networks, e-commerce)
• OpenOffice (document exchange)
Nowadays, two FS CD are distributed to the students, one of them is a LiveCD of GNU/Linux (Knoppix) and the
other one contains several programs which are used in different subjects of the Computer Science Engineering programs.
This positive experience with FS (in particular with GNU/Linux) led to a postgraduate program on GNU/Linux, which
was issued in November 2001. Since November 2003, this postgraduate program has been incorporated into the MPFS.
Apart from these initiatives, the UOC has made a great effort to adapt the virtual campus platform, the web portal,
the virtual library, and other web services to free browsers (e.g. Mozilla). In addition, the usage of multi-platform
formats (such as PDF, HTML, RTF, plain text) for document exchange has been encouraged, and free alternatives to
proprietary programs currently on use in the official degrees are being considered. Finally, we have started a project
(within the Hispalinux metadistros5 project) to develop a LiveCD distribution of GNU/Linux specially designed for the
UOC students.
There are several motivations behind this MPFS. The first one is the particular interest of a group of lecturers in
helping to promote and disseminate the FS technology together with all its ethical and philosophical implications. A
second reason is the fact that there is an increasing demand for IT professionals with a background in FS. A third reason,
as pointed out in Section 1, is the lack of traditional (guided an tutored) education in this field. The IT professionals
do not usually have enough time for teaching themselves as often occurs in the FS community and, thus, the MPFS can
help to fill this educational gap. Finally, we must not forget that the standard student at the UOC is an employed person.
This makes it possible to have an influence in the private companies and public institutions which can benefit from the
advantages of FS.
3
Master program design
The MPFS has been designed according to four different professional profiles related to Computer Science and Information Systems: networking and operating systems administrator, web development and e-commerce administrator,
application developer and information systems management.
For each of these profiles, we have suggested a different itinerary, as shown in Figure 1. These itineraries are divided
into different courses or modules the contents of which have been especially designed to focus on the particularities of
FS in each of these fields. The academic objectives of these itineraries are the following:
• Itinerary #1 – Networking and operating systems: configure and administrate network services in GNU/Linux,
know the basic aspects of networking security, identify the vulnerability problems of FS systems and learn to solve
this kind of problems.
• Itinerary #2 – Web development and e-commerce: know the components of a web server and its possibilities,
know some of the most widely used web servers, install a web server and a data base management system, be
aware of the security aspects related to web servers, organize and manage information and data integrity and
administrate data bases with web interfaces.
3
http://www.slackware.com/
http://www.knoppix.com/
5
http://metadistros.hispalinux.es/
4
5° WSL / 5° FISL
• Itinerary #3 – Application development: design and develop applications with FS tools, know the different
possibilities for reusability of FS source code, know the different virtual cooperative environments for FS programming.
• Itinerary #4 – Information systems management: know the alternative to proprietary systems, know the legal
and exploitation aspects related to FS and analyze practical implantation cases of FS platforms.
Figure 1: Master program design
As the contents are concerned, these four itineraries have a common initial block of “core” or mandatory courses,
consisting of an “Introduction to free software” 6 and “Basic Operating System GNU/Linux” 7 . These two core courses
take 4.5 credits each, where 1 credit requires about 15 hours of student work. After these core modules, the MPFS offers
different specialization courses depending on the itinerary chosen by the student:
• Itinerary #1 – Networking and operating systems: “Advanced administration of the operating system GNU/Linux” (4.5 credits), “Computer networks” (3 credits), “Advanced networking: security issues” (6 credits), and
“Implantation” (6 credits)
• Itinerary #2 – Web development and e-commerce: “Advanced administration of the operating system GNU/Linux” (4.5 credits, not compulsory), “Web development” (6 credits), “Database systems” (6 credits), and “Implantation” (6 credits)
• Itinerary #3 – Application development: “Advanced administration of the operating system GNU/Linux” (4.5
credits, not compulsory), “Introduction to software development” (6 credits), “Advanced aspects of software development” (6 credits), “Free software engineering” (6 credits), and “Implantation” (6 credits)
• Itinerary #4 – Information systems management: “Legal aspects and exploitation” (6 credits), and “Utilities
and tools” (4.5 credits)
The advanced course in GNU/Linux and a course on practical issues about FS implantation are common to the more
technical itineraries (#1, #2 and #3). In addition, all the itineraries finish with a practicum or final project (with 7.5
credits for the itineraries #1, #2 and #3, and 4.5 credits for the itinerary #4). Note, also, that the fourth itinerary (IS
manager) is shorter than the other three ones, since it only leads to a postgraduate diploma and not to a master degree.
The master degree itineraries (#1, #2 and #3) take four semesters and can be completed in about 18 months. The shorter
itinerary takes just two semesters or about 10 months.
As far as we know, there is not any other similar offer of a master program in FS. We have found some other
postgraduate courses in this issue, but their scope, contents and length are quite different from ours. Thus, we prefer not
to establish any kind of comparison with them.
4
Pedagogical model of the master program
The UOC is based on a virtual campus platform which provides with the means for inter-communication. This platform
is physically supported by a complex computer network and is completely web-based. The virtual campus offers several
6
7
http://www.uoc.edu/masters/softwarelibre/esp/materials/libre.pdf
http://www.uoc.edu/masters/softwarelibre/esp/materials/libre_m2_baja.pdf
111
112
5° WSL / 5° FISL
forums for the exchange of information between members of the UOC community. Some of the facilites offered by the
virtual campus are:
• interactive communications between the students and course tutors (or consultant lecturers) both asynchronously
and, exceptionally, synchronously,
• interactive communications between the students,
• access to the UOC information resources (libraries, bulletin boards, databases, etc.) and
• access to administrative services.
Using the electronic mail and the Internet at any Internet-connected computer, the students are able to exchange messages, ask questions and make enquiries to the course tutors without time constraints. Course tutors, themselves, also
contact students to monitor their progress or give assistance over any difficulty that may arise. In this way, the students
always feel assisted.
The UOC faces an important challenge as it develops a new concept of pedagogical model: from teaching to learning.
The course tutors are no longer mere transmitters of knowledge but rather a guide in the learning process, for which the
student is the ultimate responsible. It is a student-centered educational model, since the student is the central element
and the rest of the elements are made available to support the learning process. The following elements are directly
involved in the learning process:
• The learning materials gather and transfer the basic contents of the course. They contain the objectives, selfevaluation activities, summaries, etc., and they are designed to make the learning process simple and stimulating.
The materials for this master program are available both in paper-based and web-based formats.
• The students are assigned a course tutor or consultant lecturer for every course. This lecturer provides general
advice throughout their studies and becomes their personal advisor and their main interlocutor during the semester.
• The continuous evaluation is a series of activities that are carried out during the semester in order to ensure the
optimal achievement of the course objectives.
• The virtual library supports student training and allows students to gain access from their homes to the services
developed by the UOC library.
All these different elements of the pedagogical model of the UOC are integrated into the virtual campus. This
platform allows the students to send public (using the forums) and private (using personal e-mail accounts, integrated
into the campus) messages to their classmates and lecturers, making it possible to share experiences, ask for assistance
or make suggestions and participate in the university’s different social, cultural and academic activities. In addition, this
platform also makes it possible to access all the university administrative services.
5
Final remarks
The first edition of the MPFS presented in this paper started in November 2003 with about 90 students, mainly from
Spain but also from South American countries. A second edition of the master program started in March 2004, and the
total number of currently registered students is about 150. In addition, some grants are given each year by the Fundación
Carolina to cover part of the registration fees for South American students.
It must be pointed out that this MPFS gives back some return to the FS community. In particular, the didactic materials are being licensed using the GNU Public Documentation License (GFDL8 ) and can be downloaded (in Spanish)
from the master’s site: http://www.uoc.edu/masters/softwarelibre/esp/materials/.
Furthermore, and international scientific council of experts has been constituted in order to:
• watch over the quality of the Master’s contents and design,
• take into account sound opinions of different members of the FS community,
• contribute to the promotion, diffusion and development of FS projects,
• take into account viewpoints coming from different cultures and environments and
• make the master program internationally known to gather students from various origins.
The members of this council are: Manuel Castells (UOC), Vinton Cerf (MCI), Marcelo D’Elia Branco (software livre
project), Juantomás Garcı́a (Hispalinux), Jesús M. González Barahona (Universidad Rey Juan Carlos), Pekka Himanen
(University of California at Berkeley) Miguel de Icaza (Ximian/Novell) Òscar del Pozo (Softcatalà) Pam Samuelson
(University of California at Berkeley), Rafael Macau (UOC), David Megı́as (UOC), Jordi Mas (UOC, Ximian/Novell,
Softcatlà).
In conclusion, the first few months of this experience have been very positive and we are in contact with other
European and South American universities which are interested in offering master programs in FS.
8
http://www.gnu.org/copyleft/fdl.html
5° WSL / 5° FISL
Sessão Técnica 8
DESENVOLVIMENTO I
113
114
5° WSL / 5° FISL
5° WSL / 5° FISL
AbsTK: uma biblioteca para desenvolvimento unificado de
aplicações em modo texto e gráfico
Hisham H. Muhammad
André Detsch
½
Projeto GoboLinux
http://www.gobolinux.org
{lode,detsch}@gobolinux.org
Resumo: Manter diferentes versões para uma mesma aplicação em modos gráfico e texto é custoso
e problemático. Este artigo apresenta um toolkit livre para construção de interface que abstrai os elementos
visuais e permite desenvolver aplicações que executam tanto em ambiente texto como gráfico.
Abstract: Maintaning different versions for an application in text and graphic modes is costly and
problematic. This paper presents a free toolkit for interface building, which abstracts away the visual elements
and allows one to develop applications which execute both in textual and graphical environments.
1 Introdução
A disponibilização de interfaces adequadas para configuração e instalação de sistemas ainda é um
problema bastante comum em plataformas livres. Um número cada vez maior de usuários de software livre carecem de conhecimentos profundos sobre estes sistemas e suas aplicações, necessitando
interfaces mais avançadas e amigáveis.
O desenvolvimento de aplicações amigáveis, entretanto, demanda o uso de bibliotecas de
widgets gráficos, que são ferramentas complexas e demandam considerável dedicação por parte do
desenvolvedor, tornando o desenvolvimento de interfaces para configuração e instalação pouco atrativo para o programador, embora necessário para os usuários. Um problema que agrava este quadro
é o fato de que no mundo do software livre diferentes usuários utilizam diferentes interfaces gráficas
como KDE e GNOME, ou mesmo o console de texto.
Cada uma destes diferentes ambientes é baseado em bibliotecas visuais diferentes (Qt para
KDE, GTK+ para GNOME, e assim por diante), levando o programador a optar entre escolher uma
biblioteca ou manter múltiplas versões de sua ferramenta. Ambas as opções trazem consideráveis
desvantagens. No primeiro caso, o esforço dispendido pelo programador para produzir uma interface
amigável para sua ferramenta acaba por cobrir apenas uma fração do público-alvo. No segundo caso,
mesmo que várias versões da interface sejam desenvolvidas, a manutenção de todas em paralelo, e
especialmente a sua sincronização de desenvolvimento são um problema.
Visando resolver este problema, foi desenvolvida uma nova biblioteca de widgets para a linguagem Python denominada AbsTK (Abstract Tool Kit), que, como o nome indica, é baseada num
nível conceitualmente mais abstrato. A programação realizada sobre esta API é baseada nos aspectos semânticos dos elementos, sem necessidade de definição explícita dos aspectos de exibição. Em
tempo de execução, dependendo do ambiente onde for executada, a aplicação exibirá então uma interface em modo texto ou gráfico. Através desta API foi realizada a programação do instalador da
distribuição GoboLinux [2], utilizado a partir da versão 010.
2 AbsTK
A biblioteca AbsTK surgiu no contexto do projeto GoboLinux. Objetivava-se desenvolver um instalador amigável, que atendesse tanto aos usuários do ambiente gráfico provido pelo CD de instalação
como aos usuários que necessitem utilizar o modo texto devido a incompatibilidades de hardware no
processo de instalação (ou prefiram o uso do console). A primeira opção seria desenvolver dois instaladores, um para o ambiente gráfico, outro para o ambiente de texto. A manutenção em paralelo de
dois programas que deveriam prover funcionalidades idênticas seria algo trabalhoso e problemático.
115
116
5° WSL / 5° FISL
Decidiu-se então desenvolver uma camada subjacente única que isolasse a semântica do instalador da interface. Diferentemente da abordagem de front-end/back-end, tipicamente empregada
em programas que provêm múltiplas interfaces, optou-se por isolar a aplicação da interface por meio
de uma camada genérica em nível de toolkit, que fosse capaz de atender aos seguintes requisitos:
(1) simplicidade de prototipação; (2) independência de toolkit de exibição; (3) utilização de campos
arbitrários nas janelas; (4) definição simples de interação entre campos.
Baseados nestes requisitos, a definição do AbsTK se baseia em três tipos de entidades: campos, entidades de entradas de dados que representam informações de diversos tipos com o qual o
usuário pode ou não interagir; telas, que são conjuntos de campos; e um container, que engloba uma
ou mais telas e representa a interface como um todo. Para a aplicação do instalador, o container é um
objeto do tipo Wizard, que modela uma interface do tipo “assistente”, onde cada uma das telas é um
passo no processo de instalação, composto de campos que representam os dados e opções entrados
pelo usuário. Primeiramente, o programador cria uma instância da classe Wizard. Cada tela do wizard corresponde a um objeto da classe Screen. Esta classe possui métodos que permitem a adição
de campos. A distribuição dos campos na tela é dada pela ordem de inserção, e o layout é definido
automaticamente pelo próprio toolkit, de acordo com o ambiente onde o programa é executado.
Alguns tipos de campos, como labels, são somente-leitura, e apenas exibem informações
para o usuário. Outros têm como objetivo requisitar informações do usuário, e são descritos pela
sua representação semântica, independente de como serão visualmente exibidos. Por exemplo, cada
campo pode conter uma informação de ajuda adicional. Em um ambiente gráfico, essa informação
pode aparecer como um tooltip flutuante, e em modo texto, como uma barra de status no canto inferior
da tela. Graças a esta abstração, interfaces automaticamente adaptáveis se tornam possíveis: um
campo List, que permite a escolha de um elemento dentre uma lista, pode se exibido como um
radio group, se contiver poucos elementos, ou uma list box com barra lateral de scroll caso possua
muitos elementos. Isto facilita a manutenção da aplicação, uma vez que os elementos de interface são
substituídos automaticamente à medida que o desenvolvimento da interface evolui.
Campos podem ter seus valores acessados e alterados através dos métodos setValue e
getValue, onde os campos são referenciados através do identificador definido quando da sua inserção na tela. Assim, basta listar a seqüência de dados a serem requisitados, seguindo uma ordem de
telas, combiná-las em um container, e a interface do programa está construida, plenamente funcional
tanto em ambiente gráfico como de texto. Além da exibição e coleta de dados, foi implementado um
sistema de callbacks que permite funcionalidades bastante avançadas de programabilidade, embora
sem perder a simplicidade do sistema. Cada campo pode ter um callback associado, que é acionado
sempre que alguma ação for realizada sobre o campo. Por exemplo, é possível alterar o valor de um
campo sempre que outro for alterado.
A dinâmica de execução do programa é bastante simples: após a definição do container, que
é, no caso do instalador, um wizard (assistente), basta acionar o metodo Wizard.start(). O
wizard exibirá suas telas para o usuário à medida que este for prosseguindo pelo assistente, seja em
modo gráfico pressionando os botões “Próximo” e “Anterior” ou em modo texto, usando as teclas de
movimentação indicadas na interface. Assim que o usuário solicitar o término (via botão “Concluir”
graficamente, ou pela tecla de término em modo texto), o fluxo de execução volta para o script, que
pode acessar todas as informações entradas pelo usuário.
Adicionalmente, AbsTK oferece ainda recursos de internacionalização, permitindo que a interface se traduza automaticamente em tempo de execução, de acordo com as configurações de idioma
do ambiente onde ela executa. O arquivo de traduções é em formato ASCII, permitindo fácil edição
e contribuição de traduções por parte da comunidade de usuários. Existe também um conversor que
permite usar a interface gráfica do Qt Linguist [5] para gerenciar as traduções.
API de programação. As classes disponibilizadas ao usuário do AbsTK são Screen e
5° WSL / 5° FISL
tamanhos = {’KDE’:250, ’Python’:30, ’Qt’:50, ’PyQt’:15 }
nomes_pacotes = tamanhos.keys()
wizard = Wizard(’Exemplo’)
tela = Screen(’Pacotes’)
def habilita_desabilita_lista() :
wizard.setEnabled(’pacotes’, wizard.getValue(’habilita_selecao’))
def soma_lista_e_atualiza_campo() :
selecionados = wizard.getValue(’pacotes’)[1]
s = 0
for cada_um in selecionados :
s = s + tamanhos[cada_um]
wizard.setValue(’soma’, str(s))
tela.addBoolean(’habilita_selecao’, ’Seleção manual’, True, ”,
habilita_desabilita_lista)
tela.addCheckList(’pacotes’, ’Selecione’, (nomes_pacotes,[]), ”,
soma_lista_e_atualiza_campo)
tela.addLabel(’soma’, ’0’)
wizard.addScreen(tela)
wizard.start()
Figura 1: Exemplo de uso do AbsTK: uma lista de seleção de pacotes
Wizard. A classe Screen possui diversos métodos para adição de campos, como addBoolean(),
addButton(), addCheckList(), addLabel(), addLineEdit(), addList() e addMultiLineEdit(). Ao criar um campo, o programador pode especificar, respectivamente, um
nome para o campo (para que possa obter os dados posteriormente), um label (em toolkits tradicionais, o label é usualmente um widget distinto, que deve ser gerenciado separadamente), um valor
default para o campo, uma mensagem de ajuda e uma função de callback. A semântica, o nome e a
ordem dos parâmetros são iguais para todos os métodos de adição de campo. Cabe resaltar que todos
os parâmetros são opcionais, podendo-se passar apenas os parâmetros considerados necessários pelo
programador.
A classe Wizard, que define um container do tipo “assistente”, permite adicionar telas
(através do método addScreen()) e requisitar ou ajustar valores de campos que estejam inseridos em alguma de suas telas (métodos getValue() e setValue()). De forma similar, é possível
habilitar ou desabilitar campos através do método setEnabled().
Implementação Qt. A implementação do AbsTK para uso em modo gráfico utiliza os bindings Qt [5] para Python (biblioteca PyQt [4]). Grande parte das funcionalidades exigidas para exibição e funcionamento dos campos oferecidos por AbsTK já estão presentes em PyQt, cabendo à
implementação de AbsTK apenas oferecer wrappers adequados.
Os campos inseridos são enquadrados em um QGridLayout, classe para layout automático
disponibilizada pelo Qt. Com isso, as telas podem ser redimendionadas durante o uso sem qualquer
problema de organização dos campos, ao mesmo tempo em que o programador não precisa lidar
explicitamente com este quesito. A funcionalidade de callbacks é implementada através do uso do
mecanismo de sinais e slots oferecido pelo Qt.
Implementação NCurses. A implementação do AbsTK para operação em console baseiase no wrapper Python para a biblioteca NCurses [3]. Esta implementação tem a vantagem de estar
disponível na grande maioria dos ambientes Linux, uma vez que a biblioteca NCurses é um item
básico da maior parte das distribuições e o wrapper Python vem incluído no pacote Python padrão.
Enquanto a biblioteca Qt disponibiliza objetos gráficos de interface completos, de modo que
AbsTK limita-se a realizar o mapeamento entre estes objetos e os seus campos, a biblioteca ncurses
disponibiliza apenas primitivas para exibição de caracteres. Assim, na implementação NCurses, os
widgets visuais de modo texto (botões, listas, check boxes, etc.) são implementados por AbsTK
internamente. O mecanismo de callbacks no modo NCurses é implementado conjuntamente com a
implementação interna dos widgets textuais. Assim, o funcionamento dele na API externa é idêntico
117
118
5° WSL / 5° FISL
Figura 2: O mesmo programa, rodando nos modos Qt e NCurses.
em ambas as plataformas.
3 Exemplo de uso
Na Figura 1 temos um breve exemplo de uso do AbsTK: uma simplificação da tela de seleção de
pacotes do instalador. Após instanciar o wizard e a tela, são definidas as rotinas de callback utilizadas adiante. Na tela são inseridos um campo booleano (que define se a seleção manual de pacotes deve ser habilitada) uma check list (que permite a seleção dos pacotes disponíveis), e um label
(que exibe a soma dos tamanhos dos pacotes selecionados). Através do ultimo parâmetro passado em
addBoolean(), define-se que mudanças neste campo devem acionar a função ’habilita_desabilita_lista’. Esta função consulta o valor do campo e define se a check list de seleção de pacotes deve estar
habilitada para alteração por parte do usuário. De forma similar, utiliza-se a função ’soma_lista_e_atualiza_campo’ como callback para alterações no campo ’pacotes’. Esta função identifica os pacotes
selecionados e soma os seus tamanhos, ajustando o valor do campo ’soma’. Note que o valor de um
campo check list é dado por uma tupla, onde o primeiro elemento é a lista dos valores disponíveis,
e o segundo (acessado pelo índice [1]) a lista dos itens selecionados. Ao final, é acionado o método
start() do wizard, que procede com a exibição das telas e aguarda a finalização pelo usuário.
A Figura 2 apresenta o resultado visual da execução do exemplo utilizando a implementação
Qt e NCurses. Um aspecto a ser ressaltado é a adaptação que o próprio AbsTK faz em relação aos
botões apresentados na parte inferior da interface. Por haver apenas uma tela no wizard, são apresentados os botões ’Cancel’ e ’Ok’, no lugar dos botões, ’Anterior’ e ’Próximo’/’Concluir’, presentes em
um wizard tradicional, com mais de uma tela.
4 Considerações finais
Este artigo apresentou o AbsTK, um toolkit que permite a fácil geração de wizards através da linguagem Python. A biblioteca é distribuída segundo a GNU General Public License, e está disponível
para download em http://www.gobolinux.org/abstk, onde a API completa é documentada. A biblioteca está em um estágio maduro de desenvolvimento, sendo atualmente usada em
ambiente de produção. Como possibilidades de trabalhos futuros temos a implementação de novos
back-ends, em especial GTK+, e o desenvolvimento de novos tipos de campos e containers, flexibilizando ainda mais a biblioteca para uso em outros tipos de ferramenta.
Referências
[1] AbsTK. http://www.gobolinux.org/abstk
[2] MUHAMMAD, H. H., DETSCH, André. “Uma nova proposta para a árvore de diretórios UNIX” In: III
Workshop Software Livre, 2002, Porto Alegre. Anais do III Workshop Software Livre. , 2002.
[3] NCurses. http://dickey.his.com/ncurses/ncurses.html
[4] PyQt. Riverbank Computing. http://www.riverbankcomputing.co.uk/pyqt/
[5] Qt Overview. Trolltech. http://www.trolltech.com/products/qt/
5° WSL / 5° FISL
Desenvolvendo Jogos Computadorizados Multiplataforma
com Amphibian
João Ricardo Bittencourt1,2, Lucia Maria Giraffa1
1
Programa de Pós-graduação em Ciência da Computação (PPGCC)
Pontifícia Universidade Católica do Rio Grande do Sul (PUCRS)
Av.Ipiranga,6681 – Prédio 16 – 90619-900 – Porto Alegre – RS – Brasil
2
Centro Universitário Franciscano (UNIFRA)
Rua Andradas, 1614 – 97010-032 – Santa Maria – RS - Brasil
Abstract. In last years studies about games are growing in Brazil in relation to
business and academic scopes. Due to this it’s necessary to develop free tools for
create games. The main goal of this paper is to show Amphibian. It’s a free, no cost
framework to create multiplatform games.
Resumo. Os jogos computadorizados nos últimos anos no Brasil estão recebendo
destaque no âmbito comercial e acadêmico. Por isto existe a necessidade de
desenvolver ferramentas livres para criação de jogos. O objetivo deste artigo é
apresentar o Amphibian que consiste de um framework distribuído livremente e
gratuitamente para criação de jogos computadorizados multiplataforma.
1. Introdução
Nos últimos anos o desenvolvimento de jogos computadorizados está crescendo no Brasil. Para
Battaiola [1], os jogos computadorizados além de fomentar o desenvolvimento de pesquisas no
meio acadêmico, fomenta a criação de um nicho mercadológico que propicia o
desenvolvimento de software no país. A realização do Workshop Brasileiro de Entretenimento
Digital e Jogos Computadorizados (WJogos)[2] com o apoio da Sociedade Brasileira de
Computação (SBC); a Rede de Excelência de Empresas de Jogos de Entretenimento (GameNet)
[3] criada pelo Governo do Paraná; o edital [4] para projetos de inovação para Software Livre
lançado pelo Ministério da Ciência e Tecnologia que contemplava a área de entretenimento;
podem ser destacados como fatos que evidenciam o crescimento das pesquisas, do incentivo e
da exploração econômica dos jogos computadorizados no país. Entretanto observa-se que os
empreendimentos nacionais bem sucedidos utilizam tecnologias proprietárias e executáveis sob
a plataforma Microsoft Windows. De uma certa forma estas organizações adotam o modelo de
negócios tradicional utilizado pela indústria norte-americana desenvolvedora de jogos
computadorizados. Tal comportamento pode ser explicado pelo fato da indústria nacional estar
em um ciclo inicial de amadurecimento e pela falta de um know-how nacional. Na ausência de
uma tecnologia interna que viabiliza seus negócios acabam adotando tecnologias estrangeiras.
Por exemplo, muitas empresas utilizam a tecnologia DirectX da Microsoft. Para Hecker [5],
nem sempre uma decisão tecnológica que é boa para uma empresa, será uma boa solução para
as demais. Desta forma os empreendimentos nacionais deveriam questionar-se se o uso do
DirectX de fato é a melhor solução para seus negócios e se de fato tal tecnologia proporciona
um incremento de sua competitividade, facilitando seu processo de desenvolvimento.
Diante deste contexto existe a necessidade de projetar tecnologias que permitam o
desenvolvimento de um modelo econômico nacional para indústria de jogos, de forma que este
modelo fosse flexível suficiente para atingir diferentes nichos mercadológicos, tais como
119
120
5° WSL / 5° FISL
computadores pessoais, celulares, handhelds, Internet, videogames ou qualquer outro
dispositivo. Além destes aspectos mercadológicos, existe a questão referente ao uso da
Informática na Educação. Necessita-se do desenvolvimento de jogos com qualidade para serem
utilizados nas escolas [1]. Se considerar a criação de jogos usando a tecnologia DirectX, estes
irão executar somente na plataforma Windows, logo teria-se um grande problema na utilização
dos jogos nas escolas públicas do Rio Grande do Sul que integram a Rede Escolar Livre [6],
por exemplo. Precisa-se desenvolver tecnologias livres que permitam a construção de jogos
para executarem em diferentes plataformas, desta forma propiciando o uso de jogos
computadorizados no processo de ensino-aprendizagem [7] e no fortalecimento da indústria
nacional.
Visando contribuir na resolução destes problemas desenvolveu-se um framework,
denominado Amphibian [7] que permite a criação de motores de jogos multiplataforma,
executando inclusive sob a plataforma móvel. Este framework é distribuído gratuitamente sob a
licença LGPL, desta forma permitindo que sejam criados novos componentes e jogos sob a
filosofia de software livre. O objetivo do presente artigo é apresentar o Amphibian com suas
respectivas funcionalidades e como este pode ser usado na criação de jogos computadorizados
multiplataforma. Este artigo está divido em três seções: na seção 2 é apresentada a arquitetura
do Amphibian, principais funcionalidades e como este pode ser usado; na seção 3 é apresentado
um exemplo de jogo que ilustra a execução do Amphibian em três diferentes sistemas
operacionais; e por último serão feitas as considerações finais.
2. Amphibian
Primeiramente é importante destacar que o Amphibian é um framework para criação de motores
de jogos e a partir deste é possível construir diferentes títulos. Desta forma este framework
facilita o desenvolvimento de motores de jogos que poderão executar em diferentes
plataformas, inclusive a móvel. Para o projeto da arquitetura do framework foram utilizados
diversos padrões de projetos [8][9]. O Amphibian fundamentalmente é baseado em uma
arquitetura de camadas [8]. Esta arquitetura auxilia na criação de aplicações que podem ser
decompostas em grupos de subtarefas na qual cada um destes possui um determinado nível de
abstração. Seus benefícios são a melhoria da manutenibilidade, estensibilidade do sistema,
reusabilidade e, além disto, facilita a padronização. Em uma arquitetura de camadas, parte-se do
pressuposto que determinada camada comunica-se somente com as inferiores, veja Figura 1.
Nesta arquitetura existe uma camada referente ao sistema operacional. Sob esta,
executa-se uma máquina virtual Java (JVM) que fornece uma abstração referente à plataforma
de execução. Sob esta camada está a SAL (System Abstraction Layer) que consiste de uma
camada de abstração referente às máquinas virtuais. As extensões da SAL podem utilizar uma
máquina virtual específica, inclusive uma JVM livre que não tenha sido desenvolvida pela Sun,
ou utilizar métodos nativos e executarem diretamente sob um sistema operacional, desta forma
perdendo a portabilidade, mas sem comprometer a compatibilidade com as camadas superiores.
A camada referente ao Amphibian é projetada para utilizar somente a abstração oferecida pela
SAL. Percebe-se na Figura 1 que o Amphibian acessa somente tal camada, logo os motores de
jogos desenvolvidos com Amphibian são independentes da JVM. A última camada trata-se das
extensões criadas basicamente a partir das abstrações de cada uma das camadas básicas e
especifica a relação destas extensões com as camadas da arquitetura de execução.
O Amphibian é multiplataforma, livremente distribuído sob a LGPL, gratuito,
independente dos mecanismos de visualização (2D/3D), independente dos mecanismos de
persistência dos dados (banco de dados, arquivos de propriedades, XML) e com alta
modularidade, permitindo trocar seus componentes facilmente. Basicamente um motor de jogo
é criado conforme os seguintes passos: (a) criação das classes do domínio do jogo que trata das
regras propriamente ditas; (b) criação de componentes através da customização de componentes
5° WSL / 5° FISL
121
já existentes; (c) integração destes usando um arquivo XML que especifica os componentes que
serão usados pelo motor em tempo de execução.
$03+,%,$1
([WHQV}HV
6$/
-90
6LVWHPD2SHUDFLRQDO
Figura 1: Arquitetura de Execução Completa do Amphibian.
3. Exemplo de Utilização do Amphibian
Para verificar a viabilidade de execução de jogos computadorizados criados a partir do
Amphibian foram desenvolvidos alguns protótipos de jogos que ilustram as potencialidades da
ferramenta. Na Figura 2 estão sendo apresentadas algumas screenshots do Jogo da Serpente
executando sob o GNU/Linux, Windows e PalmOS (através de emulador). É importante
destacar que para execução no PalmOS foi utilizado a máquina virtual SuperWaba [10] que
consiste de um projeto software livre nacional. Para o desenvolvimento do Jogo da Serpente
foram criadas as classes referentes à lógica do jogo e a criação de um arquivo XML para cada
plataforma com as especificações dos componentes que serão utilizados pelo motor do jogo.
Figura 2: Screenshots do Jogo da Serpente executando em Multiplataformas.
É importante destacar que obteve-se nos testes uma média de desempenho de 41.5433
frames por segundo (fps) (atingindo até 63 fps) executando sob um Athlon XP 1800, 256 Mb de
RAM e uma placa 3D Rivas TNT2 e 31.8333 fps (atingindo até 42 fps) sob um AMD Duron
900Mhz, 64 Mb de RAM e uma placa 3D Compaq nVidia Vanta LT 8Mb. Para execução destes
122
5° WSL / 5° FISL
testes foi usado um outro jogo denominado Jogo da Vida de John Conway que aloca uma
grande quantidade de objetos (aproximadamente de 325 a 890 objetos manipulados a cada ciclo
de atualização) e possui alta complexidade. Estas taxas são bastante significativas quando
considera-se uma taxa média de 30 fps [11]. Isto demonstra as potencialidades para utilização
do Amphibian na criação de jogos computadorizados comerciais que exigem alto desempenho.
Ao término do presente trabalho é possível concluir que o Amphibian é uma ferramenta livre
que permite a criação de motores de jogos e a partir destes criar diferentes novos títulos que
poderão ser comercializados ou utilizados nas escolas. Desta forma espera-se que o Amphibian
contribua no fortalecimento da indústria nacional de jogos computadorizados e permita que
jogos sejam criados com tecnologia livre e possam executar inclusive sob plataformas móveis.
É importante destacar que mesmo sendo o objetivo principal do Amphibian criar motores de
jogos, outras aplicações multimídia podem ser criadas a partir do framework, tais como
simuladores gráficos e softwares de visualização científica. Destacando que estas podem ser
integradas em navegadores Web e poderão executar em dispositivos móveis, incluindo
handhelds e telefones celulares. A primeira versão do Amphibian está disponível no
SourceForge.net (http://sourceforge.net/projects/amphibian) e o site do projeto já foi traduzido
para o inglês, italiano, francês, espanhol e chinês. Esta versão inicial está sendo distribuída com
AmphibianSDK, que além das classes do Amphibian estão sendo distribuídos a documentação
da API, alguns plug-ins (suporte para MP3, Ogg e a biblioteca Gamelib[12]), códigos-fonte,
exemplos de utilização e alguns utilitários para converter arquivos XML para o formato PDB
utilizado no PalmOS. Cabe destacar que esta versão ainda é um protótipo, mas acredita-se no
seu constante aperfeiçoamento em função das contribuições recebidas da comunidade.
[1] BATTAIOLA, André L. Jogos por Computador – Histórico, Relevância Tecnológica e
Mercadológica, Tendências e Técnicas de Implementação In: Anais da XIX Jornada de
Atualização em Informática. Proceedings. Curitiba:SBC, Julho/2000, v. 2. 83-122 p.
[2] WJOGOS. Disponível em: <http://www.icad.puc-rio.br/wjogos/> Acesso em: 2 mai. 2004
[3] GAMENET – Rede de Excelência de Empresas de Jogos de Entretenimento. Disponível em:
<http://www.gamenetpr.com.br> Acesso em: 2 mai. 2004.
[4] MINISTÉRIO da Ciência e Tecnologia. Projeto em Inovação em Software Livre. Disponível
em: <http://www.finep.gov.br> Acesso em: 2 mai. 2004.
[5] HECKER, Chris. Developer Power and the ‘U’ Word. In: Game Developer Magazine. April,
1998.61-63 p.
[6] SECRETÁRIA Estadual da Educação/RS. Rede Escolar Livre RS. Disponível em:
<http://www.redeescolarlivre.rs.gov.br> Acesso em: 2 mai. 2004.
[7] BITTENCOURT, João R. Um Framework para Criação de Jogos Computadorizados
Multiplataforma. Porto Alegre, PUCRS, 2004. (Dissertação de Mestrado)
[8] BUSCHMANN, Frank; MEUNIER, Regine; ROHNERT, Hans; et al. Pattern-Oriented
Software Architecture: A System of Patterns. England: John Wiley & Sons Ltd., 1996,
476p.
[9] GAMMA, Erich; HELM, Richar; JOHNSON, Ralph; et al. Design Patterns: Elements of
Reusable Object-oriented Software. Boston: Addison-Wesley, 1995, 395 p.
[10] SUPERWABA. Disponível em:<http://www.superwaba.com.br/>. Acesso em: 15 abr. 2004.0
[11] LaMOTHE, André. Tricks of the Windows Game Programming Gurus: Fundamentals of
2D and 3D Game Programming. SAMS, 1999, 1040 p.
[12] GAMELIB. Disponível em: <http://home5.swipnet.se/~w-56899/gamelib_main.html> Acesso
em: 5 mai. 2004.
5° WSL / 5° FISL
ArchGenXML - Uma ferramenta CASE para
Desenvolvimento de Aplicações de Gerenciamento de
Conteúdo para o Plone
Fabiano Weimar dos Santos 1
1 Weimar
Consultoria – Rua São Francisco de Paula, 2012 – 95096-440 Caxias do Sul, RS
[email protected]
Abstract. The ArchGenXML is a CASE tool, written in Python and under GPL license.
It’s goal is to aid the content management applications development for Plone. The
main idea behind ArchGenXML is create a tool to transform UML diagrams into almost
ready to use applications. This article will describe about the ArchGenXML project, its
resources, where it have been used and its future perspectives.
Resumo. O ArchGenXML é uma ferramenta CASE, escrita em Python e sob licença
GPL. Sua meta é auxiliar no desenvolvimento de aplicações de gerenciamento de
conteúdo para o Plone. A idéia base do ArchGenXML é criar uma ferramenta que
transforma diagramas UML em aplicações praticamente prontas para usar. Este artigo irá descrever a respeito do projeto ArchGenXML, seus recursos, onde tem sido
empregado e suas perspectivas futuras.
1. Unindo Esforços
Apesar das discussões que envolvem os processos de desenvolvimento de software livre, existe
hoje uma séria preocupação com o desenvolvimento de aplicações abertas de qualidade. Atualmente, percebe-se uma séria deficiência em ferramentas livres que de fato agilizem o processo de
desenvolvimento ao invés de apenas gerar documentação do processo. No geral, e em especial na
área de desenvolvimento de aplicações para gerenciamento de conteúdo, não existiam aplicações
CASE realmente úteis até pouquissimo tempo. O projeto que tem mudado tudo isso é o ArchGenXML.
O ArchGenXML [arc, 2004b] é o resultado da união dos esforços entre dois projetos: o
próprio ArchGenXML e o projeto UML2AT. O projeto UML2AT foi resultado de uma disciplina
de Análise e Projeto de Sistemas II cursada por Fabiano Weimar dos Santos na Universidade de
Caxias do Sul. Já o ArchGenXML, por sua vez, foi idealizado inicialmente pelo Austriaco Phil
Auersperg, para uso próprio.
Após algum tempo, onde os dois autores trabalharam individualmente e sem saber a respeito do projeto do outro. o primeiro release não oficial do ArchGenXML foi lançado e, desde
então, mantido como parte de um projeto maior, o projeto Archetypes [arc, 2004a]. Ap ós uma
negociação complicada, os projetos UML2AT e ArchGenXML decidiram unir esforços, idealizando uma quantidade maior de recursos, descartando aquilo os projetos tinham de ruim e agregando as recursos interessantes de cada projeto em um único código fonte.
Atualmente, o projeto conta com um terceiro contribuidor efetivo, o Alemão Jensens
Klein. Ele tem sido o responsável pela documentação do projeto e o suporte a geração de código
para suporte a internacionalização de interfaces com usuário.
2. Plataforma de Desenvolvimento
O ArchGenXML é uma ferramenta de linha de comando que interpreta arquivos no formato
XML Metadata Interchange - XMI [xmi, 2004], um padrão definido pelo Object Management
123
124
5° WSL / 5° FISL
Group - OMG [omg, 2004] que permite a representação de diagramas UML usando XML, e gera
código Python [pyt, 2004] para o Archetypes, framework Python voltado ao desenvolvimento de
aplicações de gerenciamento de conteúdo para o Plone [plo, 2004a].
O Plone é um sistema de gerenciamento de conteúdo que tem forte preocupação com
design, usabilidade e acessibilidade, servindo como uma camada de interface amig ável para o
Content Management Framework - CMF [cmf, 2004], framwork escrito pela Zope Corporation
[zc, 2004] para tornar mais simples o processo de desenvolvimento de aplicaç ões de gerenciamento de conteúdo para o Zope [zop, 2004]. O Zope, por sua vez, é um servidor de aplicações
web, escrito em Python e mantido pela Zope Corporation e sua comunidade de desenvolvedores.
3. Recursos
Atualmente, o ArchGenXML está na versão 1.0. Essa release inclui recursos para a criação de
diagramas de classes e a geração de produtos Archetypes. A versão 1.1 está sendo desenvolvida
e incluirá suporte ao uso de interfaces e packages. Essa versão significou um grande avanço na
ferramenta e, apesar de não ter sido lançada oficialmente, já pode ser baixada através do repositório
CVS do projeto Archetypes.
O ArchGenXML suporta a geração de código a partir de modelos construidos em diversas
ferramentas de modelagem UML, dentre elas o GentleWare Poseidon [pos, 2004] (onde a ferramenta é considerada mais estável, por ser a ferramenta preferida pelos desenvolvedores do projeto
e, por sua vez, primeiramente testada), o Tigris ArgoUML [arg, 2004], o Umbrelo UML Modeller
[umb, 2004] (ferramenta do projeto KDE), o ObjectDomain [obj, 2004] (ferramenta comercial
com versão demo que suporta até 30 classes) e o Sybase PowerDesigner [pow, 2004] (ferramenta
comercial da Sybase).
O ArchGenXML implementa um parser XMI que suporta as versões 1.0, 1.1 e 1.2 da
especificação XMI. Em teoria, todas as ferramentas que representam os diagramas UML seguindo
as especificações da OMG deveriam funcionar bem com o ArchGenXML. No entanto, é sabido
que algumas ferramentas seguem a especificação XMI apenas parcialmente, como é o caso do
KDE Umbrelo.
Além da independencia de ferramenta de modelagem e respeito aos padr ões abertos, o
ArchGenXML utiliza “tagged values” e “esteriótipos” para permitir a personalização do código
fonte a ser gerado pela ferramenta. Essa idéia foi a principal contribuição do projeto UML2AT
para o ArchGenXML.
Como o Archetypes é um framework baseado no conceito de schemas (meta-definiç ões de
como as classes devem ser contruı́das para representar conteúdos) a idéia base do ArchGenXML
é permitir que, através de tagged values e esteriótipos, todas as propriedades de um schema possam ser modificadas, a fim de atender a semântica de cada modelo. Isso torna o processo de
desenvolvimento bastante ágil e flexivel.
Dentre os recursos necessários a um bom projeto orientado a objetos, o ArchGenXML
consegue interpretar com exatidão associações (que são mapeadas para referências entre objetos),
agregações e composições (que são mapeadas como classes com classes base com comportamento
de pastas), cardinalidade nas associações (com exceção da cardinalidade de N para N que não
é suportada pelo Archetypes), herança múltipla de classes e interfaces, realização de múltiplas
interfaces e múltiplos esteriótipos.
O ArchGenXML conta com uma opção que mantém o código fonte escrito dentro dos
métodos das classes assim como a documentação definida na docstring de cada método. Isso
permite, por exemplo, que a aplicação seja definida na ferramenta UML, código fonte seja gerado,
que o código fonte gerado seja editado com um editor externo e que, ap ós essas modificações
serem integradas ao código, modificações sejam feitas no modelo e novo código seja gerado sem
prejudicar a codificação dos métodos feita anteriormente.
Além do suporte a modelos UML realmente complexos, o ArchGenXML agrega fun-
5° WSL / 5° FISL
125
cionalidades interessantes à documentação dos sistemas, gerando código fonte totalmente documentado e em formato compatı́vel com ferramentas Python de geração de documentação a partir
do código fonte. Por fim, o ArchGenXML possui suporte nativo a internacionalizaç ão, usando o
i18ndude [i18, 2004] como ferramenta de apoio.
4. Projetos
O ArchGenXML tem sido usado em produção a pelo menos 6 meses. O primeiro grande projeto
onde o ArchGenXML foi utilizado foi o PloneMall [plo, 2004b], um framework completo para
desenvolvimento de aplicações de comércio eletrônico para o Plone.
O PloneMall é um projeto bastante complexo e que também é o resultado da união dos
esforços da comunidade Plone para o desenvolvimento de uma solução de comércio eletrônico.
Devido a complexidade de um projeto como esse, o ArchGenXML tem evoluı́do rapidamente a
fim de responder as necessidades dos desenvolvedores.
Em um futuro próximo, a versão 1.2 do ArchGenXML será lançada com suporte a um
novo recurso: workflow. O desenvolvimento dessa funcionalidade foi idealizado pelos autores do
projeto e incentivado por um projeto em desenvolvimento na UCS e que estará utilizando esse
recurso em breve. A idéa principal será utilizar diagramas de estado associados a diagramas de
classe para representar processos de negócio e conteúdos, respectivamente.
Referências
(2004a). Archetypes project. Disponı́vel em: http://www.sf.net/projects/archetypes. Acesso em:
maio 2004.
(2004b). Archgenxml project. Disponı́vel em: http://plone.org/documentation/archetypes/archgenxmlmanual. Acesso em: maio 2004.
(2004). Content management framework - cmf. Disponı́vel em: http://cmf.zope.org. Acesso em:
maio 2004.
(2004). i18ndude project. Disponı́vel em: http://www.sf.net/projects/collective. Acesso em:
maio 2004.
(2004). Object management group - xmi. Disponı́vel em: http://www.omg.org. Acesso em:
maio 2004.
(2004a). Plone content management system. Disponı́vel em: http://www.plone.org. Acesso em:
maio 2004.
(2004b). Plonemall project. Disponı́vel em: http://www.plonemall.com. Acesso em: maio 2004.
(2004). Poseidon. Disponı́vel em: http://www.gentleware.com. Acesso em: maio 2004.
(2004). Python.org. Disponı́vel em: http://www.python.org. Acesso em: maio 2004.
(2004). Sybase powerdesigner. Disponı́vel em: http://www.sybase.com/products/enterprisemodeling/powerdesigner.
Acesso em: maio 2004.
(2004). Tigris argouml. Disponı́vel em: http://argouml.tigris.org. Acesso em: maio 2004.
(2004). Umbrello uml modeller. Disponı́vel em: http://uml.sourceforge.net/index.php. Acesso
em: maio 2004.
(2004). Umbrello uml modeller. Disponı́vel em: http://www.objectdomain.com/welcome.do.
Acesso em: maio 2004.
(2004).
Xml
metadata
interchange
xmi.
Disponı́vel
http://www.omg.org/technology/documents/formal/xmi.htm. Acesso em: maio 2004.
(2004). Zope corporation. Disponı́vel em: http://www.zope.com. Acesso em: maio 2004.
(2004). Zope.org. Disponı́vel em: http://www.zope.org. Acesso em: maio 2004.
em:
126
5° WSL / 5° FISL
5° WSL / 5° FISL
Sessão Técnica 9
DESENVOLVIMENTO II
127
128
5° WSL / 5° FISL
5° WSL / 5° FISL
Considerações sobre controle de grupos em repositórios CVS
durante a evolução de uma ferramenta web
Daniel Cárnio Junqueira∗, Renata Pontin de Mattos Fortes
1
Instituto de Ciências Matemáticas e de Computação
Universidade de São Paulo
Av. do Trabalhador São Carlense, 400 – Caixa Postal 668
13560-970 São Carlos, SP
Abstract. To perform version control activities at Open Source projects, systems
as CVS are often used. However, considerable extra efforts are made to ensure
that users control has been made in such projects, and in many cases the desired
control is not reached. VersionWeb is a tool that is being evolved to ease the
versions control activities and to provide a better users control at Open Source
projects development. This tool shall work as an extra layer to CVS.
Resumo. Para realizar as atividades de controle de versões nos projetos de
Software Livre, sistemas como CVS são freqüentemente utilizados. No entanto,
grande esforço extra é necessário para se fazer o controle de usuários nesses
projetos, e, muitas vezes, o controle desejado não é alcançado. VersionWeb é
uma ferramenta que está sendo evoluı́da para facilitar as atividades de controle
de versões e prover melhor controle de usuários no desenvolvimento de projetos
de Software Livre, funcionando como uma camada extra do CVS.
1. Introdução
Um software é composto por diversos artefatos, entre eles arquivos de código e de
documentação. Durante seu desenvolvimento, um controle sobre as alterações que
ocorrem nos arquivos de código e documentação se faz necessário. Gerenciamento de
Configuração de Software (GCS) é a disciplina responsável por esse controle sobre as
mudanças [Pressman, 2001, Sommerville, 2000].
Para realizar as atividades de gerenciamento de configuração de software, são
utilizadas ferramentas de controle de configuração e de controle de versões. CVS é a
ferramenta atualmente mais utilizada nos projetos de software livre, apesar de diversas
falhas já terem sido detectadas [Reis, 2003].
As principais carências de CVS estão relacionadas com poucos recursos para gerenciamento de usuários e falta de suporte para operações com arquivos (renomear ou mover arquivos) [Berliner, 1990]. Para corrigir as dificuldades de CVS com gerenciamento
de usuários, recursos do sistema operacional ou mecanismos de controle de arquivos e
usuários precisam ser utilizados. Mesmo com a utilização destes recursos, muitas vezes
o controle de permissões para usuários não é tão completo como se desejaria. Já as falhas relativas a arquivos muitas vezes não são corrigidas, e os usuários precisam utilizar
recursos mais complicados quando precisam realizar essas operações.
∗
Apoiado pela FAPESP.
129
130
5° WSL / 5° FISL
VersionWeb é uma ferramenta que foi inicialmente desenvolvida para funcionar
como uma interface web para o CVS. Neste artigo relatamos uma evolução que está sendo
feita na ferramenta a fim de torná-la uma camada extra para o CVS, que suporte o controle
de usuários e permita o controle de permissões de acesso, além de oferecer mecanismos
que permitam aos usuários efetuarem operações sobre os arquivos que estiverem em repositórios CVS.
O restante deste artigo está organizado da seguinte forma: a seção 2 faz uma
breve apresentação de como são utilizados os sistemas de controle de versões nos projetos
de software livre. A seção 3 apresenta VersionWeb e as modificações que estão sendo
feitas para torná-la uma aliada ao desenvolvimento de software livre. Por fim, a seção 4
apresenta as considerações finais.
2. Controle de Versões nos projetos de Software Livre
As ferramentas de controle de versões são essenciais para o desenvolvimento de software livre. Elas são responsáveis pelo armazenamento da base do código dos projetos
[Reis, 2003]. Essas ferramentas permitem que todas as mudanças de cada desenvolvedor
sejam registradas, e, caso necessário, que recuperações de versões especı́ficas do código
possam ser realizadas.
Os projetos de software livre geralmente utilizam sistemas de controle de versões
que possuem repositórios de código centralizados. O sistema mais utilizado nestes projetos é o CVS [van der Hoek, 2000]. Por seguir um modelo de desenvolvimento colaborativo, o acesso de leitura aos arquivos costuma ser sempre permitido a todos os usuários.
No entanto, geralmente algum controle é exigido para acesso de escrita nos repositórios de
código – dessa forma, todos os usuários podem submeter sugestões para os responsáveis
pelos módulos dos projetos, e estes, se julgarem conveniente, integram as modificações
ao repositório de código.
A fim de permitir ao CVS que faça o controle de acesso aos repositórios, várias
configurações adicionais são necessárias, e, muitas vezes, recursos do sistema operacional
são utilizados. Além disso, operações como mover ou renomear arquivos não são suportadas diretamente pelo CVS, e, para serem realizadas, exigem a utilização de comandos
administrativos do CVS ou outros métodos complicados.
A próxima seção apresenta uma ferramenta que está sendo desenvolvida para permitir o controle de grupos no CVS.
3. VersionWeb
VersionWeb é uma ferramenta que foi originalmente desenvolvida como uma interface
web para o CVS [Moreira et al., 2002, Soares et al., 2000]. Está sendo evoluı́da para que
funcione como uma camada extra para o CVS, que permita o gerenciamento de grupos de
usuários com a utilização do mesmo.
Uma estrutura hierárquica dos usuários foi planejada, conforme mostra a figura 1.
Como é possı́vel ver, as seguintes categorias de usuários estão sendo criadas:
Administrador geral: responsável pela ferramenta, pela configuração dos repositórios,
criação de projetos e de administradores de projeto. Também podem criar outros
administradores gerais.
Administrador de projeto: responsável por cada projeto. Cada projeto tem apenas um
administrador, mas este pode criar áreas dentro do projeto, e outros usuários po-
5° WSL / 5° FISL
Figura 1: Estrutura hierárquica dos usuários em VersionWeb
dem ser os responsáveis por estas áreas. Isto pode ocorrer, por exemplo, quando
se tem várias equipes, responsáveis por diferentes partes de um software.
Proprietários de áreas: são desenvolvedores que são denominados, pelo administrador
do projeto, proprietários de áreas – no projeto Mozilla, por exemplo, são utilizados
os “module owners” [Mockus et al., 2002].
Autores: são os desenvolvedores propriamente ditos. Os autores precisam ter permissão
de escrita nas respectivas áreas em que estiverem trabalhando.
A ferramenta está sendo implementada utilizando linguagem Python. Sua arquitetura foi planejada conforme a figura 2: estão sendo implementados diferentes módulos,
cada um responsável por uma parte da ferramenta. Com isso, os módulos poderão ser
utilizados em outras ferramentas, sejam elas ferramentas que precisem apenas de funcionalidades de controle de versões ou das outras funcionalidades disponı́veis nos módulos.
Figura 2: Arquitetura de Versionweb: utilização de módulos
Além de permitir o controle dos usuários no acesso a repositórios CVS, estão
sendo incluı́das rotinas em VersionWeb que devem permitir a realização de algumas
operações sobre os arquivos, como mover e renomear arquivos, mantendo o histórico das
versões. A ferramenta também está sendo integrada com ViewCVS1 para permitir acesso
público de leitura aos repositórios CVS.
1
Disponı́vel em http://viewcvs.sourceforge.net
131
132
5° WSL / 5° FISL
4. Considerações Finais
O desenvolvimento de software livre tem avançado de maneira extremamente rápida, e um
acompanhamento na evolução das ferramentas de suporte se faz necessário. Nesse contexto, este artigo apresenta a evolução que tem sido realizada na ferramenta VersionWeb,
que pretende oferecer melhor suporte ao desenvolvimento de software livre. Mais especificamente, a ferramenta em sua nova versão visa atender a demanda de trabalhos em
grupos sobre os repositórios CVS. Neste artigo, foram apresentados os principais requisitos, relacionados ao suporte a trabalho em grupos, que estão sendo considerados.
Em seu estágio atual de desenvolvimento, a ferramenta funciona como uma camada extra ao CVS. No entanto, acreditamos que com apoio da comunidade em geral
a ferramenta pode ainda evoluir muito, agregando inclusive funcionalidades do CVS e
de outros sistemas de controle de versões, como o Arch2 , que utiliza repositórios distribuı́dos, tornando-se assim uma alternativa aos sistemas atuais que implemente os mais
novos conceitos de gerenciamento de configuração de software.
Referências
Berliner, B. (1990). CVS II: Parallelizing software development. In Proceedings of the
USENIX Winter 1990 Technical Conference, pages 341–352, Berkeley, CA. USENIX
Association.
Mockus, A., Fielding, R. T., and Herbsleb, J. D. (2002). Two case studies of open
source software development: Apache and mozilla. ACM Trans. Softw. Eng. Methodol., 11(3):309–346.
Moreira, D. d. A., Soares, M., and Fortes, R. P. d. M. (2002). VersionWeb: A tool for
helping web page version control. Linux Journal.
Pressman, R. S. (2001). Software Engineering: A Practitioners Approach with E-source.
McGraw-Hill, 5th edition.
Reis, C. R. (2003). Caracterização de um processo de software para projetos de software
livre. Master’s thesis, Universidade de São Paulo, Instituto de Ciências Matemáticas e
de Computação de São Carlos. Dissertação de Mestrado.
Soares, M. D., de Mattos Fortes, R. P., and Moreira, D. A. (2000). Versionweb: a tool for
helping web pages version control. In International Conference on Internet Multimedia
Systems and Applications, pages 275–280, Las Vegas, EUA.
Sommerville, I. (2000). Software engineering. Addison–Wesley, Wokingham [u.a.], 6th
edition.
van der Hoek, A. (2000). Configuration management and open source projects. In Proceedings of the 3rd International Workshop on Software Engineering over the Internet,
Limerick, Ireland.
2
Disponı́vel em http://www.gnuarch.org
5° WSL / 5° FISL
Primeiras Lições Aprendidas na criação de uma Fábrica de
Software Open-Source
Alexandre Alvaro1,3, Thiago Luiz Vieira de Lima Santos1, Paulo Rogério P. Andrade1,
João Marcos P. Vasconcelos1, Jones Albuquerque2, Silvio Romero de Lemos Meira1,3
1
Centro de Informática – Universidade Federal de Pernambuco (UFPE)
Caixa Postal 7851 – 50732-970 – Recife – PE – Brasil
2
DFM - Universidade Federal Rural de Pernambuco (UFRPE)
52171-900 – Recife – PE – Brasil
3
Centro de Estudo e Sistemas Avançados do Recife (CESAR)
50030-260 – Recife – PE – Brasil
{aa2, tlvls, prpa, jmpv, srlm}@cin.ufpe.br, [email protected]
Resumo. Pesquisa e esforços envolvendo fábricas de software têm sido apresentados
ao longo dos anos na literatura. Entretanto ainda existe uma carência de relatos da
criação de fábricas de software open-source para o desenvolvimento distribuído.
Neste artigo serão apresentadas, brevemente, as etapas de criação de uma fábrica de
software open-source e as lições aprendidas durante este processo.
1. Introdução
Ao longo da última década, o desenvolvimento de software open-source tem atraído cada vez
mais atenção. A rápida evolução de projetos de software de código aberto (OSS) como o
sistema operacional Linux, browser Mozilla, IDE Eclipse, entre tantos outros, faz com que
empresas tradicionais procurem meios de aproveitar o potencial do desenvolvimento de código
aberto em suas atividades de desenvolvimento de software.
Educação é um insumo essencial para processo produtivo de software, qualquer que
seja ele. Em particular, devido à falta de expertise mundial nos processos de criação, sob
demanda e em curto espaço de tempo, de fábricas de software para qualquer fim, especialmente
para desenvolvimento distribuído de software, a Pós-graduação em Ciência da Computação da
UFPE está experimentando, já pela segunda vez, o ensino prático do processo de
estabelecimento, medição, afinação e operação real de fábricas de software distribuídas para
desenvolvimento de software aberto. Em particular, a disciplina1 visa aplicar conceitos, técnicas
e ferramentas de Engenharia de Software tradicional, analisando as intersecções e disjunções
entre engenharia de software e o desenvolvimento de software aberto; e definir, montar (projeto
piloto) e avaliar (aplicação real) uma Fábrica de Software Open-Source, analisando durante e a
posteriori sua operação e gerando relatórios detalhados sobre o experimento. Este short paper é
um primeiro relato de uma das fábricas (das três) em andamento na disciplina que está sendo
ministrada no primeiro semestre de 2004.
Um fator relativamente importante das fábricas de software OSS propostas na disciplina
é que elas possuem clientes reais, ao contrário de um “projeto padrão OSS”, onde os detentores
das especificações são os próprios desenvolvedores. Este é um diferencial o qual faz uma
diferença enorme na complexidade do processo, tornando as negociações com o cliente e o
controle de mudanças do projeto - entre outros mecanismos de controle e negociações, como
prazos, preços, itens - essenciais para este tipo de fábrica que esta sendo considerada.
A Fábrica de Software Open-Source USInA (United Software Infra-structure Alliance)
é composta por oito estudantes de Mestrado e Doutorado, que se propuseram a estender os
objetivos da disciplina para prover artefatos do ciclo de desenvolvimento de software (processo,
modelos, procedimentos, guidelines) para que, eventualmente, a comunidade de software open1
http://www.cin.ufpe.br/~in953
133
134
5° WSL / 5° FISL
source pudesse ser beneficiada com as experiências e conhecimentos adquiridos no correr dos
estudos da disciplina.
O artigo está organizado da seguinte forma: a Seção 2 apresenta o processo de criação
da fábrica de software open-source, ressaltando as lições aprendidas durante sua elaboração; a
Seção 3 apresenta o estudo de caso que está sendo desenvolvido pela fábrica; e na Seção 4 são
apresentadas as conclusões e perspectivas de trabalhos futuros.
2. Visão Geral do Processo de Criação da Fábrica
Em função do conhecimento dos membros da equipe em projetos reais de empresas de
desenvolvimento de software, constatou-se que a primeira prioridade era disponibilizar uma boa
infra-estrutura (como sistemas de controle de versão, listas de discussão, ferramenta para
atribuição de tarefas, entre outras). Tais ferramentas possibilitam que os membros da USInA,
geograficamente distribuídos, trabalhassem colaborativamente e de forma organizada. Para
atender a essa necessidade, estão sendo utilizados dois sites que provêm suporte para tal
necessidade, o tigris e o sourceforge. No primeiro está hospedado o site da fábrica USInA2,
contendo o processo e os artefatos a serem gerados durante o desenvolvimento. No segundo foi
criada uma instância do processo da fábrica USInA para o desenvolvimento de um estudo de
caso específico, no caso de simulação de um aquário, chamado Simulare3, o qual será melhor
descrito na Seção 3.
Após esta primeira etapa, a equipe da fábrica se concentrou no desenvolvimento do
processo da USInA, identificando os artefatos a serem gerados e construindo modelos e
procedimentos de uso para tais documentos. Nesta fase, diversos processos e metodologias de
desenvolvimento presentes na literatura serviram como base, como o XP [1], o RUP [2], entre
outros [3,4,5]; assim como diversos relatos de experiências no desenvolvimento de software
Open-Source [6,7,8,9]. Visto isso, foi definido um macro-processo, o qual pode ser visto na
Figura 1. Nele observamos cinco módulos distintos responsáveis por cada uma das fases de
desenvolvimento do software desde a sua fase de pré-venda, até a pós-venda.
Figura 1. Processo de Desenvolvimento
As etapas do processo são:
1. Ciclo comercial: O ciclo comercial define o processo de pré-venda do software. Esta
etapa envolve atividades como: identificação de oportunidades de negócio; apresentação
da fábrica para possíveis clientes (necessária pela abordagem singular que é a de
2
3
http://usina.tigris.org
http://sourceforge.net/projects/simulare
5° WSL / 5° FISL
2.
3.
4.
5.
desenvolvimento de OSS); recebimento e resposta a requisições de propostas (RFP);
negociação de contratos incluindo definição do nível de serviços prestado (SLA);
Planejamento: Esta etapa define a infra-estrutura necessária à realização de projetos de
acordo com o que foi definido na RFP e no SLA. Suas atividades podem ser antecipadas
de forma a tornar as respostas a RFPs e SLA mais completas;
Acompanhamento: Esta etapa define todo o procedimento de monitoramento da etapa de
desenvolvimento. Todo desenvolvimento deve ser acompanhado de perto para permitir a
re-priorização de requisitos, gerenciamento de riscos, resolução de conflitos, e
fornecimento de relatórios ao cliente indicando o status do desenvolvimento;
Desenvolvimento: Esta etapa é dividida em diversas fases. O esforço necessário em cada
fase é variável de acordo com o estágio de evolução do projeto. Em cada iteração da etapa
de desenvolvimento, atividades de todas fases são executadas; e
Suporte comercial: Após a geração de cada release do sistema a fábrica pode fornecer
uma série de serviços associados, como: a instalação do software, treinamentos para a
utilização da ferramenta, e a confecção de manuais e tutoriais do software.
Estas etapas abrangem, além das atividades de desenvolvimento de software, todo o
processo de pré e pós venda, não contemplado por metodologias consolidadas como o RUP [2].
Para cada uma das etapas são disponibilizados modelos dos documentos que devem ser
confeccionados antes que a etapa seguinte tenha início.
Maiores detalhes do processo de desenvolvimento da fábrica de software open-source
USInA, pode ser encontrado no documento de Processo da USInA em seu site.
2.1. Primeiras Lições Aprendidas
Através do processo de criação da fábrica e do processo de desenvolvimento de software opensource, as primeiras lições já puderam ser observadas, descritas a seguir:
- Diferenças de conhecimento: Na criação da fábrica, é muito importante que alguma(s)
pessoa(s) tenham iniciativa prática, pois idéias boas surgem, entretanto pouco é colocado
em prática;
- Infra-Estrutura: Antes de criar uma fábrica de software open-source, a primeira
prioridade é a disponibilização de uma boa infra-estrutura para não impactar nas
atividades da fábrica futuramente;
- Processo Leve: O processo de desenvolvimento de uma fábrica de software distribuída
open-source deve ser o mais leve possível. Processos pesados simplesmente seriam
ignorados por colaboradores externos ou pior, desencorajaria a participação destes. O
processo deve contemplar o mínimo para garantir o entendimento da fábrica por parte do
cliente e facilitar a colaboração entre os envolvidos no desenvolvimento do software;
- Releases Freqüentes: A geração de releases freqüentes afeta positivamente a motivação
dos colaboradores, que podem ver o resultado de seu esforço em pouco tempo. Estas
versões intermediárias também ajudam a refinar os requisitos junto ao cliente;
- Processo Iterativo e Incremental: De uma forma geral, a maioria dos OSS que
obtiveram sucesso são desenvolvidos de forma iterativa e incremental. Assim, o processo
de desenvolvimento deve contemplar isso;
- Integração Contínua: As vantagens da integração contínua [1,10] são ressaltadas em
projetos open-source, contudo, é necessário cuidado durante sua implementação. Um
controle sobre quem pode colaborar diretamente é indispensável;
- Disseminação de responsabilidades entre os colaboradores, conceito de core groups:
Mais de um colaborador divide a mesma responsabilidade de um papel dentro da fábrica.
Isso evita “gargalos” no processo quando se dá a ausência de um colaborador e, facilita a
distribuição colaborativa de atividades;
135
136
5° WSL / 5° FISL
- Distribuição colaborativa de atividades: Com o conceito de core-groups, a delegação
de atividades se torna mais ágil. Uma vez finalizada uma etapa, seus responsáveis (coregroups) delegam tarefas para colaboradores responsáveis das etapas seguintes; e
- Dispositivos de comunicação assíncronos: A incompatibilidade existente entre os
horários disponíveis dos membros da USInA reflete bem a realidade de um
desenvolvimento globalmente distribuído, o que é bastante comum para projetos opensource. Meios de comunicação assíncronos, como e-mail e listas de discussão, são
favorecidos por possibilitarem que cada um colabore quando tiver disponibilidade.
3. Estudo de Caso
Para validar o processo de desenvolvimento da fábrica USInA, foi requisitado pelo cliente
(professores da disciplina) a realização do projeto e implementação de um Simulador de
Aquário. Dentro das diversas tipologias de sistemas ambientais, o aquário pretendido classificase como sistema isolado, controlado, complexo e organizado. Possui como fundamento
algorítmicos, os modelos matemáticos probabilísticos de otimização. Com isso, pretende-se
obter um modelo de conteúdo plenamente especificado e estruturado estocástico.
Este sistema está em desenvolvimento com o intuito de validar o processo proposto de
uma fábrica de software open-source, cujos releases iniciais encontram-se no site do projeto
Simulare. Após isto, haverá a re-calibração da fábrica de software e o projeto piloto será
estendido, podendo haver mudanças de requisitos por parte do cliente, no sentido de validar o
processo em um caso real dentro de uma comunidade open-source. Essa extensão está prevista
para estar em produção até agosto de 2004, quando um relatório final será disponibilizado.
Maiores detalhes do andamento do projeto podem ser vistos no site do projeto Simulare.
4. Conclusões e Trabalhos Futuros
Este trabalho apresentou as primeiras experiências da criação de uma fábrica de software opensource. As lições relatadas auxiliam e servem como ponto de partida para que novas
comunidades de software open-source possam surgir mais estruturadas e organizadas.
Como trabalhos futuros, está o amadurecimento do processo de software open-source
proposto, através da extensão do estudo de caso analisado e da interação com a comunidade
open-source. Ainda, ao final da disciplina, todo o conhecimento adquirido e mais o estado atual
do projeto estarão abertos para a comunidade open-source para novas contribuições.
5. Referências
[1] K. Beck, Extreme Programming Explained: Embrace Change, Addison-Wesley, 1st Edição, 1999.
[2] Rational Software Corporation, RUP - Rational Unified Process, Disponível em: http://www306.ibm.com/software/awdtools/rup. Consultado em Maio 2004.
[3] L. A. Norin, Open-Source software development methodology. Dissertação de Mestrado em
Desenvolvimento de Sistemas e Engenharia de Software. Luleå University of Technology, 1999.
[4] P. Abrahamsson, et. al., Agile software development methods. Relatório Técnico, Finlândia, 2002.
[5] C. Larman, Agile and Iterative Development: A Manager's Guide. Addison-Wesley. 1st Edição, 2003.
[6] D. Hart, Faster, Better, Cheaper: Open-Source Practices May Help Improve Software Engineering.
Disponível em: http://www.nsf.gov/od/lpa/news/03/pr03132.htm. Consultado em Maio 2004.
[7] B. Fitzgerald, D. L. Parnas, Making Free/Open-Source Software (F/OSS) Work Better. Proceedings
do Workshop da Conferência XP2003, Genova, 2003.
[8] W. Scacchi, Understanding the Requirements for Developing Open Source Software Systems, IEEE
Proceedings, Vol. 149, No. 1, pp.24-39. 2002.
[9] The Cathedral and the Bazaar. Disponível em: http://www.catb.org/~esr/writings/cathedralbazaar/cathedral-bazaar. Consultado em Abril de 2004.
[10]
M.
Fowler,
M.
Foemmel,
Continuous
Integration.
Disponível
em:
http://www.martinfowler.com/articles/continuosIntegration.html. Consultado em Maio de 2004.
5° WSL / 5° FISL
OCONGRA - Ferramenta para geração de Grafos de Controle
de Fluxo de Objetos
Paulo Roberto de A. F. Nunes, Ana C. V. de Melo
Universidade de São Paulo
Instituto de Matemática e Estatística
Departamento de Ciência da Computação
9 de maio de 2004
Resumo
Existem diversas ferramentas que auxiliam a realização de testes em programas orientados a objetos. No entanto exigem a aquisição de licenças de uso. Neste artigo é apresentada
uma ferramenta de código aberto que utiliza o critério de análise de uxo de objetos. para
construção de um grafo de controle de uxo com o objetivo de facilitar a análise e geração
de testes.
Abstract
Many testing tools were developed to help us to get good results in testing oriented
objects programs. However, we need to get a non-free license of use. This paper presents a
open source tool that build an Object Control Flow Graph to support system analyses and
generating testing cases.
1 Introdução
O teste de programas é uma fase complexa no desenvolvimento de software. Em sistemas
complexos, os quais envolvem diversas atividades de produção, a probabilidade de encontrarmos
falhas na programação é muito alta [4]. Para diferentes paradigmas de desenvolvimento com
diferentes características, são necessárias técnicas de testes que abordem essas características
para que erros sejam descobertos.
O paradigma de Orientação a Objetos (OO) apresenta diferenças em relação ao de programação procedural. Requisitos de teste aplicáveis a sistemas procedurais tornam-se inadequados para os testes de sistemas Orientados a Objetos - os requisitos mudam de acordo com o
paradigma. Dessa forma, alguns critérios de teste existentes para o paradigma prodedural foram
adaptados para o OO. Existem atualmente diversas técnicas para testes OO, como por exemplo,
baseado em estado [2], teste incremental [3], todos os caminhos [1], baseado no uxo de objetos
[5], etc.
A análise de uxo de objetos segue uma estratégia de validação que se baseia na cobertura
total de estados de transformação de cada objeto do sistema. Tais transformações são denotadas
pela redenição de valores para os atributos dos objetos através da passagem de mensagens entre
eles. Para monitorar o comportamento de cada um dos objetos são analisados todos os pares de
denição e uso, ou seja, os locais onde cada objeto é denido ou usado. Um objeto é denido
quando o construtor do objeto é invocado, um atributo é denido (tem seu valor alterado) ou
um método que inicializa ou modica o(s) atributo(s) é invocado. Um objeto é usado quando
137
138
5° WSL / 5° FISL
um de seus atributos tem seu valor utilizado, um método que utiliza o valor de um de seus
atributos é invocado ou o objeto é passado como parâmetro.
Em [5], Chen & Kao denem 5 passos para a construção de um grafo de controle de uxo de
objetos (GCFO) - que consiste basicamente na ligação entre as classes do sistema e seus métodos
- e os pares de denição-uso (du): criar o conjunto de denição e uso; construir o GCFO inicial
(somente nós com classes e métodos); adicionar ao grafo as arestas intra-métodos; adicionar ao
grafo as arestas inter-métodos; selecionar os pares du.
A cobertura de todos os pares du aumenta a probabilidade de se encontrar falhas no programa. Com o grafo criado torna-se muito mais fácil a visualização do sistema e também a
identicação dos pares du.
A comercialização de ferramentas desenvolvidas para testes muitas vezes inviabiliza a
aquisição das mesmas fazendo com que possivelmente haja perda de qualidade no produto nal.
Diante disso surge a necessidade de uma ferramenta com código aberto que auxilie os testes
orientados a objetos. A OConGra (Object Control Graph): uma ferramenta para geração de
grafos de controle de uxo de objetos. é um software livre que aplica a técinica sugerida em [5]
que gera um grafo e possibilita a elaboração de casos de testes mais precisos.
A Seção 2 apresenta as características principais da ferramenta, onde são abordados os
passos executados pela ferramenta para geração do grafo. A Seção 3 detalha um exemplo de
funcionamento da ferramenta, onde é lido um sistema e em seguida apresentado o resultado
obtido. Finalmente, a Seção 4 conclui apresentando outras utilizações para a ferramenta e
propostas de trabalhos futuros.
2 Características da Ferramenta
A OConGra recebe como entrada um sistema (escrito em Java) e tem como saída o grafo
de controle de seus objetos. O usuário, através de interface gráca, designa o local onde estão
localizados os arquivos fonte do sistema. Após a análise de cada classe do sistema, a ferramenta
produz o grafo e o conjunto de pares du.
2.1 Geração do Grafo
A construção do GCFO de um dado sistema obedece aos mesmos passos sugeridos em [5].
Dessa forma, a ferramenta foi desenvolvida com base nesses passos.
A seguir serão descritas as fases executadas pela OConGra para a geração do GCFO e o
conjunto de pares de denição e uso.
1. Leitura e Identicação do Projeto: o usuário especica o local do projeto. O software
então lê as classes e organiza internamente as informações;
2. Construção do OCFG com as classes-mãe: baseado nos resultados da fase anterior, será
construído o grafo contendo a relação entre cada classe do sistema lido na entrada. Assim,
essas classes terão suas chamadas de métodos denotadas;
3. Identicação das denições-usos através do OCFG: com o grafo denido, as mudanças
de estado dos objetos poderão ser analisadas com maior precisão. Analisando o grafo, o
software identicará cada denição-uso utilizada pelas classes do sistema;
4. Atualização do OCFG baseada nas denições-usos: a identicação das denições e usos
(passo anterior) possibilita a implementação de alterações no grafo obtido no passo 2,
criando assim um novo grafo;
5. Geração gráca dos resultados obtidos: o grafo encontrado após as análises do sistema é
desenhado e exibido de forma gráca ao usuário.
5° WSL / 5° FISL
2.2 Arquitetura da Ferramenta
O sistema está sendo desenvolvido em Java com a utilização da ferramenta Eclipse [6]. Possui
aproximandamente 3500 linhas de código. A arquitetura do sistema é resumida em três partes:
Principal, Estrutura Java e Geração de Grafos.
A parte Principal é responsável pela interface com o usuário. Ela lê os sistemas (através
da parte responsável pela estrutura Java) e exibe como resultado o GCFO (através da parte
responsável pela geração de grafos). Na parte Estrutura Java é feita a leitura de todos os
arquivos do sistema (designado pelo usuário) e organizado de forma a facilitar a geração do
GCFO. E nalmente, a Geração de Grafos recebe a estrutura criada e constrói o grafo nal.
3 Um Exemplo de Uso
Para exemplicar o funcionamento da ferramenta foi criada uma aplicação simples que
instancia uma classe para conversão de unidades de temperaturas:
kelvin <-> fahrenheit, celsius <-> kelvin, fahrenheit <-> celsius.
A classe principal contém um objeto t Temperatura - como pode ser visto na Figura 1 - que
é utilizado para conversões e para exibir os valores de unidades especícas.
Figura 1: Um programa Java para conversão de unidades de temperatura.
Inicialmente, após ter informado a localização do projeto, o software exibe a estrutura dos
arquivos lidos: nome das classes e suas heranças, seus respectivos métodos e quais números de
linhas eles aparecem. A Figura 2 mostra as denições e os usos presentes no método main da
classe App, conforme enunciado anteriormente. Cada linha que possui um objeto é vericada a
ocorrência de uma denição ou de um uso.
Figura 2: Denições e Usos do método main da classe App.
Já a Figura 3 mostra o grafo correspondente ao exemplo. Após identicar a estrutura do
sistema o programa constrói esta saída gráca.
Após identicar as denições-uso e o grafo, é necessário exercitar os pares pelo menos uma
vez. Para isso são criados os seguintes testes: (0,0) - exercita o par (10, 13) da classe App - e
(1,0) - exercita o par (10,15) da classe App. Esses dois testes exercitam todas as intanciações do
objeto t.
139
140
5° WSL / 5° FISL
Figura 3: Grafo de controle de uxo da aplicação.
4 Conclusões
Esse artigo apresentou a ferramenta OConGra utilizada na geração de grafos de controle de
uxo de objetos.
Além da utilização principal, a ferramenta nos auxilia na geração de bons dados para testes,
pois garantem a cobertura total dos casos de denição e uso de objetos. Com isso, caso haja
um erro, a probabilidade de encontrarmos se torna maior, pois os objetos serão exercitados ao
menos uma vez (segundo a técnica [5]).
A OConGra pode ser utilizada no auxílio educacional em matérias de Engenharia de Software
na geração gráca de grafos.
Finalmente, por ser desenvolvida em Java, há a possibilidade de um projeto para adicioná-la
ao Eclipse como um plug-in, o que será de grande utilidade para desenvolvedores, pois ao gerar
os ".class"poderão também gerar os grafos e também o conjunto de denição e uso.
Agradecimentos: Ao CNPq pelo apoio nanceiro e a todos aqueles que participam deste
projeto.
Referências
[1] CHAIM, M. L.. Depuração de Programas Baseada em Informação de Teste Estrutural. PhD
thesis, Faculdade de Engenharia Elétrica e de Computação da Universidade de Campinas,
Novembro/2001.
[2] PINTO, I. M. and PRICE, A. M. A.. Um sistema de apoio ao teste de programas orientados a objetos com uma abordagem reexiva. In XII Simpósio Brasileiro de Engenharia de
Software, pages 87-102, 1998.
[3] HARROLD, M. J., MCGREGOR, J. D. and FITZPATRICK, K. J.. Incremental testing
of object-oriented class structures. In international Conference on Software Engineering,
pages 68-80. IEEE Computer Society Press, 1992.
[4] PRESSMAN, R. S.. Software Engineering. McGraw-Hill, 2001.
[5] CHEN, M. and KAO, H. M. Testing Object-Oriented Programs - An integral aproach. In
. Proccedings of the Tenth International Symposium on Software Reliability Engineering.
IEEE Computer Society Press, 1999.
[6] PROJETO ECLIPSE. Disponível no site Eclipse, URL: http://www.eclipse.org. Consultado
em 15/08/2003.
5° WSL / 5° FISL
Sessão Técnica 10
DESENVOLVIMENTO III
141
142
5° WSL / 5° FISL
5° WSL / 5° FISL
Plataforma Mono: Estrutura e Utilização do framework
.NET como Software Livre1
Quéli Giaretta2, Jacques Duílio Brancher
Universidade Regional Integrada do Alto Uruguai e das Missões - Campus de Erechim
Av. Sete de Setembro, 1621 - Centro - Erechim - RS
Abstract. This paper presents a general view about the Mono Project. The basic idea is to
show the development of the platform, the operation structure, specifying the advantages
and the news that Mono makes available together with the new tecnologies that it
implements. The programming languages that can be used to create new applications,
mentioning the main projects under development that use this framework, and also a brief
description of the Mono Brasil project.
Resumo. Este artigo apresenta uma visão geral do Projeto Mono. A idéia básica é mostrar
o desenvolvimento da plataforma, a estrutura de funcionamento, especificando as
vantagens e novidades que o Mono disponibiliza junto com as novas tecnologias que o
mesmo implementa. As linguagens de programação que podem ser utilizadas para a
criação de novas aplicações, citando os principais projetos em desenvolvimento que
utilizam desse framework, e também uma breve descrição do Projeto Mono Brasil.
1. Introdução
O Projeto Mono é uma iniciativa para desenvolver uma versão baseada em GNU/Linux, como
Software Livre, da plataforma de desenvolvimento .NET da Microsoft. Segundo [Kuhn 2003] ele
incorpora componentes-chave do .NET e um suite completo de bibliotecas de classe. O projeto criado
em 2001 é liderado pela Ximian, empresa software livre que levou o desktop GNOME a um grande
sucesso. Tem por objetivo permitir que os desenvolvedores criem aplicações .NET e rodem elas sobre
o Windows ou qualquer plataforma suportada pelo Mono, incluindo GNU/Linux, todos os programas
desenvolvidos sobre a plataforma .NET passam a ser híbridos, podendo ser executados em qualquer
ambiente que possua um framework .NET instalado. Esta disponível a versão beta do Mono,
compilador C# e máquina virtual versão 1.0, suporte x86, PowerPC, SPARC e S390, Java VM para
rodar aplicativos Java e .NET, suporte para Linux, MacOS X, Windows, Solaris e HP-UX. Segundo
[Roith e Hansen 2004] a plataforma .NET se tornara portável, em breve.
Vários projetos já estão em andamento, uns para o desenvolvimento da própria ferramenta e
outros para aplicações especificas. Um exemplo disso é o MonoBasic que a comunidade brasileira
ajuda desenvolver, trata-se de um compilador .NET dentro do projeto Mono. Outro projeto
interessante é o Mono A.I., conforme [Binhara 2003] o projeto compreende uma série de ferramentas
voltadas a programação de agentes e sistemas de inteligência artificial.
2. Arquitetura do framework
O Mono, é um ambiente multilinguagem orientado a objetos, possui características para facilitar a
reutilização de classes entre as linguagens além de facilitar a estruturação de arquiteturas e soluções.
Segundo [Roith e Hansen 2003] o Mono organiza as APIs em divisões lógicas chamadas
namespaces, sincronia entre os headers e a implementação, os metadados que substituem os headers
são completos e estão dentro das montagens chamadas de assemblies, junto com o código. Além disso
há um esquema de controle de versões, para evitar o uso de versões incompatíveis de classes.
1 Integrante do projeto AITEM/EAD - Edital Software Livre - CNPq 401.193/2003-9
2 Estagiária do projeto AITEM/EAD - URI - Campus de Erechim
143
144
5° WSL / 5° FISL
O Mono engloba uma série de tecnologias em seus class libraries equivalente aos disponíveis
para Java. Mas no geral é mais fácil encapsular funcionalidades já prontas (como o GTK ou o QT) em
Mono do que em Java (via JNI), e normalmente obtendo-se melhor desempenho.
A Common Language Infrastructure (CLI), conhecido como runtime, implementa a execução
do Mono, usado para compilar uma aplicação .NET. Faz uma chamada ao runtime definindo os
parâmetros necessários. É uma máquina virtual que contém um carregador (loader) de classes
(carrega as classes que um programa usa para executar sua funcionalidade), um compilador JIT (justin-time), que compila o programa na sua primeira utilização gerando um código para a CPU nativa e
um ambiente de garbage collection, que gerencia o uso da memória. A CLI tem a mesma função que
a Java Virtual Machine (JVM) da linguagem Java. Segundo [Binhara e Teixeira 2003] a CLI é o
componente que irá permitir que programas escritos em C# sejam executados em sistemas
operacionais não-Windows, como o Linux.
O mecanismo de garbage collection, evita uma série de problemas (basicamente com
ponteiros perdidos, e desperdício de memória) que normalmente estão presentes no desenvolvimento
C/C++, pela dificuldade em eliminá-los sem um longo processo de depuração.
Conforme [Roith e Hansen 2003], as bibliotecas de classe fornecem uma gama de facilidades
para o desenvolvimento das aplicações. Escritas primeiramente em C#, podem ser usadas com
qualquer linguagem. A biblioteca de classe é estruturada com namespaces, e desenvolvida com
bibliotecas compartilhadas denominadas assemblies. Quando falamos da estrutura do .NET, estamos
consultando primeiramente estas bibliotecas de classe, é o elemento que permitirá que as aplicações
realizem funções vitais, tais como processamento XML, entrada/saída e conexão a redes. O projeto
Mono pretende criar uma biblioteca que seja compatível com a CLI da Microsoft, permitindo que os
programas escritos para Linux/Mono sejam executados com a mesma funcionalidade no
Windows/.NET. Além disso, existe uma grande expectativa de que a comunidade código livre crie
bibliotecas adicionais para funcionalidades extras compatíveis com a CLI.
Todo código desenvolvido para o framework .NET é dito gerenciado, ou seja, o executável
não contém código Intel x86 e sim código MSIL com chamadas à biblioteca de classes; o
gerenciamento de memória é feito automaticamente com o uso do garbage collector; as atribuições
têm o tipo validado, a princípio o sistema de tipos é inviolável; operações que podem comprometer a
segurança, exigem permissões especiais. Essas qualidades permitem rodar programas de origem
duvidosa, sem que estes possam comprometer a segurança e integridade do sistema.
3. Tecnologias Implementadas
3.1. Compilador C# (Padrão ECMA 334)
Ambiente de Execução CLI (Common Language Infrastructure). Permite que as aplicações rodem
independentes de plataforma. A linguagem C# é uma boa migração para quem vem do C padrão do
GCC, ou do C++ do mesmo compilador. Traz orientação a objetos plena, sintaxe para metadados
embutidos (atributos), distinção sintática para definição de propriedades e campos, e unicidade
sintática para o uso de ambos. É a aposta da Microsoft na concorrência com o Java, oferecendo todos
os recursos de uma linguagem de programação moderna, como orientação a objetos, suporte para
interfaces/componentes e, principalmente, código (managed code).
O código criado pelo C# não é específico para um determinado tipo de máquina. Isso permite
que o mesmo código seja executado em uma variedade de máquinas, tais como PCs, máquinas RISC,
handhelds ou palms e celulares. É necessário que exista uma máquina virtual (CLI) para cada tipo de
máquina em que o código será executado. Outra vantagem é o aumento na segurança e na estabilidade
do código gerado. Isto é obtido pelo modo como o código e a máquina virtual tratam a execução ,
impedindo qualquer operação que ponha a máquina em risco. Este foi um dos principais motivos para
a mudança de rumos da Ximian, que antes desenvolvia usando linguagens tradicionais como C. Todo
programa criado pelo compilador C# é dito verificável. Conforme [Roith e Hansen 2003] isto quer
dizer que o compilador JIT pode, em tempo de execução/ compilação, verificar e garantir que o
programa não faça nenhuma operação que comprometa a segurança e integridade do sistema.
5° WSL / 5° FISL
O MCS (The Ximian C# Compiler), segundo [Roith e Hansen 2003] é atualmente capaz de
compilar-se e compilar aplicações C# (ele inclui uma suite de testes para serem usados). É usado
também para compilar o Mono. Há ainda algumas áreas que não foram abrangidas pelo compilador
Mono, mas são muito poucas (atributos de segurança). A suite de testes é mantida para seguir o
progresso do compilador e os vários programas rotineiramente compilados e executados. O MCS não
compila o código original, mas um tipo do bytecode, que possa ser processado pelo runtime do Mono.
3.2. VB
O VisualBasic.NET trás muitas funcionalidades novas, tornando-se poderoso como C# e outras
linguagens. Graças às CLIs escritas em MonoBasic pode ser usado da mesma maneira que C#.
De acordo com [Roith e Hansen 2003], o Mono Basic.NET Compiler é um compilador CLI
para a linguagem VB, uma extensão da versão VisualBasic.NET. É baseado no compilador do MCS e
ainda em forte desenvolvimento, a idéia é suportar 100% da sintaxe .NET (arquivo .vb) e oferecer
extensões para fontes MonoBasic (arquivos .mbs), que podem ser misturados na mesma compilação.
3.3. ADO.NET
Mono oferece uma relação comum às bases de dados. Muito portátil, funciona em todas as
plataformas. ADO.NET está sendo implementado e já está bastante funcional.
Segundo [Roith e Hansen 2003] é uma API de acesso a dados, em especial bases de dados
relacionais. A Microsoft prove ao .NET os provedores de base de dados para MS SQL Server, Oracle,
ODBC, Ole-DB e XML. O Mono pode acessar as mesmas bases, e ainda Database MySQL,
PostgreSQL, e IBM DB2. Bases não disponíveis podem ser utilizadas através de ODBC ou OLE-DB.
Ambos são executados em sistemas Windows e Linux. Todas essas bases de dados tem uma interface
em comum. Há um provedor de XML, ele permite acessar arquivos XML em uma base de dados.
3.4. ASP.NET
Baseado em [Roith e Hansen 2003] pode-se dizer que o ASP.NET é o melhor framework que se tem
para desenvolvimento de WebSites e WebServices. É uma linguagem independente. Você pode
acessar todas as características das bibliotecas de classe e isso é muito rápido, porque todas as
bibliotecas são compiladas. ASP.NET apresenta WebForms, que criam elementos HTML acessando
objetos e organizando no HTTP, é possível desenvolver no Windows e rodar em Linux.
3.5. Gtk#
Segundo [Roith e Hansen 2003] Gtk # (Gtk sharp) é uma ligação da linguagem C# para o toolkit do
Gtk+ e outras bibliotecas que fazem parte da plataforma do GNOME.
Chamado de GIMP toolkit porque se originou do programa da manipulação da imagem do
GNU (GIMP), mas tem sido usado em um grande número de projetos de software, incluindo GNU
Network Object Model Environment (GNOME). O GTK# faz a ligação entre as classes Mono e o
Gnome. GTK+, Glade, gnome-db e GStreamer são suportados. A grande maioria de suas bibliotecas
são suportadas por sistemas Unixes, MacOS X e Windows e estão integradas no desktop Gnome. Há
também um esforço para que se consiga exportar um widgets GTK+ Windows e MacOS X.
3.6. QT#
Fornece uma ligação às bibliotecas de desenvolvimento do KDE. A base das bibliotecas estão
disponíveis também para Windows e MacOS X, mas são livres somente no Linux.
3.7. XML
Mono tem o suporte completo para Xml, com muitos parsers e bibliotecas de processamento.
4. IDEs - Eclipse & #Develop
145
146
5° WSL / 5° FISL
O Eclipse é uma plataforma de desenvolvimento opensource, extensível e Java-based, que integra
ferramentas de desenvolvimento, baseada em plug-ins. Com a multi-language do Mono, este parece
ser um projeto muito importante para o futuro desenvolvimento das aplicações neste framework. O
plugin C# desenvolvido para Eclipse embora faltando algumas características interessantes,
implementa a estrutura e sintaxe da linguagem. Um outro ponto extra é que, o eclipse pode usar o
toolkit Gtk2 no GNU/Linux, utilizado por usuários de Gnome, porque se adapta melhor ao ambiente.
O #Develop (SharpDevelop) é uma IDE para C# e projetos do VB.NET da plataforma do
NET da Microsoft. É open-source (GPL), e mais completo que o Eclipse, a única desvantagem é, não
funcionar em Linux/Mono, pois System.Windows.Forms não são suportados, ainda. Tem editor de
código C#, ASP.NET, ADO.NET, XML, HTML.
5. Projeto Mono Brasil
Tem por objetivo dar aos desenvolvedores brasileiros mais uma opção frente às plataformas
proprietárias.
O projeto pretende criar uma central de informações sobre a comunidade. Incentivar o uso da
plataforma em projetos de pesquisa, fornecendo todas as informações necessárias para a formação de
novos desenvolvedores. Busca de recursos para desenvolvimento de projetos de visibilidade nacional.
O website do projeto http://monobrasil.softwarelivre.org/, já possui diversos contribuintes, oferece
sessões de documentação, artigos, how-to, etc. e, explicações detalhadas de como instalar o Mono.
6. Conclusão
Com o objetivo de trazer para o desktop Linux a facilidade de desenvolvimento gerado pelo
framework .NET o Mono é uma peça chave para o sucesso do desktop no Linux, especialmente por
atacar sérios problemas na área de estabilidade/ compatibilidade de APIs.
Após ter apresentado uma visão geral do Projeto Mono, o que precisa ser feito é sensibilizar o
desenvolvedor livre da importância, para tais características: Linguagens modernas (orientadas a
objetos) e ambiente menos suscetível a falhas catastróficas (coleta de lixo), menos e melhor
depuração, APIs estáveis e versionadas. Portabilidade binária para Windows e outras plataformas.
Incomparável suporte a Web Services seguros. E a mais importante, GPL para o runtime,
compiladores, ferramentas, e algumas bibliotecas de terceiros (como a NPGSQL), e a total liberdade
na licença de suas bibliotecas e aplicações que executem sobre o Mono.
7. Agradecimentos
O presente trabalho foi realizado com o apoio do CNPq, uma entidade do Governo Brasileiro voltada
ao desenvolvimento científico e tecnológico. Os autores também agradecem a URI - Campus de
Erechim, pelo financiamento da bolsa de iniciação científica da acadêmica Quéli Giaretta.
BINHARA, A., TEIXEIRA R. Projeto Mono Brasil (2003) http://monobrasil.softwarelivre.org/.
Último acesso em Maio, 2004.
KUHN, Bradley M. Free Software Foundation (2003). http://xmundo.net , Abril, 2004.
ROITH, J. e HANSEN, M. W. Mono-Doc (2003) http://Mono.ximian.com:8080, Março, 2004
ROITH, J. e HANSEN, M. W. The Mono Handbook (2003)
http://www.gotmono.com/docs. Março, 2004.
Softsteel Solutions - C# Tutorial (2003). Disponível em:
http://www.softsteel.co.uk/tutorials/cSharp/cIndex.html. Fevereiro, 2004.
Microsoft .Net Framework Home. http://msdn.microsoft.com/netframework/. Abril, 2004.
5° WSL / 5° FISL
Mico - University Schedule Planner
Alexandre Freire , Alfredo Goldman ,
Carlos Eduardo Ferreira , Christian Asmussen , Fábio Kon
1
Department of Computer Science
Institute of Mathematics and Statistics
University of São Paulo
{alex,krico}@arca.ime.usp.br {cef,gold,kon}@ime.usp.br
mico.arca.ime.usp.br
Abstract. This paper describes the development of Mico, the XPUSP University
Schedule Planner. It is a system that manages the creation of a schedule for the
courses of the Computer Science department and the allocation of professors
to teach these courses based on preferences gathered from professors and students. It has been developed using free software and it is itself free software,
available under the GNU GPL. We will give a short description of the problem
we want to solve and how the system works, then we will discuss the free software frameworks and tools used in the development and our interaction with the
free software development community.
1. Introduction
One of the main administrative tasks in schools and colleges is the construction of the
course schedule and allocation of teachers to the courses they will lecture in the period.
There are many constraints that play an important role in these allocations. University
students show preferences to some elective courses and the period they should be offered.
Professors also have their course and time preferences and the department must fulfill its
requirements. To find a perfect allocation and schedule is a very difficult task which the
department head must face each year.
We did not find any existing software tool that incorporated the features we needed
to solve this problem in our department. However, “Arca” (ark in Portuguese): the free
software development group at the Department of Computer Science at IME/USP accepted the task to produce this tool. And so “Mico” was born (the tools developed by
Arca are named after animals).
Mico is a Web application that manages the creation of such a schedule. It was
developed following the eXtreme Programming methodology [1]. The system has been
in development since the second semester of 2001. Initially, it was the subject of the first
course in eXtreme Programming [1] taught in Brazil. After that, many programmers have
contributed. The project is currently maintained by a group of students in the Arca Group
[2].
The system works through a website where students and professors input their
preferences, professors indicate what time and days of the week they want to lecture
in, and students choose which required courses they want to attend and vote on elective
courses that they would like to be offered. The application then uses a genetic algorithm
[3] to find an optimized schedule and allocate the professors to the courses they should
lecture.
147
148
5° WSL / 5° FISL
Throughout the development of this system many free software tools and frameworks were used following the eXtreme Programming methodology. Section 2 describes
the problem requirements we considered. In section 3 we describe the system in some
detail, as well as the tools and frameworks used. In section 4 we discuss how the XP
methodology applies to the development of free software. This paper ends with some
conclusions.
2. The problem
Allocating the professors to the courses they should teach and these courses to given
periods is not an easy problem. To solve it, we had to consider many important points.
All student and professor preferences should be taken into account. For instance,
the elective courses with the most student votes should be offered, professors can only
lecture the courses they are qualified to lecture and in the periods they are available.
Given these and many other restrictions it is possible that a perfect schedule does
not even exist. In our application we define some requirements for the solution (e.g. one
teacher cannot be allocated to two courses at the same time, the required courses of the
semester must be offered). Other constraints are not strong (e.g. preferences of students
and teachers) and are used to evaluate the quality of different solutions.
3. The system
The system is accessed via a Web interface available for the students and professors of
the department. There are 3 types of users: professors, students and administrators.
Each year the administrators are responsible for starting a poll amongst students
and professors. Students can then log into the system and choose which required courses
they would like to attend and also vote for their preferred elective courses. The professors
can choose which courses they are able to lecture and which courses they prefer. They can
also indicate time preferences, tell the system that they will not be available for lectures
during a given period or even for a sabbatical semester.
We chose to solve this problem using a known technique for combinatory optimization problems, called genetic algorithms [3], which uses genetic evolution as a
metaphor for improving the quality of a solution to a problem. Using this approach we
model each possible solution as a gene, and start out with a randomly created population.
At each interaction, the algorithm selects the best fit solutions, i.e., the solutions that obey
most of the rules we have established, and using different approaches, like mutation or
cross-over reproduction, creates a new population. After a given number of interactions,
we expect that a near optimal solution will be reached.
After the poll is finished, the administrator executes the solution engine. The
algorithm periodically outputs the best solution found so far. When the administrator is
satisfied with the given solution he will be able to stop the algorithm and make manual
adjustments to the schedule if necessary. He can then publish the results for all users
to consult. The system is under development and some parts of this process are not yet
implemented.
3.1. Free Software Tools and Frameworks
All throughout the development of this system we have relied solely on a free software
infrastructure. Development was carried out on GNU/Linux workstations using common
tools, such as bash and Emacs. We chose Java as the main programming language but
5° WSL / 5° FISL
also have some code in Perl and C++. The project is currently hosted at SourceForge and
we use most of the features available there, such as the CVS server. Tools on SourceForge
were used to create a structure to track our project using the XP methodology: store story
cards, track progress, and so on.
The system was based on the Model-View-Controller (MVC) pattern [4], we
found the necessary tools to speed and re-enforce this pattern available as free software.
The Jakarta Group [5] - java sub-division of the Apache Free Software foundation - had a
very important role in providing these tool and frameworks.
The code was edited with GNU Emacs, built by Ant (Jakarta’s pure java build
tool), deployed on Tomcat (Jakarta’s servlet container) and persisted on MySql[8]. The
versioning of the source is controlled with CVS and hosted on SourceForge. Several other
- free software - tools like Open-ssh, GNU make and Dia were used either by the build
scripts or on our daily tasks.
Using frameworks such as Turbine[6] (Jakarta’s java Web application framework),
Velocity (Jakarta’s java template engine) and Torque[7] (Jakarta’s java persistence layer)
it was possible to build a database independent, secure Web application with source separated from layout.
To implement the genetic algorithm we have also relied in free software libraries.
In the beginning a C++ library was used but due to bugs with the Java to C++ bridge (JNI)
this was discontinued. As a replacement we used JGap [9], a java framework.
3.2. Feedback of the free software community
All through development we interacted with the free software community, but most important was the attention we got from other developers. Two North American developers
were interested in our project (we believe it is the only free software system available for
complex schedule creation) and one of them even submitted some documentation for our
project.
In the beginning of the project we mostly asked questions in the Turbine user
list and found solutions to common problems. As we grew more competent in these
frameworks we also talked to developers, suggesting new features and relating bugs we
found. Since we had access to the source code we could even point out where some bugs
were located in their code.
In particular, as we started using the JGap library, we maintained a close relationship with the main developer, submitting bugs and feature requests.
4. Producing Free Software using XP Methodology
We have had a great experience using eXtreme Programming techniques during the development, however some problems occurred when dealing with the free software community.
When outside developers showed interest in contributing to our project, we found
no plausible way to pair program with them (one of the main “dogmas” of XP). We were
located in different continents and time zones, what made it hard for any outside developer
to get to know the code and to be able to help. Pair programming is a XP technique where
two programmers share the same computer and work together. It is very effective and
actually cuts down development time. Also, “the code is the documentation”, another XP
paradigm, suffered from the fact that outside developers could not come into daily contact
with the rest of the team. One of the american developers had trouble understanding some
149
150
5° WSL / 5° FISL
of the advanced concepts we were using and in the end contributed only documentation
that was created to aid him in this understanding, perhaps if the project was simpler and
if he could pair with us he could have devoted this time to develop some code as well.
Another problem was that a part of this documentation quickly grew outdated.
As support for the eXtreme Programming methodology we have also customized
our project page at SourceForge to host online story cards, this way all developers had
quick access to all story cards and we could keep an online record of what was being
done and track our progress.
Using eXtreme Programming really payed off, we were able to develop a complex
system and manage the project easily. It interacted nicely with the free software production model, and even tough we encountered some problems with outside developers we
could work around them.
5. Conclusion
We have had a great experience developing free software in the university, and have shown
it is possible. It is a good model to adopt since there are so many free software tools,
frameworks and libraries available that could be used to accelerate development of many
systems. Also, we believe we should give something back to the community and contribute to make it grow.
Having the source available for the projects we had to use was a great asset: we
could learn from what others had done and find programming errors easily. Also, the
free software community was very helpful and we received some great feedback from
interested users.
We felt it was worth using free frameworks even though they were work in
progress, we had a good, close relationship with the community and had a clear vision of
what was working or not and what to expect. In the Jgap case the developers put together
a new release one week after hearing from us, fixing bugs and adding requested features.
It is gratifying to work in free software and find out that the community is interested in your project and would like to use it. Mico has been used to produce the courses
allocation for professors in 2003 and 2004. Its use has brought some new necessary features to the system and showed that in house development produced software very useful
to the department.
References
[1] [Beck 1999] - Extreme Programming Explained.
[2] Arca Project - http://www.arca.ime.usp.br
[3] [Whitley 1993] - A Genetic Algorithm Tutorial.
[4] [Model 1988] - ”The Model-View- Controller (MVC) ParadigmUser Interfaces” OOPSLA’88 Tutorial, ACM.
[5] Jakarta Project - http://jakarta.apache.org/
[6] Turbine - http://jakarta.apache.org/turbine
[7] Torque - http://db.apache.org/torque
[8] MySql - http://www.mysql.com/
[9] Jgap - http://jgap.sourceforge.net
5° WSL / 5° FISL
TerraLib: The Architecture of an Open Source GIS
Library
Gilberto Câmara1, Antônio Miguel Vieira Monteiro1, Ricardo Cartaxo Modesto de
Souza1, Lúbia Vinhas1, Karine Reis Ferreira1, Juan Carlos Pinto de Garrido1, Gilberto
Ribeiro de Queiroz1, Marcelo Tílio Monteiro de Carvalho, Marco Antônio Casanova2,
Ubirajara Moura de Freitas3
1
Image Processing Division – National Institute for Space Research (DPI/INPE)
2
3
TECGRAF – Catholic University of Rio de Janeiro (TECGRAF-PUC-RIO)
GIS Division – Research Foundation for Space Technology (GEO/FUNCATE)
{gilberto, miguel, cartaxo, lubia, karine, juan, gribeiro}@dpi.inpe.br
{tilio, casanova}@tecgraf.puc-rio.br, [email protected]
Abstract. This paper describes the architecture of TerraLib, and open source library
for handling spatio-temporal data types in object-relational DBMS.
1
Introduction
Geoinformation technology (GI) denotes the branch of information technology that develops
and deploys systems for handling spatial data. GI includes geographical information systems
(GIS), global positioning systems (GPS), location-based services, and remote sensing image
processing. GI is a key technology for Brazil, given its vast range of applications in areas such
as environmental protection, urban management, agricultural production, deforestation
mapping, public health assessment, crime fighting, and socioeconomic measurements. In recent
years, this area is undergoing substantial change, due to increased availability of database
management systems (DBMS) that can handle spatio-temporal data types. In order to allow the
open source GIS community to benefit from this opportunity, the authors are developing
TerraLib, a software library that supports quick development of custom-built applications using
spatial databases. TerraLib also allows the development of GIS prototypes that include recent
advances in spatial information science, such as spatio-temporal data models(Erwig et al.
1999), spatial statistics (Anselin 1999) and environmental modelling (Burrough 1998).
2
The Architecture of TerraLib
A crucial design decision in any open source project is its software architecture. All successful
open source products such as Linux, PostgreSQL and Apache have a kernel whose maintenance
is the responsibility of a very small team. The kernel has to be stable and to allow easy
extension without internal changes. Contributions from the community occur at the external
layers of the system. As an example, out of more than 400 developers, the top 15 programmers
of the Apache web server contribute 88% of added lines (Mockus, Fielding, and Herbsleb
2002).
However, not all software products have well-defined paradigms as in the case of operating
systems and DBMS. The challenge in GI technology is to combine object-relational DBMSes
that handle spatial data structures with modules that perform functions such as spatial analysis
and dynamic modeling. A typical GI application consists of three steps: (a) querying the spatial
database; (b) manipulating the query results to generate new objects; (c) visualizing the
151
152
5° WSL / 5° FISL
resulting objects. These three capabilities (query, manipulation and visualization) should all be
part of a generic GI software library. To respond to these requirements, TerraLib has four main
components, as shown in Figure 1:
•
kernel: the core of TerraLib is composed of: (a) spatio-temporal data structures; (b)
support for cartographic projections; (c) topological and directional spatial operators; (d)
an API for storage and retrieval of spatio-temporal objects in object-relational DBMS;
(e) classes for controlling visualization of spatial data. Kernel maintenance and upgrade
is the responsibility of the project core team (INPE and TECGRAF), as typical for other
free software projects.
•
drivers: modules that implement the kernel’s generic database API to access DBMS
products such as mySQL and PostgreSQL, and external files in both open and proprietary
formats. Basic maintenance and upgrade is the responsibility of the project core team, but
there is a large scope for external contribution.
•
functions: algorithms that use the kernel structures. Typical functions include spatial
analysis and query and simulation languages. The functions are designed to allow
external contribution.
•
interfaces: consist of different interfaces to the TerraLib components, to allow software
development in different environments (C++, Java, COM) and also the support for Open
GIS services such as WMS (Web Map Services) protocol.
Figure 1 – TerraLib Software Architecture
2.1
The TerraLib Kernel
Some of the key issues involved in the design of the TerraLib kernel include:
• Support for spatio-temporal applications: In order to handle different types of spatiotemporal applications, TerraLib includes different types of spatio-temporal data types
(events, mobile objects, and evolving regions) and supports spatio-temporal queries. Each
spatial object has a unique and persistent identifier and a spatial location. The descriptive,
5° WSL / 5° FISL
spatial and temporal components of geographical objects are stored separately on the
database and are linked by the object’s id.
•
New types of data structures: Models of spatial processes, including patterns of land use
and land cover, socioeconomic and demographic characteristics, are becoming increasing
important for geographical applications. To support these models, TerraLib includes cell
spaces in a GIS database environment. This allows is an important improvement over
current GIS technology, where most dynamical models based on cell spaces have a very
loose coupling with a GIS. In TerraLib, we have implemented support for dynamic models
using cell spaces, which generalize cellular automata by providing multiple attributes and
flexible neighborhood definitions (Pedrosa et al. 2002)..
•
Efficiency in large-scale applications: emerging GIS applications require storage and
retrieval of hundreds of thousands of spatial objects, as well as very large satellite imagery.
TerraLib supports spatial indexing of both raster and vector data, including multi-resolution
and block segmentation techniques for handling satellite imagery (Vinhas, Souza, and
Câmara 2003).
2.2
The TerraLib Drivers
The interface between the kernel and the various DBMS and file formats is done by the
modules contained in the drivers component of TerraLib. When designing this component, we
considered that the library should be able to handle different object-relational databases
management systems transparently. This has required careful design of a DBMS interface that
handles specific features of each DBMS and allows a single software interface for different
systems such as PostgreSQL and mySQL (Ferreira et al. 2002).
2.3
The TerraLib Functions
The interface between the kernel and the function components has been designed to allow
maximum extensibility. TerraLib should be extensible by other programmers, and the
introduction of new algorithms and tools should not affect already-existing code. To achieve
extensibility, we have adopted the principles of generic programming. TerraLib uses iterators
over spatial data structures to decouple algorithms from data structures, thus simplifying
extensibility. For example, for computing a histogram it is not essential to know if the elements
are organized as a set of points, a set of polygons, a grid or an image. All that is needed is the
ability to look into a list of values, and to obtain, for each element of the list, its values and the
indexes of the elements of the list that satisfy a certain property (for example, those that are
closer in space than a specified distance). In a similar way, a large number of spatial analysis
algorithms can be abstracted away from a particular data structure and described only in terms
of their properties. (Vinhas et al. 2002).
2.4
Programming Interfaces
The straightforward way to use TerraLib to develop GIS applications is to embed its C++
classes into a new system. However, the TerraLib designers have to take into account the
diverse qualifications and preferences of the GIS programming community. Interfaces for Java
and COM programming environments have been designed and are currently being
implemented. An interface for the Open GIS web services specification is also under
development.
153
154
5° WSL / 5° FISL
2.5
Project Status: May 2004
The TerraLib version 3.0 has been released on early May 2004, with an investment of 40 manyears of work. It comprises 95.000 lines of code in C++, plus 195.000 lines of code of thirdparty libraries. The software is available at the website http://www.terralib.org. There are
already many different applications that use TerraLib, including:
•
TerraView is a tool for spatial data analysis, which provides the basic functions of data
conversion, visualization, exploratory spatial data analysis, spatial statistical modelling
and spatial and non-spatial queries. This product is being used as general visualization
tool for TerraLib databases, and its source code is available together with TerraLib.
•
InfoPAE is an automated system designed to improve the response to emergency
situations for the petroleum industry. InfoPAE is developed by TECGRAF/PUC-RIO,
under contract from PETROBRAS. Current plans include implementing InfoPAE at
nearly 80 installations throughout 2003.
•
SIGMUN is a system for handling cadastral applications in metropolitan areas, used by
the cities of Santos, São Sebastião, Caraguatatuba, São José dos Campos, São Bernardo
do Campo, Cachoeiro de Itapemirim, Vitória, and in 30 cities of the state of Bahia .
References
Anselin, Luc. 1999. Interactive techniques and Exploratory Spatial Data Analysis. In
Geographical Information Systems: principles, techniques, management and applications,
edited by P. Longley, M. Goodchild, D. Maguire and D. Rhind. Cambridge:
Geoinformation International.
Burrough, P. 1998. Dynamic Modelling and Geocomputation. In Geocomputation: A Primer,
edited by P. Longley, S. Brooks, R. McDonnell and B. Macmillan. New York: John Wiley.
Erwig, Martin, Ralf H. Güting, Markus Schneider, and Michalis Vazirgiannis. 1999. SpatioTemporal Data Types: An Approach to Modeling and Querying Moving Objects in
Databases. GeoInformatica 3 (3):269-296.
Ferreira, Karine Reis, Gilberto Queiroz, Joao Argemiro Paiva, Ricardo Cartaxo Souza, and
Gilberto Câmara. 2002. Arquitetura de Software para Construção de Bancos de Dados
Geográficos com SGBD Objeto-Relacionais. Artigo apresentado em XVII Simpósio
Brasileiro de Banco de Dados, em Gramado, RS.
Mockus, Audris, Roy Fielding, and James Herbsleb. 2002. Two case studies of open source
software development: Apache and Mozilla. ACM Transactions on Software Engineering
and Methodology 11 (3).
Pedrosa, Bianca, Gilberto Câmara, Frederico Fonseca, and Ricardo Cartaxo Modesto de Souza.
2002. TerraML - A Cell-Based Modeling Language for an Open-Source GIS Library.
Artigo apresentado em II International Conference on Geographical Information Science
(GIScience 2002), em Boulder, CO.
Vinhas, Lubia, Gilberto Ribeiro de Queiroz, Karine Ferreira, Gilberto Câmara, and João
Argemiro Paiva. 2002. Programação Genérica Aplicada a Algoritmos Geográficos. Artigo
apresentado em IV Simpósio Brasileiro de Geoinformática, em Caxambu.
Vinhas, Lubia, Ricardo Cartaxo Modesto de Souza, and Gilberto Câmara. 2003. Image Data
Handling in Spatial Databases. Artigo apresentado em V Simpósio Brasileiro de
Geoinformática, em Campos do Jordao.
5° WSL / 5° FISL
Sessão Técnica 11
APLICAÇÕES
155
156
5° WSL / 5° FISL
5° WSL / 5° FISL
Software Livre na Informatização de Acervos Históricos
Elisa Yumi Nakagawa1∗
1 Depto
de Ciências Administrativas e Tecnologia
Centro Universitário de Araraquara - Uniara
Rua Voluntários da Pátria, 1309
14801-320, Araraquara, SP
[email protected]
Abstract. Nowadays, the brazilian historical holding, including those in São Carlos
and region, are sometimes unknown or unavailable. Therefore, a free Web system that
becomes possible the storage and dissemination of information about these holdings is
extremely relevant. Thus, it is necessary the identification of an attributes set based on
international norm and register format to represent the information about several types
of historical holdings. Consequently, in the next future, the system can propitiate the
implantation of a distributed and integrated database of the several historical holdings
and avail it to all community.
Resumo. Atualmente, os acervos históricos brasileiros, inclusive os da cidade de São
Carlos e região, encontram-se, muitas vezes, desconhecidos ou indisponı́veis; dessa
forma, um sistema Web livre que possibilite o armazenamento e disponibilização de
informações desses acervos é de extrema relevância. Para isso, é indispensável a
identificação de um conjunto de atributos baseado em normas e formatos de registro
internacionais que possam representar integralmente as informações sobre os diversos tipos de acervos históricos. Como conseqüência e sendo um software livre, o sistema poderá propiciar em um futuro próximo, a implantação de uma base de dados
distribuı́da e integrada dos diversos acervos históricos disponibilizada a toda a comunidade.
1. Introdução
O municı́pio de São Carlos e região apresenta uma diversidade de acervos de inestimável valor
histórico. Esses acervos contêm elementos de caráter diversificado de extrema relevância para o
resgate da história do municı́pio e inclusive relacionados à própria história do Brasil. Atualmente,
esses acervos, bem como grande parte dos acervos brasileiros, encontram-se, muitas vezes, em
estado precário de conservação e outros ainda, desconhecidos até mesmo por pesquisadores da
área. Verifica-se nos últimos dois anos diversos esforços isolados, tanto público quanto privado,
no sentido de organizar os acervos e disponibilizá-los aos interessados.
O projeto Memória Virtual de São Carlos [Mem, 2003] agrega as competências estabelecidas no meio acadêmico1 a serviço de uma iniciativa bastante relevante para a comunidade da
cidade de São Carlos e região. O projeto, de natureza multi-disciplinar e envolvendo a Prefeitura Municipal de São Carlos, a Fundação Pró-Memória de São Carlos, a Associação Pró-Casa
do Pinhal e outras instituições, pode contribuir de forma significativa para o registro histórico de
São Carlos, bem como para a ampliação do acesso a esse registro. Para isso, o principal objetivo
desse projeto é o desenvolvimento de um sistema Web que será disponibilizado como software
∗
É também professora e doutoranda do programa de pós-graduação do Instituto de Ciências Matemáticas e de
Computação - ICMC/USP.
1
Participam desse projeto pesquisadores do Instituto de Ciências Matemáticas e de Computação - ICMC/USP, do
Departamento de Arquitetura e Urbanismo - SAP/USP, do Departamento de Ciência da Informação - DCI/UFSCar, da
Biblioteca Comunitária - BCO/UFSCar e do Instituto de Biociências, Letras e Ciências Exatas - IBILCE/UNESP.
157
158
5° WSL / 5° FISL
livre2 para a gestão integrada de acervos do municı́pio; mais especificamente, para organização,
armazenamento e disponibilização de informações do patrimônio histórico e cultural, possibilitando a reunião dos diversos acervos dispersos fisicamente, seguindo normas nacionais e internacionais de definição de conjunto de atributos para representação da informação. Esse sistema
possibilitará também promover a conscientização sobre a importância de preservar a grande diversidade de acervos históricos. Vale ressaltar que, assim como as inúmeras iniciativas de diversos
órgãos públicos em nı́vel nacional para uso de software livre, a Prefeitura Municipal de São Carlos
também está empenhada na adoção, utilização efetiva e disseminação de software livre; além de
estar apoiando fortemente para a concretização desse projeto.
O objetivo deste artigo é então divulgar o Projeto Memória Virtual de São Carlos, sua
relevância e principais contribuições, bem como seu relacionamento com o tema software livre.
Dessa forma, este artigo está organizado da seguinte forma: na Seção 2 será discutido o desenvolvimento do sistema Web, mais especificamente, as atividades no tocante ao levantamento de
requisitos, bem como a identificação de um ambiente de implementação do sistema. E por fim, na
Seção 3, encontram-se as conclusões.
2. Desenvolvimento do Sistema Web
2.1. Levantamento de Requisitos
Uma vez que o sistema Web proposto nesse projeto irá gerenciar uma diversidade e um grande
volume de informações, o seu planejamento passa a ter um papel estratégico para o acesso pleno
a essa informação. O objetivo do projeto tem então demandado pesquisas nas diversas áreas de
conhecimento envolvidas. Como um dos exemplos mais sobressalentes é a pesquisa em Ciência
da Informação que tem definido um conjunto de atributos tanto para representação, armazenamento e disponibilização de informações dos diversos tipos de acervos históricos, quanto como
ponto de acesso às informações. Os resultados dessa pesquisa, inédito em nı́vel internacional,
é de extrema relevância como pré-requisito fundamental para a implementação do sistema, mais
especificamente para o projeto da base de dados.
Vale ressaltar que a escolha de atributos corretos garante rapidez e precisão na recuperação
das informações da base de dados, e conseqüentemente, credibilidade ao sistema. Entende-se por
pontos de acesso todos os elementos que descrevem a informação e, concomitantemente, servem
como chave para a recuperação da informação e para o seu acesso na ı́ntegra. Os atributos, sendo
ou não pontos de acesso, são representações da informação dentro do sistema, e por isso, também
são conhecidos como metadados, ou seja, dados sobre um outro dado [Hillmannn, 2004]. Assim,
atributos como autoria e palavra-chave, por exemplo, que representam a informação original e/ou
o seu conteúdo e permitem a sua recuperação, são metadados dessa informação.
De modo geral, o sistema inclui os seguintes módulos ou conjuntos de informação a serem manipulados: acervos documentais, coleções bibliográficas, objetos museológicos, bens arquitetônico, bens naturais, além de materiais multimeios. Atualmente, está-se concentrado no
levantamento de requisitos, projeto e implementação dos três primeiros módulos. Definir um conjunto de atributos para esses conjuntos de informação não é uma tarefa trivial, uma vez que não
existe um conjunto já estabelecido que possa servir de base e que contemple as especificidades dos
vários conjuntos de informação que serão manipulados pelo sistema proposto. Pode-se identificar
conjuntos de atributos3 — também chamados de formatos de registro — internacionais, consolidados e amplamente divulgados e utilizados para conjuntos especı́ficos de informação. No contexto
desse projeto diversos formatos têm sido considerados, dentre eles o MARC (Machine Readable
Cataloguing) como formato de registro para informações bibliográficas, a EAD (Encoded Archival Description) para os arquivos, considerados no todo ou documento por documento, e o Dublin
Core para os recursos eletrônicos.
2
3
http://www.fsf.org/philosophy/free-sw.html
http://www.ifla.org/II/metadata.htm
5° WSL / 5° FISL
Além dos formatos de registro, pode-se identificar também normas internacionais que estabelecem padrões de como descrever a informação, ou seja, como os dados devem ser inseridos na
base de dados. Certamente, essas normas são também instrumentos essenciais para a definição do
conjunto de atributos, sendo o AACR-2 (Anglo-American Cataloguing Rules, 2nd. Edition)4 e o
ISAD(G) (General International Standard Archival Description)5 padrões que têm sido utilizados
no âmbito desse projeto. Portanto, a utilização de formatos de registro e de normas internacionais
para a descrição da informação devem ser complementares. Com isso, é possı́vel garantir a qualidade das informações armazenadas e disponibilizadas, bem como a possibilidade de integração
com outros sistemas de informação, tanto nacionais quanto internacionais.
Além disso, uma vez que sistemas como o almejado não são largamente conhecidos,
brainstorms têm sido realizados em reuniões entre os membros do projeto para a identificação
e definição de requisitos do sistema. Além disso, meios de comunicação eletrônicos, tais como
correio eletrônico e sistema de mensagem instantânea, também têm contribuı́do em muito para a
realização dessa atividade. Os requisitos identificados e considerados mais relevantes, são descritos textualmente — baseando-se nas práticas recomendadas pela IEEE para especificação de requisitos do software [IEEE Std 830, 1998] — sendo uma forma de registrar para posterior verificação,
bem como para facilitar a integração de novos desenvolvedores, em se tratando de um sistema que
possui uma grande quantidade de funcionalidades não comumente conhecidas pela maioria dos
potenciais desenvolvedores.
2.2. Projeto e Implementação do Sistema
Para a construção do sistema, está sendo investigada a utilização de práticas do processo de desenvolvimento de software livre — tais como a forma como os requisitos são identificados e a
atribuição de tarefas aos desenvolvedores — como descrito inicialmente em “The Cathedral and
the Bazaar” por [Raymond, 1999] e na mesma linha de diversas pesquisas, sendo algumas delas do
ICMC/USP [Nakagawa, 2002, Reis, 2003]. Como abordagem para a implementação do sistema,
a prototipação está sendo empregada, como ocorre na grande maioria dos softwares livres sendo
desenvolvidos; ou seja, à medida que o sistema é implementado, novos requisitos são identificados
e já implementados e, no caso desse projeto, registrados também em um documento de requisitos.
Quanto ao projeto do sistema, técnicas para modelagem da funcionalidade do sistema não
estão sendo utilizadas; por outro lado, modelos da base de dados são construı́dos utilizando DER
(Diagrama de Entidade-Relacionamento), como resultado do conjunto de atributos identificado, e
também como uma forma de documentar o sistema, uma vez que se trata de uma base de dados de
razoável complexidade em termos do número de atributos, relacionamentos e tabelas. Questões
relacionadas à usabilidade do sistema em virtude da diversidade de usuários, bem como questões
no tocante à segurança e robustez tem sido consideradas em se tratando do volume de dados a
serem manipulados. Por exemplo, um dos módulos refere-se às coleções bibliográficas que irá
inicialmente gerenciar dados da Biblioteca da Fazenda Pinhal6 que possui aproximadamente 5000
obras desde livros, cartas, mapas, entre outros.
Sendo o software livre um dos requisitos do ambiente de implementação e implantação do
sistema, foi realizado um estudo e seleção das ferramentas/tecnologias a serem utilizadas. Adotouse uma plataforma de software livre, no caso o Linux7 e o Apache8 ; como SGBD (Sistema de
Gerenciamento de Banco de Dados) adotou-se o PostgreSQL9 e para a implementação das funcionalidades do sistema está utilizando-se o PHP10 , todos em consonância com a filosofia adotada
no projeto. Todas possuem uma vasta comunidade de usuário e uma experiência consagrada na
construção de uma diversidade de sistemas dos mais variados domı́nios de aplicação.
4
http://www.collectionscanada.ca/jsc/index.html
http://www.hmc.gov.uk/icacds/eng/home.htm
6
http://www.fazendapinhal.com.br
7
http://www.linux.org/
8
http://httpd.apache.org/
9
http://www.postgresql.org
10
http://www.php.net/
5
159
160
5° WSL / 5° FISL
3. Conclusão
Atualmente, a grande maioria dos acervos históricos brasileiros necessitam de tratamento adequado, bem como uma divulgação no sentido de conscientizar a comunidade de seu valor histórico.
Para isso, a tecnologia de computação possui mecanismos que quando utilizados adequadamente
possibilitam ser um veı́culo dos mais relevantes na realização dessa tarefa.
Vale ressaltar que por meio desse projeto, tem ocorrido a constante e enriquecedora troca
de experiências entre as diversas áreas de pesquisa envolvidas, o que vem salientar a relevância
da realização de projetos multi-disciplinares. No mais, esse projeto tem também contribuı́do no
sentido de identificar a problemática das áreas envolvidas e que necessita ser sanada resultando em
pesquisas de valioso teor e fundamental para a concretização dos objetivos propostos no projeto.
Como benefı́cio mais expressivo e imediato do projeto têm se a disponibilização de um
conjunto de atributos capaz de armazenar e disponibilizar de forma efetiva informações dos mais
diversos tipos de acervos históricos. Além disso, a implementação desse conjunto em um sistema
Web livre certamente irá contribuir, tanto para a comunidade de software livre com um sistema
ainda não encontrado nesse domı́nio de aplicação, quanto no sentido de facilitar a implantação
e posterior disponibilização de informações sobre os mais diversos acervos para a comunidade
em geral. Observa-se que um sistema como o proposto não é encontrado nem como software
livre, nem como software proprietário; aqueles identificados possuem funcionalidades ou bases de
dados limitadas, o que não está em consonância com os objetivos do projeto; isso vem reforçar a
relevância da disponibilização de sistema desse domı́nio de aplicação como software livre.
Partindo do sistema piloto a ser implantado inicialmente nos acervos pertencentes à rota do
café na qual São Carlos está inserido, pretende-se instalar um mecanismo para disseminação desse
sistema para diversas outras entidades similares — prefeituras, fazendas históricas, associações,
entre outras — a nı́vel regional, estadual e até nacional, construindo-se assim uma base de dados
distribuı́da, no entanto, integrada dos diversos acervos históricos brasileiros dispersos fisicamente.
Agradecimentos: Agradeço a todos os membros do Projeto Memória Virtual de São Carlos e em
especial ao Prof. Dr. José Carlos Maldonado e à Juliana de Souza Moraes pelo suporte na concepção deste
artigo.
Referências
(2003). Memória Virtual de São Carlos. Instituto de Ciências Matemáticas e de Computação - ICMC/USP,
São Carlos, SP. (Projeto aprovado no programa de polı́ticas públicas da FAPESP e coordenado pelo Prof.
Dr. José Carlos Maldonado).
Hillmannn, D. (2004). What is metadata?
[On-line], World Wide Web. Disponı́vel em http:
//dublincore.org/documents/2001/04/12/usageguide/#whatismetadata (Acessado em 30/04/2004).
IEEE Std 830 (1998). IEEE recommended practice for software requirements specifications.
Nakagawa, E. Y. (2002). Software Livre: Processo e Produto Livres no Desenvolvimento de Aplicações
Web. Exame geral de qualificação, Instituto de Ciências Matemáticas e de Computação – ICMC/USP,
São Carlos, SP. (Doutorado em andamento).
Raymond, E. S. (1999). The Cathedral and the Bazaar. O’Reilly & Associates.
Reis, C. R. (2003). Caracterização de um processo de software para projetos de software livre. Master’s
thesis, ICMC/USP, São Carlos - SP. Dissertação de Mestrado.
5° WSL / 5° FISL
WebMaterioteca – Sistema de Informação de Cadastro e Recuperação de Materiais
Juliano Varella de Carvalho, Eduardo Schweigert, Ingo Jost
Instituto de Ciência e Tecnologia – Centro Universitário FEEVALE
Campus II - RS 239, 2755 – Cep 93352-000 – Novo Hamburgo – RS – Brasil
{julianovc,sheykina,ingo}@feevale.br
Abstract. This paper describes the development of an information system in the web,
responsible for the maintenance of a database that store several materials used in
the manufacture of industrial products.
Resumo. Este artigo descreve o desenvolvimento de um sistema de informação na
web, responsável pela manutenção de um repositório de dados sobre diversos
materiais utilizados na fabricação de produtos industriais.
1. Introdução
O Centro Universitário Feevale aprovou em 2003, junto aos órgãos de fomento a pesquisa
FINEP (Financiadora de Estudos e Projetos) e CNPq (Conselho Nacional de Pesquisa
Científica e Tecnológica), um projeto para a construção de uma Materioteca, destinada,
inicialmente, a armazenar dados sobre materiais utilizados na cadeia coureiro-calçadista.
Estes órgãos permitiram a aquisição de equipamentos de informática e recursos
humanos para o desenvolvimento do projeto e, em contrapartida, um espaço físico situado no
Centro de Design da Feevale foi disponibilizado para permitir a implantação física da
materioteca, as atividades de pesquisa e a implementação de um sistema de informação.
É válido salientar que este projeto apresenta vasta interdisciplinaridade, pois conta com
professores e bolsistas dos cursos de Design, Engenharia Industrial Química, Engenharia de
Produção e Ciência da Computação.
2. Materioteca
O termo materioteca trata-se de um neologismo com significado similar a uma biblioteca,
exceto pelo fato de que, ao invés de armazenar livros em seu espaço físico, ela destina-se ao
armazenamento de materiais usados na fabricação de produtos industriais.
Para a total excelência da fabricação de um produto industrial devem ser seguidos
alguns parâmetros referentes aos materiais utilizados. Qualidade, produtividade, baixo custo,
ciclo de vida e impacto ambiental são algumas das principais características no
desenvolvimento industrial. Portanto, novas tecnologias para a produção de novos produtos são
constantemente procuradas e, quanto mais abrangentes forem às informações sobre os materiais
existentes, melhor será a escolha da matéria-prima na fabricação destes novos produtos [Silva
2002].
Portanto, a materioteca reunirá em seu espaço físico diversas amostras dos mais
variados materiais existentes no mercado, suprindo a carência de um espaço que possibilite um
contato táctil e visual com estas matérias-primas. Aliado a isto todos os materiais estarão
disponíveis a qualquer pessoa por meio de um sistema de informação que será ferramenta
essencial à pesquisa sobre o assunto, permitindo a estudantes, professores, empresários e
profissionais das áreas do design e da engenharia, acesso a informações cruciais sobre estes
materiais.
161
162
5° WSL / 5° FISL
3. Sistema de Informação
Um sistema de informação é um grupo de componentes inter-relacionados que trabalham
juntos, rumo a uma meta comum, recebendo insumos e produzindo resultados em um processo
organizado de transformação [O’Brien 2002]. Neste processo estão envolvidas três etapas:
• Entrada: responsável pela captação e reunião de elementos que entram no sistema
para serem processados;
• Processamento: processos de transformação que convertem as entradas em resultados;
• Saída: transferência de elementos produzidos até seu destino final.
Com o objetivo de armazenar os materiais, processar seus dados e levar informações
relevantes aos usuários finais, está sendo desenvolvido neste projeto um sistema de informação
para web, batizado inicialmente de WebMaterioteca, que, em breve, disponibilizará um
endereço eletrônico a comunidade, no qual, qualquer pessoa poderá executar consultas ao
sistema, bem como navegar através de dados gerais do projeto.
A WebMaterioteca, além de permitir um grande número de consultas, será a ferramenta
responsável pela entrada dos dados, ou seja, possibilitará a catalogação dos materiais; suas
propriedades químicas, físicas, mecânicas, térmicas e elétricas; suas características; seus
processos de fabricação; seu desempenho em diferentes meios (água, ácidos, bases, solventes,
etc); suas fórmulas química e estrutural, entre outros dados.
Como os materiais encontram-se sob as mais diversas formas, este sistema oportunizará
também o cadastro das amostras coletadas. As amostras são peças constituídas por um ou vários
materiais, como solas de sapato, cadarços, fivelas, etc. E, para cada amostra, serão armazenadas
diversas fotos em ângulos distintos, assim como dados referentes à empresa que a forneceu e a
descrição dos materiais que a constituem.
O sistema prevê também uma seção destinada à geração de relatórios, responsáveis por
municiar os usuários do sistema de uma visão consistente e prática de todo o conjunto de dados
armazenado.
A WebMaterioteca estará dividida em diversas seções. Dentre algumas existentes podese citar as seções de cadastros, as quais englobam os formulários de cadastro de materiais,
amostras, propriedades, classes de materiais, permissões de usuários, entre outras; as seções de
relatórios; as seções com dados gerais a respeito do projeto; e as seções pertinentes à
administração do sistema. Tais seções serão acessadas por quatro diferentes grupos de usuários
que estão descritos abaixo, bem como suas características de acesso:
• Grupo Geral: este grupo será povoado com usuários que terão permissão de
acesso aos dados institucionais sobre o projeto, como sua descrição, patrocinadores, equipe de
trabalho, envio de sugestões, glossário utilizado no projeto, entre outras seções. A este grupo
também será permitida a execução de consultas simples e avançadas no sistema. Este grupo é
constituído por qualquer visitante ao site que esteja buscando informações sobre materiais e
não será necessária qualquer espécie de autenticação.
• Grupo Materioteca: aos usuários deste grupo é reservado o direito de efetuar
a alimentação do banco de dados da WebMaterioteca, pois eles serão incumbidos das tarefas de
registro de novos cadastros, bem como alterações e exclusões de dados previamente salvos.
Todas as operações desta natureza serão registradas (registro de log) em uma tabela para
extração de futuros relatórios sobre quais usuários efetuaram as operações. Os bolsistas e
coordenadores do projeto farão parte deste grupo.
5° WSL / 5° FISL
• Grupo Coordenador: um novo cadastro, efetuado pelo grupo anterior,
sempre esperará por aprovação para que possa juntar-se aos cadastros já existentes. O grupo
coordenador tem a responsabilidade de analisar um relatório dos cadastros realizados,
aprovando-os ou rejeitando-os. Em caso de rejeição, um email será disparado para o grupo
Materioteca a fim de que algum dos seus integrantes efetue a alteração necessária para sua
aprovação.
• Grupo Administrador: as atividades deste grupo no sistema são aquelas
destinadas a criar novos usuários, novos grupos, novas seções, definir permissões dos grupos às
seções criadas, acessar os registros de log, dentre outras atividades administrativas.
4. A Tecnologia
Determinou-se, no início no projeto, que a WebMaterioteca se utilizaria quase que
exclusivamente de software livre em seu desenvolvimento. A exceção são alguns softwares de
manipulação de imagens utilizados pelos estudantes da área de Design. Esta escolha foi feita
pois, viabilizou o orçamento por causa da ausência de gastos com licenças de software, assim
como deverá ser um grande incentivador para que outros projetos na instituição venham a
utilizar este tipo de softwares.
O sistema de informação está sendo construído em três camadas, englobando as
camadas de interface, regras de negócio e armazenamento dos dados.
A camada de interface está sendo desenvolvida, inicialmente, pelos bolsistas e
coordenadores ligados à área do Design, pois são os responsáveis diretos pela identidade visual
do projeto e modelagem da interface do sistema. Em um momento posterior os estudantes da
ciência da computação interligarão a estrutura de interface criada com as páginas HTML, a fim
de permitir a navegação por todas as funcionalidades do sistema.
A camada referente às regras de negócio vem sendo implementada por meio da
linguagem Java (http://java.sun.com), a qual foi escolhida por contar com características
essenciais de uma boa linguagem de programação, tais como sua total orientação a objetos, a
sua robustez e portabilidade. E, para interligar as classes implementadas com a interface do
sistema, escolheu-se utilizar a linguagem de scripts JSP (Java Server Pages).
A fim de aumentar a produtividade na codificação das classes responsáveis pela lógica
do funcionamento do sistema, optou-se pela utilização de uma IDE (Integrated Development
Environment – Ambiente de Desenvolvimento Integrado) de fácil aprendizagem e que
englobasse diversas características que auxiliam a tarefa de programação. A ferramenta
escolhida foi o Eclipse 2.1 (http://www.eclipse.org). Esta ferramenta tem se mostrado
extremamente eficiente tanto no desenvolvimento e depuração das classes, quanto em
atividades extras que podem ser adicionadas através da inclusão de inúmeros plugins ao
ambiente do Eclipse. Desta forma, tem-se utilizado esta ferramenta para codificação também de
código escrito em JSP e Javascript, além de se prestar também à construção de Diagramas de
Use Case e Diagramas de Classes, desde que instalados os plugins adequados.
A fim de efetuar um armazenamento eficiente dos dados relativos à amostra, materiais e
demais conteúdos é necessário valer-se dos benefícios de um sistema gerenciador de banco de
dados (SGBD). O SGBD escolhido para armazenar os dados do projeto foi o PostgreSql
(http://www.postgresql.org), devido a diversas características que fazem dele um dos SGBD’s
relacionais mais utilizados atualmente (Momjiam 2004). Características como robustez,
velocidade de acesso e segurança, permitirão ao sistema de informação funcionar de modo
adequado. Além disso, este SGBD tem seu código fonte livre e não requer custo adicional ao
projeto, permitindo o uso de suas licenças livremente.
163
164
5° WSL / 5° FISL
A fim de evitar a cansativa tarefa de geração e atualização da base de dados da
materioteca, no SGBD, por meio da escrita de scripts em SQL, utilizou-se uma ferramenta para
o desenvolvimento da modelagem desta base. O software escolhido foi o DBDesigner
(http://www.fabforce.net/dbdesigner4/), o qual apresenta inúmeros recursos de manipulação do
projeto lógico da base de dados, presentes somente em ferramentas proprietárias que já sofreram
diversos aperfeiçoamentos.
Todas as camadas do sistema estarão armazenadas em um mesmo servidor Linux,
distribuição Red Hat 9, fisicamente localizado no Centro de Design da Feevale. Este servidor
contará com o Servidor Web Apache 2.0 (http://www.apache.org) a fim de administrar todas as
requisições realizadas ao site da materioteca e o container JSP TomCat 5.0.19
(http://jakarta.apache.org/), responsável pela compilação das páginas escritas em JSP.
A escolha pelo ambiente web é justificada, principalmente, pela possibilidade de um
usuário interagir com a WebMaterioteca, de qualquer lugar do mundo. Desta forma, também é
possível fazer com que o projeto seja conhecido e utilizado por uma gama muito maior de
usuários, os quais serão essenciais no envio de sugestões sobre melhorias a serem
implementadas no futuro. Além disso, há uma grande tendência dos sistemas de informação
atuais das empresas migrarem para o ambiente Web, sendo acessados então através de
navegadores (O’BRIEN, 2002). A Figura 1 mostra a arquitetura resumida do Sistema de
Informação WebMaterioteca.
Figura 1 – Arquitetura da WebMaterioteca.
5. Conclusão
Pretende-se que, ao término do projeto, com a implantação da WebMaterioteca, sejam
oferecidos mecanismos que permitam aperfeiçoar o desenvolvimento de produtos, inicialmente,
no setor calçadista, através da facilidade de pesquisa sobre materiais. Desta forma, procura-se
promover a melhoria da competência produtiva das micros, pequenas e médias empresas e
cooperativas do setor coureiro-calçadista.
O Sistema de Informação criado também terá fundamental importância na disseminação
da cultura do uso de software livre para o desenvolvimento de projetos acadêmicos, mostrando
a viabilidade de utilizá-los em todas as fases do projeto.
Cornell G., Horstmann C., Core Java – Guia Autorizado, Makron Books, 1997.
O’Brien, James A., Sistemas de Informação e as decisões gerenciais na era da Internet,
São Paulo, Saraiva, 2002.
Momjiam B, Entrevista, SQL Magazine, Rio de Janeiro, Edição 7, Ano 1, p. 46 – 48,
2004.
Silva, E. A., Implementação de uma "Biblioteca de Materiais" no estado do Rio Grande
do Sul, Revista Tecnologia e Tendências, Novo Hamburgo - RS: , v.1, p.65 - 71, 2002.
5° WSL / 5° FISL
Tecnologia Adaptativa e Sı́ntese de Voz: Primeiros
Experimentos
Felipe Augusto Zuffo1 , Hemerson Pistori1
1 CCET
- Universidade Católica Dom Bosco
Av. Tamandaré, 6000, Jd. Seminário
CEP: 79117-900 Campo Grande, MS
Abstract. This paper describes a working in progress that aims at proposing a new
methodology for voice-synthesis engineering, based on adaptive technology. The work
explores adaptive automata, a Turing-machine powerfull formalism that preserves most
of the simplicity of finite state transducers, that has already been used in voice-synthesis
for a long time. All the related implementation is being developed with the aid of a freesoftware, named AdapTools.
Resumo. Este artigo descreve um trabalho em fase de desenvolvimento cujo objetivo
final é propor uma nova metodologia para geração de sintetizadores de voz, baseandose em tecnologia adaptativa. Pretende-se explorar, nesse trabalho, os aut ômatos adaptativos, um formalismo que preserva a simplicidade dos tradicionais transdutores de
estados finitos, que já vêm sendo utilizados em sı́ntese de voz, mas que possui o mesmo
poder de expressão das máquinas de Turing. A implementação da metodologia será facilitada pela utilização de um software livre para desenvolvimento de aut ômatos adaptativos, o AdapTools.
1. Introdução
A sı́ntese de voz consiste na a geração de sinais sonoros que reproduzem as palavras equivalentes
em uma determinada linguagem natural. As aplicações que sintetizam a voz são projetadas para
imitar a fala, assim como ela é na natureza humana. O crescimento da utilização de sistemas computadorizados pelos mais diversos grupos de pessoas aumenta a necessidade de comunicaç ão ágil
entre máquinas e seres humanos. Com o aumento na capacidade de processamento e da disponibilidade de dispositivos para reprodução de som digital, a sı́ntese de voz tem se tornado viável em
uma grande variedade de aplicações, como por exemplo, aquelas voltadas para deficientes visuais, em que o monitor é substituı́do por caixas de som, e aplicações acessadas através de sistemas
telefônicos. (e.g. auto-atendimento, telemarketing, etc).
Uma grande quantidade de técnicas vêm sendo exploradas no intuito de otimizar a inteligibilidade da fala sintetizada [Goff and Benoı̂t, 1996, Burrows, 1996, Lemmetty, 1999a]. Para
isso, a adequação de fatores como ritmo e intonação são fundamentais para que a saı́da sonora soe
o mais natural possı́vel [Tatham and Lewis, 1996, Lemmetty, 1999a]. Os métodos de sı́ntese de
voz são classificados normalmente em três grupos: sı́ntese articulatória, sı́ntese fonética e sı́ntese
por concatenação [Lemmetty, 1999b].
Os métodos para sı́ntese articulatória baseiam-se em um modelo do aparelho vocal humano. Mantendo um conjunto de regras que simulam a lı́ngua, os lábios e as cordas vocais,
o sistema imita a voz humana ao produzir ressonância e articulação. Atualmente, esse tipo de
165
166
5° WSL / 5° FISL
sı́ntese é pouco utilizado, pois se mostra muito complexa e exige recursos computacionais de alto
custo.
As técnicas de sı́ntese fonética são estruturadas sobre um sistema de combinação de
freqüências que resulta em uma expressão vocal determinada. A entrada é processada por um
conjunto de ressonadores, onde cada um gera a saı́da equivalente a um som vocal. No final a saı́da
gerada por todos os ressonadores é somada, produzindo um fonema. A disposição dos ressonadores na estrutura de processamento pode variar a cada sintetizador de voz.
Já os métodos de sı́ntese por concatenação, trabalham com uma base de arquivos de som
previamente gravados, onde cada fonema é associado a um arquivo. Conforme os fonemas são
reconhecidos a partir uma cadeia de entrada, os arquivos são concatenados, de forma a produzir
a pronúncia. Com essa abordagem, torna-se mais fácil atingir naturalidade e inteligibilidade nos
resultados, porém utiliza-se mais espaço em memória do que nos demais métodos.
Um sistema tradutor texto-voz pode ser definido em dois elementos principais: um mecanismo de reconhecimento de texto e um de geração de som [O’Malley, 1990, Lemmetty, 1999a].
Os dois mecanismos se comunicam através de uma linguagem de representação intermediária,
que pode capturar a estrutura das sentenças em nı́veis morfológicos, léxicos, sintáticos, fonéticos,
sub-fonéticos, ou uma combinação de vários nı́veis. No presente trabalho, em fase de desenvolvimento, estuda-se as possibilidades da utilização de autômatos adaptativos, tanto na fase de
reconhecimento do texto, quanto de geração de som. Autômatos adaptativos generalizam o conceito de transdutores de estados finitos (e consequentemente, de aut ômatos de estados finitos),
incluindo caracterı́sticas que permitem o tratamento de dependências de contexto, o que os torna
um interessante formalismo a ser investigado na solução do problema da sı́ntese de voz. Um
software livre, o AdapTools 1 , está sendo utilizado nos experimentos com autômatos adaptativos.
Na próxima seção serão apresentados os autômatos adaptativos. Em seguida, descreveremos brevemente o software livre AdapTools. O estado atual do trabalho ser á relatado na seção 4,
seguida das conclusões e metas a serem atingidas posteriormente.
2. Autômatos Adaptativos
Um autômato adaptativo é um dispositivo guiado por regras adaptativo [Neto, 2001] em que a
camada subjacente consiste de um autômato de pilha estruturado [Neto, 1987]. Como qualquer
dispositivo adaptativo, um autômato adaptativo é capaz de alterar sua estrutura dinamicamente,
através de ações elementares que permitem que transições do autômato sejam consultadas, removidas ou inseridas. Essa capacidade de auto-modificação é que torna os autômatos adaptativos
mais poderosos que o mecanismo no qual eles se baseiam. Interessantemente, essa capacidade
de auto-modificação pode ser facilmente desabilitada, quando o poder extra de expressão não é
necessário na solução de um determinado problema.
3. AdapTools
O AdapTools é uma ferramenta livre que oferece um ambiente para experiências, implementação
e depuração de autômatos adaptativos [Pistori and Neto, 2003]. O núcleo desse software é uma
máquina virtual que executa autômatos adaptativos representados em forma de tabela. Os
autômatos e as alterações por ele realizadas são visualizados utilizando-se do pacote livre para
tratamento de grafos, OpenJGraph. A figura 1 ilustra a animação gerada pelo AdapTools, de um
autômato adaptativo reconhecendo uma cadeia da linguagem não-regular e não-dependente-decontexto an bn cn .
1
http://www.ucdbnet.com.br/adaptools/
5° WSL / 5° FISL
Figura 1: Animação gerada pelo Adaptools para os quatro primeiro estágios de um
autômato adaptativo que reconhece an bn cn
4. Sı́ntese de Voz e Autômatos Adaptativos
Utilizando a ferramenta AdapTools, foi desenvolvido um primeiro prot ótipo de tradutor texto-voz,
para a lı́ngua portuguesa. A sı́ntese de voz implementada nesse protótipo utiliza um método baseado em concatenação de arquivos armazenados no formato wave. A entrada para a tradução textovoz é uma seqüência de caracteres, que são processados pelo autômato adaptativo, que reconhece
sequências fonéticas simples, e mapeia os fonemas reconhecidos em uma rotina semântica capaz
de carregar, se necessário, o arquivo wave correspondente ao som, e reproduzi-lo. Para o tratamento de arquivos de som, foram reutilizadas classes disponı́veis no pacote livre SoundP layer 2 ,
criado por Martin Stepp, e que torna a programação utilizando sons extremamente simples. Segue abaixo o trecho de código necessário para reproduzir um arquivo de som utilizando-se o
SoundP layer:
public SoundPlayer player = new SoundPlayer();
private Token say(String nomeFonema) {
player.playAndWait(diretorioBase+nomeFonema+".wav");
}
A figura 2 mostra algumas das transições do autômato adaptativo que traduz texto em voz.
Nas legendas da forma x/y, x indica o sı́mbolo de entrada, e y, o de saı́da (fonema). As transições
(4, a, 5) e (3, a, 5), por exemplo, produzirão ambas o mesmo som (aquele do único fonema da
palavra chá).
Uma das dificuldades na tradução texto-voz é que uma mesma sı́laba, quando encontrada
em palavras ou sentenças diferentes, pode ter diferentes pron úncias. Por exemplo, a sı́laba xa,
nas palavras f ixa e Xuxa, corresponde a distintos fonemas. Este problema está intimamente
2
http://www.cs.arizona.edu/˜ stepp/java.html
167
168
5° WSL / 5° FISL
1
spc
a/ba
b
4
2
0
a/cha
h
c
5
a/ca
a/a
x
3
a/cha
Figura 2: Algumas transições do autômato de tradução texto-voz
ligado à dependência de contexto, o que sugere a utilização de autômatos adaptativos, no lugar de
transdutores de estados finitos, na produção de sistemas mais poderosos desta natureza.
5. Conclusão
Apresentamos neste trabalho os primeiros estudos sobre a possibilidade de implementaç ão de
tradutores texto-voz utilizando autômatos adaptativos. O fato de a estrutura de um autômato adaptativo poder ser alterada em tempo de execução possibilita a geração de diferentes pronúncias
para a mesma sı́laba, dependendo do contexto. Essa caracterı́stica se torna um incentivo para a
próxima etapa deste trabalho, o aprimoramento do prot ótipo apresentado, melhorando a pronúncia
de cada palavra. Também pretendemos começar a utilizar um alfabeto fonético internacional, para
a representação dos fonemas, e incorporar ao sistema métodos mais eficientes para concatenação
de fonemas na formação de palavras.
Referências
Burrows, T. (1996). Speech processing with linear and neural network models.
Goff, B. L. and Benoı̂t, C. (1996). A text-to-audiovisual-speech synthesizer for french. In Proc.
ICSLP ’96, volume 4, pages 2163–2166, Philadelphia, PA.
Lemmetty, S. (1999a). Review of speech synthesis technology. Master’s thesis, Helsinki University of Technology.
Lemmetty, S. (1999b). Review of Speech Synthesis Technology. PhD thesis, Helsinki University
of Technology - Department of Electrical and Communications Engineering.
Neto, J. J. (1987). Introdução à Compilação. LTC, Rio de Janeiro.
Neto, J. J. (2001). Adaptative rule-driven devices - general formulation anda case study. In
CIAA’2001 Sixth International Conference on Implementation and Application of Automata,
pages 234–250, Pretoria, South Africa.
O’Malley, M. H. (1990). Text-to-speech conversion technology. IEEE Computer, 23(8):17–23.
Pistori, H. and Neto, J. J. (2003). A free software for the development of adaptive automata.
In Proceedings of the IV Workshop on Free Software - WSL (IV International Forum on Free
Software).
Tatham, M. and Lewis, E. (1996). Improving text-to-speech synthesis. Proceedings of the Institute
of Acoustics, 18(9):35–42.
5° WSL / 5° FISL
Sessão Técnica 12
ELÉTRICA
169
170
5° WSL / 5° FISL
5° WSL / 5° FISL
!#$%
[email protected],[email protected],
& ')
¢£ ¢ £ $
%
$
¢£ $
¤
$ $
¤
¤
$
¢'
(
¥ $ $
¤
$
¢£ * $ ,
¤¤-£¤
£
%
£ . ¤$
% (
- ¤
¢£ ¤
¢£ £
/
%
$
(
¢£
1
2$
%
,
$$
*
3$11
4
$
5*
6 7
$ $
$(
8$19$4$3$
(:
%2¤$
¤
¤-*
$
¢'
¤*
$
,
6 7
%
$ ,5
;¥<=636>??@A$
¤¢
¤
*;5=B=A
$
¢£
8$
¢'
-C
¢£
/£/
6$¤C
$
¢'$¤
8$
£*
$¢'
$¤C
$8$$
(
%
¤C
(
$
-/
$
$¤
¤C
¤$ ( $
¢£ ¤
$DA$- 8$
$¢£$
$DA$$$
$
¤
¤C
171
172
5° WSL / 5° FISL
$
$
¤
%
%
%
$
$¢£$
$
¤
$(
¢£
5=B=
$
¢'
+ 7
4$¤C
$
¢£8$1$
$8$
9$4$3$
(:
%
1¤
;
$¢£,$A
6%2$
¤
$
¤*
$
,
%
7
1/,$F
9¤
$$1
> ¢£ ¢£ ¢' *
¤
@ 1¤@=
6 $ ¢£ ¢£ 21 $
$
¢£ 5
;¥<=636
>??@A,¤
$
¥D¥GG¤¢¤¤
$,$$
$
¢£$
(8$
¤
$$18$
1¤@=£
¥D¥GG $ $
(
1
$
$
%
,
¢£¥D¥GG
$2
62
1
;£
A
$
,$
£
$$
%¢£
*
$
+&
,
¤
$$1
$,$
1
1
$
¢£
%
1
-$
$,$8$
1
-$¢£$,$
$$1¤
¢£
£%
$
HI
9
%%
1¤
I@DH=4
62
1%
$2111
%
++
')
6
¢£21
$
$
5
$
$ $(
/ (
1$ 1 - *
¤$
$ $(
¤ £
£
%
5° WSL / 5° FISL
$
1
¥D¥GG8$$
$
$
¤-*8$( %
¤
¤
$
$(
$
¥/
¥$
¢£B¤¢
$(,
5
¥D¥GG
8$ $ $ 1
¥/
¥$
¢£ ¤
$
,¤$5=B=
8$
$
$
;5
A
!"#
$%&
+-..,-
6,$
1¤
$*$
£J?
%%
1¤
@= @= $
%%
1¤
$
9
;
A$
9$
6A
$
'
B/
*
¤
(
@=$
-¢£F
%
%%
$
- ' 1 /
¤
;K-A$-7CA.
> %%
$
$
/
21
¤
$
%$¢'$-
@ %%
%
6A%%
1¤
£$
%
¤C
8$
$
(
£
,
-$
/
6 ¤¢
¤
* ;5=B=A $
$
¢£
¢£
9
173
174
5° WSL / 5° FISL
L¤
¤
$
%
8$
¢' -C
¤
¤
*£$(
-
¢£
8$
¢'¤¢
%
=
¤
$¢'
$
£ *$ £ -
$ $ 4
1$
¢'
=$
1 $
$
65=B=¤
$(
N ;H3N44
OPPA8$$$(
¢£
$
8$
%
$
¢£
%2
01)
B
¤
£$£
%$¢'$DA$-- 2
¤
$
¢£,
9 8$ ¤
$DA$- $¢'8$8$
(
$
,¤
$
¢'¤
¤$£
23Q
AQ¥R4BB43K4<594A=¦¥GGK9 CI@T
QCNV
>??
¥<=636¥3
¦3$
¢£¥$
¥
4
T99
3
/
>??@D943
56A4N=43¥$
F
QCNVF
7W>4¢£OOP
<9559B <BRK< H=4 >DI % ¥
9A 9= V
>??
A6K=6Q H =
¥ < F 4
¥/
>???
B5A6X45=¤¤B=
¤W
W
QCNVFOO
N44H3¦Q$
$¤
%
W
$%
-C§
8$
T9444B
@?>@?¨
WOPP
©R6 ª <
X «
¤ 3 4¤¤ 3$
4-
B8$5=B=
W¤7
$
¥$«
9444B
C
BWBJ@JJ@O3OOP
5° WSL / 5° FISL
175
FCA: Uma Ferramenta Livre
para Análise de Circuitos Elétricos
1
1
2
1
Pablo Grigoletti *, Graçaliz Dimuro , Luciano Barboza , Renata Reiser , José U. de Nunes
1
2
2
Escola de Informática – Universidade Católica de Pelotas (UCPel)
Rua Félix da Cunha, 412 – 96010-000 – Pelotas – RS – Brazil
Escola de Arquitetura e Engenharia – Universidade Católica de Pelotas (UCPel)
Rua Félix da Cunha, 412 – 96010-000 – Pelotas – RS – Brazil
{pablogri,liz,lvb,reiser,junnunez}@ucpel.tche.br
Abstract. FCA is a tool for the electric circuit analysis. It was conceived as free
software, implemented using the Python programming language. The aim of this project
is to develop free tools for reliable electric circuit analysis to be used in both teaching
and research activities. This shall be obtained by means on interval techniques.
Resumo. FCA é uma ferramenta para a análise de circuitos elétricos que serve a
concepção de software livre e foi implementada utilizando-se a linguagem de
programação Python. O objetivo deste projeto é desenvolver ferramentas livres para
análise confiável de circuitos elétricos em atividades de ensino e pesquisa, o que deverá
ser obtido utilizando-se técnicas intervalares.
1. Introdução
Um dos grandes problemas enfrentados pelos alunos do curso de Engenharia Elétrica é o alto custo
de software utilizado para análise de circuitos elétricos. Existem poucos programas livres
(baseados na filosofia de software livre) e de qualidade voltados à área de análise de circuitos
elétricos. Pela mesma razão, as atividades de pesquisa que dependem destas ferramentas também
ficam prejudicadas.
O Free Circuit Analyser (FCA) foi projetado e desenvolvido com o intuito de preencher
esta lacuna, sendo este distribuído como software livre e licenciado através da GNU GPL.
Adicionalmente, a segunda versão da ferramenta pretende incorporar técnicas da Matemática
Intervalar para a modelagem de erros nos dados de entrada, controle dos erros oriundos da
computação numérica e análise automática dos erros dos resultados obtidos, garantindo assim
confiabilidade desses resultados.
Utilizou-se como base teórica para o desenvolvimento do FCA o método de análise de
circuitos elétricos denominado análise nodal [Hilburn, Johnson e Johnson, 1994; Irwin, 2000], e,
para a resolução de sistemas de equações lineares, a decomposição LUP [Cormen et al., 2002].
Esta ferramenta foi implementada utilizando-se a linguagem Python [Chun, 2001].
Atualmente, o FCA está sendo utilizado pelos alunos do 1º semestre de Engenharia
Elétrica da UCPel. Este projeto recebe apoio financeiro do programa CTINFO/CNPq e FAPERGS.
* Bolsista IC/CNPq.
176
5° WSL / 5° FISL
Este artigo está organizado como descrito a seguir. Na Seção 2, resume-se a análise nodal
de circuitos elétricos, que se adota neste trabalho. A ferramenta FCA é descrita na Seção 3. Um
exemplo de uma análise executada pela ferramenta é mostrado na Seção 4. A Seção 5 traz os
trabalhos em andamento e a Conclusão.
Informações complementares sobre o projeto e a ferramenta FCA estão disponíveis em:
http://atlas.ucpel.tche.br/~pablogri.
2. Análise de Circuitos Elétricos
Para se identificar os valores das tensões ou das correntes de um circuito elétrico são utilizadas as
técnicas de análise de circuitos, sendo as mais conhecidas a análise de malhas e a análise nodal,
ambas baseadas nas Leis de Kirchhoff [Hilburn, Johnson e Johnson, 1994; Irwin, 2000]. Estas
técnicas geram sistemas de equações lineares de ordem n, cuja solução estima os valores das
incógnitas do circuito.
Optou-se por utilizar a análise nodal por ser exigido menor esforço computacional para se
identificar os nós de um circuito (que já fazem parte da entrada de dados) do que suas malhas. Ela
baseia-se na lei de Kirchhoff das correntes, na qual as tensões nodais são as incógnitas a serem
determinadas [Hilburn, Johnson e Johnson, 1994; Irwin, 2000].
A análise nodal, em muitos casos, torna-se mais fácil quando aplicada a circuitos que
contenham fontes de tensão. A existência destas fontes acarreta o surgimento de supernós e de nós
aparentes, de acordo com a Figura 1.
Um supernó é aquele em que dois nós terminais à uma fonte de tensão estão conectados
em dois pontos quaisquer do circuito; e um nó aparente é um supernó com um de seus nós
terminais conectado à referência (ponto 0).
Figura 1. Circuito elétrico com supernó e nó aparente
Este método de análise de circuitos gera um sistema de equações lineares algébricas
(SELA) de ordem n. A resolução deste SELA resultará nas tensões nodais do circuito.
O objetivo da decomposição LUP é encontrar três matrizes L, U e P, com dimensão nxn,
de modo que PA=LU, onde L é uma matriz triangular inferior unitária, U é uma matriz triangular
superior e P é uma matriz de permutação (inicialmente uma matriz identidade).
Considerando um sistema do tipo Ax=b e multiplicando ambos os membros da equação
por uma matriz P, obtém-se PAx=Pb e se PA=LU, então LUx=Pb. Considerando Ux=y, obtém-se:
Ly=Pb (1)
Ux=y (2)
Na Eq. (1), tem-se um sistema triangular inferior e obtém-se a solução para o vetor y através
de uma substituição direta. Em posse do vetor y, resolve-se o sistema da Eq. (2). Este sistema é
triangular superior e dele obtém-se a solução para o vetor x através de uma substituição inversa.
Na prática, observa-se que com o pivotamento, a matriz A (matriz original) será alterada em
função das trocas de linhas, portanto o vetor b também deveria ser modificado para que a solução
5° WSL / 5° FISL
do sistema não se altere. É para resolver este problema que existe a matriz P, para poder realizar no
vetor b todas as trocas de linha que ocorreram na decomposição da matriz.
A decomposição LUP foi escolhida para a implementação da resolução de SELA´s por ser
um método numericamente estável e não possuir grande complexidade computacional [Cormen et
al., 2002].
3. Descrição do FCA
O Free Circuit Analyser é uma ferramenta computacional multiplataforma, desenvolvida
utilizando a linguagem de programação Python e baseada na filosofia de software livre.
A entrada de dados do FCA é realizada utilizando um arquivo texto contendo a definição
de um circuito elétrico. Cada linha do arquivo descreve um elemento do circuito no seguinte
formato:
elemento, numeração, nó1, nó2, valor
onde elemento pode ser R (resistor), I (fonte de corrente) e V (fonte de tensão); numeração é um
índice que identifica cada elemento; nó1 e nó2 são os terminais entre os quais o elemento está
conectado e valor é o valor numérico do elemento.
A saída de dados do FCA pode ser selecionada pelo usuário. Dentre as opções mais
relevantes estão: tensões nodais, corrente nos elementos e descrição em português do circuito
elétrico. Esta saída pode ser salva em um arquivo texto.
A interface gráfica foi desenvolvida utilizando-se a wxPython, um wrapper da biblioteca
wxWindows, que permite que as aplicações sejam portáveis e tenham a aparência de uma aplicação
nativa. A Figura 2 mostra a interface do FCA.
Para a utilização do FCA no sistema operacional MS Windows foi utilizado o módulo
py2exe objetivando não necessitar do interpretador Python instalado na máquina.
Figura 2. Interface do FCA (KDE)
4. Exemplo de Análise Realizada pelo FCA
Para ilustrar uma análise realizada pelo FCA, considere o circuito elétrico introduzido na primeira
coluna da Tabela 1. A segunda coluna desta tabela mostra a representação do respectivo circuito no
FCA. Os resultados obtidos com a análise nodal aplicada ao circuito, executada pela ferramenta,
são as tensões nodais e a corrente nos elementos, mostrados na Tabela 2.
177
178
5° WSL / 5° FISL
Tabela 1. Representação de um circuito elétrico
Circuito elétrico em sua representação gráfica
Representação no FCA
R
R
R
R
R
R
V
V
I
I
1
2
3
4
5
6
1
2
1
2
1
1
2
3
4
5
3
3
0
4
4
2
0
0
5
0
2
4
1
2
1
2
2
1
1
1
12
6
4
2
Tabela 2. Resultados obtidos pelo FCA
Tensões Nodais:
V0 = 0.0 V
V1 = 1.16666666667 V
V2 = -5.5 V
V3 = 6.5 V
V4 = 0.5 V
V5 = 0.25 V
Corrente nos Elementos:
IR1 = 0.666666666667 A
( 1 -> 4 )
IR2 = 3.33333333333 A
( 1 -> 2 )
IR3 = 2.75 A
( 0 -> 2 )
IR4 = 6.5 A
( 3 -> 0 )
IR5 = 0.25 A
( 4 -> 5 )
IR6 = 0.25 A
( 5 -> 0 )
II1 = 4.0 A
( 0 -> 1 )
II2 = 2.0 A
( 4 -> 2 )
IV1 = 8.08333333333 A
( 2 -> 3 )
IV2 = 1.58333333333 A
( 3 -> 4 )
5. Conclusão e Trabalhos em Andamento
Com a realização de vários testes comparativos com o software PSpice foi possível concluir que o
FCA gera resultados em menos tempo e com maior precisão.
A utilização do software pelos alunos do curso de Engenharia Elétrica possibilita concluir
que o software teve uma boa aceitação e é de fácil uso, servindo como alternativa aos softwares
comerciais utilizados na área de análise de circuitos elétricos.
Atualmente existem três linhas de trabalho relativas ao projeto FCA: (i) desenvolver uma
interface gráfica mais amigável para o software, semelhante as dos programas comerciais
utilizados na área de análise de circuitos elétricos; (ii) permitir a utilização de fontes controladas
[Hilburn, Johnson e Johnson, 1994; Irwin, 2000], pois atualmente o sistema só contempla fontes
independentes e resistores; e (iii) trabalhar com a possibilidade de tratar os valores dos elementos
como intervalos e aplicar as técnicas da Matemática Intervalar [Moore, 1966; 1979] no controle
automático dos erros de computação numérica.
Chun W. J. Core Python Programming. s.l: Prentice Hall PTR, 2001.
Cormen T. H. et al. Algoritmos: Teoria e Prática. 1.ed. Rio de Janeiro: Campus, 2002.
Hilburn J. L.; Johnson D. E.; Johnson J. R. Fundamentos de Análise de Circuitos Elétricos. 4.ed.
Rio de Janeiro: LTC, 1994.
Irwin J. D. Análise de Circuitos em Engenharia. 4.ed. São Paulo: Makron Books, 2000.
Moore, R. E. Interval Analysis. Englewood: Prentice-Hall, 1966.
Moore, R. E. Methods and Applications of Interval Analysis. Philadelphia: SIAM, 1979.
5° WSL / 5° FISL
Utilização do GNU/Linux e outros Softwares Livres na
Instrumentação Eletrônica e de Aquisição de Dados por
Computador
Daniel F. Gomes, Esdras Miranda, Luis Antonio P. Santos, João P. Brito Filho
Centro de tecnologia e geociências – Universidade federal de Pernambuco (UFPE)
Caixa Postal 7800 – 50.711-970 – Recife – PE – Brasil
{dafill,mirandaesdras}@ig.com.br, [email protected], [email protected]
Abstract. A problem frequently found when using the GNU/Linux in
laboratories is the difficulty to find hardwares and softwares of low cost for
data acquisition from computer. Aiming to popularize the GNU/Linux and
also to lower the cost with data acquisition instrumentation , we describe here
how to implement these acquisition systems in computers with free softwares.
It is explained in the present work not only how to implement acquisition
softwares, but as well as to implement low cost hardware for acquisition of
data for GNU/Linux.
Resumo. Um problema encontrado freqüentemente na utilização do
GNU/Linux em laboratórios é a pouca disponibilidade de hardwares e
softwares de baixo custo para aquisição de dados por computador. Visando
contribuir com a popularização do GNU/Linux e também baixar os custos
com instrumentação de aquisição de dados, descrevemos aqui como
implementar sistemas de aquisição em computadores com softwares livres.
Explicamos neste trabalho não somente como implementar softwares de
aquisição, mas também como implementar hardware de aquisição de baixo
custo para GNU/Linux.
1. Introdução
Este artigo destina-se a auxiliar a popularização do Linux em computadores de
laboratórios de pesquisa experimental, onde freqüentemente é necessário fazer medidas
por computador devido as grandes vantagens em relação as medidas manuais. Podemos
citar como algumas das vantagens das medidas por computador: precisão,
reprodutibilidade e facilidade de obtenção de grandes quantidades de dados em períodos
longos ou muito curtos.
Os principais dispositivos de entrada utilizados para os fins de aquisição de
dados por computador são, basicamente, as portas de comunicação padrão: RS232 ,
Centronics (paralela) e IEEE488 (GPIB). Os novos padrões como USB e FIREWARE
ainda não chegaram a se popularizar nesta área basicamente por serem bem mais novos
que os padrões anteriores e por terem implementações de hardware mais complexas.
Entretanto tudo indica que nos próximos anos o padrão USB deverá suplantar os
padrões mais antigos principalmente devido a uma nova geração de chips de interface
que estão sendo desenvolvidos pelos fabricantes de hardware e que devem simplificar
muito a implementação destes novos padrões.
179
180
5° WSL / 5° FISL
As linguagens de programação utilizadas para fazer os programas de aquisição
de dados variam muito entre linguagens proprietárias e padronizadas. Algumas das
linguagens proprietárias mais utilizadas são: LabView, HpVee, Assit, etc. Entre as
linguagens padronizadas a mais utilizada é a C, sendo o Basic também muito utilizado.
Atualmente os sistemas operacionais mais utilizados na área de aquisição de
dados são os de família Windows9x (95, 98, 98b2, etc), devido a possibilidade de
escrever programas que acessem as portas do sistema diretamente sem intermédio do
sistema operacional. Outro motivo é por serem sistemas considerados “leves”, podendo
rodar em computadores modestos destinados única e exclusivamente a aquisição de
dados. Sistemas como o WinXp, WinNT, Linux funcionam em modo protegido e
normalmente não permitem o acesso direto dos usuários as portas de comunicação do
computador. Entretanto existem desvantagens óbvias em se utilizar os sistemas
operacionais da familia windows9x, como por exemplo: instabilidade notória do
sistema, falta de suporte por parte do fabricante, não mais comercialização deste, etc ...
Usar os sistemas da série Windows mais novos como o WinXP e o Win2K, além
de representar um custo com aquisição de licenças, ainda implicam em descarte total de
computadores mais antigos e em dificuldades com a programação deste. Como o acesso
aos dispositivo de entrada e saída do computador deve ser feito via rotinas do sistema
operacional, quase sempre é necessário a obtenção de alguma “biblioteca” ou objeto (de
código fechados e/ou comerciais) de programa para facilitar o serviço de programação.
Este último fato gera dois implicantes graves:
Portabilidade comprometida. Os programas desenvolvidos, por exemplo, para
WinXP, muito provavelmente não serão facilmente portáveis para outros
computadores/sistemas operacionais se não existir um porte das bibliotecas e objetos
para o novo computador/sistema desejado.
Falta de controle e desconhecimento das rotinas internas das bibliotecas e/ou objetos.
As rotinas e algoritmos usados nessas bibliotecas/objetos podem não ser as mais
adequadas para o tipo de aquisição que o pesquisador pretenda fazer ou mesmo
podem conter falhas que possam comprometer a confiabilidade e a estabilidade dos
programas que as utilizem.
Uma alternativa é a compra de um software profissional para aquisição de dados que
incorpore soluções “pré-moldadas” que simplifiquem bastante o serviço de
programação de dispositivos de entrada e saída, exemplo: LabView. Entretanto esta
solução implicaria em custo do software que pode ter um valor bem elevado (No caso
do LabView apartir de R$1500 para uma configuração básica) além do custo com o
sistema o operacional e de um computador moderno/novo. Ainda assim a questão da
portabilidade e continuidade da sua solução fica a depender do fabricante do software
que foi utilizado.
Ao se utilizar sistemas tipo GNU/Linux como base para uma plataforma de
aquisição de dados e softwares livres como ferramentas tem-se pelo menos três grandes
vantagens:
O sistema pode ser facilmente adaptado para funcionar em computadores de
pequeno, médio e grande porte, além de poder ser adaptado para funcionar em
sistemas embarcados com hardware especializados (ex: terminais de coleta de dados,
handhelds, palms etc).
5° WSL / 5° FISL
GNU/Linux oferece confiabilidade e robustez bem superiores as do Windows da
familia 9x e sem as necessidades de hardwares dos windows XP e 2K.
Padrões e linguagens abertas asseguram a continuidade e portabilidade do programa
desenvolvido/utilizado pelo pesquisador.
2. Como fazer aquisição de dados com GNU/Linux
O acesso aos dispositivos de entrada e saída em um sistema GNU/Linux pode ser feito
diretamente em alguns casos (como o da porta paralela). Entretanto, por se tratar de um
sistema multitarefa e multiusuário a melhor maneira é através das chamadas do sistema.
No caso no Linux tal tarefa não implica em conhecimentos extra de subrotinas e
chamadas do sistema operacional como é o caso, por exemplo, do WinXP. Como o
Linux é um sistema tipo UN*X ele possui em seu sistema de arquivo pastas especiais,
pastas de dispositivos, que representam hardware do sistema. Assim a comunicação
com um dispositivo de E/S do sistema em muitas vezes pode ser uma operação tão
simples quanto escrever ou ler dados num arquivo. E efetivamente muitos dos
comandos de linguagens de programação como, por exemplo, C são os mesmos para as
duas operações, leitura/escrita em arquivos e em dispositivo. Em alguns casos, como os
dispositivos seriais, os programas para a comunicação com eles não precisam nem
mesmo serem escritos. Podendo se aproveitar programas já fornecidos com o sistema,
tais como os aplicativos de comunicação dd e minicom.
3. Resultados
O sistema de aquisição de dados aqui descrito foi desenvolvido como parte do trabalho
de intrumentção da disciplina de Instrumentação Eletrônica do Curso de Eletrônica da
UFPE.
O sistema consiste num módulo de conversão analógico-digital de uso geral
com uma saída de dados padrão RS232, a qual é conectada no computador e um
software de aquisição de dados feito em linguagem C com o auxílio das bibliotecas
gráficas GTK de código aberto. Tanto o projeto do software e do hardware servirão de
elementos-base para a construção de aplicativos específicos para as diversas
necessidades de medidas dos laboratórios modernos. O software de aquisição foi feito
através da IDE livre Anjuta.
Figura 1. Imagem da tela do software de aquisição de dados desenvolvido
O hardware foi desenvolvido para ser o mais simples possível. Ele utiliza
componentes de fácil obtenção no mercado e de baixo custo, proporcionando uma
alternativa viável e simples mesmo para quem não tem muitos conhecimentos na área
de eletrônica. Este sistema funciona com uma taxa de amostragem de dados de 72Hz,
uma taxa de transmissão de dados de 9600bps e uma resolução de 8bit de conversão
A/D.
181
182
5° WSL / 5° FISL
Figura 2. Datasheet do hardware de aquisição de dados desenvolvido para ser usado
com GNU/Linux. (Para visualização completa, usar o Zoom para ampliar a imagem)
Entretanto a taxa de amostragem pode ser facimente elevada para até 10kHz, mudando
apenas as freqüências de clock do circuito e subistituindo os acopladores ópticos 4n25
por outros de maior velocidade. No circuito o valor amostrado é um nível de tensão de 0
a 5v. O transdutor e o sistema de acondicionamento de sinal não foram incluídos no
circuito da figura 2 pelo fato destas duas etapas estarem fortemente ligadas ao tipo de
sinal e a grandeza física que se deseja medir.
4. Considerações finais
O custo total do sistema fica distribuído entre a instalação do GNU/Linux, adaptação do
programa base às necessidades do laboratório, compra dos componentes do circuito
(~R$20,00) e a confecção da placa de circuito(~R$20,00). Este sistema pode ser
utilizado para fazer medidas de baixa freqüência até 20Hz. Aplicações possívies são
medidas de temperatura, pressão, dilatação, luminosidade, peso, entre outras. Um
trabalho futuro seria redesenhar o hardware para funcionar com o padrão USB.
5. Referências bibliográficas
Thomas, R. e Yates, J. ,“Unix Total”, McGraw-Hill Ltda, São Paulo, 1989.
Schildt, H. ,“C completo e total”, MAKRON Books do Brasil Ltda, São Paulo, 1990
Welsh, M. e Kaufman, L. ,“Dominando o Linux”, Editora Ciência Moderna Ltda, Rio
de Janeiro, 1997.
Rubini, A. ,“Linux device drivers”, Market Books, São Paulo,1999.
Ercegovac, M. , Lang, T. e Moreno, J. ,“Introdução aos sistemas digitais”, Bookman,
Porto Alegre, 2000.
5° WSL / 5° FISL
Sessão Técnica 13
BIOLÓGICAS & BD
183
184
5° WSL / 5° FISL
5° WSL / 5° FISL
185
Um Sistema Baseado em Software Livre para Anotaç ão
Automática de Genomas e Proteı́nas
Ana L. C. Bazzan , Bruno S. Fajardo, Leonardo V. Nascimento, C ássia T. dos Santos, Vitório F. Sassi
Instituto de Informática – Universidade Federal do Rio Grande do Sul
bazzan,bsfajardo,lvnascimento,ctsantos,vfcsassi @inf.ufrgs.br
Abstract. The present article aims at reporting the experience achieved with the development of the ATUCG tool. The goal of this tool is to provide an annotation tool for
the expert in genomics and proteomics. Such tool is open and based on free software.
Resumo. Este artigo visa reportar a experiência obtida com o desenvolvimento da ferramenta para anotaç ão de genoma ATUCG. O objetivo deste ambiente é disponibilizar
ao especialista em genômica e proteômica uma ferramenta para anotaç ão que seja
aberta e baseada em software livre.
1. Introdução
A Bioinformática tem o propósito de ligar duas ciências que vêm crescendo de forma exponencial
nos últimos 20 anos: a Biologia e a Ciência da Computação. O estudo dos genes e proteı́nas provê
informações sobre o crescimento celular, comunicação e sua organização. O projeto genoma humano foi o principal responsável pela identificação da necessidade de ferramentas computacionais
para auxiliar os pesquisadores na análise do material decodificado. É importante salientar que o
pares de bases, mas apenas uma pequena parcela desses
genoma humano é formado de
dados são os responsáveis pela codificação das caracterı́sticas humanas.
No Brasil existem várias redes de seqüenciamento e análise de genoma trabalhando com
vários organismos (a maioria patogênicos). Quase todos estes projetos têm uma caracterı́stica fortemente multidisciplinar, incluindo especialistas das áreas de biotecnologia e informática. Este
casamento não ocorre por acaso: dado o volume de dados produzidos por cada projeto genoma,
torna-se absolutamente necessário gerenciar estes dados e, principalmente, automatizar processos de forma a libertar o especialista de tarefas repetitivas. Em geral, cada rede desenvolve suas
próprias ferramentas de integração e anotação, procedimento que poderia ser otimizado se houvesse troca destas entre as redes.
Dentre as principais tarefas associadas a estes projetos, podem ser citadas a descoberta e a
anotação das caracterı́sticas de cada gene. Anotação é a tarefa de descrever várias particularidades
de um genoma ou parte de um genoma ou ainda de seqüências de bases (DNA) ou amino-ácidos
(proteı́nas) e depositar estas informações posteriormente em um banco de dados para que sejam
utilizadas no futuro para consultas. Esta tarefa usualmente era feita de forma manual e com velocidade lenta. Entretanto, a corrida para seqüenciamento e compreensão de um genoma tem levado
os pesquisadores ao que se denomina seqüenciamento de alta vazão ou seja, um seqüenciamento
de um genoma inteiro realizado de forma rápida o que envolve mecanização de algumas tarefas
(tendência atual).
Projeto parcialmente apoiado pelo CNPq e pela FAPERGS
Autores parcialmente apoiados pelo CNPq
186
5° WSL / 5° FISL
Além do conhecimento necessário (o qual é indispensável), o especialista usa uma série
de ferramentas computacionais e programas especı́ficos. Grande parte destes processos pode ser
automatizado. Logo, o objetivo principal deste projeto é a implementação de um ambiente para
anotação automática, acessı́vel através da Internet, que disponibilize o acesso público as suas funcionalidades e código-fonte. Este ambiente é denominado ATUCG – Ambiente para anoTação
aUtomátiCa de Genomas. Como testbed estão sendo utilizados dados públicos relativos ao genoma de bactérias relacionadas com o organismo M. hyopneumoniae que é o organismo-alvo do
projeto PIGS/GENESUL [Zaha, 2001] (apoiado pela Rede Sul de Genoma que conta com financiamento da Fapergs e do CNPq).
A ferramenta proposta possibilita que pesquisadores e especialistas não precisem alocar
horas em trabalhos repetitivos e tediosos que exigem constante busca em bases de dados, pois tais
atividades podem ser feitas, ao menos parcialmente, de forma automática. Para isso, um sistema
multiagente é especialmente indicado pois permite uma modularidade ou distribuição das atividades de forma natural, baseada na função da atividade. Diversos agentes se encarregam de realizar
as tarefas repetitivas especificadas pelo especialista. Esta ferramenta tem ainda a vantagem de
reunir em um único ambiente as funcionalidades requeridas na tarefa de anotação de um genoma,
evitando que o usuário tenha que se adaptar às inúmeras interfaces e modus operandi das diversas
ferramentas hoje disponı́veis de forma isolada para auxı́lio da anotação.
Este artigo está organizado como segue. Na seção 2, a motivação para o desenvolvimento
do ambiente proposto e os trabalhos relacionados são comentados. A seção 3 apresenta a arquitetura do ambiente ATUCG. Por fim, na seção 4, as consideraç ões finais e as propostas para trabalhos
futuros são comentadas.
2. Motivação e Trabalhos Relacionados
Existem artigos publicados sobre o uso de métodos para auxı́lio nas diversas tarefas ligadas a um
projeto genoma. Entretanto, muitos destes trabalhos reportam ferramentas para áreas e usos isolados, como por exemplo para predição de estruturas de proteı́nas. Desta forma, tais ferramentas
em geral não atingem seu pleno potencial devido ao fato de que se especializam em determinados nichos de aplicação. Com o crescente volume de dados sendo posto a disposição, todos os
dias novas relações de homologia são detectadas, tornando necessário que o técnico da área de
biotecnologia conheça todos os métodos para decidir pelo seu uso.
Existe portanto, em projetos genoma, no momento, uma grande carência de ferramentas
computacionais integradas que lidem com as várias fases do projeto: desde a descoberta das ORFs
(open reading frames ou regiões potencialmente codificantes) até a predição da funcionalidade de
determinado gene. A idéia de se basear as várias atividades em sistemas multiagente e distribuir as
tarefas entre agentes não é nova (embora recente). No projeto GeneWeaver [Bryson et al., 2000],
um sistema multiagente está sendo desenvolvido onde os agentes concentram-se nas tarefas de
mais alto nı́vel como análise dos dados. Entretanto, os agentes não lidam com a parte mais repetitiva que é justamente a busca de informações. Em [Decker et al., 2001], é descrito um protótipo
que objetiva a anotação automática de um vı́rus com base em busca de informações em bancos de
dados públicos.
Outros trabalhos relacionados com a nossa proposta referem-se ao emprego de técnicas
de aprendizado de máquina (machine learning) e descoberta de conhecimento em bancos de dados. Técnicas de aprendizado têm sido usadas largamente em bioinformática. Uma proposta de
combinação de aprendizado e anotação automática é feita em [Kretschmann et al., 2001], que usa
um algoritmo de aprendizado de máquina (o C4.5) para gerar regras para realizar a anotação automática de um dos campos do banco de dados SWISS-PROT.
5° WSL / 5° FISL
187
No entanto, estes ambientes de modo geral não adotam a filosofia de software livre, embora estejam disponı́veis via Internet para uso. Neste trabalho é proposta uma plataforma integrada, baseada em software livre e acesso público, para a anotação e seqüenciamento de genomas
e proteı́nas. A motivação à adoção de software livre para o desenvolvimento deste ambiente está
baseada nas seguintes premissas: gratuidade de licenciamento; bom nı́vel de qualidade em relação
aos softwares proprietários, devido ao número de revisões do código-fonte; estabilidade, robustez e escalabilidade oferecidas pelos softwares básicos (UNIX/LINUX); sofwares necessários às
atividades propostas para o ambiente estão disponı́veis em versões estáveis de softwares livres; e
vasta documentação das funcionalidades dos softwares e de seus códigos-fonte.
3. Arquitetura Baseada em Software Livre
A arquitetura do ATUCG , ilustrada na Figura 1, é formada por diferentes camadas. Detalhes podem ser obtidos em [Bazzan et al., 2003]. A camada I é responsável pela tarefa de encontrar ORFs,
a partir da seqüência de DNA de um determinado organismo, informada pelo usuário. Nesta camada, é feita a análise da sequência informada, gerando uma lista de ORFs não redundantes,
repassadas à camada II. Na camada II, núcleo da abordagem, são realizadas as seguintes atividades: coleta de dados na base de dados SWISS-PROT; criação das consultas especı́ficas; criação de
formatos de saı́da adequados; geração de dados para os algoritmos de aprendizado de máquina;
avaliação da qualidade das regras geradas; preparo dos dados a serem anotados; aplicação das
regras; e anotação automática das palavras-chave. A saı́da desta camada é um modelo de anotação
automático dos campos do banco de dados SWISS-PROT. Finalmente, a camada III objetiva auxiliar o usuário na verificação da corretude do modelo de anotação proposto. Para isto, as regras de
anotação obtidas são convertidas para uma linguagem semântica e apresentadas de forma legı́vel
ao usuário, que pode indicar quais regras foram aplicadas corretamente e quais não deveriam ter
sido consideradas.
DNA
SEQUENCING ACTIVITIES
BLAST
I
SWISS
GENERATION OF RULES
FOR AUTOMATED
ANNOTATION
II
MOTIFS
VALIDATION BY USER
AND ANNOTATION
III
TrEMBL
FINAL
Figura 1: Arquitetura geral do ATUCG
Atualmente, as camadas I e II estão parcialmente implementadas. No futuro, devem ser
incorporados os serviços previstos para a camada III, que consiste basicamente da validação pelo
especialista. Conforme comentado anteriormente, o sistema atual está completamente implementado adotando-se software livre. Assim que optou-se pelo uso deste tipo de software, foi realizado
um estudo dos softwares que possuem compatibilidade, a partir do qual foram selecionados os
seguintes softwares/linguagens: Apache, PostgreSQL, PHP e Perl.
O gerenciamento de anotação de seqüências de um organismo é feito através de uma
interface web desenvolvida na linguagem PHP, a qual é suportada por um servidor Apache. Os
dados obtidos durante o processo de anotação são armazenados em um banco de dados relacional
PostgreSQL. Além disso, a linguagem Perl, que oferece ampla facilidade para manipulação de
188
5° WSL / 5° FISL
seqüências de strings (os bancos de dados biológicos armazenam dados neste formato), é utilizada
na implementação de scripts que geram os arquivos de entrada para as ferramentas de aprendizado
de máquina (C4.5, CN2, T2) e que formatam as regras de anotação. O Perl também é usado na
implementação de uma ferramenta de acesso ao banco de dados SWISS-PROT.
Atualmente, o acesso ao sistema restringe-se à rede interna do Instituto de Informática da
UFRGS, em função das normas de acesso do Instituto. Futuramente, pretende-se prover o acesso
livre ao sistema via Internet, para a comunidade genômica e proteômica do Brasil e Exterior,
disponibilizando versões do sistema em Português e Inglês. Além disso, objetiva-se disponibilizar
o acesso ao código-fonte do sistema, sob licença GPL.
4. Conclusão e Trabalhos Futuros
Neste artigo foi reportada a experiência obtida com o desenvolvimento da ferramenta para
anotação de genoma ATUCG, a qual está baseada em software livre e acesso público. O ambiente foi projetado visando disponibilizar aos pesquisadores de genômica e proteômica ferramentas
computacionais integradas para suporte às tarefas de anotação e seqüenciamento de proteı́nas e
genomas. Este ambiente estará disponı́vel publicamente para uso através da Internet, bem como
para download, sob os termos GPL. Grande parte dos ambientes que suportam (e integram) as
atividades relacionadas ao seqüenciamento e anotação, ainda que raros, não estão amplamente
disponı́veis. Por outro lado, os ambientes desenvolvidos com software livre ainda não provêm
estas atividades de forma integrada. O ambiente ATUCG endereça estes dois aspectos, propondo
a integração entre ferramentas para seqüenciamento e anotação, baseada em uma plataforma de
software livre e uso público através da Internet.
A próxima atividade refere-se a integração da tecnologia de agentes ao ambiente, onde
as tarefas de cada camada serão distribuı́das entre diversos agentes, atuando de forma cooperativa
(parte destes agentes já encontram-se implementados). Para isto, serão utilizadas ferramentas tais
como Apache Tomcat, distribuı́do sob licença ASF, pacote Java, disponibilizado gratuitamente
pela Sun, e plataforma JADE (Java Agent DEvelopment Framework) para suporte a comunicação
entre agentes, distribuı́da sob a licença LGPL. Além disso, devem ser incorporados os serviços
propostos para a camada III, que consiste na validação com o especialista. De acordo com esta
validação, poderá ser feita a incorporação da anotação ao banco de dados mantido pelo projeto.
Referências
Bazzan, A. L. C., Duarte, R., Pitinga, A. N., F., S. L., Silva, S. C., and Souto, F. A. (2003).
ATUCG–an agent-based environment for automatic annotation of genomes. International Journal of Cooperative Information Systems, 12(2):241–273.
Bryson, K., Luck, M., Joy, M., and Jones, D. (2000). Applying agents to bioinformatics in GeneWeaver. In Proc. of the Fourth Int. Workshop on Collaborative Information Agents, Lect.
Notes in Computer Science. Springer-Verlag.
Decker, K., Zheng, X., and Schmidt, C. (2001). A multi-agent system for automated genomic
annotation. In Proc. of the Int. Conf. Autonomous Agents, Montreal. ACM Press.
Kretschmann, E., Fleischmann, W., and Apweiler, R. (2001). Automatic rule generation for protein annotation with the C4.5 data mining algorithm applied on SWISS-PROT. Bioinformatics,
17:920–926.
Zaha, A. (2001). Projeto rede sul de análise de genomas e biologia estrutural. In Portuguese.
5° WSL / 5° FISL
Ferramenta de Telemedicina em Software Livre para
Monitoração de Sinais Vitais
Heloísa Melo Hertzog, Jorge Guedes Silveira
Grupo de Pesquisas Avançadas em Redes de Comunicação e Tecnologia da Informação
Programa de Pós-Graduação em Engenharia Elétrica
Pontifícia Universidade Católica do Rio Grande do Sul
Av. Ipiranga, 6681 - Partenon – 90619-900 – Porto Alegre – RS – Brasil
{hmelo,jguedes}@gparc.org
Abstract. Telemedicina is a used term to specify which resources of
telecommunications and information technology are used for the transmission,
control and the remote monitoring of biomedical data. The main objective of this
article is to present the applied research system that consisted on the software
implementation of a Telemedicine Tool that integrates different biomedical
applications focused on monitoring and controling the patient vital signals from an
Hospital – UTI or from a residential room.
Resumo. Telemedicina é o termo utilizado para especificar que recursos de
telecomunicações e de tecnologia da informação são utilizados para a transmissão,
controle e monitoração remota de dados biomédicos. O objetivo principal deste
artigo é apresentar a pesquisa aplicada na implementação em software de uma
Ferramenta de Telemedicina que integra diferentes aplicações biomédicas
destinadas à monitoração e controle dos sinais vitais dos pacientes a partir da UTI
de um hospital ou da sua residência.
1. Introdução
Segundo a Organização Mundial de Saúde (World Health Organization), Telemedicina é a
oferta de teleserviços ligados aos cuidados com a saúde nos casos em que a distância é um fator
crítico. Tais serviços são providos por profissionais da área da saúde, usando sistemas de
telecomunicações e de tecnologias da informação, sobretudo as redes de computadores e
sistemas de comunicação sem fio, para o intercâmbio de informações válidas tanto para
diagnósticos e prevenção quanto para o tratamento de doenças. [1]
Mais amplamente, a Telemedicina combina as tecnologias de engenharia, informática,
telecomunicação e medicina, provendo condições para o envio e o recebimento de informações
(dados, áudio, imagens, controle e biometria), viabilizando ações médicas em que os
profissionais e os pacientes não estejam fisicamente no mesmo local, permitindo a presença
real do médico através de um atendimento virtual às comunidades remotas e/ou carentes
desprovidas de profissionais especializados, tudo no interesse de melhorar a qualidade dos
serviços prestados às pessoas e suas comunidades.
Entre os principais objetivos da Telemedicina que a ferramenta desenvolvida suporta,
podemos citar:
- Monitoração de pacientes à distancia, tanto do ambiente domiciliar quanto do
ambiente hospitalar, permitindo a visualização dos sinais vitais e o recebimento de alarmes em
casos de emergência;
189
190
5° WSL / 5° FISL
- Acompanhamento remoto de pacientes, auxiliando no atendimento em localidades
afastadas e/ou carentes, postos de saúde, hospitais de pequeno porte e em ambulâncias
utilizadas para a realização de campanhas preventivas ou atendimentos de urgência, ao permitir
que determinados casos sejam avaliados a distância por médicos especialistas naquela área;
- Armazenamento eletrônico das informações do paciente, possibilitando aos médicos
acessá-las em qualquer horário e local;
- Vídeo-monitoração do paciente;
- Realização de uma comunicação entre médicos, enfermeiros e pacientes.
No contexto deste trabalho, a Ferramenta de Telemedicina foi desenvolvida de modo a
viabilizar a transmissão remota de dados biomédicos, de imagens, de áudio e de sinais de
controles para profissionais localizados à distância ou em centrais locais de monitoração.
2. Objetivos
O projeto “Ferramenta de Telemedicina em Software Livre para Monitoração de Sinais Vitais”
visa oferecer à comunidade de saúde pública, aos hospitais, às clínicas e médicos soluções que
possam ser utilizadas como fator de qualificação no atendimento dos pacientes através da
monitoração e acompanhamento dos mesmos à distância, possibilitando o acesso às
informações do paciente a qualquer hora, em qualquer local.
A ferramenta foi desenvolvida sobre um sistema Linux-embedded, oferecendo à
comunidade de software livre soluções de código aberto que podem ser utilizadas no âmbito da
monitoração de pacientes à distância através das aplicações de:
- Monitoração dos sinais vitais
eletrocardiograma, oximetria) dos pacientes;
(temperatura, respiração, pressão
arterial,
- Análise dos sinais vitais e comparação com parâmetros pré-estabelecidos, gerando
alarmes para a central de monitoração em casos de emergência;
- Armazenamento dos sinais vitais monitorados;
- Armazenamento eletrônico das informações do prontuário do paciente, contendo:
- informações pessoais do paciente;
- anotações dos médicos;
- anotações dos enfermeiros;
- anotações dos plantonistas;
- Armazenamento dos resultados dos exames realizados juntamente com suas
respectivas imagens;
- Realização de uma comunicação entre os pacientes e médicos e também entre os
próprios profissionais através da tecnologia de voz sobre IP (Internet Protocol) desenvolvida
pelo grupo de pesquisa VoIP / GPARC&TI / PUCRS; [2] [3]
- Realização da vídeo-monitoração do paciente através monitoração de imagens
desenvolvido pelo grupo de pesquisa GMART / GPARC&TI / PUCRS; [4] [5]
- Software de controle e atuação remota sobre equipamentos e dispositivos como ar
condicionado, iluminação e sobre câmeras de vídeo, acionando controles de PAN, TILT e
Zoom (PTZ), possibilitando a visualização do ambiente e dos equipamentos.
5° WSL / 5° FISL
A escolha pela utilização de software de código aberto no lugar de códigos
proprietários deve-se ao seu baixo custo, alta confiabilidade e possibilidade de acesso à
inteligência embutida no produto. Esta escolha, seguramente, aumenta a possibilidade de
expansão da telemedicina, ao reduzir os custos, ao mesmo tempo em que fortalece o
movimento de um processo coletivo de criação e produção de tecnologia disponível em escala
global.
2. Arquitetura Funcional
A Ferramenta de Telemedicina integra múltiplos meios de comunicação e diferentes
tecnologias, com uma base de dados e interface gráfica única para o(s) usuário(s) do sistema.
Em outras palavras, a Ferramenta é destinada a aceitar inovações e demonstrar a integração de
várias formas de comunicação (mensagens de texto, voz e imagens), de tecnologias (Linux
embarcado, bluetooth, Internet, Ethernet, ADSL, SMS,...) e de coletas de dados (desde sensores
até câmeras de vídeo). Para permitir que inúmeras aplicações sejam implementadas sobre esta
ferramenta e que novos serviços possam ser constantemente agregados é importante projetar e
implementar uma arquitetura modular e flexível:
- Modular: baseada em módulos capazes de operarem integrados ou de forma
autônoma, como aplicações independentes;
- Flexível: capaz de evoluir e de suportar novos serviços.
Desta forma, novas funcionalidades podem, continuamente, serem agregadas sem
alterações de códigos, bastando para tanto a reconfiguração da Ferramenta no sentido de manter
a estrutura baseada nos módulos já existentes e nos novos módulos que serão agregados.
A Figura 1 apresenta a aplicação da ferramenta no ambiente hospitalar, possibilitando a
monitoração em paralelo de vários pacientes pela equipe de médicos, enfermeiros e
plantonistas e o acompanhamento remoto pelo médico responsável.
Figure 1. Cenário de Aplicação no ambiente hospitalar
A Ferramenta de Telemedicina é formada por:
1. Box: sistema hardware-software baseado em Linux embarcado a ser disponibilizado
em cada quarto, equipado com sensores, câmeras de vídeo, atuadores e microfones para
possibilitar a monitoração, comunicação e controle remoto de dispositivos. Os sensores são
individuais para cada paciente do quarto, assim como os microfones e vários quartos podem ser
monitorados ao mesmo tempo;
2. Central de Monitoração - aplicação servidora principal, responsável pela
centralização dos diferentes serviços, armazenando todas informações recebidas dos inúmeros
191
192
5° WSL / 5° FISL
Terminais Box e as disponibilizando às pessoas autorizadas, localizadas tanto local quanto
remotamente, através das Aplicações Web Clientes;
3. Aplicação Web Cliente - módulo ou aplicação desenvolvida para ser utilizada pelos
médicos e enfermeiras para realizar a interface entre a Central de Monitoração e os
profissionais da área da saúde, possibilitando o acesso tanto aos serviços de monitoração (sinais
vitais, áudio, vídeo, alarmes e atuação) quanto ao prontuário do paciente de qualquer
computador via Web. Foi projetada utilizando o modelo web based, oferencendo uma interface
gráfica para os usuários para acesso aos diversos serviços disponíveis via Internet.
3. Conclusão
O presente já nos traz, sem dúvida, uma grande quantidade de informações digitais, seja através
de antenas, fibras ópticas, satélites, TV a cabo, Internet, linhas telefônicas comuns e celulares.
No contexto médico, o computador e as redes de comunicação serão uma parte integrante tanto
quanto o estetoscópio.
O desenvolvimento de uma Ferramenta de Telemedicina baseada em software livre
objetiva oferecer, a baixo custo, um conjunto de serviços ligados aos cuidados com a saúde,
tanto para pacientes hospitalizados quanto para pacientes que possam ser acompanhados e
monitorados à distância das suas próprias casas, sendo que a distância deixa de ser um fator
crítico. Agregamos à Ferramenta recursos de computação e de telecomunicações os quais
possibilitam prover condições para a aquisição de dados, processamento dos sinais e o
envio/recebimento das informações (dados, áudio e imagens) em tempo quase real,
viabilizando ações médicas interativas mesmo não estando os profissionais e os pacientes
fisicamente no mesmo local, permitindo a universalização do acesso à saúde, melhorando a
qualidade dos serviços prestados às pessoas e às comunidades distantes.
Em termos sociais este projeto tem uma importância fundamental para a melhoria do
sistema de saúde municipal, estadual e nacional, podendo ser um sistema embrionário de
Telemedicina que deverá ser implantado inicialmente no Hospital São Lucas e posteriormente
ampliado para a rede da Grande Porto Alegre, tornando possível a sua expansão de modo a
atingir os lugares mais remotos do estado do Rio Grande do Sul e, posteriormente, do Brasil.
Um protótipo da ferramenta estará disponível para demonstração no stand da PUCRS durante o
Fórum Internacional de Software Livre.
4. Referências
[1] World Health Organization. Disponível na Internet: http://www.who.int/en
[2] B. Ricardo, G. S. Jorge, C. C. Fladhimyr, Transmissão Robusta de Voz sobre IP Aplicado a
Redes de Comunicação. Anais do CISCI 2002, julho, 2002.
[3] B. Ricardo, G. S. Jorge, C. C. Fladhimyr , M. S. Pedro, A robust arquitecture for IP
telephony systems interconnection. Anais do PACRIM'03, agosto, 2003.
[4] Q. Alexandre, G. S. Jorge, J. R. Rafael, Telemonserver: Um sistema de Videomonitoração
Via Web. Anais do COBRAPI 2002, março, 2002.
[5] G. S. Jorge, J. R. Rafael, Câmera Robô: Controlador Remoto Via Internet para
Posicionamento de Câmeras de Vídeo. Anais do COBRAPI 2002, março, 2002.
[6] R. L. Bashshur, J. H. Sanders, G. W. Shannon, Telemedicine - Theory and Practice. Charles
C. Thomas Publisher, 1997.
5° WSL / 5° FISL
MOTV: Uma Extensão ao Modelo de Dados Orientado a
Objetos com Suporte a Tempo e Versão
Eduardo Nunes Ferreira Bastos1∗, Antônio Carlos da Rocha Costa1
1 Escola
de Informática – Universidade Católica de Pelotas
Caixa Postal 402 – 96010-000 Pelotas, RS
Abstract. MOTV is an extension to the model of object-oriented database, based in the
Temporal Version Model, with support for the dimensions of time and version. It was
implemented in Python and integrated later to the ZOPE platform, being distributed as
free software, licensed through GNU GPL.
Resumo. MOTV é uma extensão ao modelo de dados orientado a objetos, baseado no
Modelo Temporal de Versões, com suporte às dimensões de tempo e versão. Foi implementado em Python e integrado posteriormente à plataforma ZOPE, sendo distribuı́do
como software livre, licenciado através da GNU GPL.
1. Introdução
Um modelo de dados é uma coleção de conceitos que podem ser usados para descrever um conjunto de dados e operações para manipular estes dados. Em um modelo de dados orientado a
objetos estes dados são considerados como uma coleção de objetos, na maioria das vezes complexos, do mundo real.
Atualmente, não existe um padrão que regularize o modelo de dados orientado a objetos,
apesar de esforços estarem sendo realizados pelo grupo ODMG (Object Database Management
Group). Entretanto, via de regra é possı́vel identificar os princı́pios fundamentais que fazem parte
de um núcleo [Galante, 1998], considerado comum (corel model) à maioria dos modelos existentes, como: objetos e identificadores de objetos, objetos simples e complexos, classes, herança e
encapsulamento.
Estas caracterı́sticas satisfazem os requisitos para modelagem de dados em diversos
domı́nios de aplicações. Porém, recentemente as aplicações para sistemas de bancos de dados
estão sendo limitadas por restrições impostas pelo modelo relacional de dados, principalmente nas
áreas de CAD (Computer Aided Design), CASE (Computer Aided Software Engineering), SCM
(Software Configuration Management), e, mais recentemente, Hipermı́dia, como a possibilidade
de armazenar e manipular diferentes versões de um objeto [Golendziner, 1995]. Como resultado,
vários modelos de dados têm sido propostos para tratar desses novos domı́nios da aplicação, muitos oriundos da área de aplicações, propondo sistemas independentes de bancos de dados, outros
concentram-se na identificação de novos requisitos impostos, procurando estender modelos de
bancos de dados existentes para contemplar estas necessidades.
Apesar da utilização de versões armazenar as alternativas de projeto, nem todo o histórico
das alterações realizadas sobre os dados é registrado. A maior parte das aplicações atuais tem necessidade de manipular informações históricas - dados relativos a estados passados da aplicação.
Os SGBD convencionais, no entanto, não suportam estas caracterı́sticas. Esta necessidade motivou o estudo de conceitos e estratégias para tratar informações históricas em Banco de Dados
Temporais [Edelweiss, 1998].
Dentre deste contexto, o objetivo do presente trabalho é o desenvolvimento de um modelo
de dados orientado a objetos com conceitos e mecanismos para tratar aspectos de tempo e versão
∗
Bolsista do CNPq - Brasil.
193
194
5° WSL / 5° FISL
de objetos no nı́vel da aplicação, integrado à plataforma ZOPE (Z Object Publishing Environment).
A finalidade desta integração é possibilitar que as inúmeras aplicações que utilizam o servidor de
aplicações ZOPE, possam desfrutar também do modelo proposto, afim de satisfazer os requisitos
não supridos pelas atuais aplicações.
2. Modelo proposto
O modelo orientado a objetos que está sendo proposto, denominado MOTV
[Bastos and Costa, 2004b] - Modelo de Objetos Temporais e Versionados, resultou de variações
aplicadas ao Modelo de Versões [Golendziner, 1995], o qual constitui até hoje a proposta de extensão de versões mais completa e concisa presente na literatura, e ao Modelo Temporal de Versões
[Moro, 2001], e tomou como base um estudo preliminar descrito em [Nieves and Costa, 2003].
O modelo proposto contempla dois aspectos: (i) tempo, associa informações temporais
aos dados armazenados, identificando quando uma informação foi definida ou o tempo de sua
validade, permitindo assim, acessar todos os estados de uma aplicação (presentes, passados e
futuros); e (ii) versão, descrição de um objeto em um determinado momento de tempo, ou sob um
determinado ponto de vista, cujo registro é importante para aplicação.
Uma descrição em detalhes do modelo proposto só pode ser dada num relatório extenso,
incluindo ilustração de códigos, diagramas e modelos. O objetivo deste artigo é descrever de forma
sucinta as caracterı́sticas principais do modelo.
2.1. Hierarquia de Classes
A hierarquia de classes do modelo, utilizando a notação da UML (Unified Modeling Language),
pode ser visualizada na figura 1. Em [Bastos and Costa, 2004a], é apresentada e descrita a hierarquia completa, com todas as classes, métodos e atributos.
Figura 1: Hierarquia resumida de classes do modelo proposto
O usuário define as suas classes de aplicação como subclasses de Object, TemporalObject,
VersionObject ou TemporalVersionObject, o que produz um objeto não temporal e não versionado,
temporal, versionado e temporal versionado, respectivamente.
Nas figuras 2 e 3 são ilustradas as interfaces de visualização e de gerenciamento de um
objeto temporal versionado, respectivamente. Estes screenshots foram capturados através da ZMI
(Zope Management Interface).
2.2. Representação Temporal
O tempo é associado a objetos, versões, atributos e relacionamentos permitindo, assim, uma modelagem mais flexı́vel. Duas ordens no tempo são identificáveis: (i) tempo ramificado para um
objeto (devido à várias versões); e (ii) tempo linear para cada versão.
5° WSL / 5° FISL
Figura 2: Interface de visualização de
um objeto temporal e versionado
Figura 3: Interface de gerenciamento
de um objeto temporal e versionado
Os atributos e relacionamentos de um objeto podem ser estáticos (quando não há variação
de seus valores) ou temporalizados (todas as alterações de seus valores são armazenados formando
um histórico), ficando a cargo do usuário a definição. Os valores estão associados com os rótulos
pré-definidos, os quais representam os tempos de: (i) transação inicial, indica quando um objeto
foi inserido na base de dados; (ii) transação final, representa um objeto excluı́do logicamente; (iii)
validade inicial, retrata um objeto válido na realidade modelada; e (iv) validade final, designa um
objeto inválido na realidade modelada.
Foram definidos quatro estados de um objeto temporal, Ativo, Inativo, Válido e Inválido,
com o objetivo de facilitar o uso de operações sobre estes objetos. Estes estados, denominados
literais, podem ser copiados, armazenados como valores, passados como parâmetros, ou ainda
fazer parte de comparações exatas.
2.3. Representação de Versões
A caracterı́stica de versionamento está associada aos objetos e não às classes [Golendziner, 1995].
Desta maneira, um objeto que não possua versões, pode passar a ser versionado de forma dinâmica.
Duas classes são modeladas para este propósito: VersionedObjectControl (controlador de versões)
e VersionObject (versão propriamente dita).
Cada versão possui uma estrutura do tipo grafo de outras versões predecessoras (antecessoras) e sucessoras, compondo a hierarquia de composição de objetos. O relacionamento que
existe entre as versões denomina-se de derivação, e pode ser de dois tipos: alternativas, caso uma
versão seja derivada da mesma versão; e derivativas, se versões estão no mesmo caminho até a
raiz do grafo. O conjunto de relacionamentos entre versões forma uma estrutura conhecida por
histórico de versões.
Na hierarquia de herança, utiliza-se o conceito de extensão, que está relacionada com a
idéia de protótipos. Cada objeto de uma classe (protótipo) está associado com outro objeto em
uma classe mais especializada (extensão). Neste relacionamento entre objetos, modela-se versões
ascendentes e descendentes A correspondência definida pode ser do tipo 1:1 (um-um), 1:n (ummuitos), n:1 (muitos-um) ou n:m (muitos-muitos).
O relacionamento entre versões, objetos versionados e não versionados, pode ser feito de
duas maneiras [Golendziner, 1995]: (i) referência estática, permite o relacionamento especı́fico
entre objetos; e (ii) referência dinâmica, permite uma ligação de forma genérica, onde utiliza-se
um mecanismo de resolução. Este mecanismo utiliza uma versão default, escolhida pelo usuário,
ou uma versão corrente, mantida pelo sistema.
O modelo permite configurações entre objetos [Golendziner, 1995], isto é, ligação entre
195
196
5° WSL / 5° FISL
uma versão do objeto composto e uma versão de cada um de seus objetos componentes.
Uma versão pode passar por alguns estados [Golendziner, 1995], em seu tempo de
vida, que compreendem: Em Trabalho, Estável, Consolidada e Desativada. Assim como na
representação temporal, estes estados podem ser utilizados como literais.
3. Considerações Finais
O desenvolvimento deste modelo encontra-se em estágio final. Atualmente está sendo integrado
alguns aspectos à plataforma ZOPE, e gerado a documentação final da ferramenta. As próximas
etapas do trabalho envolverão o teste de software e a integração do modelo a um ambiente de
ensino na Web, denominado ENSINET [Miranda et al., 2001].
Salienta-se que às vantagens oferecidas por sofwares livres, como o servidor de aplicações
ZOPE, a linguagem de programação Python e o uso do sistema operacional GNU/Linux, contribuem de forma satisfatória para o desenvolvimento e disseminação de ferramentas, onde qualquer
pessoa interessada pode adquiri-la e utilizá-la. Espera-se que o desenvolvimento e utilização da
ferramenta possa ser compartilhada com a comunidade ZOPE e Python, visando a ampliação de
suas funcionalidades e de sua aplicação como ferramenta de gerência de objetos temporais e versionados.
Todos os frutos do trabalho realizado e descrito nesse artigo estão disponı́veis para a consulta no seguinte endereço eletrônico: http://bdi.ucpel.tche.br/motv.
Referências
Bastos, E. N. F. and Costa, A. C. R. (2004a). ENSINET/M2A: monitoração, avaliação e adaptação
no sistema ENSINET. Technical report, UCPel, Pelotas.
Bastos, E. N. F. and Costa, A. C. R. (2004b). Proposta Inicial de um Modelo de Objetos Temporais
e Versionados para Ambientes de Apoio ao Ensino. In I Workshop de Computação, Palhoça.
SBC.
Edelweiss, N. (1998). Bancos de Dados Temporais: Teoria e Prática. In Minicurso da XVII
Jornada de Atualização de Informática (JAI).
Galante, R. M. (1998). Um Modelo de Evolução de Esquemas Conceituais para Bancos de Dados Orientados a Objetos com o Emprego de Versões. Master’s thesis, PPGC/UFRGS, Porto
Alegre.
Golendziner, L. (1995). Um modelo de versões para banco de dados orientados objetos. PhD
thesis, CPGCC/UFRGS, Porto Alegre.
Miranda, R. M., Dimuro, G. P., and Costa, A. C. R. (2001). Um Ambiente de Suporte ao Ensino
Integrado dos Fundamentos Matemáticos da Ciência da Computação utilizando o ZOPE. In II
Workshop de Software Livre, pages 40–42, Porto Alegre. SBC.
Moro, M. M. (2001). Modelo Temporal de Versões. Master’s thesis, PPGC/UFRGS, Porto Alegre.
Nieves, I. V. and Costa, A. C. R. (2003). Estudo e Adaptação de um Modelo de Objetos Temporais
Versionados para o sistema ENSINET.
5° WSL / 5° FISL
Sessão Técnica 14
ENGENHARIA DE SOFTWARE
197
198
5° WSL / 5° FISL
5° WSL / 5° FISL
Utilizando o Paradigma de Software Livre para Definir Melhores
Práticas em Engenharia de Software
Eduardo Quesado Filgueiras 1,2 , Mateus Ribeiro Mota1,2
1
Universidade Luterana do Brasil (ULBRA) – Centro Universitário Luterano de Manaus
Av. Solimões, 2 – Conjunto Atílio Andreazza, Japiim II – 69.077-730 – Manaus – AM - Brasil
2
Sistema de Proteção da Amazônia (SIPAM)
Av. do Turismo, 1350 – Tarumã – 69.049-630 – Manaus – AM - Brasil
{quesado,mateus}@mn.sivam.gov.br
Resumo. Este artigo propõe a utilização de práticas de desenvolvimento de software livre
como técnicas catalisadoras a serem adotadas em processos de Engenharia de Software
tradicional, abrangendo a comunicação entre os grupos de desenvolvimento, a definição e
captura de requisitos, as decisões de projeto, a qualidade, o suporte a usuários, o teste e a
manutenção de software. A adoção de elementos do paradigma de software livre como
melhores práticas de Engenharia de Software visa criar um ambiente de desenvolvimento
socializante, comunitário e democrático, tendo as pessoas como base do sucesso
organizacional, em oposição a modelos formais e hierarquizados.
Abstract. This paper proposes the use of open source development practices as catalyst
techniques to be adopted on traditional Software Engineering processes, including
workgroup development, requirements definition and capture, project decisions, quality,
user support, software test and maintenance. The goal on adopting open source paradigm
elements as Software Engineering best practices is to create a socializing, communitarian
and democratic development environment, having peopleware as the basis for
organizational success, thus opposing formal and hierarchical models.
1. Introdução
Um dos maiores enganos que se pode cometer ao advogar a adoção de software livre é associá -lo a
software gratuito. Deve-se manter a ênfase na defesa da liberdade de expressão e na liberação de
conhecimento, e não apenas promover software que é livre de custo de aquisição, já que, em projetos
de software livre, é possível obter o código fonte, utilizar o programa e modificá-lo livremente para
satisfazer necessidades particulares, sem as restrições dos programas proprietários [Williams 2002].
Em termos de desenvolvimento de software, a premissa básica do modelo de software livre é
que um grupo fechado de desenvolvedores não pode competir com centenas ou milhares de
programadores motivados [Voightmann e Coleman 2003]. No contexto de desenvolvimento de
software tradicional, onde o código é fechado, empresas contratam programadores que desenvolvem
utilizando técnicas acadêmicas de Engenharia de Software [Pressman 2000]. Software de código
aberto, outrossim, adota um modelo diferente, não influenciado por liderança corporativa, nem realiza
repasses de custos de desenvolvimento, ou aplica restrições econômicas e políticas de uso. Ao
contrário, programadores criativos, capazes, experientes e motivados se congregam globalmente via
rede e desenvolvem uma versão inicial, razoavelmente funcional, cuja disponibilidade é anunciada aos
usuários finais, que encontram erros e identificam necessidades, reportando aos criadores, que por sua
vez corrigem e melhoram o programa, distribuindo rapidamente as novas versões a fim de que o ciclo
se reinicie, em uma espiral de qualidade crescente.
Entretanto, o modelo de desenvolvimento de software livre enfrenta ceticismo dos que
imaginam ser o processo tradicional de Engenharia de Software e seu embasamento científico a única
solução para os desafios clássicos em qualquer projeto de sistemas de software: os atrasos no
cronograma, a deficiência na qualidade e os custos ascendentes [Massey 2003]. Os chamados
processos “clássicos”, outrossim, são constantemente criticados pela sua impessoalidade, rigidez e
excesso de formalismo, e as chamadas “melhores práticas” da Engenharia de Software constantemente
199
200
5° WSL / 5° FISL
caem em erro ao serem tragadas pelo paradoxo da solução absoluta, ao se constituírem em pretensas
“receitas” ou “balas de prata” [Brooks 1987].
Uma possibilidade a explorar, portanto, é se utilizar o aprendizado sobre as vantagens do
modelo de software livre para acrescentar novas práticas ao cabedal da Engenharia de Software,
cobrindo lacunas nos processos tradicionais, principalmente no tocante à humanização do processo de
desenvolvimento.
2. Melhores Práticas com Software Livre
Não se pode assumir que o modelo de desenvolvimento de software livre veio para suplantar os
processos tradicionais. Em diversos setores, embora seja estimulável o uso crescente de ferramentas
desenvolvidas em código aberto, devido ao seu elevado gradiente evolutivo [Pinheiro 2003], sabe-se
que a institucionalização de métodos e procedimentos de software livre é de difícil aplicação, por
fatores culturais e econômicos ou características organizacionais.
Assim sendo, uma série de proposições a serem adotadas como melhores práticas no
desenvolvimento de software, advindas do modelo de software livre, são enunciadas a seguir.
2.1. A multiplicação da comunicação entre equipes de desenvolvimento
O processo utilizado por desenvolvedores de código aberto é definível como uma atividade
essencialmente social e sistêmica. O modelo baseia -se no intercâmbio de informações entre os
programadores como elemento de sinergia, onde a combinação das fontes de conhecimento múltiplas
produz uma resultante maior que a das partes, em um sistema aberto, que evolui pela contínua
comunicação. De fato, software livre leva o conhecimento compartilhado a incrementar
exponencialmente, enquanto o isolacionismo em compartimentos estanques do software tradicional
bloqueia o enriquecimento da equipe, tendo em vista que constitui, em contrapartida, um sistema
fechado, onde o intercâmbio de experiências extra-microverso do grupo de trabalho é desestimulado
ou inibido [Raymond 1998].
Dessa maneira, é razoável a suposição de que a qualidade do produto é diretamente
proporcional à equipe que o produziu, e que um grupo cujo talento e motivação são estimulados e, em
conseqüência, desenvolvidos, produz mais e melhor, em um dado período, satisfazendo às
expectativas dos usuários. Assim, software livre altera de forma radical o modo como se estabelece
comunicação entre grupos de desenvolvimento. A utilização maciça da Internet e das intranets
corporativas, com desenvolvimento baseado em Web com padrões abertos, seguida de controle de
versão avançado, são aspectos relevantes neste processo. Finalmente, o estímulo à diversidade cultural
nos grupos e o cruzamento de experiências deve ser institucionalizado. As equipes de
desenvolvimento devem ser autorizadas a ver livremente e pesquisar todo o código de seu projeto e de
outros projetos, tendo inclusive tempo dedicado a contribuir com sugestões de soluções de design e de
implementação, criando conhecimento coletivo e aprendizado comum [Filgueiras 2003].
2.2. A libertação da tirania dos requisitos
Um dos maiores desafios que enfrenta qualquer projeto de software é capacidade de adaptar-se às
mudanças de requisitos dos usuários [Pressman 2000], uma realidade inevitável e irreconciliável com
modelos documentais tradicionais baseados em normas produzidas nos anos 70 e 80, visando à
adequação a contratos governamentais norte-americanos, como o modelo waterfall (cascata). A grande
vantagem do software livre, porém, é que este evolui com os usuários, não estando ligado a ciclos ou
espirais específicos e herméticos, mas sim a uma definição muito mais flexível de incrementos que, o
mais cedo possível, estarão operando nas máquinas dos usuários, focados na satisfação das suas
necessidades reais (o princípio “release early, release often”) [Scacchi 2002].
A movimentação do centro de gravidade dos requisitos formais para as necessidades e
aspirações dos usuários deve ser considerada como elemento de redução do altíssimo custo agregado à
obtenção de requisitos e a quase constante paralisia que sua captura representa. Repensar o modelo
tradicional com as vantagens do software livre é uma possibilidade interessante e, embora a intenção
de capturar o máximo de necessidades dos clientes a priori seja uma tentativa de reduzir incertezas e
5° WSL / 5° FISL
custos, é fato que os usuários preferem flexibilidade e liberdade de evoluir suas expectativas a uma
baseline consolidada, porém monolítica.
2.3. A proatividade no gerenciamento de projetos
Devido à própria natureza do desenvolvimento de software livre, onde a motivação do programador
supera qualquer outra obrigação imposta pelos modelos de desenvolvimento tradicionais, as
responsabilidades de um projeto recaem de forma espontânea e voluntária entre os membros da
comunidade [Massey 2003]. Essas responsabilidades são guiadas pelo espírito de liderança no grupo
de desenvolvedores, onde a influência pessoal exercida pelo líder se mostra mais eficaz que a ditadura
dos tradicionais gerentes de projeto. Em resumo, software livre se baseia naturalmente no poder
pessoal e na liderança natural (cite-se Linus Torvalds) que em poder de posição e liderança puramente
hierárquica.
2.4. A liberação dos usos e costumes no processo de desenvolvimento
Embora os processos tradicionais de desenvolvimento de software tenham se mostrado eficientes na
fase inicial de evolução da indústria do software [Jacobson 1992], a mecanização do desenvolvimento,
porém, transformou a produção de software de atividade criativa e gratificante para uma manufatura
similar à produção de televisores em uma fábrica. O modelo tradicional prende o desenvolvedor a uma
série de ciclos e etapas que perdem o contato com os usuários, superespecializando-o em uma
pantomima semelhante a Chaplin em “Tempos Modernos”. O paradigma do software livre está sempre
voltado para a melhor solução de um determinado problema, não se prendendo a usos e costumes que
burocratizam a produção de software e não garantem a qualidade do mesmo [Ferraz 2002].
2.5. A qualidade como resultado natural do processo
O conhecimento associado à propriedade coletiva e responsabilidade sobre o código são elementos
que aumentam a qualidade de um software. Ter um número maior de pessoas opinando a respeito das
melhorias do código do software e possuir usuários motivados em implementar essas melhorias são a
chave da qualidade do software livre, pois todos se sentem envolvidos no processo e se comprometem
pessoalmente com o seu sucesso [Raymond 1998]. Ademais, as bases de processos formais de
desenvolvimento orientados a objetos [Jacobson, Booch e Rumbaugh 1999] encontram-se
inerentemente presentes em softwre livre: o direcionamento da especificação para os usos típicos do
sistema, a centralização em uma arquitetura sólida e o desenvolvimento iterativo e incremental.
2.6. A co-distribuição das responsabilidades de teste e manutenção
As atividades de teste e manutenção de software livre podem produzir respostas mais rápidas e
significativas quando comparadas com as de softwares proprietários. Partindo do princípio de que
muito mais pessoas tem acesso ao código de uma aplicação nas atividades de teste, a probabilidade de
um erro ser encontrado é muito maior que no software de código fechado [Ferraz 2002]. Além disso,
as atividades de teste tradicionais, que normalmente se mostram repetitivas e muitas vezes ineficazes,
podem ser voltadas para o real problema: a codificação das necessidades do usuário. Em software livre
os usuários também podem participar ativamente dos testes, o que motiva os mesmos e contribui com
o processo de desenvolvimento.
Ademais, a manutenção do software é uma das atividades mais custosas e de maior duração na
Engenharia de Software [Pressman 2000], porém quase não recebe enfoque metodológico. Quando se
trata de desenvolvimento de software livre, a manutenção é altamente voltada para os usuários, o
verdadeiro público das versões lançadas periodicamente. Adicionalmente, esta é motivada pelo desejo
de auto-satisfação dos desenvolvedores, que vislumbram as melhorias contínuas do software como
meta internalizada em seus processos cognitivos.
2.7. A humanização do suporte aos usuários
Um dos grandes mitos do software livre é a inexistência de suporte técnico por parte de seus criadores
[Voightmann e Coleman 2003]. Primeiramente, no modelo do software livre o suporte é oferecido
pelos vários desenvolvedores e usuários que conhecem a fundo o código e as funcionalidades do
201
202
5° WSL / 5° FISL
software, pois não existe “caixa preta” em software livre. Desta forma, é possível oferecer um suporte
muito mais real e produtivo nas listas de discussão e outros mecanismos da Internet. Tal interação gera
uma relação cliente-desenvolvedor muito mais satisfatória do que atendentes de “help desk” de
grandes empresas de software, os quais normalmente nunca obtiveram acesso aos códigos-fonte do
programa do qual prestam suporte, nem possuem conhecimento profundo sobre a ferramenta em
questão.
3. Conclusão
Os componentes históricos registram a importância dos processos tradicionais resultantes de
excelência científica para o desenvolvimento de software. Porém, é necessário revisar conceitos no
tocante a modelos de desenvolvimento, inserindo os aprendizados e idéias que refletem a evolução
dos sistemas de computação, adequando processos às realidades tecnológicas, econômicas e sociais
atuais. O modelo de desenvolvimento de software livre possui diversas características que fogem dos
formalismos e processos da Engenharia de Software tradicional, porém seus casos de sucesso
demonstram que este pode ser adaptado a processos de desenvolvimento como melhores práticas a
serem incorporadas ao conhecimento formal. Descartar as possibilidades e aprendizados do modelo de
software livre seria demonstrar cegueira sem precedentes, já que as lições oriundas do paradigma de
software de código aberto podem ser aplicadas e incorporadas ativamente em qualquer processo de
desenvolvimento de software, diminuindo o tempo de desenvolvimento e os custos, porém
aumentando a produtividade e a satisfação dos usuários e programadores, principalmente na captura de
requisitos, na gerência de projetos, na qualidade, no suporte a usuários, na manutenção de uma base de
código atualizada e na minimização dos problemas causados por bugs.
Referências
Brooks, F. P., Jr. “No Silver Bullet: Essence and Accidents of Software Engineering”. Computer
Magazine. Vol. 20, N° 4. April 1987.
Ferraz, N.C.T. “Vantagens Estratégicas de Software Livre para o Ambiente Corporativo”. PUC-SP.
São Paulo, 2002.
Filgueiras, E.Q. “Melhorando Processos de Engenharia de Software Através do Paradigma de
Software Livre”. Developers’ Magazine, n° 87, Axcel Books. Novembro de 2003.
Jacobson, I. “Object-Oriented Software Engineering”. Addison-Wesley, 1992.
Jacobson, I., Booch, G., Rumbaugh, J. “The Unified Software Development Process”. Massachusets:
Addison-Wesley, 1999.
Massey, B. “Why OSS Folks Think SE Folks Are Clue-Impaired”. In: Taking Stock of the Bazaar.
Proceedings. 3rd International Conference on Software Engineering (ICSE''03). Portand. 2003.
Pinheiro, A.S. “Transformando a Informação Pública pelo Software Livre. Um olhar sociotécnico”. In:
WorkShop Sobre Software Livre – WSL 2003. 4. Anais. Sociedade Brasileira de Computação. Porto
Alegre, 2003.
Pressman, R.S. “Software Engineering: A Practitioner’s Approach”. 5th Edition, Mc Graw Hill, 2000.
Raymond, E. “The Cathedral and the Bazar”. FirstMonday. Vol. 3, Nº 3. Março de 1998.
Scacchi, W. “Understanding Requirements for Developing Open Source Software Systems”. IEEE
Proceedings. Software. N. 149. 2002.
Voightmann, M., Coleman, C. “Open Source Methodologies and Mission Critical Software
Development”. In: Taking Stock of the Bazaar. Proceedings. 3rd International Conference on Software
Engineering (ICSE''03). Portand. 2003.
Williams, S. “Free As In Freedom: Richard Stallman´s Crusade for Free Software”. O´Reilly &
Associates, 2002.
5° WSL / 5° FISL
SAFE - Software Engineering Available for Everyone
Renata Pontin de Mattos Fortes, Marco Aurélio Graciotto Silva,
André Pimenta Freire, Daniel Cárnio Junqueira
1 Instituto
de Ciências Matemáticas e de Computação – Universidade de São Paulo
Av. do Trabalhador São-Carlense, 400 – Cx. Postal 668
CEP 13560-970 São Paulo, SP
{renata,magsilva}@icmc.usp.br,{apfreire,danielcj}@grad.icmc.usp.br
Resumo. O projeto SAFE visa elaborar uma infra-estrutura para desenvolvimento de
software que seja simples o suficiente para atrair a colaboração de desenvolvedores
nos diversos nı́veis de familiaridade com o processo de software livre. A infra-estrutura
será na forma de um suporte automatizado ao processo de software livre, por meio da
integração de ferramentas de software livre de apoio às atividades de engenharia de
software.
Abstract. The SAFE project aims the elaboration of a software development framework
sufficiently simple to attract the collaboration of free software’s developers with different levels of software process’s familiarity. This framework will help the automation
of free software processes, through the integration of free software tools that support
software engineering activities.
1. Introdução
Projetos de software livre têm recebido constante atenção da comunidade cientı́fica. O fato que
mais chama a atenção é a alta qualidade que tem sido obtida no desenvolvimento de projetos
de software livre, mesmo com a utilização de um processo de desenvolvimento aparentemente
caótico. Exemplos de casos de sucesso são os projetos Mozilla, Apache, e, principalmente, o
kernel do sistema operacional Linux; os projetos têm crescido muito rapidamente e apresentam
qualidade superior à esperada.
Entender esse processo de desenvolvimento é importante para facilitar a análise de como deve ser a adoção de software livre na indústria. Para esse entendimento, assim como para
a criação de documentação e bibliografia adequadas, diversos trabalhos têm sido efetuados nos
últimos anos. Exemplos disso são os estudos de caso dos principais projetos de software livre que
têm sido publicados (Mockus et al., 2000; Godfrey e Tu, 2000; Krishnamurthy, 2002). Um deles
é a pesquisa na forma de um estudo detalhado sobre o projeto Mozilla (Reis e Fortes, 2002), em
que são descritas as principais ferramentas utilizadas no processo do Mozilla e são discutidos os
resultados dessa utilização para o desenvolvimento do projeto. A partir desse estudo, surgiu uma
motivação crescente sobre como o processo de software livre conta com ferramentas de suporte às
atividades de engenharia de software.
O projeto SAFE, foco principal deste artigo, objetiva primeiramente estudar as principais
caracterı́sticas destas ferramentas e as possı́veis formas de integração das mesmas, visando assim
a construção de um framework para suporte ao desenvolvimento de software livre que possa ser
facilmente utilizado para o desenvolvimento de software livre, tanto no ambiente acadêmico como
no ambiente empresarial. Também é objetivo deste projeto identificar as lacunas existentes e criar
ferramentas baseadas nesses dados que devem também integrar o framework a ser desenvolvido.
203
204
5° WSL / 5° FISL
O restante deste artigo está organizado da seguinte forma: a seção 2 apresenta uma
caracterização do processo de software livre, baseada em estudos desenvolvidos recentemente;
a seção 3 detalha a proposta do projeto SAFE. Finalmente, a seção 4 apresenta as considerações
finais.
2. Caracterização do Processo de Software Livre
Um recente trabalho (Reis, 2003) foi desenvolvido para caracterizar o processo de software livre.
O amplo levantamento realizado, sobre os projetos estáveis de software livre, permitiu concluir
que o processo varia substancialmente entre os projetos, sendo indevido criar uma generalização
ampla do mesmo. Todavia, foi possı́vel observar que existem elementos comuns nos processos.
Analisando a relação entre o esforço despendido nas atividades de engenharia de software e uso
das ferramentas (chamado no trabalho de “Índice de Engenharia de Software”) investigadas no
levantamento em relação ao tamanho dos softwares (Figura 1), a concentração nos valores médios
para o ı́ndice de engenharia de software sugere um processo comum em boa parte dos projetos de
software livre, mas que não envolve todas as atividades abordadas no levantamento.
Figura 1: Gráfico scatter relacionando o ı́ndice de engenharia de software com o número
de linhas de código de cada projeto. Fonte: (Reis, 2003, p. 130)
Assim, um ciclo de vida para software livre é pressuposto existir de maneira que cada
projeto o instancia sob a influência de sua cultura interna, seu histórico e seus objetivos. O ciclo se delineou como composto por quatro fases: criação, lançamento público, crescimento e
organização, e maturidade. As fases mais importantes, sob a perspectiva de que contam com
apoio de ferramentas para garantia de qualidade no desenvolvimento do processo, são as que procedem ao lançamento público: a partir desse momento, o projeto entra em processo de evolução
contı́nua.
Com base nesse modelo de ciclo de vida identificado, é possı́vel apoiar um processo livre
que satisfaça as necessidades da emergente indústria de software livre brasileira, envolvendo não
somente a produção efetiva de software de alta qualidade, mas também a formação de mão-de-obra
qualificada para alimentar essa indústria.
3. Proposta do Projeto SAFE
O interesse por projetos de software livre em ambiente empresarial e no meio acadêmico tem sido
crescente. No entanto, esses mesmos ambientes, que apresentam atraentes novidades, se mostram
5° WSL / 5° FISL
deficitários no que diz respeito à adoção de atividades de engenharia de software. De fato, há uma
lacuna no que diz respeito à integração de ferramentas de projetos de software livre de apoio às
atividades de garantia de qualidade de software e, em particular, aos processos de software livre.
Com a tendência atual de utilização de software livre, torna-se relevante viabilizar um processo que
atenda às necessidades dessa nova abordagem de desenvolvimento e que contribua efetivamente
para a obtenção de produtos de alta qualidade.
A disponibilização de um framework relacionado ao contexto de processos de software
livre é particularmente interessante por viabilizar a combinação de métodos, ferramentas e procedimentos em uma única estrutura.
Dentro desse contexto, foi elaborada a proposta do projeto SAFE (Fortes et al., 2004b)
(Software Engineering Available For Everyone - Engenharia de Software Disponı́vel para Todos).
O SAFE será desenvolvido pelos Instituto de Ciências Matemáticas e de Computação (ICMCUSP) e Departamento de Computação e Estatı́stica (DCT-UFMS), com a colaboração da empresa
Async Serviços de Informática.
3.1. Objetivo do Projeto SAFE
O objetivo do projeto SAFE é desenvolver uma infra-estrutura para a integração de ferramentas
de software livre de apoio às atividades de Engenharia de Software. Esse framework possibilitará um suporte automatizado para o processo de software livre, simples o suficiente para atrair
a colaboração e a participação de desenvolvedores nos diversos nı́veis de familiaridade com o
processo de software livre.
3.2. Atividades do Projeto SAFE
Para alcançar os objetivos propostos, estão previstas diversas atividades envolvendo desde o desenvolvimento do framework até a disseminação do conhecimento referente à utilização de suas
ferramentas e do processo de software com a utilização de software livre.
A primeira atividade é a capacitação do pessoal envolvido com o projeto, através da
utilização de ferramentas de software livre de suporte às atividades de Engenharia de Software
(em especial as Webtools, adotadas no desenvolvimento do Mozilla, como a Bugzilla e o Bonsai).
A seguir, têm-se a definição e implementação do framework para auxı́lio ao processo de
software. Serão integradas as ferramentas de software livre envolvidas na atividade anterior e outras já desenvolvidas pelos grupos de pesquisa, como a No Risk Planning1 (Fortes et al., 2004a),
para agendamento de atividades em grupos, a DocRationale (Frascisco, 2004), para suporte ao
gerenciamento de razões de projeto, e a VersionWeb2 (Moreira et al., 2002), uma interface Web
para o CVS. Também será desenvolvida uma ferramenta do tipo wiki para auxiliar a engenharia
de requisitos (Silva e Fortes, 2003), por meio da construção de um hiperdocumento de requisitos, que também será integrada ao framework. Uma “cartilha” de suporte ao uso do framework,
com instruções sobre a utilização das ferramentas que o compõe, será elaborada, facilitando o
treinamento das ferramentas.
O framework será testado por meio da sua utilização durante o desenvolvimento de ferramentas. A transferência e multiplicação da tecnologia de framework desenvolvida para utilização
real em empresas de desenvolvimento de software, como a Async, permitirão a validação dos
resultados obtidos.
A disseminação do uso do framework será efetuada através da integração entre pesquisadores do meio acadêmico e profissionais envolvidos com o desenvolvimento de software livre
1
2
A No Risk Planning está disponı́vel em http://nrp.sourceforge.net.
A VersionWeb está disponı́vel em http://versionweb.sourceforge.net.
205
206
5° WSL / 5° FISL
no setor industrial. O framework também será utilizado durante o ensino de Engenharia de Software nos cursos de graduação e pós-graduação em Ciência da Computação do ICMC-USP e do
DCT-UFMS, capacitando pessoal para sua posterior aplicação na indústria.
4. Conclusão
A definição de um processo de engenharia de software é um importante passo para a eficiente
disseminação da cultura de desenvolvimento de software livre de qualidade. Existem projetos
de software livre que têm demonstrado uma grande eficiência no desenvolvimento de produtos
de qualidade, através da utilização de diversas ferramentas, que apóiam diversas atividades do
processo de desenvolvimento.
Neste artigo foi apresentada a proposta do Projeto SAFE (Software Engineering Available
For Everyone), que tem como objetivo desenvolver um framework que forneça uma infra-estrutura
para apoio de processos de software, integrando ferramentas consagradas, utilizadas no desenvolvimento de produtos de software livre de sucesso, e ferramentas novas que complementem o
framework e incrementem o suporte a processos de software com a utilização de ferramentas de
software livres.
Agradecimentos
Agradecemos à FINEP, pelo patrocı́nio do projeto, e às agências FAPESP e CAPES pelo apoio
financeiro aos autores.
Referências
Fortes, R. P. d. M., Freire, A. P., Vieira, V. H., Paiva, D. M. B. (2004a). An academic webbased agenda and its engineering process. In VII Workshop Iberoamericano de Ingenierı́a de
Requisitos y Desarrollo de Ambientes de Software, pp. 151–156, Arequipa, Peru.
Fortes, R. P. d. M., Turine, M. A. S., Reis, C. R. (2004b). Engenharia de Software Disponı́vel
a Todos - Software Engineering Available for Everyone (SAFE). Proposta de Projeto para
Chamada CT-Info-FINEP.
Frascisco, S. D. (2004). DocRationale - uma ferramenta para suporte a design rationale de artefatos
de software. Dissertação de Mestrado, Instituto de Ciências Matemáticas e de Computação,
Universidade de São Paulo, São Carlos, Brasil.
Godfrey, M. W., Tu, Q. (2000). Evolution in Open Source Software: A Case Study. In Proceedings
of the 2000 Intl. Conference on Software Maintenance, pp. 131–142, San Jose, California.
Krishnamurthy, S. (2002). Cave or Community? An Empirical Examiniation of 100 Mature Open
Source Projects. First Monday, 7(6).
Mockus, A., Fielding, R., Herbsleb, J. (2000). A Case Study of Open Source Software Development: The Apache Server. In Proceedings of ICSE 2000, pp. 263–272, Limerick, Ireland.
ACM Press.
Moreira, D. d. A., Soares, M., Fortes, R. P. d. M. (2002). VersionWeb: A tool for helping web
page version control. Linux Journal.
Reis, C. R. (2003). Caracterização de um processo de software para projetos de software livre.
Dissertação de Mestrado, Universidade de São Paulo, São Carlos, SP.
Reis, C. R., Fortes, R. P. M. (2002). An Overview of the Software Engineering Process and Tools
in the Mozilla Project. In Workshop on Open Source Software Development, pp. 155–175,
Newcastle, UK.
Silva, M. A. G., Fortes, R. P. d. M. (2003). Processo de Engenharia de Requisitos com Apoio
de Hiperdocumentos. In Workshop de Teses e Dissertações em Engenharia de Software, pp.
65–70, Manaus, AM.
5° WSL / 5° FISL
Levantamento sobre Processo de Software Livre
Renata Pontin de Mattos Fortes, Marco Aurélio Graciotto Silva, Christian Robottom Reis
1 Instituto
de Ciências Matemáticas e de Computação – Universidade de São Paulo
Av. do Trabalhador São-Carlense, 400 – Cx. Postal 668
CEP 13560-970 São Paulo, SP
{renata,magsilva}@icmc.usp.br,[email protected]
Resumo. Este artigo apresenta alguns dos principais resultados obtidos de uma ampla
pesquisa sobre processo de software livre. A pesquisa foi veiculada por meio de questionário e, com base nas respostas obtidas, puderam ser identificadas caracterı́sticas do
processo de software livre.
Abstract. This paper presents the main results gathered from an extensive research on
Open Source Projects. The research consists of a survey and, regarding the obtained
answers, characteristics of the open source process could be identified.
1. Introdução
Compreender melhor o processo de desenvolvimento em projetos de software livre apresentase como um desafio, motivando o surgimento de diversas questões a respeito da organização,
motivação e coordenação das equipes envolvidas. Nos últimos anos, diversas publicações cientı́ficas têm procurado descrever esses projetos de forma mais detalhada. No entanto, grande
parte desses trabalhos se concentra em projetos individuais ou em aspectos particulares do processo de software.
Aparentemente, os processos de software livre contam com grupos de pessoas geograficamente distribuı́das, na maioria informalmente organizados, produzindo software de alta qualidade
sem auxı́lio de ferramentas sofisticadas. A investigação das idéias subjacentes a essa eficiência de
processo de engenharia de software foi alvo de um recente trabalho desenvolvido por Reis (Reis,
2003). Sua pesquisa, reportada neste artigo, se propôs a fornecer uma ampla visão do cenário
de projetos de software livre, cobrindo lacunas importantes relacionadas ao processo de software
aplicado nos projetos.
Assim, o objetivo foi o de caracterizar o processo de software livre através de um amplo
levantamento abordando os projetos estáveis de software livre (Reis, 2003). Foram contactados
1.102 projetos, e obtidas 519 respostas válidas (47% do total). De maneira bastante resumida, este
artigo apresenta a metodologia adotada na seção 2. Os resultados obtidos são discutidos na seção
3, seguida de uma análise desses dados, na tentativa de identificar a comunidade dos processos de
software de cada projeto, na seção 4. Na seção 5, são apresentadas algumas das conclusões do
trabalho realizado.
2. Metodologia
Para o levantamento de dados, treze hipóteses (Reis, 2003, pp. 64-65) sobre o processo de software
livre foram consideradas, obtidas através do estudo da literatura e de técnica de etnografia adotada
por Reis. Os dados necessários foram obtidos através de um questionário, veiculado a pessoas com
bom conhecimento especı́fico do fluxo de trabalho e da equipe de um projeto de um software livre
especı́fico (preferencialmente o mantenedor responsável pelo projeto), e uma análise do pacote de
código-fonte do projeto, a fim de comparação com os dados do questionário.
207
208
5° WSL / 5° FISL
O questionário foi então testado e avaliado por alguns membros de projetos de software livre e engenheiros de software, sendo então preparada sua veiculação. Dado o desconhecimento da
dimensão total da população de projetos livres a ser avaliada, optou-se por selecionar uma amostra
não-aleatória. O critério adotado foi a escolha de projetos de software livre cujo processo de software se mostrasse saudável e sustentável e, por esse motivo, projetos que tenham caracterı́sticas
de longevidade, intensa atividade ou grande e permanente destaque público. O estabelecimento da
amostra, por cotas e casos crı́ticos, envolveu a seleção de projetos em dois diretórios de software
livre, o freshmeat.net e sourceforge.net, que qualificam os projetos segundo a própria comunidade
de desenvolvedores.
Um importante ponto a ser discutido em qualquer levantamento é a significância da amostra. Assumindo que os sites de registro de projetos sejam representativos da população de projetos
de software livre, é possı́vel fazer uma estimativa do total de projetos de software livre observados: 27.000 projetos registrados no freshmeat.net, 7.019 (26%) são estáveis ou maduros; 57.000
no sourceforge.net, 7.231 (12,7%) como maduros ou estáveis. Assumindo, conservadoramente,
que 40% dos projetos estão registrados em ambos os sites simultaneamente, é provável que a
população de projetos estáveis e maduros não passe de 8.550. Com base nessa dedução, o número
de respostas obtidas corresponde a até 6% do total de projetos maduros e estáveis, o que indica
uma boa cobertura para o estudo empı́rico.
3. Resultados
A veiculação do questionário foi iniciada em setembro de 2002, se estendendo até novembro do
mesmo ano. Foram enviadas mensagens para os responsáveis por projetos de software livre classificados como estáveis ou maduros e, com a chegada das respostas, fez-se a análise dos resultados e
coleta secundária de dados. Os resultados quantitativos do questionário são apresentados a seguir:
Localização geográfica dos participantes - a população avaliada é internacional, com uma grande participação de norte-americanos e europeus.
Domı́nio de aplicação - a maioria dos projetos está relacionada à engenharia de software, redes
e segurança, multimı́dia, navegadores e aplicações de escritório (53%).
Código-fonte - a linguagem mais utiliza é ANSI C, presente em 70,7% dos projetos analisados.
Seguem sh (65,9%), Perl (39,1%), C++ (32,76%), yacc (16,76%), Python (14,26%), dentre
outras. Cada projeto utiliza, em média, 3,2 linguagens. Analisando a quantidade de linha de
códigos, verifica-se uma média de 60 mil linhas por projeto (KLOC). Apenas 18% dos projetos
possuem mais do que a média, com apenas 10% superando 100 KLOCs.
Motivação - a maioria dos projetos (71,1%) foi iniciada por motivos pessoais, não tendo
contribuição significativa de uma organização formal (13,3%) e, desde o inı́cio, feitos como
software livre (58,6%). Uma parcela considerável de projetos (27,7%) teve como base um
outro projeto de software.
Perfil do usuário - usuários técnicos são os principais usuários dos softwares, a começar pelo
lı́der do projeto (75,1%) e a comunidade de software livre (62,2%), seguidos por técnicos e
estudantes de computação. Usuários não técnicos figuram com 37,2% de participação.
Idade do projeto - a faixa etária dos projetos se concentra entre 2 e 5 anos (39,9%). A minoria de
projetos com menos de um ano (14,6%) reflete o critério do levantamento, escolhendo projetos
estáveis ou maduros.
Tamanho da equipe - equipes de desenvolvimento com menos de cinco membros predominam
(74%). Projetos de dimensões maiores são responsáveis pelas equipes mais numerosas.
Modelo de liderança - encontram-se projetos cuja responsabilidade é de uma única pessoa
(35,2%) e daqueles em que se observa a presença de uma organização hierárquica (57%), com
delegação, formal ou informal, de responsáveis por um lı́der (40,3%) ou comitê (16,8%). Poucos projetos (2,5%) indicaram a ausência de uma forma de organização, sugerindo um forte
consenso entre os participantes de que alguma estrutura de liderança precisa de fato existir.
5° WSL / 5° FISL
Aspectos da equipe - a maioria dos membros da equipe se conhece apenas através da Internet
(62,2%), com uma pequena parcela (11%) desenvolvendo de forma convencional (localmente).
Observa-se também que muitos dos desenvolvedores (40,1%) executam mais de uma tarefa no
projeto e que 55,5% dos desenvolvedores possuem mais de cinco anos de experiência.
Requisitos - a existência de precedentes nos projetos de software livre, constatada em motivação,
é um facilitador de requisitos, tendo 52,8% dos projetos afirmado a replicação de softwares já
existentes (35,6%) ou se basear em especificações e padrões públicos (32,2%). Além disso,
destacam-se o grande esforço na definição das funcionalidades do software (42,8%) e a independência da equipe quanto a esses requisitos, sem contribuições significativas dos usuários
(40,3%).
Usabilidade - notável a baixa ênfase em engenharia de usabilidade: poucos projetos dedicam-se
a boas interfaces usuário-computador. Uma pequena parcela realiza prototipação (27,7%) e
estudos sobre interfaces (6,6%), com uma fraca polı́tica para controlar as alterações nas mesmas (sem necessidade de aprovação de mudanças na interface em 11,8% ou equipes especı́ficas
para este aspecto do software em 7,9%).
Documentação - muitos projetos afirmam despender um grande esforço na geração de
documentação, seja ao nı́vel de requisitos (69,6%), de projeto (30,1%) e para usuários finais
(77,6%). Praticamente toda documentação é gerada inteiramente pela equipe do projeto, com
apenas 11,8% dela sendo produzida por grupos externos. O ı́ndice relativamente baixo de
documentação é justificado pela disponibilidade do código-livre e a possibilidade de extrair
dele, seja pelos comentários ou utilização de ferramentas especializadas, os dados do projeto.
Garantia de qualidade - os softwares são testados apuradamente antes de seu lançamento
(55,7%). Diferente do senso comum, não são realizadas muitas atividades de garantia de qualidade ao longo do desenvolvimento: executar testes periódicos, possuir um plano de testes
(9,9%), um processo de revisão (22,9%) ou regras para integração de alterações no código
(15,0%). A disponibilização do código publicamente, por meio de releases alpha, beta e release candidates, visando a execução de testes pelo usuário final, é a principal atividade executada
para garantir qualidade (27,0%).
Ferramentas - uso intenso de gerenciamento de configuração (73,2%) e meios de comunicação
simples, como listas de discussão e sites Web (ambas 66,9%) são fato na maioria dos projetos.
Serviços de hospedagem, como sourceforge.net e gnu.org, também são representativos, sendo
utilizados por 57% dos projetos. Outras ferramentas, como FAQs, gerenciadores de erro (como
o Bugzilla) e Internet Relay Chat (IRC) são usufruı́dos por mais de 22% dos projetos. O baixo
nı́vel de utilização de ferramentas mais especializadas (gerenciadores de erro, editores colaborativos como wikis e sistemas de comunicação de tempo real) provavelmente é conseqüência da
existência de equipes de desenvolvimentos pequenas, não justificando o esforço em mantê-las.
4. Análise dos resultados
Uma quantificação mais geral dos dados obtidos em relação à engenharia de software foi obtida
pela criação de um ı́ndice denominado “Índice de Engenharia de Software”. Ele é calculado a
partir de uma lista de alternativas, obtidas do questionário, consideradas relevantes para um bom
processo de engenharia. A cada item dessa lista foi associado um peso, variando de 1 (esforço
desprezı́vel) a 5 (grande esforço), calculado com base em um levantamento simples com dois
especialistas. De forma semelhante, foi criado um ı́ndice para descrever o uso de ferramentas de
engenharia de software.
Analisando a relação entre o esforço despendido nas atividades de engenharia de software
e uso das ferramentas (por meio do “Índice de Engenharia de Software”) em relação ao tamanho dos softwares (figura 1), a concentração nos valores médios para o ı́ndice de engenharia de
software sugere um processo comum entre boa parte dos projetos de software livre, mas que não
envolve todas as atividades abordadas no levantamento.
209
210
5° WSL / 5° FISL
Figura 1: Gráfico scatter relacionando o ı́ndice de engenharia de software com o número
de linhas de código de cada projeto. Fonte: (Reis, 2003, p. 130).
Analisando o ı́ndice de engenharia de software e o tamanho e idade das equipes (figura 2),
verifica-se que a execução de atividades de engenharia de software está relacionada à dimensão
da equipe, mas não ao tempo de existência do projeto: projetos com mais integrantes realizam
mais atividades de engenharia de software. Não parece existir uma relação entre a maturidade
dos projetos e utilização de novas atividades, como seria o esperado em processos de software
tradicionais.
Figura 2: Gráfico representando a relação entre o ı́ndice de engenharia de software, o
tamanho da equipe e a idade do projeto. Fonte: (Reis, 2003, p. 131)
Define-se, então, um ciclo de vida para software livre, cada projeto instanciando-o sob
influência de sua cultura interna, histórico e objetivos. O ciclo é composto por quatro fases:
criação, lançamento público, crescimento e organização, e maturidade. As fases mais importantes
são as que procedem ao lançamento público: a partir desse momento, o projeto entra em processo
de evolução contı́nua.
5. Conclusão
O levantamento realizado permitiu visualizar interessantes caracterı́sticas do processo de software
livre, algumas inclusive fugindo ao senso comum, tal como a relativamente baixa ocorrência de
atividades de garantia de qualidade. Isso contrapõe o fato de softwares livres apresentarem
Uma justificativa são os aspectos humanos que existem nos projetos de software livre: a
forte interação usuário-desenvolvedor, o trabalho auto-gratificante. No mesmo caso das atividades
de teste, provavelmente esses mecanismos sociais e psicológicos têm impacto significativo na
qualidade do software. Conforme exemplificado por D. J. Bernstein: “Reliability means never
having to say you’re sorry”.
Os projetos livres oferecem uma chance de cooperar com pessoas com quem não se teria
contato normalmente, trabalhando para um objetivo prático e com resultados concretos. Essa é
caracterı́stica chave de todo processo de software livre.
Referências
Reis, C. R. (2003). Caracterização de um processo de software para projetos de software livre.
Dissertação de Mestrado, Universidade de São Paulo, São Carlos - SP.
5° WSL / 5° FISL
Integração dos Ambientes Livres WEKA e ImageJ na
Construção de Interfaces Guiadas por Sinais Visuais
Hemerson Pistori1 , Mauro Conti Pereira1
1 Centro
de Ciência Exatas e Tecnológicas – Universidade Católica Dom Bosco
79117-900 Campo Grande, MS, Brasil
Abstract. WEKA and ImageJ are free-softwares, not well-known in Brazil, but that offer a great variety of resources for, respectivelly, machine learning and digital image
processing algorithms implementations. The present work, besides presenting these
packages, describes how they have been integrated to create two prototypes of systems
with a humam-computer interface based on visual-input. Two differents visual signs
were used: eyes-gaze and hand-gestures, however, the proposed soluction may be generalized to any system with input captured from webcams.
Resumo. Os pacotes livre WEKA e ImageJ, ainda pouco conhecidos no Brasil, oferecem uma grande variedade de recursos para a implementaç ão de algoritmos de aprendizagem de máquina e algoritmos de processamento digital de imagens, respectivamente. Além de apresentar esses pacotes, este trabalho descreve como os pacotes
foram utilizados, de forma integrada, na criaç ão de dois protótipos de sistemas com
interface guiada por sinais visuais. Dois tipos de sinuais visuais foram utilizados, um
relacionado com a direção do olhar e o outro com gestos realizados através das mãos.
A solução proposta pode ser generalizada para qualquer tipo de sistema em que se
pretende utilizar imagens capturadas através de uma webcam, na interação homemmáquina.
1. Introdução
O baixo custo dos dispositivos de captura de imagens, juntamente com o aumento significativo na
capacidade de processamento dos computadores pessoais, abrem espaço para o desenvolvimento
de novos tipos de interfaces homem-máquina. A substituição dos tradicionais teclados e mouses
por sinais visuais, a serem apresentados ao computador através de uma filmadora digital, oferece
uma variada gama de aplicações que podem viabilizar e facilitar a utilização de computadores
por segmentos da sociedade que apresentam determinadas deficiências fı́sicas. Editores de texto e
navegadores para Internet acionados através de movimentos do globo ocular, por exemplo, poderiam ser utilizados por pessoas tetraplégicas. Surdos também poderiam se beneficiar deste tipo de
sistema, com a introdução de programas de computador capazes de interpretar lı́nguas de sinais.
Stiefelhagen [Stiefelhagen et al., 1997] relata ter obtido uma precisão entre 1.3 e 1.9
graus em um sistema que permite o controle do ponteiro do mouse através do olhar. Gee e Cipolla [Gee and Cipolla, 1994], descrevem um sistema que infere a direção do olhar a partir da
reconstituição de um modelo simplificado da cabeça, a partir da imagem projetada. Neste modelo,
busca-se valorizar a posição relativa dos olhos, boca e nariz, que, segundo os autores, são atributos
que variam pouco em relação a diferentes sujeitos. Wang e Sung [Wang and Sung, 2001] modelam
a direção do olhar como sendo a direção da normal ao plano de suporte de cada ı́ris. Aproximando
211
212
5° WSL / 5° FISL
a forma da ı́ris através de circunferências e assumindo raios, distâncias focais e fatores de escala
conhecidos, é possı́vel estimar a normal em questão a partir da projeção dos cı́rculos.
Outro elemento visual utilizado na interface homem-máquina é a mão. Além de sua importância nas lı́nguas de sinais para surdos, sistemas para rastreamento (tracking) das mãos humanas possuem aplicações que incluem jogos controlados por movimentos de mão, aparelhos
de televisão acionados por sinais manuais [Freeman et al., 1996] e dispositivos que substituem o
mouse na interação com computadores.
Neste trabalho, mostraremos como alguns pacotes livres existentes puderam ser integrados
na criação de dois protótipos de sistemas guiados por sinais visuais. Todos os pacotes utilizados
são escritos em Java, o que facilita a portabilidade das soluç ões para novas plataformas. As novas
classes que precisaram ser criadas para permitir a integração dos pacotes e o controle de webcams,
a partir de um programa em Java, estão disponı́veis na Internet 1 . Na próxima seção, descreveremos cada um dos pacotes livres utilizados no projeto. Na seção 3, apresentaremos a arquitetura de
um sistema guiado por sinais visuais, bem como os problemas e as soluç ões encontradas, para que
os pacotes existentes pudessem ser utilizados, em conjunto, na construção desse tipo de sistema.
Os dois protótipos desenvolvidos e as conclusões são apresentadas nas duas últimas seções.
2. Descrição dos Pacotes Utilizados
Para implementar e testar técnicas de visão computacional e de processamento digital de imagens,
utilizamos o pacote ImageJ 2 , que é uma versão multiplataforma, ainda em desenvolvimento, do
software NIH Image, para Macintosh. Entre os recursos oferecidos pelo pacote destacamos a disponibilidade, com programas-fonte abertos, de diversos algoritmos para: manipulaç ão dos mais
variados formatos de arquivo de imagens, detecção de bordas, melhoria de imagens, cálculos diversos (áreas, médias, centróides) e operações morfológicas. Esse software disponibiliza também um
ambiente gráfico que simplifica a utilização de tais recursos, além de permitir a extensão através
de plugins escritos em Java. Um outro fator importante para a sua escolha é a existência de uma
grande comunidade de programadores trabalhando em seu desenvolvimento, com novos plugins
sendo disponibilizados freqüentemente. Um desses plugins, o HoughCircles, foi desenvolvido
pelo nosso grupo, durante a execução deste projeto, e está disponı́vel na página do ImageJ.
O segundo pacote utilizado neste projeto foi o WEKA3 (Waikato Environment for Knowledge Analysis) [Witten and Frank, 2000], também escrito em Java e com programas-fonte abertos. O WEKA é um ambiente bastante utilizado em pesquisas na área de aprendizagem de
máquina, pois oferece diversos componentes que facilitam a implementação de classificadores
e agrupadores (clustering tools). Além disto, esse ambiente permite que novos algoritmos sejam
comparados a outros algoritmos já consolidados na área de aprendizagem, como o C4.5, o Backpropagation, o KNN e o naiveBayes, entre outros. Podemos com esse pacote obter facilmente
resultados estatı́sticos comparativos da execução simultânea de diversos programas de aprendizagem em domı́nios variados, tais como o reconhecimento de caracteres e diagn óstico médico.
Por fim, utilizamos o pacote Java Media Framework 4 para captura de sinais temporais
em tempo real. Este pacote permite que programas em Java possam acessar, por exemplo, imagens capturadas através de uma webcam acoplada a um computador pessoal. O software abstrai
detalhes das arquiteturas e interfaces de diferentes dispositivos de captura de imagem, facilitando
assim a portabilidade dos aplicativos.
1
http://www.ec.ucdb.br/ pistori/projetos/sigus/index.html
http://rsb.info.nih.gov/ij/
3
http://www.cs.waikato.ac.nz/ ml/weka/
4
http://java.sun.com/products/java-media/jmf/
2
5° WSL / 5° FISL
213
Teclado/Mouse
WebCam
JMF
Conversor
J−I
ImageJ
Conversor
I−W
Weka
Filtros
Monitor
AdapTree
Figura 1: Sistema guiado por sinais visuais
3. Integração dos Pacotes
A figura 1 apresenta, utilizando uma notação gráfica similar à de um diagrama de fluxo de dados,
a arquitetura básica de um sistema guiado por sinais visuais e aprendizagem. As linhas pontilhadas resumem o fluxo de informação relacionado com o treinamento do sistema, que acontece
da seguinte forma: uma imagem do sinal (e.g. uma mão humana realizando o sinal manual para
a letra p) a ser aprendido é capturado através de um webcam, com auxı́lio do JMF, juntamente
com uma classificação para o sinal, que é fornecida através do teclado ou mouse (e.g. digitação
da letra p). A imagem é transmitida, após ser devidamente convertida (Conversor J-I), para o
módulo de processamento digital de sinais (ImageJ). Nesse módulo são realizadas transformações
na imagem que podem envolver filtros adicionais (Filtros), indisponı́veis no pacote ImageJ. O resultado dessa transformação é convertido e repassado, juntamente com a classificação do sinal,
para o módulo de aprendizagem (Weka), que aciona o algoritmo de aprendizagem, neste caso, o
AdapTree-E [Pistori, 2003], baseado em tecnologia adaptativa [Neto, 2001].
Depois que os sinais são aprendidos, o sistema entra no modo de funcionamento representado pelas linhas cheias da figura 1. Nesse modo, a entrada consiste apenas das imagens capturadas
pela webcam (sem as informações de treinamento). As imagens são processadas através dos mesmos filtros utilizados no treinamento e as informações resultantes são passadas para o módulo de
aprendizagem. O módulo de aprendizagem deve agora oferecer uma resposta à entrada, com base
no modelo abstraı́do a partir dos exemplos fornecidos anteriormente. Esta resposta é apresentada
ao usuário através de algum dispositivo de saı́da, como por exemplo, o monitor do computador.
Nosso trabalho incluiu o desenvolvimento dos módulo de conversão J-I (JMF para ImageJ) e I-W (ImageJ para Weka), além é claro, da implementação do mecanismo de aprendizagem,
AdapTree-E, e de filtros especı́ficos para as duas aplicações. O resultado é um grupo de classes, escritas em Java, que podem ser especializadas ou modificadas na implementaç ão de outros
sistemas com caracterı́sticas semelhantes.
4. Protótipos Implementados
Para realizar alguns dos nossos experimentos com interfaces baseadas na direção do olhar, implementamos um simples jogo da velha. Existem apenas nove regi ões de interesse para o usuário
nesse jogo: as posições do tabuleiro onde podemos marcar os cı́rculos ou as cruzes. Fazendo
com que a apresentação visual do tabuleiro ocupe grande parte do monitor, conseguimos relaxar o
grau de precisão na detecção da direção do olhar. Além disto, é bastante natural a transposição da
interface por mouse para a interface pelo olhar.
214
5° WSL / 5° FISL
Inicialmente, existe um perı́odo de aprendizagem, em que usuário deve olhar para cada
uma das nove regiões do tabuleiro. A captura de imagens de treinamento é iniciada e finalizada
clicando-se o mouse. Depois que uma quantidade pré-definida de exemplos é capturada, o sistema
infere uma primeira árvore de decisão, e o usuário pode começar a jogar “com o olhar”. O módulo
de aprendizagem não trabalha diretamente sobre a imagem obtida, mas sobre um conjunto de
parâmetros dela extraı́dos pelo módulo de processamento digital de imagens. Uma descrição mais
detalhada sobre as técnicas utilizadas pode ser encontrada em [Pistori, 2003].
Nós implementamos também um protótipo de um editor para sı́mbolos alfabéticos da LIBRAS. Primeiramente, ocorre a fase de treinamento, quando o usuário deve executar os sinais
manuais, com uma das mãos, e utilizar a outra para digitar a letra correspondente. Diversas imagens da mão são capturadas, até que uma tecla qualquer seja pressionada. Este procedimento é
repetido, diversas vezes, para todas as letras desejadas: normalmente, quanto mais exemplos forem
colhidos na fase de treinamento, maior será a precisão obtida na fase de reconhecimento. Quando
uma tecla especial, reservada, é pressionada, o sistema induz a árvore de decisão adaptativa inicial,
e o usuário pode então iniciar a edição do texto utilizando sinais manuais.
5. Conclusões
Apresentamos neste artigo um conjunto de pacotes e bibliotecas, alguns desenvolvidos por n ós,
outros disponı́veis gratuitamente na Internet, que podem ser utilizados na implementação de sistemas guiados por sinais visuais. A integração dos pacotes pré-existentes não foi uma tarefa trivial,
uma vez que, além de complexos, estes pacotes não foram projetados para trabalhar em conjunto.
Um objetivo para o futuro é a construção de um ferramenta com interface gráfica que permita
mais facilmente a utilização destes pacotes e bibliotecas, que hoje é feita basicamente através da
alteração de programas-fonte escritos em Java. Também seria interessante buscar uma alternativa
ao pacote JMF, que embora gratuito, não é livre (os programas-fonte não estão disponı́veis).
Referências
Freeman, W. T., Tanaka, K., Ohta, J., and Kyuma, K. (1996). Computer vision for computer
games. In 2nd International Conference on Automatic Face and Gesture Recognition, pages
100–105, Killington, VT, USA.
Gee, A. H. and Cipolla, R. (1994). Determining the gaze of face in images. Technical Report
CUED/F-INFENG/TR 174, Cambridge University, Trumpington Street, Cambridge CB2 1PZ,
England.
Neto, J. J. (2001). Adaptative rule-driven devices - general formulation anda case study. In
CIAA’2001 Sixth International Conference on Implementation and Application of Automata,
pages 234–250, Pretoria, South Africa.
Pistori, H. (2003). Tecnologia Adaptativa em Engenhara de Computaç ão: Estado da Arte e
Aplicações. PhD thesis, Universidade de São Paulo, São Paulo, Brasil.
Stiefelhagen, R., Yang, J., and Waibel, A. (1997). Tracking eyes and monitoring eye gaze. Proceedings of the Workshop on Perceptual User Interfaces (PUI’97)., pages 98–100.
Wang, J. G. and Sung, E. (2001). Gaze determination via images of irises. Image and Vision
Computing, 19(12):891–911.
Witten, I. H. and Frank, E. (2000). Data Mining: Practical Machine Learning Tools and Techniques with Java Implementations. Morgan Kaufmann.

2004 - Wiki-SL - Software Livre Brasil

Transcrição

Documentos relacionados

programação - Software Livre Brasil

IV Workshop sobre Software Livre – WSL 2003 Porto - Wiki-SL

o problema mente-corpo através das abordagens psico

Prática certificada

Empanada de Frango com Sultanas Ingredientes p/ a massa

World Surf League 2015 Anti

Baixar Material Teórico

Expandindo uma Arquitetura para HPC em Nuvens

Detecção de streamers em redes BitTorrent

migração de aplicações de escritório para o contexto do software

Teorema de Ptolomeu

Sincronizaç ˜ao de Arquivos entre Nuvens de