BOCA: um sistema de apoio a competicoes de programacao

Cassio P. de Campos1 , Carlos E. Ferreira2

1

Pontifcia Universidade Cat lica de S o Paulo o a Centro das Ci ncia Exatas e Tecnologia e Rua Marqu s de Paranagu , 111 e a Consolacao - S o Paulo - SP - Brasil a Universidade de S o Paulo a Instituto de Matem tica e Estatstica a Rua do Mat o, 1010 a Cidade Universit ria - S o Paulo - SP - Brasil a a
cassio@pucsp.br, cef@ime.usp.br
2

Abstract. In this article we describe BOCA, a software for supporting programming contests developed to be used in the Maratona de Programacao of the Brazilian Computing Society. The system can also be used for supporting disciplines that make evaluation of student assignments during the classes. Resumo. Neste artigo apresentamos o BOCA, um sistema de apoio a competicoes de programacao desenvolvido para ser usado na Maratona de Programacao da Sociedade Brasileira de Computacao. O sistema pode ser usado tamb m no apoio a disciplinas em que se faca uso de submiss o e e a correcao de trabalhos durante as aulas.

1. Introducao
Competicoes de programacao s o uma excelente oportunidade para desenvolver nos alu a nos diversas habilidades que ser o extremamente uteis no seu crescimento prossional. a Nelas, os alunos aprendem de forma divertida conceitos importantes sobre estruturas de dados, algoritmos e desenvolvimento de software enquanto, ao mesmo tempo, aprendem a trabalhar em grupo e sob press o. Dois exemplos de competicoes deste tipo s o o Cona a curso de Programacao da ACM (o ICPC: ACM International Collegiate Programming Contest [1]) e as Olimpadas Internacionais de Inform tica (IOI) [5]. a O ICPC da ACM destina-se a alunos de instituicoes de ensino superior e em 2004 a realizou sua 28 nal mundial em Praga, Rep blica Tcheca. As nais mundiais da 16a u IOI ser o em Atenas, Gr cia. a e O sucesso destas competicoes tem sido extraordin rio. No ano de 2003 competi a ram em regionais para o ICPC mais de 3000 times (cerca de 1400 instituicoes de ensino superior) de 75 pases de todo o mundo. Destes, apenas 72 times t m o privil gio de e e competir nas nais mundiais pelo ttulo de melhor equipe de programacao do planeta. No ` ultimo ano este ttulo pertenceu a Universidade de Vars via, Pol nia, e ap s as ultimas o o o ` nais o ttulo passou a St. Petersburg University of Information Technology, Mechanics & Optics, R ssia. u No Brasil temos vericado interesse semelhante nestas competicoes. A Olim pada Brasileira de Inform tica [7] realizou em 2003 sua quinta edicao e contou com a a participacao de mais de 1300 alunos na selecao dos 4 brasileiros que compuseram o time

 nas nais mundiais do IOI, nos Estados Unidos. A Olimpada e realizada pela Sociedade Brasileira de Computacao, sob coordenacao do Prof. Ricardo de Oliveira Anido, do IC Unicamp, e com apoio do CNPq. Desde 1996 v m ocorrendo no Brasil competicoes de programacao seletivas para e as nais mundiais do ICPC. Naquele ano, a competicao foi organizada pelos Profs. Clau dionor Coelho e Ricardo Dahab (IC-Unicamp, que desde ent o tem sido o diretor da a regional sulamericana da competicao) e 13 times competiram em Belo Horizonte pelo direito de representar o pas nas nais mundiais do concurso, que foi ganho pelo time do IC da Unicamp. O time do IC Unicamp disputou as nais mundiais de 1997 em San Jose, California. No ano 2000, a competicao (chamada no Brasil de Maratona de Programacao [6]) passou a ser realizada pela Sociedade Brasileira de Computacao e coordenada por Carlos E. Ferreira, do IME-USP. Na tabela abaixo mostramos a evolucao da participacao de times e escolas brasileiras na Maratona de Programacao desde 1996. Ano Escolas Times 1996 13 13 1997 18 18 1998 21 21 1999 22 26 2000 26 40 2001 39 68 2002 61 114 2003 60 119 Como pode ser vericado na tabela acima, a cada ano o interesse cresce, e a competicao envolve mais e mais escolas e estudantes. Em muitas escolas h iniciati a vas de preparar equipes de alunos para a competicao atrav s de disciplinas optativas, e onde os alunos aprendem t cnicas de programacao como divis o e conquista, algoritmos e a gulosos, programacao din mica, etc. O aprendizado e baseado na solucao de desaos a que zeram parte de competicoes anteriores. Neste sentido, podemos inclusive encon ` trar livros abordando diretamente esse assunto [12]. A id ia deste trabalho e colocar a e disposicao de alunos e professores o sistema de apoio que vem sendo utilizado na Ma ratona de Programacao desde o ano de 2002 com bom desempenho. O sistema est a a ` disposicao dos interessados no site do BOCA [3]. Este trabalho est organizado da seguinte forma. Na pr xima secao descrevemos a o o ambiente de programacao disponvel para os alunos na Maratona de Programacao. Na secao 3 descrevemos as principais caractersticas do BOCA. O trabalho encerra com al gumas conclus es. o

2. Ambiente de Programacao
` Durante a realizacao de uma competicao ocial, temos algo semelhante a realizacao de uma prova. Os times n o podem ter acesso a nenhum material externo ao seu computador a ` (n o podem ter acesso a internet e nem aos arquivos dos outros times). a Na competicao, cada time tem acesso a um unico computador, onde devem estar presentes ferramentas de desenvolvimento de software, como compiladores, editores de texto, ambientes integrados de desenvolvimento, depuradores, etc. E necess rio que exista um mecanismo para a entrega dos programas em tempo a real, j que a correcao e resposta e feita durante a prova e a informacao sobre o acerto ou a erro deve ser passada assim que possvel para o time.

 Uma maneira de controlar o acesso dos times, disponibilizando apenas o que e necess rio, e atrav s de um sistema criado exclusivamente para tal nalidade. Assim a e nos ultimos dois anos a Maratona de Programacao vem usando uma distribuicao Linux (denominada Maratona Linux) projetada para atender suas necessidades. A distribuicao Maratona Linux foi inicialmente criada com base na famosa ` distribuicao Red Hat Linux [11], mas sua id ia n o est presa a mesma. e a a O Maratona Linux foi projetada para ser uma distribuicao de instalacao muito f cil, e assim seu uso n o necessitaria da presenca de uma especialista em administracao a a de sistemas Linux. Durante uma competicao normalmente s o utilizados os laborat rios a o onde outras atividades s o realizadas antes e logo ap s o t rmino do evento. No Maratona a o e Linux apenas um computador e instalado desde as razes( aquele que ser o servidor), e a perdendo-se o conte do do disco rgido. Nos computadores que s o utilizados pelos times u a apenas um arquivo precisa ser copiado, sem a necessidade de apagar nada. Dessa forma, mesmo que no mesmo dia o laborat rio precise ser utilizado por outros, basta reiniciar os o computadores que o sistema antigo estar funcionando. a Durante a instalacao do servidor, o sistema encarrega-se de criar as conguracoes para todos os demais computadores que ser o usados na competicao. Al m de a e conguracoes dependentes do hardware das m quinas, s o criadas regras para bloquear a a acessos ilcitos. Todos os dados vol teis do computador de cada time (arquivos de conguracao, a arquivos de trabalho do time, etc) cam armazenados no servidor. Isso possibilita tamb m e uma f cil troca de computador caso haja problemas. Somente o servidor n o pode ser a a trocado de maneira trivial. A instalacao e feita de forma dirigida, onde o respons vel precisa apenas respon a der simples quest es. Ao nal, j se tem um sistema pronto para iniciar uma competicao, o a que e gerenciada pelo BOCA (includo tamb m no Maratona Linux). e

3. Sistema BOCA

Figura 1: Interface do time para enviar submissoes.

Na competicao, a correcao dos programas enviados pelos times e feito de forma online, e o resultado deve ser transmitido ao time o mais breve possvel. Temos aqui uma diferenca fundamental com relacao a comparacao a uma prova tradicional, feita na secao ` anterior. Imagine que, durante uma prova tradicional, os alunos entregam suas quest es o separadamente assim que as terminam, e o professor deve prontamente corrigi-las, informar ao aluno se a mesma est certa ou errada, e caso esteja errada o aluno tem a possibia lidade de tentar consert -la e entreg -la novamente, ainda durante o tempo de prova, mas a a

 sem saber especicadamente o que estava errado na quest o. Esse e basicamente o mea canismo das competicoes de programacao citadas. Assim, podemos dizer que a principal func o do BOCA e executar esse servico durante uma competicao. Na gura 1 podemos a ver a interface disponvel para o aluno enviar suas solucoes as quest es propostas pelos ` o juzes. Continuando a analogia, as d vidas que os alunos t m com relacao a prova u e ` tamb m podem ser enviadas pelo sistema, sem a necessidade de car chamando o proe ` u fessor. O professor pode responder a d vida de forma individual ou coletiva, sempre atrav s do sistema. Assim o BOCA internamente tem disponvel um esquema similar a e um chat/f rum de discuss es, mas que funciona apenas de forma dirigida e controlada. o o ` Na gura 2 podemos ver a interface disponvel para um juiz (ou professor) responder as perguntas feitas por alunos.

Figura 2: Interface do juiz para responder a perguntas feitas pelos times.

Desenvolvido com uma interface web, o BOCA e um sistema de entrega de exerccios, com autenticacao, controle de tempo e disponibilizacao de resultados, tudo em tempo real. Toda a programacao do sistema foi feita na linguagem PHP [8], e assim e port vel para todo sistema onde tal linguagem esteja disponvel. Para armazenamento dos a dados e controle de concorr ncia utilizamos o banco de dados relacional PostgreSQL [9]. e Vale ressaltar neste ponto que o sistema e exvel para acomodar trocas de tecnologia. Ambas as tecnologias s o livres e n o trazem custos adicionais. E necess rio ainda um a a a servidor de p ginas onde o sistema estar incubado. O Apache [2] (tamb m livre) e uma a a e boa escolha para tal.

Figura 3: Interface para autenticacao no sistema.

Podemos dividir o BOCA em cinco partes, de acordo com a especicidade de cada usu rio: time, juiz, administrador, staff e placar. Cada uma dessas partes tem a interface pr pria e diferenciada, de acordo com as necessidades e responsabilidades de o

cada perl. Note que n o existem diferencas entre os computadores que s o usados pelos a a juzes, administradores, times, etc, a n o ser pelo m que e dado em cada caso. Assim, o a Maratona Linux pode ser usado em todos os computadores.

3.1. Time Os times possuem uma interface simples e direta, onde e possvel enviar os programas para correcao, alterar informacoes pessoais, submeter d vidas aos juzes e vericar o u placar online da competicao. Al m disto, durante a competicao, os times podem solicitar e atrav s do sistema a impress o de seus c digos-fonte e ajuda do pessoal de staff. O e a o ambiente do time (descrito nesta secao) e a parte do placar (descrita na secao 3.5) s o as a interfaces mais simples do sistema.

Figura 4: Time alterando seus dados cadastrais e senha de acesso.

No momento de submeter seu arquivo-fonte (tipicamente chamado de uma run), o time pode escolher a linguagem que o programou e para qual problema ele e destinado. Atrav s do ambiente de janelas do navegador, o time escolhe o arquivo do disco que deseja e submeter e o envia para correcao dos juzes. Na mesma janela de submiss es, o time pode o vericar o andamento das correcao de submiss es passadas feitas por ele, como mostrado o na gura 1. No item envio de perguntas (ou clarications), o time pode escolher sobre qual quest o da prova deseja fazer a pergunta (ou se a mesma e geral) e digitar diretamente a a d vida. Nesta mesma janela, o time acompanha as d vidas feitas anteriormente por ele u u e tamb m d vidas de outras equipes que, por decis o dos juzes, foram escolhidas para e u a serem divulgadas entre todos. No item score, o time pode acompanhar em tempo real o placar da competicao, podendo at mesmo us -lo como decis o de que rumo tomar na continuacao da sua prova. e a a Equipes experientes costumam usar o placar como indicativo de qual a melhor ordem para atacar as pr ximas quest es. o o Resta ainda a janela de tasks, onde o time envia seus arquivos para impress o a ou chama por assist ncia do pessoal de staff. Em ambos os casos o time e atendido e diretamente no local onde est fazendo a prova, onde uma pessoa da organizacao leva-lhe a a impress o ou oferece-lhe ajuda. a

3.2. Juiz A interface do juiz permite ao mesmo responder perguntas e d vidas de forma individual u ou coletiva, al m de permitir ao juiz criar perguntas globais para serem respondidas a e todos. O juiz tem a possibilidade de analisar e corrigir os programas enviados pelos

times, denindo no sistema qual a resposta que o time receber para sua tentativa. As a repostas possveis podem ser conguradas para cada competicao. Nas competicoes citadas no incio do texto, utilizamos respostas como certo, sada errada, sada mal formatada, erro de compilacao, erro em tempo de execucao, etc. Nada al m desse e tipo de informacao e transmitido ao time, que dever achar seu pr prio erro no caso de a o uma resposta negativa. O juiz pode tamb m acompanhar o placar online da competicao e no seu pr prio computador ou alterar seus dados, como nome, liacao, senha, etc. o

Figura 5: Juiz respondendo uma submissao de um time.

No item runs, o juiz acompanha quais as submiss es foram feitas pelos times e o que ainda n o foram completamente processadas. Aparecem nesta janela as runs que a est o sendo julgadas por outros juzes, pelo pr prio, e ainda aquelas que n o comecaram a o a a ser julgadas. ` A opcao clarications e muito semelhante a opcao runs, por m existe ainda a e possibilidade do juiz incluir uma d vida pr pria para ser respondida por ele mesmo ou u o por outro juiz. O objetivo deste tipo de procedimento e divulgar, de forma global, algum detalhe dos problemas e/ou enunciados que n o cou claro ap s a confeccao do caderno a o de quest es da prova. o ` Para vericar tudo que foi feito por ele, o juiz tem ainda a disposicao o item history, onde pode acompanhar todas as respostas de perguntas passadas e todas as runs que foram julgadas por ele. 3.3. Administrador

Figura 6: Administrador tem controle sobre a conguracao competicao, como a inclusao de problemas.

inicial

da

A interface do administrador da competicao e a mais sosticada. Atrav s dessa e interface devem ser conguradas as informacoes sobre a competicao, sobre as linguagens

 de programacao que ser o permitidas e as quest es da prova. E atrav s dessa interface que a o e e feita a inclus o de times, juzes, placares, staff e administradores, onde a prova e dea nida, iniciada e interrompida, e onde se pode tamb m ter acesso aos registros de tudo que e est ocorrendo no sistema. S o permitidas alteracoes em diversos dados da competicoes a a (inclusive nas submiss es, programas, perguntas, controle de acesso ao sistema). o

Figura 7: Administrador pode fazer o acompanhamento completo competicao, como a vericacao das submissoes dos times.

da

O usu rio administrador possui diversas janelas diferentes para controlar o sisa tema. A seguir, descrevemos suas funcoes principais: Runs: nesta pasta est o apresentadas na tabela todas as submiss es, com a o informacoes sobre elas. O administrador pode retirar uma submiss o de um juiz, a apagar uma submiss o, julg -la ou reabri-la ap s j ter sido corrigida. Clicando a a o a sobre uma submiss o e aberta uma tela para julgamento da mesma (note que o a administrador pode at julgar uma run, mas isso deve ser feito excepcionalmente e para corrigir erros de julgamento). Score: Nesta pasta o administrador pode acompanhar o andamento do placar da competicao. ` Clarications: Esta opcao e semelhante a Runs. O administrador pode apagar, reabrir, retirar de um juiz ou responder a uma d vida. Ao clicar sobre o n mero u u de uma pergunta, uma tela para respostas estar disponvel. Nesta janela o ada ministrador e capaz de responder uma d vida postada. Note novamente que esse u procedimento deve ser feito apenas em casos excepcionais. Users: essa janela tem duas funcionalidades b sicas: incluir novos usu rios e a a acompanhar os usu rios logados no sistema. S o apresentados todos os usu rios a a a da competicao e um formul rio para cadastramento de novos. Clicando sobre um a usu rio pode-se alterar seus dados ou remov -lo do sistema. Tamb m e possvel a e e incluir novos usu rios atrav s de um arquivo de importacao. a e Problems: interface para cadastrar os problemas da prova. Para incluir um problema, deve-se especicar os dados do mesmo no formul rio apropriado. Pode-se a ainda remover ou alterar dados dos problemas j cadastrados. a Languages: interface para fazer o cadastramento das linguagens da competicao. Existem duas formas para tal cadastramento: importando de arquivo ou digitando os dados das linguagens. E possvel ainda nesta janela alterar os dados da lingua gens j cadastradas ou exclu-las. a Site: neste item podem ser visualizados (e alterados) os dados relativos ao site. As principais informacoes s o: nome, endereco IP, dias/hor rios da competicao, a a regras de submiss es e placares, quantidade de registros atualmente no sistema. o Nesta janela pode-se iniciar/terminar uma competicao, remover denitivamente submiss es, d vidas, tarefas do sistema e controlar globalmente o acesso dos o u usu rios. a Contest: nesta pasta podem ser vistos e/ou alterados os dados gerais da competicao ativa. Os dados principais s o nome da competicao, dias e hor rios, a a regras de placar, recebimento de respostas de submiss es e penalidades. o

 Logs: nesta pasta s o mostrados todos os registros de ocorr ncias. E possvel a e ainda alterar a ordem e fazer consultas especcas nos registros existentes. Tasks: aqui e feita a administracao das tarefas que est o sendo executadas pelo a possvel gerenciar completamente as tarefas. pessoal de staff. E Answers: nesta pasta o administrador deve congurar quais as respostas possveis que um juiz dar para uma submiss o. Apenas uma dessas respostas pr -denidas a a e poder ser enviada para o time como motivo para seu programa estar certo/errado. a Reports: nesta pasta o administrador pode gerar relat rios da competicao (como o placar nal, lista de equipes, lista de submiss es, etc) e importar ou exportar uma o competicao. Options: nesta pasta e possvel alterar os dados do usu rio administrador. a Logout: opcao para desconectar do sistema. Assim, para colocar uma competicao em funcionamento, praticamente todo o servico necess rio est ligado com a interface do administrador, que deve incluir a a problemas, respostas, linguagens, usu rios, e congurar os dados da competicao e do a site.

3.4. Staff

Figura 8: Tarefas que o pessoal de staff tem que executar.

As principais funcoes do pessoal de staff durante a prova s o: a 1. Controlar o acesso e movimentacao dos times no local da prova. 2. Imprimir arquivos solicitados pelos times e entregar a impress o aos mesmos. a 3. Entregar bal es para cada time que acerta um problema (bal es s o usados como o o a placar visualdurante as competicoes). 4. Dar assist ncia a times com problemas de hardware e/ou software. e Apesar de todos estes itens necessitarem de alguma interacao fsica, o controle sobre os pedidos de impress es, entregas de bal es e pedidos de assist ncia podem ser o o e feitos pelo sistema BOCA. Assim, o ambiente disponvel para o pessoal de staff possui interfaces para alterar seus dados, vericar o placar durante a prova, e pegar tarefas para processar. As tarefas necess rias s o basicamente aquelas descritas anteriormente (com a a o a primeira, onde o sistema n o ajuda muito). Assim, uma pessoa do staff tem as ` exceca a opcoes de pegar tarefa para fazer, marcar tarefa como feita ou ainda devolver uma tarefa para que outra pessoa do staff a faca.

Figura 9: Placar online durante a competicao.

3.5. Placar O objetivo b sico da exist ncia de um usu rio placar e poder disponibilizar pela rede a e a o resultado em tempo real da competicao para pessoas que n o est o diretamente a a envolvidas com ela. Assim, este ambiente do placar n o possvel nenhum tipo de opcao a de conguracao e/ou alteracoes no sistema. Ele e apenas para leitura dos resultados parciais da competicao por pessoas locais que n o devem ter muito acesso (como os a t cnicos das equipes), ou por pessoas localizadas fora do ambiente da prova. e 3.6. Competicoes distribudas e treinamento online Devido ao uso de interfaces web, o sistema BOCA pode ser usado para a criacao de competicoes distribudas, onde equipes podem estar espalhadas em qualquer lugar com conex o a internet. Claro que competicoes como a Maratona de Programacao ou o ICPC a ` ` da ACM n o poderiam ser feitas simplesmente dessa forma (pois todos teriam acesso a a internet), mas simulacoes e outras competicoes poderiam ser enquadradas, como as que ocorrem no famoso site da Universidade de Valladolid [13], acessado diariamente por milhares de estudantes de computacao de todo o mundo.

Figura 10: Conguracoes disponveis em um site para uma competicao dis tribuda com correcao centralizada.

Al m disso, o BOCA tem a opcao de ser usado para uma competicao com diversas e sedes (ou sites), todos trabalhando ao mesmo tempo e com correcao centralizada das submiss es e das d vidas. Isso torna vi vel uma competicao em larga escala atingindo o u a pontos extremos de um pas como o Brasil, como j podemos notar na Maratona de a

Programacao. Apenas com processamento centralizado das submiss es e d vidas o u podemos ter igualdade de condicoes para todos os participantes, independente do lugar onde os mesmos estiverem, pois tudo ser processado pelo mesmo grupo de juzes. a 3.7. Seguranca e Conabilidade Do ponto de vista de invas es, a maioria das tranfer ncias de dados s o feitas atrav s o e a e do protocolo de p ginas HTTP, e assim podemos utilizar sua vers o segura, o HTTPS. a a As demais s o feitas entre bancos de dados PostgreSQL, que tamb m aceita conex es a e o seguras com autenticacao e SSL. Al m disso, o uso de um sistema operacional adequado e e softwares de rewall (para bloqueio de conex es indesejadas) torna o ambiente do BOCA o completamente seguro para uma competicao distribuda. Para garantir o funcionamento do sistema durante toda a competicao, dependemos de diversos fatores externos e de hardware. A escolha de manter todos os dados dos times no servidor garante que, em caso de problema de hardware ou queda de forca em um computador de um time, tudo que ele tem salvo est armazenado no servidor. Assim, a mesmo que seja necess rio alocar outro computador para este time, basta que esta nova a m quina j esteja preparada para ser usada na competicao, e o time poder continuar sua a a a prova com um tempo mnimo de prejuzo. Dessa forma dois pontos de preocupacao ainda restam: os servidores e a conex o a entre servidores remotos (no caso de competicoes distribudas). Para aumentar a cona bilidade dos servidores, podemos usar m quinas com recursos de hardware redundantes, a ` e manter sempre um computador equivalente a disposicao para troca r pida se o problema a for mais grave. J com relacao a conex o, n o h muito o que fazer. O sistema BOCA e a ` a a a projetado para utilizar a conex o sempre que a mesma estiver ativa, e desistir da mesma a quando n o e possvel prosseguir. Assim, caso um servidor perca sua conex o com os a a demais, nenhum dos outros e afetado (a menos pelo fato de n o receber mais informacoes a atualizadas daquele servidor), e a competicao pode continuar normalmente, agora com a necessidade de duas equipes de juzes (uma para cada parte desconexa da rede).

4. Conclus es o
Neste trabalho apresentamos o Maratona Linux e o BOCA: sistema que vem sendo utilizado no gerenciamento de competicoes de programacao. O sucesso de olimpadas ci entcas reside em incentivar alunos dos cursos a estudar para obter bons resultados nas competicoes. O formato destes concursos de programacao vem sendo utilizado tamb m e ` em disciplinas regulares, uma vez que permite aos alunos uma resposta imediata as solucoes para os problemas por eles propostas, assim como acompanhar o desempenho de seus colegas. Esperamos que o sistema BOCA venha a ser utilizado em competicoes por todo o pas, bem como em apoio a disciplinas com tais caractersticas. Estas competicoes v m experimentando crescimento extraordin rio e despertando cada vez mais o interesse e a nos alunos de cursos de computacao do Brasil. Este interesse e bastante positivo, uma vez que motiva os alunos a estudar importantes conceitos da computacao, como estruturas de dados, an lise de algoritmos, t cnicas e linguagens de programacao, etc. a e

Refer ncias e
[1] ACM International Collegiate Programming Contest, The ACM Programming Contest Website, http://icpc.baylor.edu/icpc [2] The Apache Software Foundation, Apache HTTP Server Project, http://httpd.apache.org

[3] C. P. de Campos, BOCA Home Page, http://boca.incubadora.fapesp.br [4] E. Geschwinde, H. Schoenig, PHP and PostgreSQL Advanced Web Programming, Sams, 2002 [5] International Olympiad in Informatics, IOI Home Page, http://olympiads.win.tue.nl/ioi [6] Maratona de Programacao da SBC, Maratona Home Page, http://maratona.ime.usp.br [7] Olimpada Brasileira de Inform tica a http://olimpiada.ic.unicamp.br da SBC, OBI Home Page,

[8] The PHP Group, PHP Hypertext Processor Home Page, http://www.php.net [9] The PostgreSQL Global Development Group, PostgreSQL Database System Home Page, http://www.postgresql.org [10] D. Thomas, Professional PHP4 Programming, Wrox Press Inc, 2002 [11] Red Hat, Inc, Red Hat Home Page, http://www.redhat.com [12] S. S. Skiena, M. Revilla, Programming Challenges, Springer Verlag, 2003 [13] Universidad de Valladolid, Valladolid Programming Contest Site, http://acm.uva.es