TCC Versao Final

Software livre e sistemas de informação na Fatec Praia Grande – 1
FACULDADE DE TECNOLOGIA PRAIA GRANDE
SOFTWARE LIVRE E SISTEMAS DE

INFORMAÇÃO NA FATEC PRAIA GRANDE
AUTOR: MARIO SERGIO KIRDEIKA JUNIOR
ORIENTADOR : PROF. WAGNER ALVES
Praia Grande
2007
SOFTWARE LIVRE E SISTEMAS DE
INFORMAÇÃO NA FATEC PRAIA GRANDE
MARIO SERGIO KIRDEIKA JUNIOR
Monografia apresentada à Faculdade de

Tecnologia de Praia Grande, como parte dos requisitos
para obtenção do título de Tecnólogo em Informática com
Ênfase em Gestão de negócios.
Orientador : Prof. Wagner Alves
Praia Grande
2007
Para resolver um problema interessante, comece achando um
problema que é interessante para você.
Eric Raymond
Dedico
A minha esposa, pela compreensão do tempo dispendido

e apoio, pelo amor, carinho e paciência nos momentos
de maior tensão e necessidade de companheirismo
AGRADECIMENTOS
À Fundação GNU e a Linus Torvalds, por iniciarem um verdadeira revolução

tecnológica, através da divulgação de seu trabalho e idéias, com profundas influências sociais
e econômicas, sem as quais este trabalho perderia o sentido.
Ao Prof. Wagner Alves, pelo apoio e incentivo no assunto tratado, e pelas valiosas
orientações que guiaram este trabalho.
À Profª. Cybelle Rocha, pelo apoio e orientação na construção do trabalho.
Ao sr. Domingos Latorre, pela colaboração mútua no intenso trabalho no Centro de

Informática da faculdade.
À Profª. Sônia Budin, pelo incentivo e colaboração com material de estudo e apoio no
desenvolvimento dos sistemas.
Ao Prof. Nilson Duarte, pela compreensão do alcance do trabalho realizado, apoio e

incentivo na realização das diversas tarefas necessárias à conclusão deste trabalho.
Ao sr. Venâncio e a sra. Zilda, funcionários da biblioteca, pelo apoio e colaboração na

implantação da solução em seu ambiente de trabalho.
Aos demais colegas, pela troca constante de informações e apoio ao longo de todo o
curso.
Software livre e sistemas de informação na FATEC de Praia Grande – v
SUMÁRIO
LISTA DE FIGURAS ..............................................................................................................vii
LISTA DE TABELAS.............................................................................................................viii
RESUMO...................................................................................................................................ix
ABSTRACT................................................................................................................................x
INTRODUÇÃO........................................................................................................................11
1. SISTEMAS DE INFORMAÇÃO.........................................................................................14
1.1. Dado, informação, sistemas e T.I. ................................................................................14
1.2. Classificação..................................................................................................................15
1.3. Desenvolvimento...........................................................................................................15
1.4. O Processo Unificado....................................................................................................16
1.5. Unified modeling language...........................................................................................17
2. FERRAMENTAS PARA SISTEMAS ABERTOS..............................................................18
2.1. O software.....................................................................................................................18
2.2. Patentes de software......................................................................................................18
2.3. O software livre.............................................................................................................19
2.4. O sistema operacional Linux.........................................................................................21
2.5. Debian GNU/Linux 3.1r2..............................................................................................22
2.5.1. Conhecendo a distribuição Debian........................................................................22
2.5.2. Conhecendo o sistema operacional Debian...........................................................23
2.5.3. Instalação...............................................................................................................25
2.5.4. Conceitos e utilização básica do sistema...............................................................27
2.6. O servidor web apache..................................................................................................41
2.7. Bancos de dados............................................................................................................46
2.7.1. Gerenciador de banco de dados MySQL...............................................................46
2.7.2. Gerenciador de Bancos de Dados PostgreSQL.....................................................49
2.8. Principais linguagens de programação..........................................................................57
2.8.1. A linguagem C/C++...............................................................................................58
2.8.2. A linguagem Perl...................................................................................................60
2.8.3. A linguagem PHP..................................................................................................62
2.8.4. A linguagem Java..................................................................................................65
2.8.5. Shell Scripting.......................................................................................................67
3. SISTEMA DE GERÊNCIA DE BIBLIOTECAS KOHA....................................................70
Software livre e sistemas de informação na FATEC de Praia Grande – vi
3.1. Contexto........................................................................................................................70
3.2. Requisitos......................................................................................................................71
3.3. Arquitetura.....................................................................................................................74
3.4. Análise da aplicação......................................................................................................82
3.5. Cenários de uso típicos..................................................................................................82
3.6. Instalação do sistema Koha...........................................................................................86
3.6.3. Instalando o Koha 2.2.6.........................................................................................91
4. SISTEMA AGENDA............................................................................................................94
4.1. Introdução......................................................................................................................94
4.2. Concepção.....................................................................................................................95
4.3. Elaboração...................................................................................................................101
4.4. Construção...................................................................................................................110
4.5 Transição......................................................................................................................124
5. RELAÇÃO ENTRE SISTEMAS, ALUNOS E DOCENTES............................................128
5.1. Disponibilização de códigos e documentação.............................................................128
5.2. As disciplinas e o material livre disponível.................................................................129
CONCLUSÃO........................................................................................................................131
ANEXOS................................................................................................................................133
ANEXO A - Utilização básica do sistema Koha................................................................133
REFERÊNCIAS BIBLIOGRÁFICAS....................................................................................147
BIBLIOGRAFIA....................................................................................................................150
GLOSSÁRIO..........................................................................................................................153
Software livre e sistemas de informação na FATEC de Praia Grande – vii
LISTA DE FIGURAS
Figura 1 – Arquitetura do sistema de gerência de bibliotecas Koha.........................................75
Figura 2 – Componentes do Koha.............................................................................................76
Figura 3 – Componentes OPAC................................................................................................77
Figura 4 – Pacote INTRANET..................................................................................................77
Figura 5 – Pacote Deamons......................................................................................................78
Figura 6 – Pacote DB................................................................................................................79
Figura 7 – Esquema do banco de dados 1 de 2.........................................................................80
Figura 8 – Esquema do banco de dados 2 de 2.........................................................................81
Figura 9 – Caso de uso acessos do cliente................................................................................83
Figura 10 – Interface de pesquisa para o cliente.......................................................................83
Figura 11 – Interface de trabalho do funcionário......................................................................84
Figura 12 – Caso de uso do sistema de circulação....................................................................85
Figura 13 – Caso de uso catalogação de materiais....................................................................85
Figura 14 : Fluxo de dados entre processos para o sistema proposto.......................................99
Figura 15 - Diagrama de casos de uso....................................................................................105
Figura 16 - Diagrama de seqüência do caso de uso acessarInternet.......................................106
Figura 17 – Diagrama de seqüência do caso de uso gerenciarAluno......................................107
Figura 18 – Diagrama de seqüência do caso de uso gerenciarAcesso....................................108
Figura 19 – Modelo de domínio do Sistema Agenda..............................................................110
Figura 20 - Modelo de entidades e relacionamentos...............................................................112
Figura 21 – Diagrama de arquitetura lógica............................................................................113
Figura 22 - Diagrama de atividades programa AcessoSquid..................................................114
Figura 23 – Diagrama de classes programa AcessoSquid......................................................115
Figura 24 – Diagrama de atividades, método main(), classe AcessoSquid............................116
Figura 25 – Diagrama de atividades, método conectar_BD(), classe Persistencia.................117
Figura 26 – Diagrama de atividades método consulta_acesso(), classe Persistencia.............118
Figura 27 – Diagrama de atividades método grava_log(), classe Persistencia.......................119
Figura 28 – Diagrama de atividades método grava_acesso() classe Persistencia...................120
Figura 29 – Diagrama de atividades método verifica_usuario() classe Persistencia..............120
Figura 30 – Diagrama de atividades método incrementa_bloqueio() classe Persistencia......121
Figura 31 – Diagrama de estados do sistema, módulo AcessoAdm.......................................122
Figura 32 - Diagrama de implantação do sistema AcessoSquid e dependências....................125
Figura 33 – Diagrama de implantação do sistema AcessoAdm e dependências....................126
Software livre e sistemas de informação na FATEC de Praia Grande – viii
LISTA DE TABELAS
Tabela 1 : Respostas ao instalador do Koha.............................................................................92
Tabela 2 : Lista Ator-objetivo.................................................................................................102
Tabela 3 : Regras do domínio.................................................................................................110
Software livre e sistemas de informação na FATEC de Praia Grande – ix
RESUMO
O presente trabalho tem por objetivo relacionar as informações e códigos sobre

sistemas de informação utilizando software livre, especificamente aqueles que resolvem dois
problemas conhecidos na instituição, a informatização da biblioteca e maior controle e
flexibilidade em relação ao acesso à Internet nos laboratórios e demais áreas da faculdade. Foi
realizado estudo sobre um sistema existente para solução da questão da biblioteca e
utilizando-se dos conceitos ministrados pelo curso e informações pesquisadas desenvolveu-se
um sistema para a solução da questão dos acessos. Foi possível a publicação do material e
códigos pesquisados e desenvolvidos pela utilização de licenças livres como a GNU/GPL
tanto em ambiente da faculdade, pela sua rede interna e pela implantação definitiva do site e
disponibilização do material neste, quanto pela publicação externa em site específico. Foi
percebido que é possível a realização de sistemas de informação utilizando-se exclusivamente
de software livre, desde a infra-estrutura até o cliente final, com a necessária interação de
diversos interessados e o material aberto, para sua compreensão, uso, estudo e possível
melhoria conforme convenções e melhores práticas da comunidade de software livre
internacional.
Palavras-chave: software, livre, sistemas, informação, desenvolvimento, implantação.

Software livre e sistemas de informação na FATEC de Praia Grande – x
ABSTRACT
The present work has for objective to relate the information and codes on information
systems using free software, those that decide two problems known in the institution, the
computerization of the library and greater controller and flexibility in relation to the access to
the Internet in the laboratories and other areas of the college. Study on an existing system for
solution of the question of the library was carried through and using of the concepts given for
the course and searched information a system for the solution of the question of the accesses
was developed. It was possible the publication of the material and codes searched and
developed by the use of free licenses as the GNU/GPL in such a way in environment of the
college, for its internal net and the definitive implantation of the site and publication of the
material in this, how much for the external publication in specific site. It was perceived that
the accomplishment of systems of information using itself exclusively of free software is
possible, since the infrastructure until the final customer, with the necessary interaction of
diverse interested and the opened material, for its understanding, use, study and possible in
agreement improvement practical better conventions and of the community of international
free software.
Keywords: software, free, systems, information, development, implantation.

Software livre e sistemas de informação na Fatec Praia Grande
INTRODUÇÃO
No estudo de sistemas de informação ao longo do curso da instituição não foi possível

o contato direto com sistemas completos, em efetiva utilização, o que forma uma lacuna no
desenvolvimento do profissional habilitado à sua criação e/ou manutenção.
Tendo em vista a restrição de acesso à documentação e ao código de sistemas

proprietários, e a necessidade da faculdade em suprir deficiências em determinadas áreas
administrativas, pesquisou-se a existência de sistemas que atendessem a estas premissas, e
ainda permitissem aos alunos e docentes que o estudassem, tanto em nível de documentação
quanto de código.
Para que se pudesse ter acesso irrestrito ao sistema, o mesmo deveria ser licenciado
como software livre, o que permitiria inclusive que se fizessem alterações no sistema ou
documentação, com a possibilidade de redistribuição destas modificações, em regime de
projeto da faculdade ou trabalho de alguma disciplina, ou isoladamente por algum aluno ou
professor.
A primeira e mais incidente necessidade foi notada em relação aos procedimentos

efetuados pela biblioteca. Depois, em relação ao controle de acessos à Internet pela rede da
faculdade.
A partir destes requisitos, considerando a estrutura de T.I. em uso na faculdade e as

restrições de recursos humanos e financeiros que envolvem uma instituição pública, foi
realizada uma pesquisa pela rede mundial de computadores através do site de busca Google1
pela existência de sistemas que atendessem aos requisitos.
1 Disponível em <http://www.google.com.br>. Acesso em 10/07/2006.

Foi então verificada a existência do sistema de gerência de bibliotecas Koha,

desenvolvido pela então Katipo Comunications, que atendia aos requisitos, com
documentação disponível suficiente para efetiva implantação e código disponível como
software livre sob Licença Geral Pública da GNU2.
Mas para o sistema de controle de acesso nada que atendesse aos requisitos foi
localizado. Em contatos efetuados com o sr. Diretor e a coordenadoria do Centro de
Informática, na época srs. Nilson Duarte e Domingos Latorre, respectivamente, e havendo
então a disciplina de Projeto de Sistemas, com o propósito que um sistema completo fosse
desenvolvido ao longo do semestre, foi decidido que um sistema seria criado para suprir esta
necessidade, utilizando-se exclusivamente de software livre.
Com estas considerações, foi possível então estabelecer o principal objetivo deste
trabalho, que é o compartilhamento de informações sobre desenvolvimento, utilização e
manutenção de sistemas de informação envolvendo software livre, tema ainda não abordado
pela instituição ao longo do curso. Esta definição levou à seguinte pergunta para nortear a
pesquisa e conseqüêntemente o trabalho :
É possível implantar sistemas de Informação utilizando-os em sua função inicial, e

como exemplo de aplicação dos conteúdos ministrados, de forma a propiciar aos alunos e
professores meios práticos de interação com sistemas reais ?
A existência de informações abertas e livres sobre sistemas de informação,

ferramentas de desenvolvimento e linguagens de programação propicia o aprendizado e o
crescimento profissional das pessoas que se predisporem a interagir com estas informações.
Mas é fato que muitos sequer sabem de sua existência. Sendo assim, a coleção de informações
sobre como colocar em funcionamento ferramentas de desenvolvimento, a explanação sobre a
aplicação de um sistema já desenvolvido, para uma situação real, e o desenvolvimento
completo de um sistema, seguindo os requisitos de uma situação e de um cliente a ser
atendido, propicia ao mesmo tempo a solução para problemas reais e imediatos da instituição,
assim como permite a interação de diversas disciplinas, alunos e professores de modo a prover
crescimento profissional, educacional e ainda possibilidades de negócios com as informações,
sistemas e pessoas relacionadas.
2 Disponível em <http://www.gnu.org/licenses/licenses.html#GPL>. Acesso em 19/05/2007.

Então, como obter tais informações, relacioná-las e disponibilizá-las de modo a

permitir que alunos e docentes dela se beneficiem ? Qual estrutura seria necessária para que
todos os interessados pudessem ter acesso a estas informações ?
Com isto, foram relacionados os temas necessários ao entendimento de sistemas

abertos, as ferramentas e serem utilizadas em seu desenvolvimento e a plataforma de
execução destes.
Estas informações foram estruturadas na forma descrita neste trabalho.
No capítulo um são apresentadas as teorias essenciais sobre sistemas de informação,

com noções sobre seu desenvolvimento, metodologias e recursos.
No capítulo dois estão as ferramentas, softwares e sistemas auxiliares utilizados para a

criação de sistemas de informação e suporte à sua estrutura.
No capítulo três consta a implantação do sistema Koha, a sua estrutura e utilização

nesta faculdade.
No capítulo quatro, está relacionada a documentação sobre o desenvolvimento do

sistema de filtro ao acesso à Internet Agenda.
No capítulo cinco, está apresentada a forma com que foram disponibilizadas as

informações, códigos criados e sistemas utilizados, e a forma com que alunos e docentes
podem interagir com estes recursos.
Ainda, no Anexo A, há o manual para o iniciante na utilização do sistema Koha, aqui

disponibilizado para facilitar seu entendimento.
1. SISTEMAS DE INFORMAÇÃO
A definição dos conceitos fundamentais sobre dado, informação, sistemas e

metodologias de desenvolvimento são passados ao longo do curso da instituição, e neste
capítulo são elucidadas algumas destas definições.
1.1. Dado, informação, sistemas e T.I.
Conforme Rezende(2005), o dado é entendido como um elemento da informação, que

isoladamente não possui um significado claro, não transmite nenhum conhecimento.
Ainda, informação é o dado trabalhado, útil, com valor significativo e com sentido
para quem usa a informação.
A organização e seleção de informações, com o objetivo de gerar cenários, simulações

e oportunidades, gera conhecimento. (Rezende, 2005 : p.26 ).
Organizações humanas, como o propósito de confecção de produtos ou serviços,

geram dados, que trabalhados tornam-se informações. Para o trato destas informações, no
sentido da criação de conhecimento para a administração e tomada de decisões, estas
organizações utilizam-se de Sistemas de Informação.
Conforme Rezende ( 2005 ), toda empresa ( organização ) é um sistema, e assim

possuem partes interagindo entre si, de modo a integrar-se para atingir um objetivo comum.
Sistemas podem ser fechados, que não trocam informações com outros sistemas, ou como são
as organizações, abertos, interagindo com outros sistemas trocando informações. (Rezende,
2005 : p.21 ).
Para gerenciar a complexidade e volume de dados e informações gerados pelas

organizações, mantendo a sinergia dos sistemas estas utilizam-se dos recursos

disponibilizados pela Tecnologia de Informação. Conhecida como T.I., é composta pelos
equipamentos, programas, pessoas e dinheiro, recursos estes disponíveis conforme o porte e
as necessidades destes pela organização. ( Rezende, 2005 : p.33 ).
1.2. Classificação
Conforme a posição na pirâmide organizacional em que um sistema de informação

tem sua principal importância ou atuação, estes podem ser classificados conforme segue
(Rezende, 2005) :
● operacionais : atuam com o nível mais baixo da pirâmide da organização, onde

são importantes para o controle dos processos produtivos, transações e operações;
● gerenciais : trabalham com os grupos de dados gerados pelos sistemas

operacionais, de modo a suprir informações necessárias para tomadas de decisão de
nível gerencial;
● estratégicos : operam com os níveis mais altos da organização, trabalhando

com dados e informações sintetizados para auxiliar a tomada de decisão estratégica .
Na prática, estas definições perdem sentido com o dinamismo dos sistemas, onde não
existe mais a separação formal destes níveis, pois as próprias organizações em razão da
dinâmica dos negócios, complexidade e necessidade de rápidos resultados, promovem a
quebra das barreiras formais entre o corpo gestor, o técnico a alta administração, envolvendo
a todos na conquista dos objetivos comuns.( Rezende, 2005 : p.36).
1.3. Desenvolvimento
Para propiciar a conquista destes objetivos comuns, é primordial a identificação das

reais necessidades da organização em relação a um sistema de informação. Esta levou a
criação de diversas formas e metodologias, ou processos, de desenvolvimento ao longo do
tempo, que avançaram em paralelo aos recursos tecnológicos disponíveis.
Sistemas possuem uma vida cíclica ( Rezende, 2005 ), a qual extingüe-se em
aproximadamente 5 anos, caso não sejam feitas adaptações. Das suas fases, entre elas a
concepção, construção, implantação, maturidade, declínio, manutenção e morte, a manutenção
permite e extensão de sua vida útil, retardando a sua morte.( Rezende, 2005 : p.41).
Conforme Larman(2004), um processo de desenvolvimento de software descreve uma

abordagem para a construção, a implantação e manutenção de um software ( sistema ) e o
Processo Unificado surgiu como um processo popular para sistemas orientados a objeto.
( Larman, 2004 : p.38 ).
1.4. O Processo Unificado
Ainda conforme Larman( 2004 ), o P.U. promove diversas práticas, entre elas se
destacando o desenvolvimento iterativo. Nesta abordagem, cada iteração é um miniprojeto, de
duração fixa, e o resultado de cada é um sistema testado, integrado e executável. Em cada
iteração, são executadas as fases de análise de requisitos, projeto, implementação e testes.
Nestas iterações, o sistema cresce incrementalmente com o tempo, com repetidas iterações de
tempo preferencialmente curto e limitado, até que se atinja o ponto de corresponder a todas as
necessidades a que o sistema em desenvolvimento deve atender.
Nesta abordagem do P.U., outras práticas relacionadas são :
● enfrentar alto risco e alto valor nas primeiras iterações;

● envolver continuamente os usuários finais;
● a estrutura inicial coesa deve ser construída nas primeiras iterações;
● testes freqüêntes de qualidade em situações reais;
● aplicar casos de uso;
● utilizar modelagem visual;
● gerenciar requisitos;
A organização de cada iteração possui quatro fases, descritas a seguir :
● Concepção - visão aproximada, escopo e estimativas vagas;

● Elaboração - visão refinada, implementação iterativa da arquitetura central,
solução dos altos riscos, levantamento da maioria dos requisitos, escopo e estimativas
mais realistas;
● Construção - implementação do restante do sistema e preparação para
implantação;
● Transição - testes beta e implantação.
1.5. Linguagem de Modelagem Unificada - UML
Conforme Pender(2004), foi criada inicialmente por Grady Booch, Jim Rumbaugh e
Ivar Jacobson, e oferece aos desenvolvedores uma linguagem de modelagem pronta para uso,
expressiva e visual, para a criação e troca de modelos gráficos significativos. A UML foi
projetada especificamente para representar sistemas orientados a objeto, que são descritos
como um conjunto de blocos cooperativos de informações e comportamentos. ( Pender, 2004 :
p.5 ).
Os sistemas descritos neste trabalho fazem uso desta linguagem de modelagem,

servindo então como exemplos de utilização.
2. FERRAMENTAS PARA SISTEMAS ABERTOS
Neste capítulo serão apresentados os conceitos e programas utilizados em

desenvolvimento de software livre. A abordagem é essencialmente prática, no sentido de
fornecer um mínimo de conhecimento para iniciar o uso de cada ferramenta ou sistema
apresentado.
2.1. O software
Conforme a lei 9609, de 19 de fevereiro de 1998, em seu artigo 1º, software ou

programa de computador é “a expressão de um conjunto organizado de instruções em
linguagem natural ou codificada, contida em suporte físico de qualquer natureza, de emprego
necessário em máquinas automáticas de tratamento da informação, dispositivos, instrumentos
ou equipamentos periféricos, baseados em técnica digital ou análoga, para fazê-los funcionar
de modo e para fins determinados.”
2.2. Patentes de software
Ainda em seu artigo 2º, a Lei 9609/98 confere ao autor do software o direito da
propriedade intelectual, em conexão com a legislação de direitos autorais, com possibilidade
de registro no Instituto Nacional de Propriedade Industrial (INPI), sendo que para a
reivindicação da paternidade do software o autor não necessita tê-lo registrado.
Em seu capítulo IV, a Lei 9609/98 determina que o uso de programas de computador
no País é objeto de contratos de licença, e que na sua inexistência o documento fiscal relativo
à sua aquisição é a comprovação suficiente da regularidade para seu uso.
Empresas produtoras de software cobram pelo uso de seus programas. Isto

transformou o cenário de desenvolvimento ao longo dos anos, pois nos anos 70, conforme a
Free software Foundation (2006), as empresas e os programadores compartilhavam código

entre si freqüêntemente, época em que o foco dos negócios era o hardware. Nos anos 80
quase todo o software era proprietário, com restrições que impediam o compartilhamento livre
de tecnologia entre usuários e entre programadores. (Free software Foundation,2006:p.1).
Conforme a Free Software Foundation(2006), em 1983 foi idealizado o projeto GNU,

como forma de resgatar o espírito cooperativo que prevalecia nos primórdios da computação,
e com o objetivo inicial de desenvolver um sistema operacional livre e compatível com
UNIX.
Até os anos 90 o projeto GNU já havia conseguido a maioria dos componentes

necessários a um sistema UNIX, a não ser pelo KERNEL. Foi então que Linus Torvalds, então
estudante da Universidade de Helsinki na Finlândia, criou um kernel compatível com padrões
UNIX, vindo de encontro às necessidades do projeto GNU.
Esta fusão do kernel de Linus com os utilitários GNU formou o que se conhece como
sistema operacional GNU/Linux, ou simplesmente linux.(Free software Foundation,
2006:p.1).
Esta breve história deste sistema deve ser conhecida pois este é o precursor de um
movimento de colaboração entre especialistas em computação, cujas idéias e realizações
tornaram possíveis os objetivos deste trabalho.
2.3. O software livre
Richard Stallman, em artigo publicado no CIPSGA3(1996), disse :
“Nós devemos continuar a falar sobre a liberdade de compartilhar e modificar

software -- e ensinar outros usuários o valor destas liberdades. Se nós nos
beneficiamos por ter um sistema operacional livre, faz sentido para nós pensar em
preservar estas liberdades por um longo tempo. Se nós nos beneficiamos por ter uma
variedade de softwares livres, faz sentido pensar sobre encorajar outras pessoas a
escrever mais software livre, em vez de software proprietário.”(Stallman,1996:p.1).
A liberdade de modificar um software exige certas pré-condições, tanto em relação à

autoria do mesmo quanto ao destino final da modificação, assim como criar um que se
mantenha livre exige que o mesmo tenha algum tipo de proteção legal.
3 Disponível em <http://www.cipsga.org.br/sections.php?op=viewarticle&artid=49>, Acesso em 19/05/2007.
Assim, segundo Stallman(1998) :
“Free como liberdade

O termo "free software" [em inglês free = livre ou grátis] às vezes é mal
interpretado --não tem nada a ver com o preço. E sim com liberdade. Aqui, então, a
definição de software livre é: um programa é software livre, para você, um usuário em
particular, se:
Você tem liberdade para executar o programa, com qualquer propósito.”
Esta liberdade garante o uso de um software, sem qualquer tipo de impedimento legal
ou interferência de qualquer natureza.
“Você tem a liberdade para modificar o programa e adaptá-lo às suas

necessidades. (Para fazer esta liberdade ser efetiva na prática, você deve ter acesso ao
código fonte, porque modificar um programa sem ter a fonte de código é
excessivamente difícil.)”
O acesso ao código fonte é possibilitado pela sua disponibilização para cópia através
de servidores acessíveis pela rede mundial de computadores (Internet).
“Você tem liberdade para redistribuir cópias, tanto grátis como com taxa.
Você tem a liberdade para distribuir versões modificadas do programa, de tal

modo que a comunidade possa beneficiar-se com as suas melhorias.”(Stallman,
1998:p.1)
Para que estas quatro liberdades sejam respeitadas, foi criada a Licença Geral Pública
(GNU GPL), pela Fundação GNU4, e desenvolvedores puderam então licenciar seus
programas por esta, e assim manter as quatro liberdades básicas de um software livre como
exposto por Stallman. A documentação dos desenvolvedores, ou criadas por outras pessoas
não diretamente relacionadas ao desenvolvimento de um também podem ser licenciadas e
mantidas livres, para permitir seu acesso e uso a quem delas necessitar.
Respeitando estas liberdades, e visando a colaboração entre alunos, professores e

funcionários da Faculdade, segue uma introdução teórica sobre as principais peças de
software utilizadas, e como obtê-las, em concordância com os termos do software livre.
4 Disponível em <http://www.gnu.org/licenses/licenses.html>. Acesso em 01/05/2007.

2.4. O sistema operacional Linux
Conforme Silva (2003) este sistema foi criado em 1991 por Linus Torvalds. É um
sistema operacional de código aberto, distribuído gratuitamente pela internet, e o principal
local de distribuição do kernel é o kernel.org5. Seu código fonte é distribuído como software
livre, sob a licença GPLv2 (veja glossário e anexos). Há avisos de direitos autorais nos
arquivos dos fontes explicando sobre isto detalhadamente e o próprio Linus não pode fechar o
sistema para distribuí-lo comercialmente.
A licença diz que não é crime copiar, instalar em outros computadores ou modificar o
software, mas incentiva a realizar tais ações e a divulgar eventuais alterações.
Como requisito mínimo de hardware é descrito um computador com processador Intel

386SX com 2 MB de memória e 40MB para uma instalação básica e funcional. Evidente que
conforme necessidades de desempenho e das aplicações estes requisitos podem diferir.
Linux é composto pelo núcleo desenvolvido por Linus (o kernel) e ferramentas GNU,
como compiladores, editores de texto, entre outras. Existem documentos que descrevem como
construir um sistema Linux a partir dos códigos fonte, como o LFS ou Linux From Scratch,
de Gerard Beekmans6.
Existem grupos de pessoas, empresas e organizações que decidem "distribuir" o Linux

junto com outros programas essenciais, como por exemplo editores gráficos, planilhas, bancos
de dados, ambientes de programação, formatação de documentos, firewalls, entre outros.
Este é o significado básico de distribuição. Cada distribuição tem sua característica

própria, como o sistema de instalação, o objetivo, a localização de programas, nomes de
arquivos de configuração, etc. A escolha de uma distribuição é pessoal e depende das
necessidades de cada implantação e finalidades.
Algumas distribuições bastante conhecidas são: Slackware, Debian, Red Hat,

Mandriva e SuSe todas usando o S.O. Linux como kernel principal.(Silva, 2003:p.1).
5 Disponível em <http://www.kernel.org>, Acesso em 21/03/2007.

6 Disponível em <http://www.linuxfromscratch.org> . Acesso em 09/04/2007.
Uma das distribuições em uso no Centro de Informática é a distribuição Debian versão

3.1r2, codinome Sarge. Os assuntos a seguir baseiam-se nos pormenores desta versão.
2.5. Debian GNU/Linux 3.1r2
Conforme o Projeto Debian(2007), a distribuição Debian se iniciou em 1993, quando

Ian Murdock ofereceu um convite livre a desenvolvedores de software livre para contribuir
com uma distribução completa e coerne baseada no kernel do Linux relativamente novo.
Aquele grupo de entusiastas originalmente fundaram a Debian baseando-se nos ideais da Free
software Foundation e influenciados pela filosofia GNU, e cresceu através dos anos em uma
organização em torno de 900 Desenvolvedores(Projeto Debian, 2007:p.1).
2.5.1. Conhecendo a distribuição Debian
Conforme o Projeto Debian(2007), a filosofia da distribuição Debian é expressa em

uma série de documentos. Dentre eles, o Contrato Social Debian é o que dá as diretrizes
àqueles que contribuem com o projeto. Conforme a filosofia Debian, quem aceita seguir o
Contrato Social pode se tornar um mantenedor, ou seja, aquela pessoa que pode contribuir de
alguma forma com o projeto. Em linhas gerais, este documento diz :
• Debian se manterá 100% software livre;

• Os desenvolvedores retornarão contribuições à comunidade como software livre;
• Problemas não serão escondidos;
• As prioridades serão os usuários e o software livre;
• Programas que não são software livre serão suportados, apesar de não fazerem parte
da distribuição;
A Definição Debian de software Livre é o documento que descreve o que é ou não

software livre conforme a filosofia do projeto. Conforme o mesmo :
• Uma peça de software deve poder ser livremente redistribuída;

• Esta peça deve conter o código-fonte, igualmente redistribuível;
• Estas peças devem permitir modificações, e os trabalhos derivados destas peças devem
ser licenciados conforme o software original;
• A licença pode restringir modificações nos originais somente se arquivos com

alterações aplicáveis aos originais puderem ser distribuídos com os mesmos, para
efeito de modificação na compilação, e deve explicitamente poder distribuir
executáveis modificados. Esta licença pode requerer que a versão deste software
modificado seja diferente do original. A Debian encoraja os seus desenvolvedores a
não restringir qualquer arquivo, fonte ou executável, de possibilidades de
modificações. Estes termos visam proteger a autoria do código;
• A licença não pode discriminar pessoas ou grupos;
• Não deve haver discriminação de uso para o software;
• A licença deve ser aplicável a todos que obtiverem o software, sem excessões ou
particularidades;
• A licença não deve ser específica para a Debian, daqueles softwares desenvolvidos no
projeto, mas igualmente aplicável a todos;
• A licença de um software não deve fazer restrições a outros softwares distribuídos
conjuntamente;
• GPL, BSD e Artistic são exemplos que a Debian considera licenças de software livre.
(Projeto Debian, 2007:p.1).
2.5.2. Conhecendo o sistema operacional Debian
Conforme Projeto Debian(2007), Linux é um sistema operacional: uma série de

programas que lhe permitem interagir com seu computador e executar seus programas.
Um sistema operacional consiste em vários programas fundamentais que são

necessários para que seu computador possa se comunicar e receber instruções dos usuários,
ler e gravar dados para os discos rígidos, fitas, impressoras, controlar o uso de memória e
executar outros aplicativos. A parte central de um sistema operacional é o kernel. Em um
sistema GNU/Linux o Linux é o componente do kernel. O resto do sistema consiste de outros
programas, muitos dos quais foram escritos pelo ou para o projeto GNU.
O Linux é modelado sobre o sistema operacional Unix. Desde o inicio, o Linux foi
designado para ser um sistema multi-tarefa e multi-usuário.
A combinação da filosofia da Debian e metodologia e ferramentas GNU, o kernel do

Linux e outros softwares livres importantes, formam a única distribução de software chamada
Debian GNU/Linux. Esta distribuição é feita de um grande número de pacotes de softwares.
Cada pacote na distribuição contém programas executáveis, scripts , documentação e
informações de configuração, e tem um mantenedor que é o responsável primariamente por
manter o pacote atualizado, analisando bug reports e comunicando-se com o autor do pacote
do programa.
O que distingue a distribuição Debian das demais é essencialmente seu sistema de

gerenciamento de instalação de pacotes de software, conhecido como APT. Este sistema
possibilita a instalação ou remoção de um ou vários pacotes através de um a três comandos,
tipicamente. Podem ser usados cd's ou uma conexão com a internet para a obtenção de novos
pacotes ou atualizações. Para uma atualização completa do sistema, estes mesmos meios
podem ser utilizados(Projeto Debian, 2007:p.1).
Pelas suas características de gerenciamento de pacotes e controle de qualidade dos

softwares envolvidos, a Debian deu origem a muitas outras distribuições, entre elas algumas
nacionais como Kurumin e Kalango, e outras em ascensão na comunidade como Ubuntu.
Conforme o Projeto Debian, são mantidas três frentes de revisões em sua distribuição,
cujos codinomes são relativos a personagens do filme Toy Story, a saber :
• Estável : esta é a distribuição oficial, atualmente 3.1r2 codinome Sarge, lançada em 19

de abril de 2006. É a recomendada para ambientes de produção pelo extenso ciclo de
testes aplicado;
• Teste : é a distribuição que ainda não atingiu o nível de estável, mas está na fila de
testes para isto. É a que possui versões dos pacotes mais recentes que a estável e
atualmente tem o codinome Etch. Pacotes desta distribuição comumente recebem
apenas correções de falhas, sem inclusão de muitas novas funcionalidades que
poderiam gerar novas falhas. Passam por uma série de testes e avaliações de
desenvolvedores e usuários até serem considerados estáveis. Conforme anúncios
oficiais da Debian, a previsão de lançamento desta distribuição como nova estável é
dezembro de 2006, cuja versão será 4.0. Amostragens da distribuição estão
disponíveis semanalmente para download.
• Instável : é onde o intenso trabalho de desenvolvimento ocorre. Inclusão de novos

pacotes, de novas funcionalidades e últimas versões de pacotes estão nesta
distribuição. É considerada instável pois pode conter muitas falhas. Não é
recomendada para ambientes de produção e atualmente tem o codinome Sid.
Amostragens da distribuição estão disponíveis semanalmente para download.(Projeto
Debian, 2007:p.1).
2.5.3. Instalação
Estes tópicos baseiam-se no manual de instalação da Debian, disponíveis nos

cd's/dvd's de instalação e em versões mais recentes no site oficial da distribuição.
Conforme o Projeto Debian, a distribuição Debian não impõe requerimentos de

hardware especiais além dos requerimentos do kernel do Linux e conjunto de ferramentas da
GNU. No entanto, qualquer arquitetura onde o kernel do Linux, libc, gcc, etc. foram portados,
e que um porte da Debian existe, poderá executar a Debian. Neste trabalho trataremos sobre a
i386, instalável sobre a maioria dos computadores pessoais em uso no país, comumente
equipados com processadores Intel ou AMD, pertencentes a esta arquitetura.
Um dos métodos de instalação da distribuição é através de imagens de CD-ROM

disponíveis para download nos sites oficiais ou espelhos. É necessário um outro sistema
operacional já instalado que possibilite o acesso a tais arquivos e um gravador de cd's para
que as imagens possam ser gravadas em mídias virgens encontráveis no mercado de
suprimento de materiais para informática. Cd's pré-gravados podem ser comprados, e mais
informações a respeito podem ser obtidas no site oficial da distribuição. Manuais de como
gravar as imagens estão igualmente disponíveis.
A distribuição está dividida em cd's ou dvd's, e a organização dos pacotes de software

nos mesmos é definida de acordo com a popularidade dos pacotes na comunidade de software
livre. Para a instalação típica é essencial apenas o primeiro cd ou dvd.
Com a Debian, a circunstância de requerer uma reinstalação completa do sistema é

muito rara, talvez falhas mecânicas de um disco rígido podem ser a causa mais comum.
Muitos sistemas operacionais podem requerer que a reinstalação completa seja feita
quando falhas críticas são descobertas ou quando são necessárias atualizações para novas
versões. Até mesmo caso uma nova instalação completa não seja requerida, os programas
deverão ser freqüentemente reinstalados para funcionar adequadamente na nova versão.
Sob a Debian GNU/Linux, é muito mais provável que o sistema seja reparado ao invés
de substituído caso as coisas saiam erradas. A atualização nunca requer uma completa
reinstalação, sempre será possível atualizar o sistema. E os programas são em sua maioria
compatíveis com lançamentos de revisões sucessivas. Caso uma nova versão do programa
requeira uma nova versão de um software, o sistema de empacotamento da Debian se
assegura que todos os programas necessários sejam automaticamente identificados e
instalados. O programa de instalação não está preparado para fazer reinstalações através de
um sistema operacional existente.
Estes são os passos para o processo de instalação, conforme o manual de instalação do

Debian :
• Fazer o backup de dados ou documentos existentes no disco rígido onde deseja instalar
o sistema.
• Obter informações sobre o computador e documentação necessária antes de iniciar a
instalação.
• Criar o espaço na tabela de partição para a Debian no disco rígido.
• Localizar e/ou baixar o programa de instalação e quaisquer arquivos de controladores
especializados que a máquina precise (exceto para usuários que possuem o CD da
Debian).
• Configurar tapes de inicialização/disquetes/cartões de memória USB ou colocar os
arquivos de boot (a maioria dos usuários de CD da Debian podem inicializar a partir
de um dos CDs).
• Iniciar o sistema de instalação.
• Selecionar o idioma da instalação.
• Ativar a conexão de rede ethernet, se disponível.
• Criar e montar as partições que terá o sistema Debian instalado.
• Assistir o download/configuração/instalação automática do sistema básico.
• Instalar um gerenciador de boot que poderá iniciar a Debian GNU/Linux e/ou seu
sistema existente.
• Carregar o novo sistema instalado pela primeira vez e fazer alguns ajustes iniciais.
• Instalar programas adicionais (tarefas (tasks) e/ou pacotes) conforme necessário.
Caso ocorram problemas durante a instalação o debian-installer mostrará que pacotes
estão envolvidos com quais passos. Esta é a relação dos programas atuantes na instalação:
• O programa de instalação, debian-installer, é a parte fundamental . Ele detecta e

carrega os controladores de dispositivos apropriados, utiliza o dhcp-client para
configurar uma conexão de rede e executa o debootstrap para fazer a instalação dos
pacotes do sistema básico. Muitos mais programas atuam neste processo e o debian-
installer completará sua tarefa quando carregar o novo sistema pela primeira vez.
• Assim que carregar o novo sistema básico, o base-config executará a tarefa de adição
de novos usuários, ajuste do fuso-horário (usando o tzsetup) e configuração do sistema
de instalação de pacotes (usando o apt-setup). Ele então carregará o tasksel que pode
ser usado para selecionar um grande grupo de programas relacionados e ainda em
tempo poderá executar o aptitude que permite selecionar pacotes de programas
individualmente.
• Quando o debian-installer finalizar, antes do sistema ser carregado pela primeira vez,
haverá somente um sistema simples guiado via linha de comandos. A interface gráfica
não será instalada a não ser que seja selecionada durante os passos finais, seja no
tasksel ou no aptitude. Ela é opcional porque muitos sistemas Debian GNU/Linux são
servidores que não tem qualquer necessidade de interface gráfica para usuários
realizarem seu trabalho.(Projeto Debian, 2007:p.1).
2.5.4. Conceitos e utilização básica do sistema
Conforme Silva(2003), o sistema GNU/Linux foi concebido desde o início para ser
utilizado por vários usuários, ao mesmo tempo. Cada usuário pode realizar várias tarefas, ao
mesmo tempo. Este é o conceito de um sistema operacional multiusuário e multitarefa.(Silva,
2003:p.1).
2.5.4.1 Usuários
Mas para que o sistema identifique cada usuário é utilizado um sistema de contas de
usuário, onde cada um em particular tem sua identificação no sistema, o seu login. Para
acessar o sistema, o usuário deve fornecer seu nome de login, que pode ser alfanumérico, e
uma senha. Estas credenciais identificarão o usuário unicamente, e dará a ele permissão para
executar algumas tarefas.
Em um sistema GNU/Linux, existe apenas um usuário que tem permissão irrestrita

neste sistema, identificado para o sistema como sendo usuário número 0 (UID=0) e
tipicamente com nome de login root. Este é conhecido como super-usuário e apenas este tem
credenciais para dar permissões a outros usuários.
Usuários podem ser organizados em grupos, para facilitar a sua identificação e

atribuição de permissões. Um grupo pode ter determinadas permissões. Usuários pertencentes
a estes grupos receberão estas mesmas permissões.
Um sistema Linux é instalado em um determinado disco rígido. Este disco é divido em

porções lógicas denominadas partições. Esta partição é formatada com um determinado tipo
de sistema de arquivos para que possa ser usada pelo sistema. Para que um sistema de
arquivos possa ser identificado pelo sistema, ele deve ser montado sobre um determinado
diretório. Afinal, para sistema baseados em conceitos Unix, como o Linux, tudo é arquivo,
que deve estar em algum diretório. Este é o principal ponto de confusão para usuários de
outros sistemas operacionais, pois para o Linux uma impressora, o monitor de vídeo, a rede,
um modem, teclado, mouse, discos rígidos ou flexíveis, cd-roms, tudo é arquivo, relacionado
a um determinado ponto de acesso ou montagem.
Quando um usuário é criado no sistema Linux, um determinado diretório é associado

ao mesmo, e sobre o qual este usuário tem plenas permissões, é o chamado diretório home.
Quando um usuário entra no sistema, é neste diretório que ele inicia seus trabalhos.
2.5.4.2. A organização de diretórios
Em um sistema Linux, o principal diretório é chamado raiz ( / ). Este tipicamente está

relacionado a uma partição em algum disco rígido do computador, porém não
obrigatoriamente. Todos os outros diretórios estão abaixo deste, podendo ser alguns
montagens de outras partições. E em alguns estão arquivos importantes para o sistema, como
arquivos executáveis, de configuração, de dispositivos especiais ou de sistema.
Não existe padronização oficial para a nomenclatura ou distribuição dos diretórios em

um sistema Linux, mas algumas convenções herdadas de sistemas Unix mais antigos
prevalecem para efeitos de organização, com algumas diferenças entre distribuições. Uma
tentativa de organizar este problema é o projeto FileSystem Hierarchy Standart7. Este projeto,
conjunto com o Linux Standard Base8, são padrões abertos de referência para organização da
distribuição de diretórios e arquivos, de modo a permitir que uma determinada aplicação
desenvolvida possa ser executada em várias distribuições. A próxima versão da Debian,
codinome Etch, será compatível com estes padrões.
A organização atual dos diretórios é :
• /bin - Contém arquivos de programas do sistema que são usados por todos os usuários.
• /boot - Contém arquivos necessários para a inicialização do sistema.
• /cdrom - Ponto de montagem da unidade de CD-ROM.
• /dev - Contém arquivos usados para acessar dispositivos (periféricos) existentes no
computador.
• /etc - Arquivos de configuração de seu sistema local.
• /home - Diretórios contendo os arquivos dos usuários.
• /lib - Bibliotecas compartilhadas pelos programas do sistema e módulos do kernel.
• /lost+found - Local para a gravação de arquivos/diretórios recuperados pelo utilitário
fsck.ext2. Cada partição possui seu próprio diretório lost+found.
• /mnt - Ponto de montagem temporário.
• /proc - Sistema de arquivos do kernel. Este diretório não existe no disco rígido, ele é
criado pelo kernel e usado por diversos programas que fazem sua leitura, verificam
configurações do sistema ou modificam o funcionamento de dispositivos do sistema
através da alteração em seus arquivos.
• /root - Diretório do usuário root.
• /sbin - Diretório de programas usados pelo superusuário (root) para administração e
controle do funcionamento do sistema.
• /tmp - Diretório para armazenamento de arquivos temporários criados por programas.
• /usr - Contém a maior parte dos programas. Acessível somente como leitura por
usuários comuns.
• /var - Contém a maior parte dos arquivos que são gravados com freqüência pelos
programas do sistema, e-mails, spool de impressora, cache, etc.
7 Disponível em <http://www.pathname.com/fhs>, Acesso em 21/03/2007.
8 Disponível em <http://www.linux-foundation.org/en/LSB>, Acesso em 21/03/2007.
2.5.4.3. Permissões de acesso
Em um sistema multiusuário, devem existir meios de proteção dos arquivos de um

usuário, de modo a evitar acesso não autorizado por outros usuários. Em Linux, este modo de
proteção é efetuado pelas permissões de acesso. Para o superusuário não existe restrição de
acesso, a não ser em configurações especiais de sistema.
Quando um arquivo é criado no Linux, obrigatoriamente suas permissões devem ser

configuradas. Como padrão, um comando em tempo de boot define o padrão de permissões
para arquivos criados pelo usuário, podendo o mesmo alterá-las posteriormente. É o comando
umask. Apenas o dono do arquivo ou o superusuário (root) podem alterar permissões de
acesso. Existem comandos específicos para tal tarefa.
As permissões são aplicadas aos arquivos em relação ao seu dono, ao grupo ou outros.
Elas podem ser leitura, escrita ou execução. Elas são em modo literal ou octal.
Para a exibição do conteúdo de um diretório pode ser usado o comando ls. Com
opções especiais as permissões destes arquivos podem ser igualmente mostradas. Este é um
exemplo da saída de um comando ls -la em um diretório :
root@kirdeika:bin# ls -la zip

-rwxr-xr-x 1 root root 64792 2005-05-26 06:49 zip
Neste exemplo :
• A primeira letra diz sobre o tipo de arquivo, um d para diretório, l para um link para
outro arquivo, um – para arquivo comum;
• Da segunda à quarta letras, as permissões do dono do arquivo, neste caso r – ler, w –
escrever e x – executar;
• Da quinta à sétima letras, as permissões para o grupo, neste caso, ler e executar;
• Da oitava à décima letras, as permissões para outros, igualmente ler e executar;
• Na próxima posição, diz a quantidade de subdiretórios se for um diretório, ou 1 para
arquivos comuns;
• A próxima posição diz o nome do dono do arquivo;
• A próxima posição diz o nome do grupo do dono do arquivo;
• A próxima posição diz o tamanho do arquivo;
• A próxima posição diz a data de criação ou última modificação do arquivo;

• A próxima posição diz a hora de criação ou última modificação do arquivo;
• A última posição diz o nome do arquivo.
Quando em diretórios, o x é relativo ao acesso ao mesmo.
Para alterar as permissões de um arquivo, usa-se o comando chmod. Este comando

aceita como parâmetros o modo literal ou octal de permissões.
Com o comando chmod, usando o modo literal, pode-se configurar, adicionar ou

retirar permissões. Usa-se u para o dono, o para outros, g para o grupo e a para todos. Pode-se
adicionar (+), retirar (-) ou atribuir (=) permissões. Usa-se x para execução, r para leitura e w
para escrita. Como no exemplo :
• adicionar : # chmod ug+x arquivo – é adicionada a permissão de execução;

• configurar : # chmod a=rx arquivo – são configuradas as permissões de leitura e
execução ao dono, grupo e outros;
• retirar : # chmod o-x arquivo – é retirada a permissão de execução do arquivo para
usuários que não sejam o dono ou estejam no grupo do arquivo.
Permissões especiais:
• s - Quando é usado na permissão de acesso do Dono, ajusta a identificação efetiva do

usuário do processo durante a execução de um programa, também chamado de bit
setuid. Não tem efeito em diretórios. Quando s é usado na permissão de acesso do
Grupo, ajusta a identificação efetiva do grupo do processo durante a execução de um
programa, chamado de bit setgid. É identificado pela letra s no lugar da permissão de
execução do grupo do arquivo/diretório. Em diretórios, força que os arquivos criados
dentro dele pertençam ao mesmo grupo do diretório, ao invés do grupo primário que o
usuário pertence. Ambos setgid e setuid podem aparecer ao mesmo tempo no mesmo
arquivo/diretório. A permissão de acesso especial s somente pode aparecer no campo
Dono e Grupo.
• S - Idêntico a "s". Significa que não existe a permissão "x" (execução ou entrar no
diretório) naquele lugar. Um exemplo é o chmod 2760 em um diretório.
• t - Salva a imagem do texto do programa no dispositivo swap, assim ele será carregado
mais rapidamente quando executado, também chamado de stick bit. Em diretórios,

impede que outros usuários removam arquivos dos quais não são donos. Isto é
chamado de colocar o diretório em modo append-only. Um exemplo de diretório que
se encaixa perfeitamente nesta condição é o /tmp, todos os usuários devem ter acesso
para que seus programas possam criar os arquivos temporários lá, mas nenhum pode
apagar arquivos dos outros. A permissão especial t, pode ser especificada somente no
campo outros usuários das permissões de acesso.
• T - Idêntico a "t". Significa que não existe a permissão "x" naquela posição (por
exemplo, em um chmod 1776 em um diretório).
• X - Se for usado X ao invés de x, a permissão de execução somente é afetada se o
arquivo já tiver permissões de execução. Em diretórios ela tem o mesmo efeito que a
permissão de execução x.
Ao invés de utilizar o modo de permissão literal pode ser usado o modo octal para se
alterar a permissão de acesso a um arquivo. O modo octal é um conjunto de oito números
onde cada número define um tipo de acesso diferente.
É mais flexível gerenciar permissões de acesso usando o modo octal ao invés do

literal, pois pode ser especificada diretamente a permissão do dono, grupo, outros ao invés de
gerenciar as permissões de cada um separadamente. Abaixo a lista de permissões de acesso
octal:
• 0 - Nenhuma permissão de acesso. Equivalente a -rwx.

• 1 - Permissão de execução (x).
• 2 - Permissão de gravação (w).
• 3 - Permissão de gravação e execução (wx).
• 4 - Permissão de leitura (r).
• 5 - Permissão de leitura e execução (rx).
• 6 - Permissão de leitura e gravação (rw).
• 7 - Permissão de leitura, gravação e execução. Equivalente a +rwx.
O uso de um destes números define a permissão de acesso do dono, grupo ou outros

usuários. Um modo de entender como as permissões de acesso octais funcionam, é através da
seguinte relação:
• 1 = Executar, 2 = Gravar, 4 = Ler. Para Dono e Grupo, multiplique as permissões por

x100 e x10.
E para as permissões de acesso especiais:
• 1000 = Salva imagem do texto no dispositivo de troca

• 2000 = Ajusta o bit setgid na execução
• 4000 = Ajusta o bit setuid na execução
O uso desta relação é a seguinte:
• Somente permissão de execução, use 1.

• Somente a permissão de leitura, use 4.
• Somente permissão de gravação, use 2.
• Permissão de leitura/gravação, use 6 (equivale a 2+4 / Gravar+Ler).
• Permissão de leitura/execução, use 5 (equivale a 1+4 / Executar+Ler).
• Permissão de execução/gravação, use 3 (equivale a 1+2 / Executar+Gravar).
• Permissão de leitura/gravação/execução, use 7 (equivale a 1+2+4 /
Executar+Gravar+Ler).
• Salvar texto no dispositivo de troca, use 1000.
• Ajustar bit setgid, use 2000.
• Ajustar bip setuid, use 4000.
• Salvar texto e ajustar bit setuid, use 5000 (equivale a 1000+4000 / Salvar texto + bit
setuid).
• Ajustar bit setuid e setgid, use 6000 (equivale a 4000+2000 / setuid + setgid).
Para ajustar a permissão de um arquivo para que todos possam executá-lo, apenas o
dono possa editá-lo, e que seja executado sempre como se o dono estivesse executando, o
comando é o seguinte :
# chmod 4755 arquivo

2.5.4.4. Trabalhando com arquivos
Arquivos podem ser binários, cujo conteúdo somente é legível para máquinas, ou
texto, cujo conteúdo é legível para pessoas. Existem inúmeros comandos para manipular
arquivos em linux, para cópia, edição, leitura ou outras tarefas.
Pode-se copiar arquivos com o comando cp. Como no exemplo :
# cp arquivo1 arquivo2
Pode-se ler o conteúdo de um arquivo com o comando cat :
# cat arquivo
Pode-se editar um arquivo texto com vários editores, entre eles o vi, nano , mcedit,
emacs entre outros. Como no exemplo :
# nano arquivo
Pode-se criar um arquivo vazio (sem conteúdo) com o comando touch. Quando
aplicado a um arquivo existente, a data e hora de modificação são alteradas.
2.5.4.5. Manipulando e navegando diretórios
Existem diversos comandos para a criação ou alteração de diretórios, assim como a

navegação do usuário na árvore de diretórios. As permissões afetam como os usuários podem
manipulá-los ou navegar, excetuando-se o superusuário. A saber :
• mkdir : cria um diretório;

• mv : pode mover ou renomear tanto diretórios como arquivos;
• rmdir : remove diretórios vazios;
• rm : remove arquivos e diretórios, possui várias opções para diferentes necessidades;
• cp : copia arquivos e diretórios, também com várias opções;
• cd : altera o diretório corrente do usuário;
Pode-se a qualquer momento saber em que diretório o usuário está usando-se o

comando pwd. Sabendo onde se está, é possível navegar pelos diretórios em que o usuário
tenha permissão de acesso, usando-se o comando cd, aplicando-se como parâmetros um
diretório de destino absoluto ou relativo a onde se está.
Considerando a seguinte estrutura de diretórios, para o usuário mario, com diretório

home em /home/mario :
/home/mario
/home/mario/pesquisa
/home/mario/arquivos
Após o login, o diretório corrente é /home/mario. Ao se executar < cd pesquisa >,

considera-se o caminho relativo pesquisa e descende-se ao diretório pesquisa. Neste momento
o diretório corrente é /home/mario/pesquisa. Ao se digitar < cd ../arquivos >, o sistema
considera que deva subir um nível, em /home/mario, e descender ao arquivos. Neste momento
o diretório corrente é /home/mario/arquivos. Ao se executar < cd ~ >, o sistema considera o
diretório home do usuário e direciona para ele, em /home/mario. Novamente, pode-se
executar < cd /home/mario/pesquisa > e o sistema considera o caminho absoluto
/home/mario/pesquisa e o acessa.
2.5.4.6. Executando arquivos
Para que um usuário possa executar um arquivo, ele deve ter permissão para isto.
Executa-se um arquivo digitando-se o seu nome no aviso de comando, passando após o nome
do arquivo seus parâmetros, conforme o necessário.
2.5.4.7. Caminho de busca
Para que o sistema encontre o arquivo digitado no aviso de comando, o caminho onde
o arquivo pode ser encontrado deve estar em seu caminho de busca, ou path. Como a maioria
dos executáveis está em /bin, /usr/bin ou /usr/share/bin ou outros, testes caminhos devem
constar em seu path, que é configurado armazenando-se na variável de ambiente PATH os
caminhos. Executando-se < echo $PATH > pode-se saber qual o caminho de busca atual.
Executando-se < export $PATH:/novo/caminho > adiciona-se um diretório ao path atual.
Para que um usuário execute um arquivo que está em seu próprio diretório, o nome do
arquivo deve ser precedido de ./ , o que referenciará para o aviso de comando que o arquivo a
ser executado está no diretório corrente.
2.5.4.8. Entrada e saída padrão e saída de erros
Em Linux, existem as três vias acima para os dados. Quando um comando é

executado, por definição sua saída é direcionada para a padrão, que normalmente é o console.
(video). A entrada padrão é normalmente o teclado, e a saída de erro é o console.
2.5.4.9. Redirecionamentos e pipes
Estas vias podem ser redirecionadas com o uso de comandos especiais, de modo a
flexibilizar o processamento de comandos. A saída de um comando pode ser redirecionada à
entrada de outro, assim como para um arquivo, ou o conteúdo de um arquivo para um
comando, por exemplo. Os direcionadores são >, >>, <, <<, e | . Exemplificando :
# cat <relatorio 2>erro.log | grep ajuste | tee verifica.log > /dev/tty2
O comando acima envia o arquivo relatorio para o comando cat, caso exista um erro o
mesmo é enviado para o arquivo erro.log, sendo que a saída do cat é enviada ao grep. A saída
do grep é enviada ao tee, cuja saída é direcionada ao dispositivo /dev/tty2.
2.5.4.10. A inicialização do sistema Linux
Para que um sistema Linux seja utilizável, uma sequência de arquivos deve ser lida e
executada, e esta varia conforme a distribuição, versão ou origem.
O gerenciador de inicialização, normalmente lilo ou grub, após a escolha do usuário de

qual imagem carregar, lê os arquivos de imagem de kernel e ramdisk inicial, carregando-os na
memória. Segue-se então o boot (inicialização). Uma vez carregados a ramdisk e o kernel, o
kernel busca pelo programa init, que é o encarregado pelo restante do procedimento de
inicialização.
2.5.4.11. Processos, programas e deamons
No Linux, arquivos em execução são chamados processos, que podem estar em

primeiro plano, ou seja, o usuário que os executou está aguardando o seu resultado, ou em
segundo plano, quando o usuário está realizando outras tarefas enquanto o processo está em
execução. Um deamon é um processo, mas o usuário apenas percebe a sua existência quando
é necessário interagir com ele, ou seja, ele está sempre em execução, aguardando alguma
solicitação. A maioria dos processos de serviços no Linux, como servidores web, de banco de
dados, e-mail, dns, ftp, podem ser considerados deamons.
2.5.4.12. Níveis de execução
O nível de execução atual do sistema pode ser visualizado através do comando

runlevel e modificado através dos programas init ou telinit. Quando é executado, o runlevel lê
o arquivo /var/run/utmp e adicionalmente lista o nível de execução anterior ou a letra N em
seu lugar (caso ainda não tenha ocorrido a mudança do nível de execução do sistema).
Na Debian, os diretórios /etc/rc0.d a /etc/rc6.d contém os links simbólicos para

arquivos em /etc/init.d que são acionados pelo nível de execução correspondente.
Por exemplo, o arquivo S10sysklogd em /etc/rc2.d, é um link simbólico para

/etc/init.d/sysklogd.
Removendo-se o arquivo /etc/rc2.d/S10sysklogd o daemon sysklogd deixaria de ser

executado no nível de execução 2 do sistema (que é o padrão da Debian).
A Debian segue o seguinte padrão para definir se um link simbólico em /etc/rc[0-6].d

iniciará ou interromperá a execução de um serviço em /etc/init.d, que é o seguinte:
• Se um link é iniciado com a letra K (kill), quer dizer que o serviço será interrompido
naquele nível de execução. O que ele faz é executar o daemon em /etc/init.d seguido
de stop.
• Se um link é iniciado com a letra S (start), quer dizer que o serviço será iniciado
naquele nível de execução (é equivalente a executar o daemon seguido de start).
Primeiro os links com a letra K são executados e depois os com S. A ordem em que os
links são executados dependem do valor numérico que acompanha o link, por exemplo, os
seguintes arquivos são executados em seqüência:
• S10sysklogd
• S12kerneld
• S20inetd
• S20linuxlogo
• S20logoutd
• S89cron
• S99xdm
Os arquivos que iniciam com o mesmo número (S20*) são executados

alfabeticamente.
O nível de execução do sistema pode ser modificado usando-se o comando init ou

telinit. Os seguintes níveis de execução estão disponíveis na Debian:
• 0 - Interrompe a execução do sistema. todos os programas e daemons finalizados. É

acionado pelo comando shutdown -h
• 1 - Modo monousuário, útil para manutenção do sistema.
• 2 - Modo multiusuário (padrão da Debian)
• 3 - Modo multiusuário
• 4 - Modo multiusuário
• 5 - Modo multiusuário com login gráfico
• 6 - Reinicialização do sistema. Todos os programas e daemons são encerrados e o
sistema é reiniciado. É acionado pelo comando shutdown -r ou pelo pressionamento de
CTRL+ALT+DEL.
Por exemplo, para listar o nível de execução atual do sistema digita-se runlevel. O
runlevel deverá listar algo como:
# runlevel
N 2
Para mudar para o nível de execução digite init 3. Digitando-se novamente runlevel,
deverá ver-se este resultado:
#runlevel
2 3
Isto quer dizer que o nível de execução anterior era o 2 e o atual é o 3.
Quando um programa deve ser executado na inicialização, um link deve ser criado no
diretório correspondente ao(s) nível(is) de execução onde o mesmo deve ser iniciado e
parado. Na Debian, estes links apontam para os scripts reais em /etc/init.d.
2.5.4.13. Pacotes de programas
A Debian usa o sistema APT para gerenciamento de pacotes de programas. Um pacote

é um arquivo que contém vários executáveis, arquivos de configuração e de documentação.
O arquivo que contém a configuração do apt é o /etc/apt/apt.conf. O apt pode utilizar

mídias removíveis, arquivos em disco ou a conexão com a internet para obter listas de pacotes
ou os próprios pacotes, e este comportamento é configurado em /etc/apt/sources.list.
Estas são algumas opções do comando apt-get relacionados à administração de pacotes

na Debian :
• update : atualiza a relação de pacotes, conforme a origem configurada em

/etc/apt/sources.list;
• upgrade : atualiza os pacotes para as versões mais novas da lista atualizada;
• dist-upgrade : realiza a atualização da distribuição completa, para a nova versão
configurada com apt-config;
• install : instala um pacote e suas dependências;
• remove : remove determinado pacote, menos os arquivos de configuração;
• purge : usado com remove, desinstala determinado pacote e apaga todos os arquivos
relacionados, inclusive os de configuração;
O seguinte comando instala o pacote chamado zip :
#apt-get update
#apt-get install zip
2.5.4.14. Compilando programas de terceiros
Como qualquer sistema Linux, a Debian possibilita que programas distribuídos sob a
forma de código fonte possam ser compilados e instalados para uso. Além dos arquivos
básicos relativos às linguagens como c, c++, entre outras, estes arquivos-fonte podem
depender de outros arquivos. Pacotes de desenvolvimento que contém estas dependências
podem ser instalados e a procura de quais pacotes que contém tais arquivos é auxiliada pelo
utilitário auto-apt. Em arquivos-fonte, são executados três passos básicos para sua
compilação, a saber :
• ./configure – neste passo são verificadas as dependências, e outros parâmetros básicos

para a compilação, é então gerado um arquivo Makefile que será usado pelo programa
make;
• make – a partir dos parâmetros do Makefile, chama o compilador gcc ou outro para
executar a construção do arquivo binário executável;
• make install – este comando efetua a instalação dos binários/documentação gerados,
em seus devidos diretórios. Este passo só pode ser executado como superusuário.
No passo do configure, o auto-apt auxilia a instalar dependências faltantes, da seguinte

maneira :
#auto-apt run ./configure
E então as dependências são instaladas a cada necessidade.
2.5.4.15. Procurando ajuda no sistema
A Debian, na sua instalação padrão, disponibiliza meios para os usuários obterem

ajuda sobre programas e comandos. Em diretórios específicos também são instalados
arquivos, texto simples ou HTML, contendo manuais sobre alguns aplicativos.
Em /usr/share/doc estão a maioria destes arquivos, separados por programa. No aviso

de comando, man <comando> exibe a ajuda sobre o mesmo. Funções e bibliotecas têm
igualmente sua ajuda disponibilizada por estes meios, podendo os arquivos de cabeçalho com
as funções serem lidos diretamente em /usr/include.
2.5.4.16. Extensões de arquivos
Em sistemas Linux, o nome do arquivo, incluindo sua extensão, nada diz sobre seu
conteúdo para o sistema operacional. Assim, dentro do espaço de 255 caracteres, o arquivo
pode conter quaisquer caracteres menos os especiais e os que formarem palavras reservadas, a
saber :
| & ; ( ) < > || && ;; ( ) | <newline> : :: <tab> ! case do done elif else
esac fi for function if in select then until while { } time [[ ]] . , / \//
Porém, as extensões facilitam a identificação de um arquivo, através da atribuição

constante de determinadas extensões a arquivos com conteúdos semelhantes, como as
seguintes:
• html - arquivos hipertexto

• txt - arquivos texto simples
• sh - executáveis shell
• log - arquivos de registro de algum programa
O utilitário file é usado para descobrir o tipo do arquivo, independente de seu nome.
Como no exemplo abaixo :
# file /bin/bash
/bin/bash: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for
GNU/Linux 2.2.0, dynamically linked (uses shared libs), for GNU/Linux
2.2.0, stripped
2.6. O servidor web apache
Para que os usuários de computador, usando um programa navegador qualquer,

possam ler uma página de um site da Internet, o navegador deve poder obter esta página, suas
figuras, texto e outros componentes visualizáveis e de controle. Estes dados, quando não
estão gravados na própria máquina do usuário, vêm de outros computadores da Internet. Estes
possuem programas que tem a capacidade de responder a protocolos específicos de
comunicação e entregar à máquina do usuários os dados necessários. Estes programas são
chamados servidores web.
Além da capacidade de servir texto e imagens estáticas, estes servidores web podem, a
partir da execução de outros componentes de software e de arquivos específicos, também
executar aplicações e realizar a entrega de páginas dinâmicas, de conteúdo variável conforme
valores previamente especificados ou armazenados. Nesta categoria está o servidor web
Apache.
2.6.1. Histórico
Conforme a Apache Software Foundation, as origens do servidor web apache

remontam à 1995 quando o mais usado servidor web era o NCSA web server, da National
Center for Super Computing Aplications (EUA), no momento em que seu principal
desenvolvedor abandona o projeto e o desenvolvimento do software começa a parar. Neste
meio tempo, usuários do NCSA começaram a compartilhar suas próprias implementações do
servidor e a implantação de um fórum para organizar o código se tornou necessário. Este foi o
nascimento do The Apache Group. Este grupo, aproveitando parte do código original do
NCSA, cujo desenvolvimento estava paralizado, e dos códigos dos usuários criou o Apache
web server, que se tornou o servidor web mais usado após três anos destes fatos.
A versão inicial, 0.6.2, foi publicada em abril de 1995. A versão 1.0 foi
disponibilizada em primeiro de dezembro do mesmo ano. O Apache Group cresceu como uma
instituição sem fins lucrativos, cujo trabalho era feito completamente pela internet. Usuários
que não pertenciam ao grupo também contribuiam com o projeto, submetendo código ao
grupo para análise, que se aprovados em diversos testes, era incluído na distribuição do
servidor conhecido como Apache web server. O desenvolvimento deste software segue este
molde até os dias atuais.
A hoje conhecida como Apache software Foundation, disponibiliza para os usuários as

versões 2.2.3, 2.0.59 e 1.3.37 como as mais recentes revisões do servidor HTTP Apache, sob
a forma de executáveis para diversas plataformas de sistemas operacionais, como diversos
tipos e derivados de Unix, diversas versões de Windows da empresa Microsoft Corporation,
entre outros.
Conforme o site de pesquisas web NetCraft, o Apache é o servidor web usado por
62,52% de todos os sites ativos no mundo em agosto de 2006, o que corresponde a
57.906.817 de um total de 92.615.362 de sites. O segundo colocado é o IIS da Microsoft, com
27.905.439 de sites ativos. Em termos de servidores instalados, a pesquisa indica um total de

instalações de Apache HTTP Server de 27.891.065, correspondendo a 62,05% do
total.(Apache Software Foundation, 2007:p.1).
2.6.2. Principais características
Neste trabalho, são abordados assuntos relativos à versão 2.0 deste software, conforme
a Apache Software Foundation(2007) :
• Suporte à versão de protocolo HTTP 1.1 ;

• Configuração por arquivos texto simples ;
• Suporte a CGI 1.1 (Common Gateway Interface) ;
• Suporte a FastCGI ;
• Suporte a hosts virtuais ;
• Suporte a autenticação por HTTP ;
• Interpretador Perl integrado para programação CGI ;
• Suporte a scripts PHP ;
• Suporte a java servlets e java server pages (JSP) ;
• Servidor proxy integrado ;
• Suporte a Server Side Includes e Secured Socket Layer (SSI e SSL) ;
2.6.3. A licença apache
Diferentemente do sistema de licença do Linux, a GPLv2, o servidor HTTP Apache

usa a licença Apache, inclusa em anexo a este trabalho, que não impede que alterações
aplicadas ao código original do servidor HTTP Apache tenham licença diferente da usada no
software original. Ela impede explicitamente que indicadores da marca Apache sejam usadas
em propaganda das alterações, e diz que o código não é domínio público ou software gratuito.
É considerado software livre pois a licença garante os quatro princípios básicos necessários,
executar a qualquer fim, copiar, redistribuir e modificar o software. É distribuído pela Apache
software Foundation sem garantias, como é, e em caso de disputa legal por qualquer motivo a
licença de uso é revogada no momento da abertura do correspondente processo. (Apache
Software Foundation, 2007:p.1).
2.6.4. Instalação na distribuição Debian
Usa-se o sistema de pacotes da distribuição para a instalação do servidor, conforme

estes comandos :
#apt-get install apache2 apache2-common
Este comando instala o servidor e vários utilitários e arquivos de configuração, de

acordo com pré-configurações específicas para a distribuição.
2.6.5. Principais parâmetros de configuração
Como o servidor web Apache é concebido para propósito geral, a sua configuração
dependerá de sua destinação específica, e a título de exemplo, considera-se uma máquina
instalada em uma rede local, com sistema operacional Debian/GNU Linux instalado e
configurado para acesso a esta rede. O gateway da rede é a máquina com endereço
192.168.0.1, onde está disponível o serviço DNS. O servidor será instalado na máquina com
endereço 192.168.0.2, o domínio é exemplo.com.br e o nome da máquina será www. Haverá
apenas um servidor virtual, acessível na rede interna.
O conteúdo deste servidor encontra-se no diretório /var/www/www.exemplo.com.br .

A página inicial é index.html e o usuário dono dos processos do servidor é www-data.
A seguinte relação de arquivos deve ser alterada, em relação à instalação básica :
• /etc/hosts
• /etc/apache2/apache2.conf
• /etc/apache2/sites-enabled/000-default
No arquivo /etc/hosts é configurado o nome da máquina e o endereço de rede, para

resolução de nomes pelo servidor, como no exemplo:
192.168.0.2 www.exemplo.com.br
No arquivo /etc/apache2/apache2.conf são configuradas as diretivas aplicáveis ao

servidor de forma geral, entre elas :
• ServerRoot /etc/apache2 - diretório dos arquivos de configuração

• User www-data
• Group www-data - usuário e grupo que executará os processos responsáveis
pelas respostas aos usuários
• ErrorLog /var/log/apache2/error.log - arquivo que armazena eventos de erro
durante a execução dos processos
• Include /etc/apache2/mods-enabled/*.conf - diretiva que inclui a este arquivo
outros arquivos de configuração, neste exemplo os arquivos de configuração de
módulos adicionais
• DirectoryIndex index.html - Diz ao apache qual será o arquivo entregue ao
usuário caso não seja especificado, ou seja apenas indicado o nome de um diretório
No arquivo /etc/apache2/sites-enabled/000-default é configurada a informação

principal do conteúdo e permissões de acesso, através de várias diretivas, para o caso de
exemplo ficará como se segue :
NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin webmaster@mario.exemplo.com.br
ServerName www.exemplo.com.br
DocumentRoot /var/www/www.exemplo.com.br
<Directory /var/www/www.exemplo.com.br>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
Allow from all
</Directory>
LogLevel warn
CustomLog /var/log/apache2/access.log combined
ServerSignature On
</VirtualHost>
2.6.6. Iniciando e parando o servidor
Usa-se o script /etc/init.d/apache2 para o controle do servidor, com o parâmetro start

para iniciar o servidor e stop para finalizar a sua execução. A execução na inicialização é
garantida pelo link criado na instalação, nos diretórios /etc/rc[1-6].d.
2.7. Bancos de dados
Segundo Alves(2004) informação é qualquer fato ou conhecimento do mundo real e

que pode ou não ser registrado/armazenado. Dado é a representação da informação, que pode
estar registrado em papel, num quadro de aviso ou no disco rígido do computador.
(Alves,2004:p.24).
Conforme Alves(2004), um banco de dados é uma coleção de dados com um

significado, representando uma porção do mundo real, ordenado logicamente, povoado para
um determinado objetivo, com usuários e meios para que estes possam manipular os dados.
Um gerenciador de banco de dados é uma coleção de ferramentas e programas que dão

a usuários meios de manipulação de bancos e de seus dados.
Um gerenciador de banco de dados relacional é caracterizado pelo fato de organizar os

dados em tabelas, formando colunas e linhas. Esta organização permite separar os dados em
conjuntos relacionados por assuntos.
Um gerenciador de banco de dados orientado a objetos caracteriza-se por permitir

armazenar no banco objetos complexos, com a definição tanto da sua estrutura como de seus
métodos. Um gerenciador objeto-relacional é a evolução de um gerenciador relacional, onde
os desenvolvedores adicionaram extensões SQL para permitir a manipulação de dados
complexos.(Alves,2004:p.25)
Serão apresentados tópicos específicos para instalação e gerenciamento básico dos

Sistemas Gerenciadores de Banco de Dados Relacionais MySQL e PostgreSQL, usados para
os sistemas de informações de exemplo em capítulos posteriores. Não serão abordados tópicos
específicos sobre linguagem SQL, pois cada SGBDR implementa uma sub-coleção específica
a uma determinada versão da norma ANSI/ISO SQL, que não é contemplada pelo foco do
trabalho.
2.7.1. Gerenciador de banco de dados MySQL
Conforme o manual da versão 4.1 do MySQL9, “o Programa de Banco de Dados

MySQL é um sistema cliente/servidor que consiste de um servidor SQL multi-tarefa que
suporta acessos diferentes, diversos programas clientes e bibliotecas, ferramentas
administrativas e diversas interfaces de programação (API's).”.
Este software implementa a linguagem ANSI/ISO SQL/92, é escrito em c/c++ com

ferramentas GNU Automake, Autoconf e LibTool para portabilidade, possui interfaces
clientes em linguagens c, c++, Eiffel, java, Perl, PHP, Python, Ruby e Tcl, possui suporte a
ODBC e está disponível para diversas plataformas de hardware e sistemas operacionais.
2.7.1.1. Licença
O MySQL está disponível como software livre, sob a licença GPL, mas para
aplicações onde o software que inclua o MySQL não seja livre, deve ser adquirida uma
licença de uso.
2.7.1.2. Instalação na distribuição Debian
Usando o sistema de pacotes da Debian, o comando a seguir instala o programa

servidor e suas dependências:
#apt-get install mysql-server-4.1
Após a execução deste comando, um servidor MySQL já estará em execução, não

acessível pela rede local, se existir, apenas pelo endereço 127.0.0.1 ou localhost.
Para a correta utilização, são necessárias configurações após a instalação, conforme o

manual da versão 4.1, executando os seguintes comandos:
• #mysql_install_db – conforme o manual de instalação da versão 4.1,

“mysql_install_db cria seis tabelas (user, db, host, tables_priv, columns_priv e func)
no banco de dados mysql. De forma resumida, estes privilégios permitem que o
9 Disponível em <http://www.mysql.org>. Acesso em 23/05/2007.
usuário root faça qualquer coisa no MySQL, e permitem a qualquer um criar ou usar
bancos de dados com o nome 'test' ou iniciando com 'test_' .”(MySQL AB,2007:p.1);
• #mysqladmin -u root password nova_senha - configura a senha para o usuário
root, permitindo apenas que este usuário tenha privilégios irrestritos sobre o servidor.
Para que o MySQL possa ser acessado por outras máquinas da rede, é necessário
configurar o arquivo /etc/mysql/my.conf, na diretiva bind-address, que vem configurada para
que apenas a máquina local possa efetuar conexões. Adiciona-se diretivas bind-address para
endereços de interfaces da máquina para as quais se necessita que o servidor possa responder
a conexões. Caso seja necessária conexão também pela rede local, e a interface de rede da
máquina possua o endereço 192.168.0.1, deve-se adicionar a seguinte linha após a diretiva
existente e reiniciar o servidor:
bind-adress = 192.168.0.1
2.7.1.3. Gerenciando bases de dados
O usuário root ou um usuário com privilégio CREATE pode criar um banco de dados,
onde poderão ser criadas tabelas para armazenar dados. Quando um banco é criado, não
existem tabelas e portanto apenas um subdiretório é criado no diretório de dados configurado
para o MySQL, onde as tabelas neste subdiretório corresponderão a arquivos. O banco é
criado usando o comando SQL CREATE DATABASE <nomedobancodedados>, mas pode-
se criar um banco de dados com o utilitário mysqladmin, com a seguinte sintaxe :
#mysqladmin create <nomedobancodedados>
Para se remover um banco de dados, usa-se o comando SQL DROP DATABASE

<nomedobancodedados>, ou o utilitário mysqladmin com a seguinte sintaxe:
#mysqladmin drop <nomedobancodedados>
Estes comandos para deletar bancos de dados apagam todas as tabelas existentes do
banco e então o remove. Se o banco de dados for um link simbólico, o link e o original são
deletados.
2.7.1.4. Gerenciando usuários
Existem dois métodos para se manipular usuários ao servidor MySQL, acessando

diretamente as tabelas de permissões ou usando o comando GRANT. No segundo modo,
primeiro conecta-se ao servidor usando o cliente mysql, em seguida usa-se o GRANT com os
parâmetros como necessário, lembrando-se que para manipular usuários, deve-se conectar ao
servidor com um usuário com privilégio administrativo reload e insert no banco de dados
mysql. Como no exemplo:
#mysql -u root mysql -p

mysql>GRANT ALL PRIVILEGES ON banco.* TO mario@localhost IDENTIFIED BY
'alguma_senha' WITH GRANT OPTION;
mysql>GRANT ALL PRIVILEGES ON banco.* TO mario@'%' IDENTIFIED BY

'alguma_senha' WITH GRANT OPTION;
Isto criará o usuário mario com acesso total ao banco banco e os dois comandos
GRANT são necessários pois se não for adicionada a entrada com localhost, a entrada para o
usuário anônimo para localhost que é criada por mysql_install_db toma precedência na
conexão ao banco a partir da máquina local, porque ele contém um campo Host com um valor
mais específico e também vem antes na ordenação da tabela user, e então a conexão do
usuário criado é negada.
Para se deletar um usuário do MySQL, revoga-se todos os direitos do mesmo com o

comando REVOKE, que podem ser listados com o comando SHOW PRIVILEGES, e então
remove-se o mesmo com DROP USER, note-se que este comando só pode ser aplicado a
usuários sem privilégios.
2.7.1.5. Iniciando e parando o servidor
Executa-se o script /etc/init.d/mysql para o controle do servidor, usando a opção start

para iniciar o servidor e stop para parar o mesmo. A execução na inicialização é garantida
pelo link criado na instalação, nos diretórios /etc/rc[1-6].d.(MySQL AB,2007:p.1).
2.7.2. Gerenciador de Bancos de Dados PostgreSQL
Conforme o PostgreSQL Global Development Group(2007), PostgreSQL é um

gerenciador de banco de dados objeto-relacional, Baseado no Postgres versão 4.2
desenvolvido pela Universidade da Califórnia (EUA), no Departamento de Ciências da
Computação de Berkeley. É um software livre descendente do software original de Berkeley,
que suporta os padrões SQL92 e SQL99, com modernas implementações para bancos de
dados e devido à sua licença liberal pode ser usado, modificado e distribuído por qualquer um,
livre de taxas, para qualquer propósito, privado, comercial ou acadêmico.
2.7.2.1. História
O ancestral do PostgreSQL é o Ingres, desenvolvido pela Universidade de Berkeley

(EUA), entre 1977 a 1985. Este código original foi posteriormente desenvolvido pelas
empresas Relational Technologies e Ingres Corporation, que resultou no primeiro banco de
dados relacional comercialmente bem sucedido. Ainda em Berkeley, Michael Stonebraker
liderou um time de desenvolvimento no projeto de um banco de dados objeto-relacional
chamado Postgres, entre 1986 e 1994. A empresa Illustra a partir deste código desenvolvido
tornou o Postgres um produto comercial.
Dois estudantes de Berkeley, Jolly Chen e Andrew Yu, adicionaram posteriormente

capacidades de linguagem SQL ao código do Postgres, resultando no projeto Postgres95, e
após saírem de Berkeley Chen continuou o desenvolvimento do Postgres95 a partir de uma
lista de discussão.
Em 1996 ficou clara a demanda por um banco de dados de código aberto, e um time
para seu desenvolvimento estava formado.
Em 1996 o nome do projeto foi alterado para PostgreSQL, em homenagem ao código

de Berkeley e a suas capacidades SQL, sendo o código mantido em um servidor CVS para
todos pudessem mater cópias atualizadas sem ter que baixar todo o código diariamente. Havia
lançamentos de novas versões a cada três a cinco meses.
A base de usuários expandiu-se rapidamente quando a Red Hat incluiu o PostgreSQL

em sua distribuição.
Hoje, o PostgreSQL é conhecido como uma alternativa de código aberto para projetos
onde é necessário um gerenciador de banco de dados estável, escalável e confiável, o que foi
conseguido pelo modelo de desenvolvimento aberto onde usuários podem contribuir com
código, sugestões de melhorias e relatórios de falhas, diretamente ao time de desenvolvimento
do PostgreSQL.
2.7.2.2. Licença
O software é fornecido sob uma licença tipo BSD, clássica de software livre que
conforme parte do texto contido em arquivo da distribuição : "Permissão de uso, cópia,
modificação e distribuição desse software e sua documentação para qualquer propósito, sem
taxa, e sem um acordo escrito está concedida por esse meio, contanto que a nota da licença
acima, esse parágrafo e os dois parágrafos seguintes apareçam em todas as cópias.".
2.7.2.3. Instalação
Serão abordados tópicos específicos para a instalação do software na distribuição

Linux Debian. Para outras modalidades de instalações podem ser obtidas informações no site
oficial do projeto.
A versão disponível na Debian Sarge para instalação é a 7.4, sendo que a mais atual é
a 8.1.4, disponível para instalação nesta distribuição apenas por código fonte ou a partir de
scripts de automatização disponíveis no site oficial da distribuição instável. Será abordada a
instalação da versão 7.4, disponível nos cd's/dvd's da Debian Sarge.
O seguinte comando instala o gerenciador e o cliente local para o banco de dados, e

suas dependências :
#apt-get install postgresql postgresql-client
Após estes comandos, um usuário chamado postgres foi criado, o cluster foi
inicializado em /var/lib/postgresql/7.4/main, com a criação do banco inicial template1 que
servirá de base para criação dos outros bancos de dados, e o usuário postgres é o
administrador do banco.
2.7.2.4. Notas sobre segurança
O arquivo /etc/postgresql/7.4/main/pg_hba.conf contém as diretrizes de acesso no que

diz respeito a máquinas/redes e métodos de acesso ao servidor. No mesmo diretório, o arquivo
pg_ident.conf contém os mapas de usuários, relacionando um usuário do sistema operacional
a um usuário do gerenciador.
Na instalação padrão, o superusuário do sistema operacional pode a qualquer momento

iniciar uma sessão como postgres através do utilitário su, e então obter poderes sobre o
gerenciador como superusuário do mesmo. Igualmente, conexões externas à máquina da
instalação não são autorizadas, por definições no arquivo pg_hba.conf.
Estas configurações são suficientes em ambientes de desenvolvimento, mas para

instalações reais a proteção de acesso aos dados é imperativa. São os seguintes os passos para
habilitar mecanismo de autenticação para os usuários do banco, lembrando que mesmo para o
usuário administrador do gerenciador será exigida senha para conexão. Note-se que o neste
modelo simplificado de instalação, a qualquer momento o superusuário do sistema
operacional pode abrir sessão como postgres. Para todos os passos a seguir, é necessário estar
acessando o sistema como superusuário:
• alterando a senha do usuário postgres, para o s.o. (informar senha e confirmar):
#passwd postgres
• abrir sessão como usuário postgres
#su - postgres
• conectar ao gerenciador com o banco template1, ainda em modo inseguro
$psql template1
• alterar a senha do superusuário postgres no gerenciador
template1=#alter user postgres with password 'novasenha';

• fechar a conexão com o gerenciador
template1=#\q
• sair da sessão com usuário postgres
$exit
• finalizar a execução do gerenciador
#/etc/init.d/postgresql-7.4 stop
• alterar o arquivo /etc/postgresql/7.4/main/postgresql.conf:
de <tcpip_socket = false> para <tcpip_socket = true>
Isto habilita a porta 5432 para as interfaces de rede da máquina.
• alterar o arquivo /etc/postgresql/7.4/main/pg_hba.conf
de <local all all ident sameuser> para <local all all md5>
Isto fará com que o gerenciador exija a senha anteriormente alterada para a conexão de
qualquer usuário, quando o mesmo estiver abrindo uma sessão no gerenciador a partir da
máquina onde está instalado o mesmo.
Ainda neste arquivo, e dependendo da necessidade da instalação, adicionar esta linha

após a descrição da conexão de host local:
host all all 127.0.0.1 255.255.255.255 (md5 – original)

host all all 192.168.0.0 255.255.255.0 (md5 – adicionada)
Isto permite que máquinas da rede 192.168.0.0 possam abrir conexões com o
gerenciador. Deve-se então reiniciar o servidor e efetuar uma conexão com usuário postgres,
verificando a ação das opções alteradas :
#/etc/init.d/postgresql-7.4 start
#su - postgres
#psql template1 (informar senha)
template1=#\q
Confirma-se então o funcionamento da validação do usuário através de senha.
2.7.2.5. Gerenciando Bancos de Dados
Uma instância do gerenciador PostgreSQL em execução pode gerenciar um ou mais

bancos de dados, que é o mais alto nível da hierarquia estrutural de objetos deste gerenciador.
Precisamente, um banco de dados do PostgreSQL é uma coleção de esquemas, e cada
esquema contém tabelas, funções, entre outros objetos. A coleção dos bancos gerenciados
pela instância é chamada cluster.
Durante a conexão de um usuário ou aplicação, é necessário a especificação do banco

de dados, e não é permitido o acesso a outros bancos na mesma conexão, mas é permitido
acessar outros esquemas do mesmo, e é permitido efetuar várias conexões simultâneas cada
uma acessando um banco diferente.
A inicialização da área de armazenamento de dados pelo gerenciador é realizada na

criação do primeiro banco, através do utilitário initdb. Este cria o banco chamado template1,
que servirá de base para todos os bancos criados subseqüentes. Então, qualquer alteração
neste banco refletirá nos bancos criados após a alteração. Não é permitido o uso do utilitário
após a criação do primeiro banco.
Para a criação de um banco de dados o usuário deve ter a permissão <create database>,
e estar conectado ao gerenciador. O comando a seguir cria um banco cujo dono será o usuário
que o executar :
template1=#create database teste;
Essencialmente, o banco de dados template1 é clonado, e portanto este não deve ser
usado para trabalhos reais. Outros bancos podem ser criados como base, e passados como
parâmetro na criação dos bancos reais.
Para conveniência, o utilitário createdb pode realizar a criação de bancos de dados, e o

dono do banco criado será o usuário que executou o comando, se o mesmo possuir a devida
permissão ou um erro será gerado. Também é possível para superusuários do gerenciador
criar bancos para outros usuários, como no exemplo:
# createdb --owner jose estoque
Este comando cria o banco estoque, e o dono do banco será o usuário jose.
Para a remoção de bancos de dados, é usado o comando <drop database>. Somente

pode ser executado pelo dono ou pelo superusuário, e esta operação não pode ser desfeita.
Não se pode estar conectado ao banco a ser removido ou a operação não será permitida,
podendo-se estar conectado a qualquer outro, inclusive o template1.
O utilitário dropdb fornecido para conveniência realiza a tarefa da mesma forma que o
comando SQL. O usuário corrente ou outro especificado como parâmetro com a devida
permissão pode executá-lo. O comando a seguir ilustra o comando:
# dropdb --username postgres --password estoque
O superusuário postgres removerá o banco estoque, e para isto será exigida sua senha.
2.7.2.6. Gerenciando usuários
Cada cluster contém uma coleção de usuários, que são independentes dos usuários do
sistema operacional onde o gerenciador está sendo executado. Usuários podem ser donos de
objetos, como tabelas, e podem conceder permissões a outros usuários para seus objetos.
É conveniente manter relação entre usuários do sistema operacional e do gerenciador,

mas não exigido, e seu nome é visível por todo o cluster.
Apenas o superusuário do gerenciador pode criar outros usuários, podendo conceder

ao mesmo permissões já no momento de sua criação, como criação de bancos de dados com a
permissão CREATEDB. Esta criação pode ser feita com comandos SQL ou com o utilitário
createuser, como no exemplo:
# createuser --adduser --encrypted --pwprompt -U postgres -W mario
Este comando cria o usuário mario, conectando ao banco como usuário postgres. É
exigida a senha do usuário postgres e o sistema pede a senha para o usuário mario que será
gravada criptografada. O usuário criado tem perfil de superusuário.
Para remover um usuário, é usado o comando SQL DROP USER ou o utilitário

dropuser. Tanto o usuário quanto os bancos de dados pertencentes ao mesmo são excluídos, e
a operação somente pode ser executada por um superusuário, como no exemplo:
# dropuser -U postgres -W jose
O superusuário postgres removerá o usuário jose e todas as bases de dados

pertencentes ao mesmo, exigindo a senha do superusuário para realizar a operação.
2.7.2.7. Iniciando e parando o gerenciador
Executa-se o script /etc/init.d/postgresql-7.4 para o controle do servidor, usando a

opção start para iniciar o servidor e stop para parar o mesmo. A execução na inicialização é
garantida pelo link criado na instalação, nos diretórios /etc/rc[1-6].d.
2.7.2.8. Configuração do gerenciador para conexões seguras
Se o gerenciador tiver sido compilado com a opção de SSL (Secure Socket Layer),
então conexões seguras podem ser habilitadas alterando a opção ssl para true no arquivo
postgresql.conf. O pacote de software OpenSSL deve estar instalado para que conexões
criptografadas possam ser estabelecidas.
Para que a conexão possa ser estabelecida, um certificado de autenticidade do servidor

deve existir, e fornecido por uma autoridade certificadora reconhecida que ateste sua
veracidade.
Para efeitos de teste, um certificado local pode ser gerado, com os seguintes
comandos:
#openssl req -new -text -out server.req
Este comando cria um certificado auto-assinado, cuja senha pode ser deixada em
branco, mas necessita de uma frase-senha. Esta frase é solicitada na inicialização do
gerenciador, o que pode se tornar um inconveniente, e pode ser retirada com os seguintes
comandos :
#openssl rsa -in privkey.pem -out server.key

#rm privkey.pem
#openssl req -x509 -in server.req -text -key server.key -out server.crt
#chmod og-rwx server.key
Devem ser fornecidas as informações conforme forem solicitadas, e então os arquivos

server.key e server.crt podem ser copiados para o diretório de dados do gerenciador, que então
deve ser reiniciado para validar estas configurações.
Quando a certificação de clientes é requerida, seus certificados devem incluídos no

arquivo root.crt, e então sua autenticidade é verificada na solicitação de conexões. Na
ausência deste arquivo, conexões seguras podem ser estabelecidas, mas sem autenticação do
cliente.(PostgreSQL Global Development Group, 2007:p.1).
2.8. Principais linguagens de programação
Serão abordados tópicos referentes a manipulação dos ambientes para utilização das
linguagens, como instalação e configurações específicas, de modo a permitir a usabilidade
destas no sistema operacional Debian GNU/Linux, como obter ajuda no sistema e algumas
fontes de ajuda na Internet. Não serão abordados conceitos sobre lógica de programação,
orientação a objetos ou explicações sobre especificidades de cada linguagem, pois fugiriam ao
foco do trabalho.
Linguagem de programação é a relação de comandos, ferramentas e padronizações que

permitem que um conjunto de instruções padronizadas com um determinado objetivo possam
ser convertidas em arquivos binários, executáveis por um computador. Estas instruções
padronizadas, organizadas em arquivos no computador, são chamadas código-fonte.
A geração de arquivos binários executáveis é conhecida por compilação, composta

pelos passos pré-processamento, criação de arquivo-objeto e linking. No pré-processamento, o
arquivo com o código-fonte é analisado, e a partir de diretivas incluídas no código é criado
um código-fonte modificado próprio para ser enviado ao gerador de arquivo-objeto. A
compilação realmente acontece na criação do arquivo-objeto, que é a tradução do código-
fonte modificado em linguagem binária. O arquivo executável é finalizado com o linking, que
une o arquivo binário gerado com as bibliotecas requisitadas pelo código original.
Não são todas as linguagens que geram arquivos finais diretamente executáveis. Por
exemplo, java é uma linguagem caracterizada por gerar um código intermediário, conhecido
por byte-code, que deverá ser executado por uma máquina virtual java ( uma espécie de
interpretador) para produzir os efeitos de um programa. Outras linguagens como PHP e Shell
Script, não geram executáveis, mas são interpretadas no momento da execução a partir de
recursos presentes no sistema operacional.
2.8.1. A linguagem C/C++
Conforme Schildt(1998), a linguagem C foi inventada e primeiramente implementada

por Dennis Ritchie na década de 1970 em um computador DEC PDP-11 visando melhorar o
então sistema operacional Unix. Foi o resultado do desenvolvimento da linguagem BCPL de
Martin Richards e influenciada pela B de Ken Thompson. Sua primeira descrição foi no livro
The C Programming Language de Brian Kernighan e Dennis Ritchie, publicada pela Printice-
Hall em 1978. A linguagem hoje tem padronização publicada desde 1990 pela ANSI e
adotada posteriormente pela ISO, respectivamente American National Standard Institute e
International Standards Organization, padrão conhecido como ANSI/ISO C.
C é conhecida como linguagem de nível médio, por combinar elementos de

programação de alto nível com o controle e flexibilidade da linguagem assembly, e é
considerada estruturada por permitir a compartimentalização do programa, separando e
escondendo do resto do programa as instruções e dados necessários à realização de uma tarefa
específica. Os programas são construídos a partir de 32 palavras-chave padronizadas pela
ANSI/ISO C. A biblioteca padrão C fornece uma coleção de funções utilizáveis por qualquer
programa, e mais funções podem ser acrescentadas adicionando-se bibliotecas.
C++ é a evolução do C, com a introdução de orientação a objetos à linguagem, cujas

primeiras extensões foram inventadas por Bjarne Stroustrup em 1979, que então chamou a
linguagem de “C com Classes”, alterando o nome para C++ em 1983. Foram introduzidas a
biblioteca de Classes (de Bjarne Stroustrup) e a Standard Template Library (STL, de
Alexander Stepanov), padronizada em 1997 e chamada ANSI/ISO C++.(Schildt, 1998:p.37).
Sistemas operacionais Unix são ambientes de excelência para programação em C/C++,

pois a linguagem e o sistema operacional estão intimamente ligados, e as ferramentas para
trabalhar com a linguagem são fornecidas por padrão. São elas, editores de texto,
compiladores, assembladores, bibliotecas padrão, depuradores, entre outras.
2.8.1.1. Ferramentas básicas para C/C++ em Linux
O principal objetivo do projeto GNU é o de fornecer um sistema operacional livre e

completo. Para isto, seria necessário um compilador livre para que os programas pudessem ser
construídos. Desta necessidade nasceu o GCC, primeiramente conhecido como GNU C
Compiler, e hoje como GNU Compiler Collection, que fornece o ambiente completo para que
os programadores construam seus programas em C/C++ e outras linguagens. Este compilador
é fornecido por padrão praticamente em toda distribuição Linux, mas será nosso foco sua
instalação e uso na distribuição Debian GNU/Linux.
Para se instalar o compilador e ferramentas necessárias, usa-se o sistema de pacotes da

Debian, o APT. A relação de pacotes necessária ao ambiente de programação mínimo C/C++
pode ser instalada com o seguinte comando;
# apt-get install gcc g++ binutils bin-utils-dev libstdc++5-3.3-dev libtool

make
2.8.1.2. Programa exemplo
Para ilustrar, considera-se o seguinte código, gravado no arquivo de nome alomundo.c:

#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Alo mundo\n");
return(0);
}
Para criar o executável do programa, executa-se o seguinte comando :
# gcc -o alomundo alomundo.c

Este comando instrui o compilador a ler o arquivo alomundo.c, pré-processar,
compilar e ligar o executável às bibliotecas, criando um arquivo executável chamado
alomundo. Este arquivo pode ser executado apenas digitando-se seu nome no aviso de
comando, como no exemplo:
# ./alomundo
Alo mundo
Programas podem evidentemente ser muito mais complexos, e a tarefa de compilação

pode se tornar igualmente complexa pois o programa pode conter vários arquivos-fonte com
inúmeras dependências. Raramente um programa é projetado para uso em apenas um
computador, e por isso a sua compilação em outros computadores pode ficar impedida pela
falta de uma determinada biblioteca. Outros fatores como versões de bibliotecas e
ferramentas, localização destes e especificidades do sistema também são complicadores, mas
ferramentas do projeto GNU auxiliam na distribuição destes códigos-fonte, permitindo a
verificação do ambiente e gerando arquivos de parâmetros para o sistema de compilação.
Além do método de pacotes da Debian e de outras distribuições, programas podem ser

distribuídos a partir de seu código-fonte. Estes programas podem requerer bibliotecas além
das que podem estar instaladas no sistema, e para esta situação a Debian possui um utilitário
que auxilia na solução destas dependências, possibilitando a correta compilação destes
códigos-fonte, em conjunto com as ferramentas GNU.
O método independente de distribuição Linux para se instalar programas consiste em

três passos, a saber configure, make e make install, derivados do uso das ferramentas GNU,
entre elas Autoconf, Automake e outras.
2.8.2. A linguagem Perl
A Practical Extraction and Reporting Language foi criada por Larry Wall, com sua
versão 1.0 disponibilizada em 18 de dezembro de 1987. Conforme Robert(2007)10, Perl é uma
linguagem de programação de propósito geral de alto nível originalmente criada para
manipulação de textos e atualmente usada para diversas tarefas como administração de
sistemas, desenvolvimento para web, programação para rede, entre outras. Ainda, Robert diz
que a intenção da linguagem é de ser prática ao invés de elegante, que suporta programação
estruturada e orientada a objetos, que tem suporte interno poderoso a processamento de textos
e tem uma impressionante coleção de extensões desenvolvidas por terceiros.(Robert,
2007:p.1).
Será abordada a instalação de pacotes específicos para a linguagem na distribuição

Debian, assim como o módulo para utilização pelo servidor web Apache 2.0 e sua respectiva
configuração.
2.8.2.1. Ferramentas básicas para Perl em Linux
Perl é incluído por padrão em praticamente toda distribuição GNU/Linux, devido à

extensa lista de scripts de diversos propósitos escritos nesta linguagem. Além do Perl,
muitos módulos de extensão são requeridos. A instalação básica do Perl segue o sistema de
pacotes APT :
#apt-get install perl perl-base perl-modules libapache2-mod-perl2
Este comando instala o ambiente mínimo para a execução do Perl, resolvendo

possíveis dependências. A instalação de módulos segue o mesmo padrão, podendo o nome
correto do pacote ser encontrado através de sites de busca, pelo uso do utilitário apt-file, ou
pelo programa synaptic, este em ambiente gráfico. Como no exemplo:
#apt-get install libnet-perl
Outro método para instalação de módulos Perl é através do utilitário CPAN. Este
utilitário copia o arquivo com o código-fonte do módulo do repositório oficial de módulos
10 Disponível em <http://perldoc.perl.org/perlintro.html>, Acesso em 21/03/2007.

CPAN.org, os descompacta, resolve dependências de outros módulos, compila e instala, em

uma só operação, de acordo com interação com o usuário. Mas para que o utilitário possa ser
usado, um conjunto mínimo de pacotes deve estar instalado para permitir a funcionalidade do
mesmo. O comando a seguir instala as dependências do utilitário que não são módulos Perl:
#apt-get install unzip make lynx wget ncftp ftp less gcc
E então um módulo pode ser instalado pelo utilitário, como no exemplo:
#perl -MCPAN -e 'install "Event"'
Este comando efetua a configuração inicial do utilitário, caso nunca tenha sido usado,
atualiza a lista de módulos disponíveis, e então copiará o módulo Event de CPAN.org ou de
outro repositório configurado.
Um programa em Perl é essencialmente um arquivo texto, composto por comandos

Perl. Este arquivo pode conter uma linha inicial com o caracter especial #!, seguido do
caminho do interpretador Perl instalado, conhecido por shebang, ou não. No caso de não
conter, o arquivo é enviado diretamente ao interpretador Perl como um parâmetro, que o
compila e o executa. No caso de conter o caracter especial #!, o próprio arquivo é executado,
e neste momento o interpretador de comandos reconhece o caracter especial, e envia o
restante do arquivo ao interpretador indicado logo após o shebang. Considera-se o arquivo
alomundo.pl, com o seguinte conteúdo:
#!/usr/bin/perl
print "alo mundo!\n";
Este arquivo deve receber a permissão de execução, e então executado:
#chmod +x alomundo.pl
#./alomundo.pl
Alo mundo!
No arquivo, a primeira linha indica a localização do Perl para o interpretador de

comandos, que reconhece o caracter shebang e envia o resto do arquivo ao Perl. O seguinte
comando produziria o mesmo efeito, mas em uma única linha:
#perl -e 'print “Alo mundo!\n”'

Alo mundo!
2.8.3. A linguagem PHP
Conforme o The PHP Group(2007), PHP, ou PHP Hipertext Preprocessor, é uma

linguagem criada para construção de web sites dinâmicos e interativos, que descende da
PHP/FI criada por Ramus Lerdorf em 1994. Andi Gutmans e Zeev Suraski em 1998, em
cooperação com Ramus lançaram a versão 3.0, a mais parecida com as atuais versões. Em
maio de 2000 foi lançada a versão 4, e a revisão lançada no momento da edição deste trabalho
é a 5.1.6, de 24 de agosto de 2006. Ela tem as seguintes principais características :
• Multi-plataforma : um código em PHP pode ser executado em sua maioria sem

alterações em diversas plataformas de sistemas operacionais, como Linux e Windows;
• Embutido : o código PHP normalmente é mesclado ao código HTML que compõe
uma página web;
• Executado no servidor : o programa é executado no lado do servidor, especificamente
um servidor web;
• Uma linguagem de script : presentes nas páginas que serão processadas e entregues ao
navegador do usuário, os códigos PHP são executados pelo servidor que entrega ao
usuário apenas o resultado do processamento.
Como é uma linguagem de script, não é compilada, e portanto não são gerados
executáveis binários. Mas PHP não é apenas executado em servidores web, e pode ser usado
em scripts para diversos propósitos com o interpretador PHP em aviso de comandos. Tarefas
de administração, aplicações diversas e programas com interface gráfica podem ser
implementados em PHP, com ajuda de extensões.
À época da edição deste trabalho, PHP estava em sua versão 5, que implementava
integralmente conceitos de orientação a objetos, mas a versão 4 permanecia igualmente
utilizada. O principal local de informações e códigos sobre a linguagem é o site php.net11. O

PHP 5 utiliza códigos desenvolvidos pela Zend Tecnologies Ltd. e de outros contribuidores e
é considerado software livre, conforme os termos de sua licença, a licença PHP.(The PHP
Group, 2007:p.1).
2.8.3.1. Instalação
Serão abordados tópicos sobre sua instalação na distribuição Debian GNU/Linux, mas
a partir de informações que podem obtidas no site oficial da linguagem, PHP pode ser
instalado em diversas outras plataformas. Estão disponíveis as versões 4 e 5 para a Debian
através de seu sistema de pacotes APT, mas será abordada a instalação da versão 4. O
seguinte comando instala os pacotes básicos da linguagem e seu módulo para o servidor web
apache 2 :
#apt-get install php4 php4-cli php4-pgsql php4-mysql php4-odbc libapache2-

mod-php4
Após a instalação dos pacotes, deve-se habilitar as extensões para os bancos de dados
MySQL e PostgreSQL, tanto para o módulo do apache quanto para o interpretador da linha de
comandos. O arquivo de configuração do módulo do apache é /etc/php4/apache2/php.ini e o
do interpretador PHP para linha de comando é /etc/php4/cli/php.ini, devendo-se alterar a
seguinte linha :
;extension=mysql.so
Para as seguintes, incluindo o suporte ao PostgreSQL:
extension=mysql.so
extension=pgsql.so
Pode-se testar tanto o ambiente em linha de comando quanto o módulo do apache com
o seguinte trecho de código, gravado no arquivo info.php :
11 Disponível em <http://www.php.net>, Acesso em 21/03/2007.

<?
phpinfo();
?>
Em linha de comando, pode ser assim executado :
#php info.php
Isto produzirá a relação de todos os parâmetros de configuração da compilação,

extensões habilitadas e variáveis de ambiente do interpretador PHP como resultado.
Igualmente, o apache pode processar o arquivo, resultando na mesma relação de parâmetros,
porém entregue a um navegador web qualquer. Para executar, o arquivo deve ser gravado em
algum diretório de documentos do servidor web, e chamado relativamente ao diretório
gravado pelo navegador. Considerando que o arquivo tivesse sido gravado na raiz de
documentos do servidor web, e acessado a partir da própria máquina onde o servidor está
instalado, a URL digitada no navegador seria <http://localhost/info.php>, e a mesma relação
seria mostrada na janela do navegador.
2.8.4. A linguagem Java
Conforme a Sun Microsystems(2007), a linguagem Java descende da linguagem Oak,

criada pela equipe “Green team” liderada por James Gosling no “The Green Project”, da Sun
Microsystems, em 1991. Trancados em um escritório anônimo, trabalharam por 18 meses e o
resultado foi uma linguagem não atrelada a dispositivos.
Mais que uma linguagem, Java é uma plataforma. Composta por um interpretador
conhecido como máquina virtual java e pela java API (aplication programming interface),
está disponível para diversas plataformas de sistemas operacionais e arquiteturas de hardware.
Java é portável, ou seja, um programa java poderá ser executado nas mais diversas
plataformas para as quais exista uma máquina virtual.
Java é marca licenciada da Sun Microsystems Inc., que permite através do

licenciamento de seus produtos, o uso dos mesmos para o desenvolvimento e execução de
programas, com algumas restrições. (Sun Microsystems,2007:p.1).
Além da implementação da Sun, existem plataformas Java de código aberto, como o

projeto Classpath e GCJ da GNU, e o Kafee do Kafee.org.
2.8.4.1. Ferramentas básicas para Java em Linux
Serão abordados tópicos para instalação do ambiente de desenvolvimento (JDK) e do

ambiente de execução (JRE) a partir dos programas disponibilizados pela Sun, pois permitem
o desenvolvimento de aplicações cujo licenciamento dependerá do desenvolvedor. À época da
edição deste trabalho, a versão corrente do JDK e do JRE é 1.5.0_8 .
O ambiente de execução (JRE) pode ser obtido em <http://java.sun.com> , tendo sido

obtido para efeitos deste trabalho o arquivo jre-1_5_0_08-linux-i586.bin. Conforme
instruções de instalação do site oficial, o arquivo deve ter recebido a permissão de execução e
ser executado a partir do diretório onde se deseja instalar o JRE. São os seguintes comandos,
assumindo que se deseja instalar no diretório local, e o arquivo está no mesmo :
#chmod +x jre-1_5_0_08-linux-i586.bin
#./jre-1_5_0_08-linux-i586.bin
Após a leitura dos termos de licença, o instalador descompacta no diretório local a

estrutura provida pelo pacote. Dentro do diretório jre1.5.0_06 está tudo o necessário para a
execução de aplicativos Java já compilados. Porém, visível apenas para o usuário que efetuou
a instalação ou a quem mais possuir permissão de leitura e execução no diretório do usuário.
Para a instalação visível a todos os usuários, este diretório criado deve estar em um
diretório visível globalmente, por exemplo /usr/share. Move-se ou copia-se o diretório criado
pelo instalador para este, porém são necessários poderes de superusuário, como no exemplo :
#mv jre1.5.0_06 /usr/share/
Necessário para todos os usuários, uma variável de ambiente JAVA_HOME contém o

local onde estão as classes java necessárias à máquina virtual, e na variável de ambiente
PATH o local dos executáveis instalados anteriormente, para que não exista necessidade de
especificar o caminho completo da máquina virtual java a cada execução. Estas variáveis
podem ser definidas globalmente ou para o usuário que instalou o pacote. Para apenas o
usuário o arquivo .bashrc no diretório raiz do usuário contém as suas variáveis de ambiente, e
para visão global o arquivo /etc/bash.bashrc. Ao final de cada arquivo devem ser
acrescentadas as linhas a seguir :
#export PATH=/usr/share/jre1.5.0_05/bin:$PATH
#export JAVA_HOME=/usr/share/jre1.5.0_06
Para atualizar as variáveis de ambiente, executa-se :
#. /etc/bash.bashrc
A instalação do pacote de desenvolvimento JDK segue os mesmos termos, alterando-

se apenas os caminhos para os executáveis, de acordo com o diretório criado pelo instalador.
Considere o código abaixo, gravado no arquivo Alomundo.java :
import java.lang.* ;
class Alomundo
{
public static void main(String[] args)
{
nome = System.getenv("USER");
System.out.println("Bem vindo " + nome + "!\n");
}
}
O processo de compilação Java cria um código intermediário chamado bytecode, e
este é executado pela máquina virtual java. como no exemplo :
#javac Alomundo.java
#java Alomundo
Bem vindo mario!
2.8.5. Shell Scripting
Linux é conhecido como um sistema operacional multiusuário. Portanto, vários

usuários podem estar conectados ao sistema, ao mesmo tempo. A parte do sistema operacional
que gerencia estas conexões é o kernel, que estabelece um processo de conexão para cada
usuário, atribuindo a este usuário as devidas permissões sobre os recursos do sistema.
Quando um usuário estabelece uma conexão com o sistema, uma interface de

comandos lhe é apresentada. Esta interface é conhecida como shell. Este é um programa que
faz a ponte entre o usuário, seus comandos e os recursos do sistema, gerenciados pelo kernel.
Existem vários shells para Linux, alguns relacionados abaixo :

• BASH ( Bourne-Again SHell ), de Brian Fox e Chet Ramey, disponível na Free
software Foundation. O shell mais comum , padrão na maioria das distribuições
Linux;
• CSH (C Shell), de Bill Joy, disponibilizado pela Universidade da California (Berkeley,
para o BSD), sua sintaxe e uso são semelhantes à linguagem C;
• KSH (Korn Shell), de David Korn, disponibilizado pela AT & T Bell Labs;
• TCSH (TENEX C Shell), uma versão melhorada do Berkeley Unix C Shell.
O shell que o usuário usará na sua conexão é definido no arquivo /etc/passwd,

configurado durante a criação do usuário no sistema. Um exemplo de usuário é mostrado :
mario:x:1000:1000:mario,,,:/home/mario:/bin/bash
A última informação é de que o shell do usuário mario é o bash.
Quando um usuário efetua a conexão (login) no sistema, um processo (arquivo em

execução) é criado pelo kernel para gerenciar aquele usuário, e o mesmo pode então executar
comandos no sistema.
Este usuário pode criar um arquivo com os comandos desejados, que poderão ser
executados em sequência, inclusive com passagem de parâmetros para o mesmo, com uso de
variáveis para armazenamento de dados temporários, leitura de arquivos, execução de outros
programas, passagem de parâmetros durante a execução, e a saída deste processamento pode
ser direcionada a outros arquivos, programas, rede, outros usuários, entre outras facilidades.
Este fluxo de trabalho é conhecido como Shell Scripting.
Uma vez que o usuário possa efetuar uma conexão a um sistema Linux, o mesmo está
habilitado a criar scripts, se puder efetuar gravação de arquivos no seu diretório, ou outro do
sistema, ou a executar scripts de outros usuários, se possuir permissão para tal. Qualquer
comando interno do bash ou programa instalado no sistema que o usuário possua permissão
de execução pode ser usado em seus scripts.
Inúmeras tarefas de administração de sistema são feitas com o uso de scripts. Os

maiores exemplos são os scripts de inicialização do sistema, responsáveis por executar os
programas necessários durante a carga do sistema.
Shell Scripting é uma linguagem de programação, comparável aos arquivos BATCH

de sistemas operacionais como o DOS, porém com mais funcionalidades.
Considere a seguinte sequência de comandos, gravados no arquivo Alomundo.sh :
#!/bin/bash
#script de teste da linguagem
echo “Ola mundo!\n”
Para que este arquivo possa ser executado diretamente, deve ser concedida permissão
de execução ao mesmo, e então executado, conforme abaixo ;
#chmod +x Alomundo.sh
#./Alomundo.sh
Ola mundo!
3. SISTEMA DE GERÊNCIA DE BIBLIOTECAS KOHA
O capítulo apresentado é baseado no texto de Nicholas Rosasco e Erik Bakke, sobre o

estudo arquitetural publicado no site kohadocs.org12, a respeito do sistema Koha. O trabalho
original está licenciado sob a Licença Geral Pública GNU versão 2 ou posterior, e conforme
nota no texto original, o presente trabalho, derivado daquele original, deve seguir a mesma
linha de licenciamento, e portanto segue a licença GNU GPLv213.
Conforme Rosasco & Bakke(2004), o projeto Koha está se tornando popular para
bibliotecas pequenas e especializadas, ou aquelas com orçamentos pequenos, especialmente
para aquelas com necessidades de interfaces web ou padronizadas com baixo custo. Criado
originalmente para uso local da biblioteca, é encontrado agora entre coleções escolares e
institucionais como ferramenta de gerência da coleção. A aplicação provê funcionalidades
comparáveis a sistemas comerciais de gerência, mas não possui alguns dos aspectos mais
polidos encontrados em soluções fornecidas por corporações (incluindo imagem de
arquitetura e explicações de casos de uso). Koha tornou-se suficientemente simples e flexível
para que desenvolvedores locais possam extendê-lo e customizá-lo pela virtude da
“construção”, com mínimo de custos construindo sobre o conjunto existente.
3.1. Contexto
Koha é um sistema de catalogação e gerência de coleção. Inicialmente desenhado pela

Katipo Communications para a Horowhenua Library Trust (HLT), uma biblioteca na Nova
Zelândia. O coração da aplicação foi criado para gerenciar buscas pelo cliente, multas,
gerência de aquisições, e catalogação/acesso aos livros pela HLT.
12 Disponível em <http://www.kohadocs.org/Koha_arquiteture.html>. Acesso em 25/03/2007.

13 Disponível em <http://www.gnu.org/licences/gpl.html>. Acesso em 25/03/2007.
Como parte dos requisitos, a aplicação foi criada sob a GNU Public Licence. Desde a
implementação inicial, o sistema foi extendido por vários contribuidores, largamente
envolvidos com outras bibliotecas usando ou com interesse em usar a aplicação.
A filosofia inicial de desenvolvimento está expressa em uma entrevista transcrita e

hospedada em kohadocs.org14.
Informações adicionais foram recolhidas de vários sites relacionados ao sistema,

incluindo o Koha Developer Wiki15.
3.2. Requisitos
As necessidades da comunidade de usuários do Koha evoluíram com diversas versões

da aplicação. Elas podem ser agrupadas em largas categorias, baseadas na sua fonte e
natureza. Todos os requisitos e exigências foram refinados pelas necessidades do ambiente de
uma biblioteca.
3.2.1. O ambiente da biblioteca
Tanto a versão inicial quanto as posteriores do Koha vieram de encontro às

necessidades tanto da instalação da instituição quanto ao público a que serve. Isto significa
alguns requisitos básicos não unica e especificamente do Koha, mas de toda biblioteca de uso
geral, que nunca são explicitamente declarados, mas são comuns a todo sistema integrado de
biblioteca. Parte do sistema é uso do público em geral, que criou imperativos em diversas
categorias, enquanto que os componentes para os funcionários necessitariam resistir
cuidadosamente a um grupo descompromissado.
Adicionalmente, Horowhenua Library Trust (HLT), a biblioteca que financiou a

versão inicial do Koha, tinha interesses específicos solicitados à Katipo Communications, que
implementou a versão inicial do Koha, algumas implicando em sérios desafios.
14 Disponível em <http://www.koha.org/about/story.html>. Acesso em 25/03/2007.

15 Disponível em <http://wiki.koha.org/doku.php>. Acesso em 25/03/2007.
3.2.2. Requisitos e regras
● Robustez :
As interfaces públicas deveriam ser suficiente estáveis para suportar uma operação
errada (pergunta mal feita) que poderia causar a queda do sistema;
● Usabilidade :
O catálogo on-line público (OPAC, do original), deveria ser útil imediatamente ao
cliente esporádico;
● Performance básica :
A média das perguntas deve ser respondida suficientemente rápido para respeitar a
expectativa (quando for difícil atribuir quanto, deve existir um retorno contínuo se este
aspecto for negligenciado);
● Ocorrências de queda do sistema :

Ocorrências de queda devem ser minimizadas. O sistema de gerência de coleção é a
principal aplicação para a circulação de materiais, e se não funcionar efetivamente aleija a
biblioteca. Entretanto, após algumas horas, manutenção ou rotinas de limpeza são geralmente
aceitas, mas acesso 24 horas ao sistema é preferível.
● Retaguarda
Rotinas de retaguarda são necessárias : quase nenhuma coleção de biblioteca é
estática, então rotinas de acesso aos materiais devem ser suportadas e é aceitável que isto
requeira algum treinamento inicial.
● Inventário :
Veículo de inventário e sistema de relatório são necessários;
● Sistema de compras de livros :

HLT requisitou a inclusão de um sistema de controle para as compras, para simplificar
orçamento e disponibilização de livros:
● Filiais :
Koha deve ser capaz de lidar com operações em múltiplos locais. HLT possui
bibliotecas filiais acostumadas com um catálogo comum para as coleções distribuídas.
Conforme bibliotecas adicionalmente se interessaram pelo sistema, novas

funcionalidades foram sendo adicionadas. Estas ampliaram de itens relacionados a diferentes
locais a conformidade de padrões :
● interfaces modeladas, para customização visual;

● funcionalidade multilíngüe – um esquema simplificado para adaptar a tradução da
interface em múltiplas línguas foi considerada uma prioridade;
● um sistema de instalação simples, pois funcionários da Katipo não estão disponíveis
para viagens pelo mundo;
● suporte a sistemas operacionais alternativos ( principalmente Windows);
● conformidade ao padrão MARC ( MAchine Readable Cataloging ), permitindo o uso
tanto de variantes de catalogação Norte-Americanas quanto internacionais, como
substituto ao esquema próprio de registro bibliográfico;
● importação de registros MARC, permitindo o uso de bancos de dados de catálogos
públicos acessíveis para a fácil disponibilização de materiais. Idealmente, isto deve ser
realizado com acesso direto a estas bases de dados, o que requer suporte ao protocolo
Z39.50;
3.2.3. Regras de negócio
● Orçamento :
HLT é uma biblioteca de serviço local, e o esforço da Katipo devia encaixar-se no
orçamento, pois não havia uma base de clientes existente para distribuir custos;
● Custos operacionais :
Os resultados iniciais dos processos da HLT levam a uma condição de necessidade de
custos menores com comunicação;
● Interesses de manutenção :
Katipo Communications é uma pequena empresa local. Uma solução de suporte
contínuo foi desejada, como o tradicional contrato de suporte que várias bibliotecas tem com
os vendedores de seu sistema de gerência nem sempre possível.
3.2.4. Outras regras
● Tempo :
Não necessariamente um requisito, mas a primeira versão do sistema devia ser
entregue a tempo de substituir o sistema não compatível com o ano-2000.
3.3. Arquitetura
As exigências básicas e a evolução do Koha levaram à arquitetura em camadas de

composição encontrada na série Koha 2.x do Koha.
3.3.1. Z39.50 Componente cliente-servidor
Koha tem a opção de uso de um cliente Z39.50 (em configuração de cliente/servidor)

para recuperar registros MARC de repositórios acessíveis pela rede.
3.3.2. Componente cliente/servidor de funcionários
A versão original do Koha incluía um cliente não web para atividades dedicadas de
circulação, em parte para criar interfaces com scanners de código de barra de modo simples,
bem como permitir o trabalho com altos nível de tráfego, que não seria confortável com a
interface web.
Com a versão 2.0 do koha, este componente foi retirado, pois a interface web foi o
método aceito para atividades de circulação.
3.3.3. Núcleo do Koha
O núcleo do Koha é construído em torno de diferentes peças de software, trabalhando

em sintonia.
Figura 1 – Arquitetura do sistema de gerência de bibliotecas Koha
Fonte : <http://www.kohadocs.org/Koha_architecture.html>, acesso em 09/04/2007
3.3.3.1. OPAC , Componente HTTPD da intranet
O servidor web Apache é a ferramenta padrão que suporta o coração do sistema Koha,
um conjunto de scripts Perl que são a camada entre os funcionários e clientes e a retaguarda
do sistema. Estes scripts do Apache e os navegadores que mostram seus resultados são um
relacionamento cliente/servidor, como a maioria das aplicações para a web.
3.3.3.2. Funções do Perl
Estes scripts do lado do servidor são chamados pela extensão CGI do servidor Apache.
Todos os scripts são escritos em Perl. Estes são módulos Perl que acessam a interface do
banco de dados.
Todas as páginas html são geradas pelos scripts Perl. Um módulo padrão HTML Perl
gera as páginas baseadas em modelos HTML Perl. São em sua maioria como tags HTML e
JSP.
Há um conjunto de módulos Perl para a parte do OPAC do sistema e um conjunto

separado de módulos Perl para a parte intranet do sistema.
Os módulos Perl são fornecidos nos quatro pacotes seguintes com suas dependências :
Figura 2 – Componentes do Koha
Fonte : <http://www.kohadocs.org/Koha_architecture.html>. Acesso em 09/04/2007
● OPAC
Acesso dos clientes ao sistema Koha.
● INTRANET
Retaguarda e interface de trabalho do sistema.
● Deamons
Contém todos os scripts para todos os deamons no sistema.
● DB
Contém os scripts para acesso ao banco de dados para o sistema.
3.3.3.3. Pacote OPAC
Figura 3 – Componentes OPAC

O pacote OPAC contém dois componentes.
O Main-OPAC contém todos os scripts Perl e o HTML-OPAC contém todos os

modelos HTML para todas as páginas HTML para a parte Koha do sistema.
3.3.3.4. Pacote Intranet
Figura 4 – Pacote INTRANET

O pacote Intranet é composto por 9 componentes.
O componente Main-INTRANET contém todos os principais scripts Perl que

compôem a navegação, login, logout e provêm conexão com outros componentes.
O componente HTML-INTRANET contém todos os modelos HTML para todas as

páginas para o lado INTRANET do sistema.
O componente Bookshelves contém os scripts Perl que definem/descrevem as

prateleiras da biblioteca.
O componente Acquire contém os scripts Perl que tratam aquisições de livros e outros
materiais da biblioteca.
O componente Circulation contém os scripts que tratam o sistema de circulação da

biblioteca.
O componente Import and Export contém os scripts que tratam da importação e

exportação de dados para o sistema Koha.
O componente Report provê os scripts Perl para a geração de relatórios.
O componente Admin contém os scripts Perl para configuração a administração do

sistema Koha.
3.3.3.5. Pacote Deamons
Figura 5 – Pacote Deamons

Há nesta versão apenas um deamon, o z3950 deamon, no pacote Deamons. Este

componente provê a conectividade a servidores z3950 para respostas a perguntas de material
de biblioteca usando o protocolo z3950.
3.3.3.6 Pacote DB
Figura 6 – Pacote DB
O C4-Database-Wrapper provê os scripts Perl parta acesso aos dados do banco de

dados.
3.3.3.7. Componente camada de acesso ao banco de dados
As bibliotecas Perl DBI são usadas como camada de acesso para tratar conectividade
coma instância do gerenciador de banco de dados MySQL. É um módulo Perl padrão de
terceiros.
3.3.3.8. Banco de dados (MySQL)
O banco de dados é implementado usando atualmente MySQL.
Originalmente Koha é capaz de usar virtualmente qualquer gerenciador de banco de

dados, no entanto, o sistema tem crescido dependente de algumas funcionalidades avançadas
do MySQL. Isto fez aspectos óbvios com a camada de acesso, desde que todos eles
necessitam é de um serviço SQL na “ponta final”.
Os dois diagramas a seguir mostram uma visão dos esquemas de banco de dados e
provêm uma boa visão funcional do sistema koha.
Figura 7 – Esquema do banco de dados 1 de 2

Figura 8 – Esquema do banco de dados 2 de 2

3.4. Análise da aplicação
A arquitetura Koha dominante é baseada em cliente/servidor, usando um cliente leve

com navegador web conectado a um servidor HTTP. O servidor é pensado como uma camada
de acesso, onde o servidor web e os scripts Perl provêm acesso ao banco de dados
implementado com o MySQL.
Uma das questões a responder é quanto escalável é esta arquitetura. Baseada nesta
estrutura cliente/servidor, a aplicação deve escalar desde sistemas pequenos até sistemas
médios, no entanto, isto não foi quantificado em nenhum requisito.
A arquitetura sob a qual o Koha foi criado ajudaram seus usos mais do esperado
originalmente. As funções e decisões em torno dela merecem uma avaliação mais que
“primária” no modo de operar do Koha, ao passo de que se pareceu melhor no projeto
original.
3.5. Cenários de uso típicos
Serão demonstrados alguns casos de uso para o sistema.
3.5.1. Clientes
O componente mais visível do Koha é a interface do OPAC (Online Public Access

Catalog). Ele é acessado pelos clientes da biblioteca por um navegador web ( cuja aplicação
ou versão são desconhecidos) e tipicamente resultam na localização de um item em particular
pelo cliente, anotando esta localização por impressão ou outros meios, e indo até o local
retornado pela sua pesquisa.
Figura 9 – Caso de uso acessos do cliente

Figura 10 – Interface de pesquisa para o cliente

3.5.2. Funcionários
O projeto do Koha agrupa todas as funções de funcionários que não são objeto de
acesso pelos clientes em uma interface unificada, referenciada como o componente “Intranet”.
Esta é escondida do cliente (na prática) por ser acessada em uma porta diferente do servidor.
Com esta solução, o projeto limita a possibilidade de conexões de terminais de funcionários e

descobertas “acidentais” de funções restritas de funcionários (e permite maior segurança
adicionada ao componente Intranet se desejado). Pelo uso da mesma arquitetura
cliente/servidor para as duas interfaces de acesso, é permitida maior flexibilidade para os
funcionários na ocorrência de falhas de equipamentos ou atividades fisicamente dispersas.
Uma biblioteca tipicamente tem um terminal de acesso tradicionalmente acessado

pelos bibliotecários e especialistas em circulação, e um terminal de retaguarda, relacionado
aos trabalhos de circulação com a coleção.
Figura 11 – Interface de trabalho do funcionário

3.5.2.1. Funcionário de circulação e referência
O funcionário de atendimento da biblioteca usa o Koha para processar retorno de

livros e verificação de saídas, assim como assistência aos clientes nas suas pesquisas. O
processo normal tem a apresentação de alguma forma de cartão de cliente da biblioteca e dos
itens que o cliente deseja. O atendente entra com o ID do cliente seguido pelos números
identificadores dos itens, e o cliente recebe verbalmente a data da devolução de seus itens.
Este atendente é normalmente responsável pelo fornecimento de novos cartões a novos

clientes da biblioteca.
Figura 12 – Caso de uso do sistema de circulação

3.5.2.2. Funcionário de catalogação
O funcionário de retaguarda da biblioteca tipicamente faz vários serviços, como

entrada de novos itens, retirada de itens da coleção, manutenção de itens, compra e pós-
compra de itens.
Quando recursos estão disponíveis, é prática normal estes funcionários efetuarem a

compra de materiais.(Rosasco & Bakke, 2004:p.1).
Figura 13 – Caso de uso catalogação de materiais

3.6. Instalação do sistema Koha
O capítulo apresentado é baseado no texto de Joshua Ferraro, sobre a instalação do

sistema Koha na Distribuição Linux Debian 3.1 stable codinome “Sarge”16. O trabalho
original está licenciado sob a Licença Geral Pública GNU versão 2 ou posterior, e conforme
nota no texto original, o presente trabalho, derivado daquele original, deve seguir a mesma
linha de licenciamento, e portanto segue a licença GNU GPLv217.
Este capítulo cobre a instalação do Koha no Ubuntu 6.10 Edgy Eft server, que pode
ser obtido no site oficial da distribuição ou no espelho no Brasil mais próximo18.
3.6.1. Condição inicial e conhecimentos necessários
É presumido que se irá instalar o Koha em um computador com a distribuição linux

ubuntu server pré-instalada, mas em uma condição de instalação mínima. Também é
presumido que o instalador possua conhecimentos mínimos necessários de administração de
sistemas linux, o suficiente para efetuar os procedimentos descritos. Maiores informações
podem ser obtidas nos respectivos sites dos desenvolvedores dos softwares dos quais o Koha
depende.
Também é necessária uma conexão à internet, preferivelmente de banda larga, mas

uma conexão discada pode suprir as necessidades, desde que se disponha de tempo. Muitos
downloads serão efetuados, e caso uma conexão à internet não esteja disponível, a instalação
das dependências através de cdrom's com o conteúdo necessário é possível, mas não será
coberta neste documento.
3.6.2. Dependências
Conforme Ferraro (2006), o Koha é uma aplicação cliente/servidor, instalada em um

ambiente conhecido como LAMP. O grupo de aplicações conhecido como LAMP, ou Linux,
Apache, MySQL e PHP/Python/Perl é um dos mais comuns para servidores linux.
16 Disponível em <http://www.kohadocs.org/Installing_Koha_on_Debian_sarge.html>. Acesso em 04/04/2007.

17 Disponível em <http://www.gnu.org/licences/gpl.html>.Acesso em 04/04/2007.
18 Disponível em <http://espelhos.edugraf.ufsc.br/ubuntu-releases/edgy/ubuntu-6.10-server-i386.iso>.Acesso
em 04/04/2007.
3.6.2.1. Instalando o Perl
A maioria da funcionalidade do Koha é escrita em Perl, e vários módulos são

necessários para o correto funcionamento do sistema.
Muitos módulos necessários ao Koha poderão ser instalados pelo método apt-get,
outros apenas recorrendo ao repositório de módulos Perl conhecido como CPAN.
O primeiro passo é conseguir acesso de super-usuário no servidor, ou de usuário root.

Na instalação padrão do ubuntu, a conta root é desabilitada, então primeiro deve-se habilitá-
la, alterando a senha do usuário root. Primeiro, loga-se como o usuário com o qual foi
efetuada a instalação, então executa-se os comandos a seguir ;
$ sudo passwd
Enter your unix password :
Renter your unix password :
passwd :
Password updated successfully.
Então, deve-se sair e efetuar novo login como root, com a senha informada
anteriormente.
Com o novo login, através do apt-get atualiza-se a base de dados e instala-se o Perl e
os módulos iniciais necessários :
# apt-get update && apt-get install perl libdbi-perl libdbd-mysql-perl

libdate-manip-perl libhtml-template-perl libmail-sendmail-perl libevent-
perl yaz libyaz2 libxml-sax-perl libclass-accessor-perl libcompress-zlib-
perl libyaz2-dev libnet-ldap-perl
Este comando instalará estes módulos e várias dependências dos mesmos.
3.6.2.2. Preparando para utilizar o CPAN
Existem algumas dependências para o Koha que não estão disponíveis como pacotes
na distribuição, assim, devem ser instaladas a partir dos repositórios CPAN. Mas o instalador
do CPAN também depende de alguns aplicativos, que podem ser instalados utilizando o
método apt-get, conforme o comando a seguir :
# apt-get install unzip make lynx wget ncftp ftp less gcc cvs
Deve ser confirmada a informação de hora e data do servidor, para prevenir falhas no
uso do módulo do CPAN. Para esta tarefa usa-se o comando date.
3.6.2.3. Instalando o Yaz
Alguns módulos do CPAN tem dependências que não podem ser instaladas pelo apt-
get. O Yaz é uma destas dependências, e instala-se o mesmo executando os comandos :
# wget http://ftp.indexdata.dk/pub/yaz/yaz-2.1.38.tar.gz
# tar xzvf yaz-2.1.38.tar.gz
# cd yaz-2.1.38
# ./configure
# make
# make install
3.6.2.4. Configurando o módulo CPAN enquanto instala o módulo

Net::Z3950
No primeiro uso do módulo CPAN, a sua configuração inicial deve ser feita, inicia-se
informando ao módulo que instale o Net::Z3950, conforme o comando a seguir :
# perl -MCPAN -e 'install "Net::Z3950"'
O módulo retornará solicitando algumas informações, e caso a conexão de rede seja

direta à internet, é seguro responder "no" à questão, que dirá ao módulo que faça uma auto-
configuração. Pode-se alterar esta configuração depois, conforme o texto retornado do
módulo:
"/usr/share/perl/5.6.1/CPAN/Config.pm initialized.
CPAN is the world-wide archive of perl resources. It consists of about

100 sites that all replicate the same contents all around the globe.
Many countries have at least one CPAN site already. The resources
found on CPAN are easily accessible with the CPAN.pm module. If you
want to use CPAN.pm, you have to configure it properly.
If you do not want to enter a dialog now, you can answer 'no' to this
question and I'll try to autoconfigure. (Note: you can revisit this
dialog anytime later by typing 'o conf init' at the cpan prompt.) Are
you ready for manual configuration? [yes]"
O processo de inicialização demora um pouco, e é seguro responder a algumas

questões do módulo com as opções padrão. Talvez algumas dependências necessitem ser
instaladas antes do módulo solicitado, e o módulo perguntará se deve ou não instalar estes
pré-requisitos. É seguro responder a este método como "follow", que causará a auto-
instalação de dependências, como no exemplo a seguir :
"The CPAN module can detect when a module that which you
are trying to build depends on prerequisites. If this
happens, it can build the prerequisites for you
automatically ('follow'), ask you for confirmation
('ask'), or just ignore them ('ignore'). Please set your
policy to one of the three values.
Policy on building prerequisites (follow, ask or

ignore)? [ask]"
Eventualmente, se um site do CPAN não responder, será feita uma pergunta sobre qual
site o módulo deverá usar. Responde-se como no exemplo :
"Please check, if the URLs I found in your configuration

file () are valid. The urllist can be edited. E.g. with
'o conf urllist push ftp://myurl/'
Could not fetch MIRRORED.BY CPAN.pm needs at least one

URL where it can fetch CPAN files from.
Please enter your CPAN site: []"
Alguns sites que podem ser utilizados são :
● ftp://archive.progeny.com/CPAN/
● ftp://cpan.cse.msu.edu/
● ftp://cpan.pair.com/
Após o primeiro terminar, instale os módulos restantes, observando como são

digitados :
# perl -MCPAN -e 'install Digest::MD5'

# perl -MCPAN -e 'install Business::ISBN'
# perl -MCPAN -e 'install "Compress::Zlib"'
# perl -MCPAN -e 'install "ZOOM"'
# perl -MCPAN -e 'install "GD::Barcode"'
# perl -MCPAN -e 'install "Data::Random"'
# perl -MCPAN -e 'install "PDF::Reuse::Barcode"'
# perl -MCPAN -e 'install "Net::LDAP"'
# perl -MCPAN -e 'install "Date::Calc"'
3.6.2.5. Instalando os módulos marc
Alguns módulos do Perl necessitam dos módulos marc, que devem ser instalados a
partir dos códigos fonte disponíveis. Executa-se os comandos a seguir para instalá-los :
# cvs -z3 -d:pserver:anonymous@marcpm.cvs.sourceforge.net:/cvsroot/marcpm

co -P marc-record
co -P marc-charset
co -P marc-lint
co -P marc-xml
# cd marc-record
# perl Makefile.PL
# make
# make install
E repete-se a compilação, entrando em cada diretório dos outros três módulos

baixados.
3.6.2.6. Instalando o módulo PDF-API2
Este módulo é usado para gerar os arquivos em formato pdf dos relatórios e dos
códigos de barras, mas uma versão específica deve ser instalada. Esta versão está disponível
para download no CPAN19. Assim, segue-se os comandos abaixo para sua instalação ;
# wget http://backpan.cpan.org/modules/by-authors/id/A/AR/AREIBENS/PDF-
API2-0.3r77.tar.gz
# tar xzvf PDF-API2-0.3r77.tar.gz
# cd PDF-API2
# perl Makefile.pl
# make
# make install
3.6.2.7. Instalando o MySQL
O Koha usa o gerenciador de banco de dados MySQL, um gerenciador baseado em

linguagem SQL. Maiores informações sobre o aplicativo estão disponíveis no site oficial do
desenvolvedor20. Para instalá-lo, segue-se os procedimentos a seguir.
19 Disponível em <http://backpan.cpan.org/modules/by-authors/id/A/AR/AREIBENS/PDF-API2-
0.3r77.tar.gz>. Acesso em 04/04/2007.
20 Disponível em <http://www.mysql.com/doc/en/index.html>, acesso em 09/04/2007.
Primeiro, instala-se o pacote do servidor e dependências :
# apt-get install mysql-server-4.1
Configura-se a senha do administrador do banco neste momento, que deve estar

disponível quando o resto da instalação do Koha for feita, pois o instalador do Koha solicitará
esta senha. A senha do banco pode ser configurada com o seguinte comando :
# mysqladmin password <senha>
3.6.2.8. Instalando o Apache
Conforme o site Netcraft de pesquisas na internet , o servidor web apache é usado por
mais de 60% dos servidores no mundo. Maiores informações sobre a pesquisa podem ser
obtidas no site da Netcraft21. No site do desenvolvedor22 estão disponíveis maiores
informações sobre o aplicativo.
O apache pode ser instalado com o seguinte comando :
# apt-get install apache2
Isto efetuará a instalação padrão do apache. Quando o koha for instalado será efetuada
a configuração do apache para o correto funcionamento da aplicação.
3.6.3. Instalando o Koha 2.2.6
Baixa-se o pacote23 e descompacta-se o arquivo, com os seguintes comandos :
# wget http://download.savannah.nongnu.org/releases/koha/koha-2.2.6.tar.gz
# tar xzvf koha-2.2.6.tar.gz
Depois, entra-se no diretório criado e executa-se o instalador do Koha, conforme o

comando:
21 Disponível em <http://www.netcraft.com>, acesso em 09/04/2007.

22 Disponível em <http://www.apache.org>, acesso em 09/04/2007.
23 Disponível em <http://download.savannah.nongnu.org/releases/koha/koha-2.2.6.tar.gz>. Acesso em
04/04/2007.
# perl installer.pl
As perguntas devem ser respondidas conforme o necessário, e algumas opções padrão

são suficientes, a seguir um pequeno exemplo de respostas dadas a uma das instalações, a
partir da execução do script de instalação, sendo que estão presentes apenas aquelas respostas
a perguntas em que a opção padrão não atende à necessidade. Após cada resposta, padrão ou
não, a tecla "enter" deve ser digitada :
Texto do instalador, informação não padrão necessária Resposta

"Are you ready to begin the instalation ? Y
"Enter number of the file to read" 2
"Password for database user kohaadmin" <senha>
"Web e-mail contact" <e-mail>
"MySQL root user password" <senha mysql>
"Choose marc definition" 1
"Add branch and printer" Y
"Choose language" en
"Select sql directory" 1
"Choose sql file" 1
"Choose sql file" 2
"Choose sql file" 0
"Select sql directory" 0
"Restart apache" Y
Tabela 1 : Respostas ao instalador do Koha
Fonte : Elaborado pelo autor
Neste momento o Koha já está instalado, mas o arquivo de configuração do servidor

web apache ainda deve ser editado.
Copia-se o arquivo a ser editado, para outro diretório ou com outro nome, de modo a
manter uma versão do original em caso de problemas.
Em um editor de texto, por exemplo o nano, edita-se o arquivo /etc/apache2/sites-

enabled/000-default, e apaga-se todo seu conteúdo, ou desabilita-se adicionando um caracter
"#" ao começo de cada linha. Ao final do arquivo, adiciona-se "include /etc/koha-httpd.conf",
que significa que a configuração do servidor será incluída a partir do conteúdo deste arquivo.
Este arquivo é gerado a partir do instalador do Koha, com as opções passadas ao mesmo
durante a instalação.
Edita-se o arquivo /etc/koha-httpd.conf e altera-se os parâmetros a seguir, para obter

uma instalação mínima funcional do Koha :
● na diretiva Listen 8080, retira-se o caracter "#" do começo da linha;

● na diretiva NameVirtualHost, altera-se a linha para "NameVirtualHost *", sem nada
mais nesta linha.
Reinicia-se o servidor web com o seguinte comando :
# /etc/init.d/apache2 restart
Neste momento, já pode ser realizado o primeiro teste de conexão, tanto do módulo
OPAC quanto do Intranet, com os seguintes endereços, digitando-os em um navegador que
possua acesso à rede na qual foi instalado o servidor :
OPAC = http://<nomeouipdamaquina>
Intranet = http://<nomeouipdamaquina>:8080
O usuário inicial é kohaadmin e a senha solicitada no módulo intranet é a digitada para

este usuário durante a instalação.
A instalação está finalizada, e o Koha está funcional e pronto para que o usuário possa
iniciar a configuração dos parâmetros da biblioteca ou coleção pessoal e utilizar o
sistema.(Ferraro, 2006:p.1).
4. SISTEMA AGENDA
4.1. Introdução
Motivação
Como parte integrante da formação de tecnólogo em informática, foi proposto que se

desenvolvesse um sistema, para a disciplina Projeto de Sistemas, nos moldes ministrados em
disciplinas ao longo do curso e do semestre.
Tendo em vista as dificuldades enfrentadas por alguns setores da instituição, foi

proposto desenvolver uma solução, de modo a unir a necessidade de uma solução prática com
o tempo que seria dispendido na realização do projeto exigido pela disciplina.
Sob outro ponto de vista, há a disposição de liberar o que for desenvolvido sob a
forma de software livre, facilitando o estudo pelos colegas e servindo como material de apoio
dos professores, com a devida autorização da instituição.
Objetivos
Desenvolver um sistema de gestão operacional, com registro de dados suficientes para

análises gerenciais de acessos à internet nas dependências da Fatec Praia Grande.
Este sistema proverá mecanismos de registro de dados para que se possa efetuar o
controle dos acessos à internet nas dependências da Fatec. Todo acesso à internet deverá
respeitar as regras básicas da instituição, conforme modelo e regras fornecidos e gerenciados
pela Diretoria e coordenadoria do Centro de Informática.
Fornecer toda a documentação e código desenvolvido em área passível de acesso pelos

alunos no site da faculdade, de modo a possibilitar o seu livre acesso por todos os
interessados.
Metodologia
Para o desenvolvimento será usado o Processo Unificado, com análise e programação

orientados a objeto, com documentação incluindo diagramação utilizando UML 2.0,
orientados pelos trabalhos de Larman e Medeiros.
Toda a documentação gerada por este sistema visa informar as principais decisões de
análise e implementação, não documentar interfaces de classes. A informação criada tem a
intenção de elucidar o funcionamento do sistema, permitindo ao aluno e professor a quem tais
informações são primeiramente destinadas, a aprofundar a documentação, desenvolver,
melhorar e incluir funcionalidades neste sistema de código aberto. Afinal, como diz
Larman(2007) :
“Há artefatos ou práticas opcionais no PU24 ?
Sim! Quase tudo é opcional. Dito isso, algumas das práticas e dos princípios do PU são
invariáveis, como o desenvolvimento iterativo e orientado ao controle dos riscos, bem
como a verificação contínua da qualidade.
Entretanto, um aspecto-chave do PU é que todas as atividades e os artefatos (modelos,

diagramas, documentos, etc.) são opcionais – bem, talvez não o código!”(Larman, 2007:
p.64).
4.2. Concepção
Conforme Larman(2007), nesta fase do PU se faz uma investigação suficiente para

formar uma opinião racional e justificável da finalidade geral e da viabilidade do novo
sistema em potencial, para então decidir se vale a pena investir em uma investigação mais
profunda.(Larman, 2007:p.77).
Foi solicitado que um sistema de informações fosse desenvolvido, como parte da

formação de Tecnológo em Informática, com Ênfase em Gestão de Negócios, no sexto ciclo
do curso, segundo semestre de 2006. Foram observadas certas deficiências no controle dos
acessos à Internet realizado na Faculdade. Ensejando aproveitar a oportunidade criada para
24 Abreviação para Processo Unificado.

que um sistema fosse desenvolvido e resolver um problema da Faculdade, foi então

apresentada a idéia inicial de resolver este problema dos acessos com a criação de um sistema
à diretoria da Faculdade que apoiou a continuidade do projeto.
4.2.1. O problema
Conforme constatado em entrevistas com os srs. Domingos e Nilson, respectivamente

coordenador do centro de informática e diretor da Fatec, foi apurado que o sistema de controle
de acessos à internet no ambiente da faculdade tem algumas precariedades.
Todo o acesso é monitorado, mas os usuários não são registrados e, portanto, o acesso
de cada um não tem registros suficientes para auditoria.
Existem bloqueios de acesso a alguns sites, mas a administração destes bloqueios

exige que o administrador tenha acesso direto aos arquivos de configuração da máquina
controladora, com conta de poderes irrestritos, o que é por si só uma falha de segurança.
Quando algum bloqueio é alterado ou adicionado, é exigida a parada total dos acessos e o
reinício do aplicativo controlador, para que as regras passem a valer. Isto configura uma
indisponibilidade de serviço.
O acesso à internet é bloqueado totalmente em alguns laboratórios, provocando

problemas com relação aos agendamentos de aulas pelos professores, pois nem sempre um
laboratório com acesso disponível está liberado, assim como se o professor desejar que os
alunos não tenham acesso à internet durante a aula, incorre novamente na questão de
bloqueios falhos anteriores.
É ciência da administração que existem alunos que desviam sua atenção das aulas por
ter disponível acesso à internet, lendo e-mails, acessando sites não correspondentes às aulas,
entre outros problemas.
4.2.2. A solução proposta
Baseando-se nas características do aplicativo usado para o compartilhamento à

internet, é possível que um programa externo ao mesmo consulte regras dinamicamente,
editáveis em banco de dados. Também é possível melhorar o registro dos sites acessados com
a inclusão de novas informações conforme solicitações dos responsáveis.
Assim, foi proposto um sistema de controle composto por duas partes. Uma, em
constante conexão com o aplicativo de compartilhamento e controle, receberá as requisições
deste aplicativo e fornecerá respostas baseadas em regras lidas em um banco de dados. Por
outro lado, a outra parte do sistema tratará da edição destas regras, conforme modelo a ser
definido em conjunto com as áreas responsáveis.
Um modelo inicial proposto é que os agendamentos sejam gerenciados por este

sistema, com informações sobre a aula, professor e necessidade de internet ou não,
referenciando os horários das aulas. Neste modelo, estas regras poderiam ser definidas com
bastante antecedência, passando a valer no horário agendado. Informações sobre acessos
seriam colhidas a partir de uma nova configuração no aplicativo de compartilhamento, com a
inclusão da necessidade de identificação do usuário através de login ou obter tais informações
a partir do login anteriormente realizado na estação, questão ainda a ser definida.
A solicitação do cliente é que o controle do acesso geral fosse efetivado pela

administração, e que necessidades específicas de cada aula seriam resolvidas pelo professor
que estivesse no laboratório, cabendo ao mesmo a alteração do modelo de acesso,
minimamente respeitando o que fosse anteriormente definido como regra geral. Por exemplo,
se um determinado site foi banido pela administração, o professor poderia apenas editar seus
bloqueios durante sua aula no laboratório, nunca remover um bloqueio criado pela
administração.
Conforme solicitação, neste modelo podem ser acrescidas informações que os

responsáveis julguem necessárias.
Como parte integrante do projeto, e conforme autorização a ser obtida junto à

instituição, todo o material desenvolvido ficará disponível sob licença de software livre, tanto
para aproveitamento dos professores, alunos e funcionários responsáveis pela manutenção,
quanto para quem dele necessitar, nos moldes da filosofia do software livre descritos pela
Free software Foundation e projeto GNU.
Desde já o grupo transfere todos os direitos autorais do que for desenvolvido à

Faculdade de Tecnologia de Praia Grande, principal interessada no desenvolvimento da
solução proposta, desde que a mesma se encarregue de manter o mesmo como software livre,
durante o tempo de vida útil do sistema, e transferir o direito autoral deste sistema em favor
daquele que se interessar em mantê-lo após este período, ou a qualquer momento, o que
ocorrer primeiro.
Tudo o que for desenvolvido e utilizado no desenvolvimento em se tratando de

software será obrigatoriamente livre, preferencialmente sob a GPLv2. Não serão usados novos
recursos de hardware ou software, apenas os já existentes na estrutura atual da Fatec e o que
for desenvolvido. Não serão utilizados novos recursos humanos, os responsáveis deverão
designar as pessoas que serão treinadas a utilizar e a realizar manutenção na solução
desenvolvida.
Todo o acesso ao módulo de administração, assim como aos bloqueios realizados em

tentativas de acesso a sites não autorizados, serão registrados e estarão disponíveis para
auditoria pelos interessados autorizados.
A data de início do projeto é a data de início das aulas do segundo semestre de 2006 e
seu término coincide com prazos a serem estabelecidos na disciplina Projeto de Sistemas do
sexto ciclo, sob a coordenação do professor responsável pela disciplina no período.
Para efetiva implantação do que for desenvolvido, será necessária a autorização pela
direção e coordenadoria do centro de informática ao acesso do líder do projeto e seus
designados, às dependências que se fizerem necessárias.
Este projeto não tem relação com a Fábrica de software Livre desta faculdade, mas a
seu critério pode ser designado à Fábrica para sua manutenção após o término do projeto.
O sistema a ser desenvolvido pode ser entendido a partir da figura a seguir, onde setas
indicam o fluxo dos dados importantes para o sistema. Note-se que esta figura não demonstra
o atual estado de conexões de rede ou entre equipamentos, mas tão somente sua interligação a
nível de processos.
Figura 14 : Fluxo de dados entre processos para o sistema proposto

4.2.3. Análise inicial dos custos
Conforme exposto em tópicos anteriores, não haverá necessidade de aquisição de

licenças de software de qualquer tipo, não será necessário contratar pessoal para interagir com
sistema, e poderão ser usados recursos da instituição em termos de hardware e software já em
produção, tanto em fase de desenvolvimento quanto na implantação definitiva da solução.
4.2.4. Soluções alternativas
Como o principal objetivo é desenvolver um sistema de informação, aplicando

conteúdos de disciplinas cursadas e em andamento ao longo do curso, não foram encontradas
soluções alternativas para a proposta inicial.
Como o sistema pode ser implementado de diversas maneiras, será dada preferência
pelos métodos de desenvolvimento e linguagens de programação já utilizados por professores.
O sistema a ser desenvolvido visa resolver uma questão de bloqueios de acesso a sites
considerados impróprios pela administração, com registro das tentativas, e permitir aos
professores controle mais efetivo do quê os alunos podem acessar em período de aula, e se
podem ou não ter acessos. As pessoas que terão direitos de controle sobre o sistema são os
administradores, na pessoa do diretor e pessoas por ele designadas. Os professores poderão
durante o período em que estiverem no laboratório bloquear completamente, parcialmente

com o registro de sites que considerarem próprios ou liberar o acesso dos alunos, desde que
respeitando definições dos administradores. Todo este acesso será registrado.
4.2.5 Pessoal
Não será necessária contratação de pessoal para operação de qualquer parte do

sistema, seguindo as diretrizes de administração impostas anteriormente. Serão previamente
cadastrados no sistema os administradores, que se encarregarão de administrar os professores,
que terão os direitos descritos anteriormente no sistema. Logo, uma vez cadastrados todos,
pouca interação deste tipo será realizada no sistema, demandando pouco tempo de
administração e portanto considera-se que não haverá necessidade de pessoal.
4.2.6 Equipamentos
Serão utilizados os equipamentos já existentes na Faculdade, e apenas pequenas

alterações nos softwares já em uso serão realizadas. Não há necessidade de aquisição de
equipamentos para os propósitos deste sistema.
4.2.7 Instalações
Como não será contratado pessoal para operação, nem serão adquiridos equipamentos
para o mesmo, não há necessidade de ampliação das instalações existentes, para os propósitos
do sistema.
4.2.8 Custo do desenvolvimento
O sistema desenvolvido tem função acadêmica e pública, uma vez que se propõe a
resolver um problema de uma instituição pública. Assim, não será cobrado para que seu
desenvolvimento ocorra, desde que sejam respeitadas pela instituição as condições de
disponibilização do código-fonte gerado para os interessados.
4.2.9 Treinamento
Um período de treinamento de 2 (DUAS) horas será disponibilizado para 6 (SEIS)

pessoas, entre elas administradores e professores, a serem definidos pela Faculdade.
4.2.10 Custo do código-fonte
Conforme diretrizes acordadas e finalidade do sistema, não haverá custo pela

transferência do direito autoral sobre o código desenvolvido, desde que:
● A Faculdade concorda, irrevogavelmente, em manter o código-fonte aberto e

considerado software livre, considerando a licença original dos desenvolvedores sem
alterações, primeiramente licenciado sob os termos da General Public Licence
(GPLv2);
● A Faculdade manterá os créditos originais dos desenvolvedores, em qualquer alteração
ou trabalho derivado deste sistema;
4.2.11 Custo total do sistema
Não haverá custo pelo desenvolvimento, implementação ou implantação deste sistema,

e sua manutenção ficará a cargo da instituição, com toda a documentação necessária para tal
disponibilizada.
4.3. Elaboração
Neste capítulo serão descritos os objetivos, os atores, os requisitos e o domínio do

problema para o sistema, incrementalmente em iterações, conforme descrito por
Larman(2004,p.32).
Conforme Larman(2004), nesta fase deve-se construir a arquitetura central, resolver os

elementos de alto risco e definir a maioria dos requisitos.
4.3.1 Modelo de casos de uso
Serão descritos o requisitos funcionais para o sistema.
4.3.1.1 Lista Ator-objetivo
Esta lista relaciona os atores, seus principais objetivos a serem alcançados com o
sistema e os casos de uso que realizam estes objetivos.
Ator Objetivo Caso de uso

Professor Gerenciar permissão de acesso de aluno gerenciarAluno
Administrador Gerenciar dados globais gerenciarAcesso
Squid Obter informação para o acesso à internet acessarInternet
Tabela 2 : Lista Ator-objetivo.
Fonte : Elaborado pelo autor.
4.3.1.2 Casos de uso do sistema
Descrição dos casos de uso para o sistema proposto.
4.3.1.2.1 Caso de uso acessarInternet
Ator principal: Squid
Interessados e interesses:
➔ Squid : deseja receber a permissão de acesso da URL requisitada pelo
Aluno/Funcionário;
➔ Aluno : deseja visualizar em seu navegador a URL solicitada ao Squid;
➔ Funcionário : deseja visualizar em seu navegador a URL solicitada ao Squid;
➔ Administrador : deseja relatório sobre os acessos realizados pelos Alunos e
Funcionários, e deseja que acessos não autorizados sejam bloqueados e registrados;
➔ Professor : deseja que acessos à internet não permitidos por ele no Laboratório em que
estiver ministrando aula sejam bloqueados e registrados;
Pré-condições : O Aluno ou o Funcionário deve ter sido identificado e autenticado.

As regras de acesso devem ter sido estabelecidas e registradas no sistema.
Garantia de sucesso (Pós-condições) : O Squid recebe uma resposta(OK/ERR). O

acesso é registrado.
Cenário de sucesso principal :
1. O Squid envia a URL, o nome do usuário e a identificação do computador ao sistema;
2. O sistema avalia os dados e responde com OK ou ERR ao Squid conforme regras
cadastradas;
Extensões :
*a . A qualquer momento, o sistema falha :
Uma informação será retornada ao Aluno/Funcionário.
1a. Caso falte alguma informação, o sistema retorna ERR, registrando o erro.
2a. Se a URL solicitada constar como bloqueada, o sistema registra o fato e retorna
informando.
2b. Se o Aluno estiver com o acesso bloqueado, o sistema registra o fato e retorna
informando.
2c. Se o Funcionário estiver com o acesso bloqueado, o sistema registra o fato e retorna
informando.
2d. Se o nome do usuário constar no registro de Funcionário, o sistema o identifica como
Funcionário e obedece às regras para o mesmo.
2e. Se o nome do usuário não constar no registro de Funcionário, o sistema o identifica
como Aluno e verifica as regras globais de acesso e as regras do Professor para o
Laboratório/máquina para processar o acesso.
2f. Se a url solicitada constar como exceção ao bloqueio, será retornado OK apenas se não
constarem bloqueios para computadores, laboratórios e usuários.
2g. Se o usuário identificado como aluno estiver na n-ésima tentativa de acessar uma
URL proibida, o sistema o bloqueia.
4.3.1.2.2 Caso de uso gerenciarAcesso
Ator principal: Administrador

➔ Administrador : deseja inserir/remover/atualizar/visualizar regras de acesso, relação de

URL's permitidas e proibidas, dados sobre máquinas, laboratórios e Funcionários.
Pré-condições : O Administrador deve ter sido identificado e autenticado.
Garantia de sucesso (Pós-condições) : Os dados são registrados e imediatamente

validados. O acesso e ações são registrados.

1. O Administrador solicita ao sistema a tarefa desejada.
2. O sistema retorna ao Administrador a função requerida.
3. O Administrador trabalha os dados desejados e solicita o registro ao sistema.
4. O sistema efetua o registro dos dados e das ações do Administrador.
O Administrador pode repetir os passos 1 a 4, até que deseja encerrar a sessão.
5. O Administrador solicita o encerramento da sessão.
6. O sistema encerra a sessão.
Extensões :
Uma informação será retornada ao Administrador.
4.3.1.2.3 Caso de uso gerenciarAluno
Ator principal: Professor
➔ Professor : deseja inserir/remover/atualizar/visualizar regras de acesso e relação de
URL's permitidas e proibidas para os alunos, apenas para o laboratório em que estiver
ministrando aulas, pelo período em que nele estiver.
Pré-condições : O Professor deve ter sido identificado e autenticado.

Garantia de sucesso (Pós-condições) : Os dados são registrados e imediatamente

validados. O acesso e ações são registrados.

1. O Professor solicita ao sistema a tarefa desejada.
2. O sistema retorna ao Professor a função requerida.
3. O Professor trabalha os dados desejados e solicita o registro ao sistema.
4. O sistema efetua o registro dos dados e das ações do Professor.
O Professor pode repetir os passos 1 a 4, até que deseja encerrar a sessão.
5. O Professor solicita o encerramento da sessão.
6. O sistema encerra a sessão.
Extensões :
Uma informação será retornada ao Professor.
4.3.1.3 Diagrama de casos de uso
O diagrama a seguir ilustra o levantamento efetuado.
Figura 15 - Diagrama de casos de uso

4.3.1.4 Diagramas de seqüência relativos aos casos de uso principais
Estes diagramas esclarecem sobre os eventos que ocorrem nos casos de uso.
Conforme Medeiros(2006), este tipo de diagrama pode ser usado para mostrar a
evolução de uma dada situação em determinado momento do software, mostrar uma dada
colaboração entre duas ou mais classes e pode também ser usado para mostrar a tradução de
um Caso de Uso desde a interação com o usuário até a finalização daquele dado
processo.(Medeiros, 2006:p.147).
4.3.1.4.1 Diagrama de seqüência para o caso de uso acessarInternet
Este diagrama ilustra a interação entre o Squid e o sistema proposto, no plano do

acesso à internet pelos usuários.
Figura 16 - Diagrama de seqüência do caso de uso acessarInternet

4.3.1.4.2. Diagrama de seqüência para o caso de uso gerenciarAluno
Este diagrama ilustra a interação entre o usuário do tipo professor e o sistema, em sua
interface de administração.
Figura 17 – Diagrama de seqüência do caso de uso gerenciarAluno

4.3.1.4.3. Diagrama de seqüência para o caso de uso gerenciarAcesso
Este diagrama ilustra a interação entre um usuário do tipo administrador e o sistema,

em sua interface de administração.
Figura 18 – Diagrama de seqüência do caso de uso gerenciarAcesso

4.3.2 Especificações suplementares
Este tópico é o repositório de todos os requisitos que não constam nos casos de uso.
4.3.2.1 Funcionalidades
1. Todos os erros devem ser registrados, e um relatório deve poder ser visualizado com
estes erros;
2. O sistema deve permitir regras restritivas ou permissivas, ou seja, liberar acessos a
partir de “lista branca” ou bloquear a partir de “lista negra”;
3. Um relatório com o ranking dos usuários mais bloqueados deve poder ser visualizado.
4.3.2.2 Usabilidade
1. As telas de relatórios e administração devem ser visualizáveis nos navegadores de

internet em uso na faculdade;
4.3.2.3 Desempenho
1. O sistema deve parecer transparente para os usuários quando sites permitidos forem
requisitados, isto significa uma espera não maior que 3 segundos para respostas;
4.3.2.4 Restrições de implementação
1. Devem ser usados apenas soluções de código aberto/software livre para todas as fases
do projeto, como ferramentas case e linguagens de programação;
4.3.2.5 Licenciamento do sistema
1. O sistema deve ser licenciado como software livre, de preferência GPLv2.
4.3.3 Modelo do domínio
A lista a seguir relaciona as regras do problema a ser solucionado com o sistema.
Número Regra Mutabilidade Fonte

1 O Aluno não poderá acessar URL que Freqüente Administração
contenham palavras proibidas.
2 O acesso do Aluno à internet deverá Dependente dos Administração
seguir as regras cadastradas pelo horários de
professor, para o laboratório em que o aulas.
mesmo estiver ministrando aula, pelo
período de suas aulas.
3 Apenas os Administradores poderão Conforme o Administração
alterar dados sobre os acessos globais, necessário.
máquinas, laboratórios e funcionários.
4 Em relação a acessos à internet, Conforme o Administração
Administradores e Professores são necessário.
considerados funcionários.
Número Regra Mutabilidade Fonte

5 Um usuário que solicitar n vezes uma Conforme o Administração
URL proibida será bloqueado pelo necessário
sistema.
Tabela 3 : Regras do domínio
Conforme Larman(2007), o passo mais essencialmente orientado a objetos na análise é

a decomposição de um domínio25 em conceitos ou objetos importantes. (Larman, 2007:p.159).
O estudo dos problemas e dos conceitos relativos ao sistema levou ao modelo de

domínio a seguir.
Figura 19 – Modelo de domínio do Sistema Agenda

4.4. Construção
Neste capítulo será executado o restante da implementação do sistema, através de

iterações incrementais, preparando-o para a transição (implantação ou produção do sistema).
25 Problema ou campo de conhecimento envolvido.

4.4.1 Projeto dos objetos
Para a solução do caso de uso acessarInternet, foram levantados os seguintes objetos :
➔ squid laboratório aluno administrador acesso

➔ computador funcionario professor URL departamento
4.4.1.1 Responsabilidades dos objetos
Nesta seção serão definidas as responsabilidades de alguns dos objetos no sistema, em

relação ao domínio, aplicando Padrões GRASP, conforme Larman(2004,p.231).
• Usuario - Criador : operações com usuários, como retornar nome, login e estado;
• Computador - Criador : operações com computadores, como retornar laboratório em
que foi cadastrado, e estado de bloqueio;
• Lista_URL - Criador : operações com URL, lógica de negócio com sites;
• Persistencia - Especialista na informação : pesquisa dos dados sobre usuários, sites e
computadores no banco de dados;
• AcessoSquid - Controlador : gerenciamento das operações necessárias, acessando
operações conforme dados recebidos pela interface com o Squid e requisitos;
• AcessoAdm - Interface do administrador / professor para acesso aos recursos de
administração do sistema.
4.4.2 Entidades e relacionamentos
O projeto é baseado no SGBD PostgreSQL 8.2.3. Para a implementação da base de

dados de teste foi usada a interface web phppgadmin e ferramenta de linha de comando psql.
O modelo de entidades e relacionamentos apurado a partir do modelo de domínio está

a seguir.
Figura 20 - Modelo de entidades e relacionamentos

4.4.3. Arquitetura lógica
Conforme Larman(2007), arquitetura lógica é a organização em larga escala das

classes de software em pacotes ( ou espaços de nomes ), subsistemas e camadas. É chamada
de lógica porque não há decisão sobre como estes elementos são implantados pelos diferentes
processos do sistema operacional ou pelos computadores físicos em uma rede (estas decisões
posteriores são parte da arquitetura de implantação).(Larman, 2007:p.221).
A arquitetura lógica para o projeto Agenda está no diagrama a seguir.

Figura 21 – Diagrama de arquitetura lógica

4.4.4 Estrutura do software
Foi planejada estrutura em três camadas, interfaces com o Squid e com o usuário,
camada de domínio e persistência.
A interface com o Squid em linguagem Java, e as telas de administração em HTML,

originadas de processamento de código PHP. O banco de dados escolhido é o PostgreSQL.
Todo o ambiente foi desenvolvido para ser executado em sistema operacional Linux,
independente de distribuição, mas a interface de administração independe de sistema
operacional, pois é executada no servidor e a interação dá-se através de navegador web, em
conformidade com os padrões da W3C26.
26 Padrões disponíveis em <http://www.w3c.org>. Acesso em 09/04/2007.

4.4.5 AcessoSquid
Este módulo resolve o caso de uso acessarInternet, obedecendo ao diagrama de

atividades correspondente.
Foi usada a linguagem Java, e o programa compilado e empacotado como arquivo jar,
para facilidade de configuração com o programa Squid. É usado um arquivo de
configuração agenda.conf, que contém os parâmetros para acesso ao banco de dados. O
código gerado está disponível como anexo, e o diagrama de atividades está a seguir.
Figura 22 - Diagrama de atividades programa AcessoSquid

Para resolver este diagrama, foram criadas duas classes, AcessoSquid e Persistencia. A
seguir estão os diagramas de classes e atividades dos métodos criados.
Figura 23 – Diagrama de classes programa AcessoSquid, projeto Agenda

Os diagramas de atividades que explicam os métodos das classes estão a seguir.

Figura 24 – Diagrama de atividades, método main(), classe AcessoSquid

Figura 25 – Diagrama de atividades, método conectar_BD(), classe Persistencia

Figura 26 – Diagrama de atividades método consulta_acesso(), classe Persistencia

Figura 27 – Diagrama de atividades método grava_log(), classe Persistencia

Figura 28 – Diagrama de atividades método grava_acesso() classe Persistencia

Figura 29 – Diagrama de atividades método verifica_usuario() classe Persistencia

Figura 30 – Diagrama de atividades método incrementa_bloqueio() classe Persistencia

4.4.6 AcessoAdm
Este módulo do sistema é responsável pelos recursos de administração dos dados sobre
bloqueios, sites, usuários e outros dados. Resolve os casos de uso GerenciarAcesso e
GerenciarAluno, respectivamente de interesse do administrador e do professor, e todos os
casos de uso incluídos. O desenvolvimento baseia-se na linguagem PHP, com as páginas
hospedadas em um servidor web apache sob sistema operacional Linux, no ambiente da
faculdade. Os acessos apenas serão efetuados criptografados, de modo a evitar que dados
confidenciais sejam expostos.
Os diagramas de seqüência das figuras 17 e 18 ilustram a interação entre as classes e

os usuários, e o diagrama de estados a seguir ilustra como o sistema reage a solicitações.
4.4.6.1. Estados do sistema AcessoAdm
Quando um usuário, sendo ele professor ou administrador do sistema, abre um

navegador e solicita acesso à página de administração do sistema, é solicitado ao mesmo que
se identifique através de seu usuário e senha, previamente cadastrados no sistema. Esta
interação e as subseqüentes são demonstradas no diagrama a seguir.
Figura 31 – Diagrama de estados do sistema, módulo AcessoAdm

4.4.7 Compilações das dependências
Será descrito como será gerado código utilizável a partir do código-fonte, para os
arquivos gerados pelo projeto e para os sistema dos quais depende.
4.4.7.1 AcessoSquid
Para compilar o AcessoSquid, foi usada a ferramenta javac do pacote da Sun, versão
1.6.0 da JDK27.
Foram usados os comandos a seguir para criar o bytecode e empacotar em um arquivo

jar, lembrando que o conteúdo de “arquivo” é “AcessoSquid.java Persistencia.java” :
27 Disponível em <http://java.sun.com/javase/downloads/index.jsp> . Acesso em 06/05/2007.
#javac @arquivo
#jar cfm AcessoSquid.jar manifest-jar-AcessoSquid *.class postgresql-8.1-
405.jdbc3.jar
O arquivo de manifesto manifest-jar-AcessoSquid contém os parâmetros básicos para

o pacote jar, como autor, versão, CLASSPATH e classe principal de execução, no caso,
AcessoSquid.class que contém o método main(). Conforme a página de manual on-line do
utilitário jar (Sun), responsável pelo empacotamento, os parâmetros “f” e “m” devem estar na
mesma seqüência em que estão os nomes dos arquivos de destino do pacote e do
manifesto.(Sun Microsystems, 2007).
4.4.7.2 Squid
Para correta execução do cache Squid28, foi necessário a sua compilação a partir do
código-fonte, pois testes efetuados com pacotes pré-compilados das distribuições Debian,
Arch e Ubuntu resultaram em não utilização do AcessoSquid ou falta de parâmetros ao
mesmo, resultando em falha nos testes iniciais.
Para a compilação, foram utilizados os comandos básicos configure, make e make

install, mas com parâmetros especiais passados ao configure, que ficou como segue :
#./configure --prefix=/usr --datadir=/usr/share/squid \

--sysconfdir=/etc/squid --libexecdir=/usr/lib/squid \
--localstatedir=/var --enable-auth="basic,digest,ntlm" \
--enable-removal-policies="lru,heap" \
--enable-digest-auth-helpers="password" \
--enable-storeio="aufs,ufs,diskd,coss,null" \
--enable-basic-auth-helpers="getpwnam,YP,NCSA,SMB,PAM,multi-domain-NTLM,LDAP" \
--enable-external-acl-helpers="ip_user,unix_group,wbinfo_group" \
--enable-ntlm-auth-helpers="SMB,fakeauth,no_check" \
--enable-delay-pools --enable-arp-acl --enable-ssl \
--enable-linux-netfilter --enable-ident-lookups \
--enable-useragent-log --enable-cache-digests --enable-referer-log \
--enable-async-io --enable-truncate --enable-arp-acl \
--enable-htcp --enable-carp --enable-poll --with-maxfd=4096 \
--enable-default-err-language=Portuguese \
--enable-err-languages="Portuguese" \
--enable-async-io --enable-arp-acl
28 Disponível em <http://www.squid-cache.org>. Acesso em 20/05/2007.

Explicando :
● --prefix=/usr = Utilização do prefixo /usr para os diretórios de instalação

dos executáveis, bibliotecas e arquivos de inclusão;
● --sysconfdir=/etc = Uso do diretório /etc/squid para os arquivos de
configuração;
● --enable-delay-pools = Habilitação do controle de uso de banda dos acessos;
● --enable-icmp = Habilitação da possibilidade de requisições ICMP echo
reply, ou ping;
● --enable-default-err-language=Portuguese = Língua Português brasileiro para
mensagens de erro;
● --enable-linux-netfilter= Habilitação para proxy transparente em sistemas Linux;
● --enable-basic-auth-helpers=LDAP,NCSA = Habilitação para os sistemas
básicos de autenticação de usuários.
4.4.7.3. Outras dependências
Os outros pacotes dos quais o Agenda depende podem ser instalados pelos
procedimentos normais da distribuição Linux utilizada, sendo possível teoricamente sua
instalação em ambientes Windows, mas isto não foi testado. Para ambientes Linux, os
procedimentos descritos no capítulo 2 são suficientes.
4.5 Transição
Serão realizados os testes finais e a implantação do sistema, em iterações.
A implantação do sistema desenvolvido será efetivada em parte na máquina que

controla os acessos à Internet, e em parte na máquina que contém o servidor web da
instituição. Note-se que o sistema Agenda depende do sistema de autenticação de usuários
proveniente de um terceiro equipamento, este que contém a base de usuários da rede em um
serviço de diretório Active Directory©29, da Microsoft Corp. A instalação e as dependências
entre os pacotes de software são elucidados nos diagramas de implantação a seguir.
29 Active Directory e Microsoft são marcas registradas da Microsoft Corp.

Figura 32 - Diagrama de implantação do sistema AcessoSquid e dependências

Figura 33 – Diagrama de implantação do sistema AcessoAdm e dependências

Para a instalação do sistema, foi criado um script que automatiza as tarefas de

implantação, como cópia dos arquivos necessários, a criação da base de dados e carga dos
dados iniciais, e a compilação do programa AcessoSquid. Este script, de nome instala.sh,
possui como parâmetro o modo de instalação, descrito a seguir :
● completo - Verifica se há uma instalação anterior, se não, instala o

sistema criando uma nova base de dados, copiando os arquivos e corrigindo
permissões;
● atualiza_acessoSquid - Apenas copia os arquivos referentes ao AcessoSquid,
compilando-o e corrigindo permissões;
● atualiza_acessoAdm - Apenas copia os arquivos referentes ao AcessoAdm e
corrigindo permissões;
● não_verifica - Força uma instalação completa, sem verificações.
A alteração da configuração do programa Squid deve ser feita de modo manual, mas
um arquivo com um exemplo de uso é fornecido.
Para eventuais problemas, um teste do programa AcessoSquid em linha de comando é

possível, executando-se para isto os seguintes comandos :
# java -jar /usr/share/Agenda/AcessoSquid/AcessoSquid.jar
Será executado o programa e o mesmo ficará aguardando a entrada de dados. Para

verificação, digita-se a seguinte seqüência de caracteres :
www.google.com.br mario 192.168.0.1 /

OK
Isto será interpretado pelo sistema como se o site “www.google.com.br”, requisitado

pelo usuário “mario”, utilizando a máquina com endereço de rede “192.168.0.1” e a página
solicitada é a índice do diretório “/”. Os dados serão analisados e a resposta será “OK”, pois
estes dados iniciais fazem parte da carga inicial do banco de dados. Para sair do programa
digita-se conjuntamente “CTRL+C”.
5. RELAÇÃO ENTRE SISTEMAS, ALUNOS E DOCENTES
A utilização de softwares licenciados como livres, sob licenças como a GNU GPL30,
permite a sua livre redistribuição, mas também permite que se solicite o pagamento de taxas.
Mas a GPL exige que mantenha um meio aberto de disponibilização do material.
Para respeitar esta exigência, e para possibilitar que os interessados nos projetos
tenham acesso ao que foi pesquisado e desenvolvido, foi criado um diretório no equipamento
usado para compartilhar arquivos entre alunos e professores, acessível pela rede da faculdade,
e um acesso a este por meio do servidor web da página da instituição, e assim os interessados
podem ter acesso tanto pela rede interna, através de compartilhamentos com as máquinas dos
laboratórios, quanto pelo site, interna ou externamente.
Para acesso por compartilhamento, está disponível dentro do diretório “Fabrica” em

“Publica”, no servidor “fenix”. Para acesso pelo site, deve ser utilizado o link “downloads” na
página principal31.
5.1. Disponibilização de códigos e documentação
A documentação e códigos do projeto Agenda estão sob diretório de mesmo nome,

dentro de “Projetos/fabrica_de_software/”, no site da instituição. Assim como o material
pesquisado e códigos sobre o sistema Koha, que estão em diretório de mesmo nome do
sistema.
Igualmente, por ter sido desenvolvido pelo autor deste trabalho, foi disponibilizado o
material que serviu de base para o estudo do sistema Koha, assim como o que foi
30 Disponível em <http://www.gnu.org/licences/gpl.html>. Acesso em 17/05/2007.

31 Disponível em <http://www.fatecpg.com.br>. Acesso em 17/05/2007.
desenvolvido para o sistema Agenda. Para que o público interessado pudesse ter ciência sobre
a existência de tal material, foram postadas notícias sobre os assuntos no site br-linux32,
especializado na publicação sobre o assunto software livre. Além do material no servidor da
instituição, este está também acessível pelo site do Grupo de usuários de Linux de Praia
Grande33.
Em qualquer destas fontes, o acesso é permitido a qualquer interessado, sem a

necessidade de prévio cadastro, e o seu uso é regido pela Licença Geral Pública GNU.
5.2. As disciplinas e o material livre disponível
O corpo docente e os alunos aproveitariam o material no sentido de auxílio a seus

estudos e base de orientação a novos projetos. São diversas as disciplinas que tem condições
de aproveitamento imediato do material, e a seguir estão relacionadas algumas indicações de
como o fazer.
As disciplinas Inglês e Informática poderiam utilizar o sistema Koha como base de

estudo de HTML, tanto em sua estrutura quanto na tradução do sistema para o português, na
forma de trabalho acadêmico. Os resultados destes poderiam ser aproveitados para uso na
instituição e publicados na forma de contribuição para o projeto Koha, adicionando a tradução
às linguas oficialmente distribuídas com o projeto.
A disciplina de Sistemas Operacionais poderia demonstrar como os diversos sistemas

envolvidos interagem, e suas necessidades de configuração, operação e manutenção.
A disciplina de Teleprocessamento e Redes demonstraria como os diversos serviços se

comunicam, a nível de rede local e mundial, e as diversas tecnologias envolvidas na
publicação de material pela Internet e as entidades internacionais envolvidas em sua operação
e controle.
A disciplina de Banco de Dados usaria os diversos sistemas envolvidos como modelos

de estudo, tanto em estrutura, tecnologias e plataformas, como na modelagem de dados e sua
implementação.
32 Disponível em <http://br-linux.org/linux/agenda-novo-sistema-de-filtro-para-o-squid>. Acesso em
19/05/2007.
33 Disponível em <http://www.linux-pg.com.br>. Acesso em 19/05/2007.
A disciplina de Computação Gráfica poderia utilizar os mesmos sistemas em prol da

melhoria gráfica dos mesmos, demonstrando tecnologias e ferramentas utilizadas na edição de
imagens dos sistemas. Aproveitando-se de trabalhos acadêmicos, os sistemas poderiam ser
atualizados e adaptados para a realidade da Fatec.
As disciplinas de Análise de Sistemas, Sistemas de Informação, Linguagens de

Programação e Estruturas de Dados seriam as maiores beneficiadas, utilizando-se de todo o
material coletado e desenvolvido para base de estudo e como exemplos, para aprendizado de
desenvolvimento em software livre, assunto pouco comentado na instituição, pois em sua
maioria, são preferidas ferramentas e plataformas proprietárias pelo corpo docente, privando
alunos de contato com tecnologias livres.
Por fim, as disciplinas de Segurança de Dados e Auditoria Sistemas poderiam interagir

com os sistemas e os alunos de modo a verificar e aplicar os diversos conceitos envolvidos.
CONCLUSÃO
Foram utilizadas diversas fontes de informação ao longo da pesquisa,

desenvolvimento e implantação dos diversos sistemas e ferramentas, relacionadas
posteriormente.
Todas as informações necessárias à implantação do sistema de gerência de bibliotecas

Koha foram suficientes para efetiva implantação. Até o momento de conclusão deste trabalho,
estava em curso o treinamento dos usuários e a sua adequação para autenticação dos alunos
por meio dos sistemas existentes na faculdade, um Active Directory® da empresa Microsoft
Corporation®, onde estavam as informações sobre usuários cadastrados e senhas.
Ainda nesta fase de adequação de infra-estrutura, testes estavam em andamento para

implantação do sistema de filtro de acesso Agenda.
A efetiva ativação do servidor web, responsável pelo site principal e auxiliares de

serviços foi conseqüência desta adequação de estrutura. Foram utilizados apenas softwares
livres nesta ativação.
Com a ativação e utilização dos sistemas pesquisados em curso, e a ativação do

servidor web na faculdade, e ainda com a disponibilização do material criado e pesquisado
neste equipamento e outros, foi possível avaliar o resultado do principal objetivo deste
trabalho, a publicação para efetiva utilização por parte dos alunos e professores, sem
restrições quanto ao uso do material.
O referido está disponível, no momento da conclusão deste trabalho através de dois

meios de acesso, a saber o site da Fatec Praia Grande34 e do Linux Praia Grande35.
34 Disponível em <http://www.fatecpg.com.br/>. Acesso em 19/05/2007.

35 Disponível em <http://www.linux-pg.com.br/>. Acesso em 19/05/2007.
A estrutura na instituição para possibilitar esta publicação não envolveu a aquisição de

novos equipamentos ou a contratação de pessoal para sua operação. Os dois acessos
disponíveis à Internet instalados, um fornecido pela prefeitura da cidade de Praia Grande e o
outro pelo Centro Paula Souza, responsável pela faculdade, estão em plena utilização como
conseqüência do acerto na estrutura.
A ciência por parte do corpo docente e discente da instituição e de demais interessados

da liberação da documentação e códigos, é premissa para sua efetiva utilização. Para este
objetivo foi efetivada a publicação em veículo de abrangência nacional, o site de notícias em
tecnologias com software livre BR-Linux, e no site da faculdade, assim como pessoalmente
com diversos professores, coordenadores de curso da Escola técnica e Faculdade, e
diretamente aos alunos.
Além do escopo deste trabalho, mas que também foram utilizados na pesquisa, três
documentos sobre o sistema Koha foram traduzidos pelo autor e publicados no site do Linux
Praia Grande. Até o momento do fechamento deste trabalho, o Guia do novato contou 226
cópias, o Manual de instalação com 313, o Guia de estudo de arquitetura totalizou 252 cópias
efetuadas por interessados.
Além destes dados, o projeto Agenda ali disponível totalizou 207 cópias do código e
40 cópias dos seus respectivos diagramas UML. Estas informações são relativas a data de
acesso em 19/05/2007, e dados atualizados podem verificados no site do Linux Praia
Grande36.
Atinge-se assim o principal objetivo, o compartilhamento de informações e códigos de

sistemas de informação, e sua utilização efetiva em sistemas reais com a possibilidade de
interação com alunos, professores e demais interessados com os mesmos, na forma descrita de
software livre por Stallman(1998).
36 Disponível em <http://www.linux-pg.com.br/>. Acesso em 19/05/2007.

ANEXOS
ANEXO A - Utilização básica do sistema Koha
Koha basicamente tem três grandes partes, uma parte Linux, uma Intranet e um
catálogo on-line. As orientações são para se interagir com a parte Intranet. A intranet é a parte
que trabalha com o que as pessoas vêem na parte OPAC.
A.1. Conhecimentos básicos iniciais
Estes passos levam em consideração que não existam conhecimentos sobre o sistema
de gerenciamento de bibliotecas por parte do leitor. Assim, fluxos de trabalho herdados de
outros sistemas se aplicam, ou em parte, haja visto que sistemas como este relacionam-se a
um fluxo de trabalho muito parecido.
A.2. Introdução
Foram mantidos os termos em inglês originais do sistema para facilitar a localização

dos comandos e telas, pois a tradução do Koha para o português ainda não foi feita.
A.2.1. Consiga o Koha
É presumido que já se tenha um computador com o Koha instalado. Se não for o caso,
utilize as instruções constantes no capítulo 3.6 deste trabalho.
A.2.2. Material para catalogar
Este é o material de trabalho que fisicamente faz uma biblioteca. Eles podem ser
livros, músicas ou DVD's. Koha trabalha com qualquer material que você deseje catalogar.
A.3. Primeiros passos
Acesse a parte Intranet do sistema e, inicie clicando em "Parameters" que é a próximo

ao final da tela.
A.4. Parameters
Preencha os campos na ordem em que eles aparecerem e de acordo com as descrições

deste trabalho para ter um sistema Koha utilizável.
Preenchidos os campos, clique em "OK".
A.4.1. Adicionando uma filial
O primeiro passo é em "Library Branches". Clique.
O começo é a definição das categorias da filial. Clique em "Add new category" e na

tela apresentada preencha os campos. Clique em "OK" para salvar os dados e repita para as
outras categorias se necessário, se existirem.
Agora clique em "Add New Branch".
Se houver apenas uma biblioteca, é apenas isto. É como se houvesse uma coleção
caseira ou apenas uma coleção, ou coisa parecida, necessitando de apenas uma filial. Se
expandir depois, o Koha aceita que sejam adicionadas filiais mais tarde.
Digite um código pequeno para a filial. O Koha aceita apenas quatro caracteres aqui.
Um exemplo, foi digitado "MAIN" para filial dos testes.
Devem ser preenchidos os campos Phone, Fax, e E-mail com os dados

correspondentes. Selecione dentre as categorias cadastradas anteriormente, conforme qual
filial a biblioteca em questão pertence.
Se alguma coisa mudar, poderão ser alteradas estas informações mais tarde voltando
nesta tela e clicando em "Edit".
A.4.2. Book Funds
Se deseja adicionar um orçamento, clique em "Add Bookfund".
Agora o novo fundo irá aparecer na tela "Book Funds", na forma de uma barra amarela
e verde clara. Clique no ícone de papel com sinal + para dizer ao Koha algo mais sobre o
orçamento.
Koha pede uma data inicial, uma final e o total do orçamento. Note que Koha pede o
formato europeu para datas, dia, mês e ano.
A.4.3. Currencies
Também não é necessário fazer nada aqui, a não ser que se trabalhe com o fundo para
livros.
Se deseja adicionar uma moeda, clique em "Currencies" e em "Add currency". Nos

testes foi usado "US DOLLARS", com rate em 1. Se necessitar de uma faixa maior que 1,
digite-a calculando a partir da principal.
A.4.4. Item Tipes
É todo tipo de material que se desejaria cadastrar, que existe em alguma localização da
biblioteca. Talvez sejam necessários mais ou menos que 28 tipos de itens, mas os 20
primeiros, como exemplo, podem ser :
Adult Audio Book Fiction, Adult Audio Book Non Fiction, Adult Audio Book on
CD Fiction, Adult Audio Book on CD Non Fiction, Adult Fiction, Adult Magazine,
Adult Non Fiction, Board Book, Caldecott Award Book, Comic Book, Musical
CD, DVD, Kid's Easy Reader, Graphic Novel, Kid's Audio Book Fiction, Kid's
Audio Non Fiction, Kid's CD, Kid's Fiction, Kid's Magazine, Kid's Non Fiction
(Interfiled with Adult).
A.4.4.1 Adicionando novos tipos
Na tela "Item Type", clique em "Add Item Type".
Crie um código de até 4 letras para o tipo de item. Por exemplo, o código para "Adult
Audio Book Fiction" pode ser AAF. Pode ser que não sejam mais vistos estes códigos, mas
ele existe para que o computador trabalhe com ele.
O que será visto é a descrição. Quando listar o primeiro grupo de tipos de itens, serão
todos descrições. Uma boa descrição dá ao cliente e ao funcionário uma idéia geral sobre
onde o item pode ser encontrado e o que ele é. Isto não é nada preciso, apenas uma idéia
geral.
É crucial nomear corretamente os tipos de itens, porque se decidir que alguns devem
ter nomes diferentes mais tarde, deverão ser mudados os registros MARC individualmente
para todos eles depois.
A.4.4.1.1. Not for loan
Isto é essencialmente material para apenas uso exclusivo da biblioteca, que não será
emprestado.
Os materiais com esta caixa assinalada são gerenciados, mas não é permitido a eles o
empréstimo.
A.4.4.1.2. Number of Renewals
É quantas vezes o item poderá ter sua renovação no período de empréstimo, desde que
não tenha sido selecionado o campo "Not For Loan", o que fará com que este campo seja
inútil.
A.4.4.1.3. Rental charge
Neste campo será digitado o quanto será cobrado por cada empréstimo de seus
clientes. Algumas bibliotecas cobram pelo aluguel de vídeos ao invés de simplesmente

emprestá-los. Se este é o caso em sua biblioteca, o valor do aluguel é digitado aqui.
A.4.4.1.4. Clique OK
Depois de todo este trabalho, não se deve esquecer de salvá-lo. Tenha certeza de clicar
em "OK" para salvar o que foi digitado nesta tela.
A.4.5. Borrower Categories
Para o banco de dados, estes tipos de pessoas como são os tipos de itens.
Podem ser diferenciados os tipos de emprestadores para dar aos mesmos direitos
diferentes sobre os materiais. Pode ser desejado cobrar taxas de mensalidade ou anuidade
diferenciadas de uns e não cobrar de outros, por exemplo.
A.4.5.1. Add Category
Clique em "Add Category" na tela de administração "Category" para começar.
A.4.5.1.1 Category code
Este campo tem apenas 2 caracteres. Apenas crie um código para os tipos e o digite
aqui.
A.4.5.1.2. Description
Neste campo deve ser digitada a descrição do tipo do emprestador, como Adulto,
Criança, Jovem, Empregado ou outro que seja necessário.
A.4.5.1.3. Enrollment period
Este é o período em anos pelo qual o registro de um emprestador deste tipo de pessoa
será mantido.
A.4.5.1.4. Upperage Limit
Aqui é digitada a idade máxima que uma pessoa pode ter para pertencer a esta
categoria.
A.4.5.1.5. Age Required
Aqui é digitada a idade mínima que uma pessoa precisa ter para pertencer a esta
categoria.
A.4.5.1.6. Enrollment fee
Aqui é digitada a taxa anual para que o cliente mantenha seu cadastro na biblioteca. Se
for digitado 0 aqui, nada será cobrado, ou digite o valor desejado. O registro do pagamento
será realizado na tela "Members".
A.4.5.1.7. Overdue notice required
Este campo refere-se à criação de relatórios de relocações. Se configurado para "no", o

tipo de emprestador não receberá um aviso de que seu empréstimo foi cobrado novamente ou
multado, após o atraso no período normal de empréstimo.
A.4.5.1.8. Issue limit
Neste campo é digitada a quantidade máxima de itens que pode ser emprestada a cada
vez para este tipo de emprestador.
A.4.5.1.9. Reserve fee
Neste campo é digitado o valor que será cobrado deste tipo de emprestador para cada
reserva que o mesmo faça de um item. Caso não seja cobrado nada, basta digitar 0 neste
campo.
A.4.6. Issuing rules
Nesta tela são configuradas as regras de empréstimos, para cada tipo de

emprestador/material cadastrado, ou comum a todos.
As multas são editadas em relação às categorias de emprestadores e dos tipos de itens.

Assim, antes de editar algo aqui, os tipos de emprestadores na tela "Borrower Categories
deverão estar corretamente configurados. No caso de ser adicionado um novo tipo de
emprestador, e se houver regras de multas aplicáveis ao mesmo, diferentes de um padrão,
estas devem ser editadas aqui. Igualmente, os tipos de itens devem estar configurados para
que as regras desta tela possam ser editadas.
A.4.6.1. Regras para empréstimos (Issue)
Cada campo deve ser preenchido com os valores de quantidade de dias de empréstimo
e quantidade de itens a cada empréstimo, números inteiros e separados por uma vírgula. Por
exemplo, "7,2" neste campo (Issue) significa um empréstimo de 7 dias com no máximo 2
itens.
A.4.6.2. Regras para multas (fines)
Cada campo deve ser preenchido com valor da multa, tempo em dias para início de
cobrança, e de quantos em quantos dias a cobrança deve ser feita. Por exemplo, "1,7,7" neste
campo significa que será cobrado o valor de 1 moeda cadastrada em "Currencies", começando
7 dias após o empréstimo, e com uma nova cobrança a cada 7 dias.
Observ.: As multas são calculadas pelo script fines2.pl, localizado no diretório misc da
instalação do Koha. Solicite ao seu administrador que o inclua no crontab do servidor para
que as multas possam ser calculadas toda noite.
Caso alguma célula não seja preenchida, os valores constantes nas células "*" serão
usados, e caso não tenha sido preenchida, o valor "21,5" será usado, que está no código do
Koha.
A.4.7. Authorized Values
Quando é definida uma estrutura para uma tag MARC, pode ser definido como o
subcampo será gerenciado. Se não for definido nada, o subcampo é livre. se for escolhida uma
categoria de valores autorizados, então uma lista é apresentada e um valor desta lista terá que
ser selecionado.
Por exemplo, a língua de um documento. Há uma tabela existente, que relaciona

códigos de três dígitos com uma língua, eng=english, fre=french, etc.
Então, entre estes valores numa lista autorizada (por exemplo, categoria LANG), e
selecione subcampos de língua para LANG. Os dígitos que forem eng corresponderão a
english, e assim por diante.
A.4.8. Thesaurus
O arquivo Thesaurus pode ser usado de duas formas, gerenciar formas autorizadas e
rejeitadas para o mesmo conceito, ou gerenciar hierarquia dos dados.
Como os valores autorizados, thesaurus é usado no editor MARC. Se for selecionada

uma categoria thesaurus para um subcampo, então uma janela popup abrirá e deverá ser
selecionada a face do subcampo.
Pode ser procurado no thesaurus um valor, acima ou abaixo, adicione o valor se não
for encontrado.
Também podem ser definidos valores rejeitados. Se for procurado e selecionado um

valor rejeitado, um valor autorizado será colocado em seu lugar.
A.4.9. Printers
Aqui são configuradas as impressoras do sistema, que poderão ser usadas nas
operações de circulação e relatórios. Lembrando que a qualquer momento, as telas do
navegador poderão ser impressas caso exista necessidade.
A.4.10. Stop Words
Stop Words são as palavras ignoradas durante uma pesquisa. Palavras comuns como
"A", "O", "de" quando bloqueadas aceleram uma pesquisa.
A.4.11. Z39.50 Servers
Koha é fornecido com um cliente Z39.50 para pesquisas em outras bibliotecas

compatíveis com registros MARC. Nesta tela são definidos os parâmetros dos servidores onde
o Koha efetuará as pesquisas.
O padrão internacional Z39.50 é usado para pesquisas e recuperação de dados de

servidores remotos. Na prática, ele provê um modo das bibliotecas pesquisarem e
recuperarem registros de outras bibliotecas. O cliente Z39.50 é fornecido como um
componente do sistema integrado de biblioteca, e o servidor Z39.50 é muito menos comum.
Index Data of Denmark (http://www.indexdata.dk) fornece a maioria das ferramentas de
software usadas para o Z39.50, e mantém uma lista dos servidores Z39.50 ao redor do mundo
(http://targettest.indexdata.com).
Nesta tela, podem ser definidos os servidores para as pesquisas. Tenha certeza que os
servidores escolhidos suportam o formato MARC definido nas preferências do sistema. Para
adicionar servidores, devem ser conhecidos o nome ou ip do servidor, a porta e o nome da
base de dados a ser acessada. Alguns servidores não aceitam conexões anônimas, e usuário e
senha podem ser digitados nos seus campos.
A.4.12. System Preferences
Esta tela contém uma miscelânea de configurações que merecem atenção. Elas
definem o comportamento do sistema e devem ser editadas com cuidado.
A.4.13. Tools
As ferramentas de importação e exportação tratam arquivos no format ISO2709, para

transferência de dados com o sistema.
A.4.13.1. MARC biblio export
Esta ferramenta possibilita o backup dos seus registros bibliográficos, ou a exportação

dos dados que podem ser enviados a outra pessoa. O backup é realizado não preenchendo
nenhum campo, e clicando em OK, salvando o arquivo resultante em um diretório.
A.4.13.2. Upload MARC records into Reservoir
Esta ferramenta permite a importação de registros MARC, obtidos de outra forma que
não a pesquisa Z3950 durante a catalogação de materais.
A.4.13.3. Generate Barcodes
Esta ferramenta pode ser usada para gerar etiquetas com código de barras para os itens
de sua biblioteca. Mas para que isto funcione, a versão 0.33r77 do módulo Perl PDF::API2
deve estar instalada.
A tela pode ser confusa no começo. Pode ser gerada uma ou uma série de etiquetas,
mas apenas de itens que já constam do catálogo. As etiquetas serão geradas em código
EAN128, comum mundo afora. Há um campo que pode ser usado para digitar o texto que será
impresso nas etiquetas, e se estiver em branco será usado o nome e o autor do item
relacionado.
Em uma tabela embaixo pode ser selecionado a partir de qual etiqueta a impressão
começará, pois podem ter sido usadas algumas etiquetas de uma folha de etiquetas adesivas,
por exemplo. A quantidade de etiquetas na página e outros dados podem ser editados clicando
no link "Go to Printer Configuration". Edite os dados nesta página de configuração da
impressora e clique em salvar.
Com os parâmetros configurados, as etiquetas podem ser geradas clicando em

"Generate Barcodes" . Note que o código de barras é gerado com 11 dígitos.
A.5. Catalogando o material
Clicando em "Catalogue", é apresentada a tela de pesquisa no catálogo, e outras

funções estão disponíveis como a seguir.
A.5.1. Para adicionar um item, de mesmo tipo de um já cadastrado :
1. Selecione "Catalogue -> Add biblio".

2. Digite o título no campo title ou o código ISBN em seu campo e clique em "Go" para
iniciar a pesquisa dos dados na base de dados.
3. Será apresentada uma tela contendo os dados cadastrados da obra, e então como o
material já está cadastrado, basta clicar em "Edit" para verificar os dados.
4. Uma vez clicado em "Edit", altere se desejar algum campo MARC e então clique em
"Save" acima dos campos.
5. Será apresentada então uma tela com uma lista dos itens existentes desta obra,
possibilitando o acréscimo de novos itens. Se desejar acrescentar um item desta obra,
no quadro "New item" selecione a biblioteca filial de origem do item em
"homebranch" e a biblioteca responsável pelo item em "holdingbranch", que podem
ser a mesma filial. Digite ou escaneie o código de barras do item posicionando o
cursor com o mouse (clicando) no campo "barcode", digite o preço do item para
possível cobrança em caso de perda do mesmo por um cliente, se desejar no campo
"price", e a data de entrada do item no campo "dateaccessioned". Se o item não for
para empréstimo, digite "y" no campo "notforloan", ou deixe em branco para permitir
que o item fique disponível para empréstimo.
A.5.2. Para adicionar um item ainda não cadastrado :
1. Selecione "Catalogue -> Add biblio".

2. Digite o título no campo title ou o código ISBN em seu campo e clique em "Go" para
iniciar a pesquisa dos dados na base de dados. Se tiver certeza que o item não possui
informações cadastradas, clique em "Create empty biblio".
3. Na página de edição apresentada, existem abas numeradas à esquerda de 0 a 5, digite
as seguintes informações nos campos numerados, de acordo com o número da aba :
● aba 0
022 - digite o ISBN da obra

100 - digite o autor da obra ou 110 - digite a empresa autora da obra
● aba 1
245 - digite o título da obra
250 - digite a edição da obra
260 - digite a imprenta da obra (local, editora e data de publicação)
● aba 2
500 - digite a categoria da obra (ficção, documentário, etc...)
505 - digite o conteúdo da obra (ficção científica, romance, etc...)
● aba 5
942 - no item b, selecione o tipo de item entre um dos pré-cadastrados
4. Clique então em "Add biblio"
5. Será apresentada uma tela para acréscimo de novos itens, e segue-se então as
instruções do tópico 5 anterior.
Então, no menu abaixo do título da obra, clique em "normal", e será então apresentada
uma tela com dados básicos da obra e a lista dos itens cadastrados. No menu abaixo do título
da obra clique em "Add to shelf", para relacionar o item a uma prateleira da biblioteca. Se
desejar relacionar o item a uma prateleira já existente, selecione-a em "Add to virtual shelf",
ou então digite o nome da prateleira no campo abaixo de "or add to a new book shelf",
selecionando o tipo de prateleira no campo, ao lado, conforme o desejado.
A.6. Cadastrando ou editando um cliente
Clique em "Members -> Add member" para adicionar um novo cliente à biblioteca.
A tela "Add member" será apresentada, e então os campos relativos ao novo cliente
podem ser digitados.
Clique em "Members -> Search" para localizar os dados sobre um cliente.
Clique em "Members -> Add organization" para adicionar um cliente institucional.
Os campos em negrito são obrigatórios, mas tanto melhor quanto mais informações
forem coletadas neste momento.
Os campos FLAGS significam :
● "Gone no address" - o cliente não tem endereço de e-mail, então mensagens

endereçadas a ele serão retornadas à biblioteca.
● "Lost" - o cliente perdeu o cartão da biblioteca.
● "Debarred" - o cliente infringiu alguma regra da biblioteca e os serviços da biblioteca
estão bloqueados a ele enquanto sua situação não for regularizada.
Após a edição necessária, não esqueça de clicar em "Save" para salvar sua alterações.
Para alterar o nível de acesso do cliente cadastrado, de modo a que ele tenha o nível de
acesso de um funcionário da biblioteca por exemplo, na tela "Membership record" clique em
"Modify user flags" e altere conforme a permissão desejada ao mesmo.
A.7. Emprestando e retornando material
Para acessar as funções acima no Koha, clique em "Circulation".
A.7.1. Emprestando um material
Pode ser acessada a função diretamente clicando em "Circulation -> Issue". Na tela
apresentada, no quadro "Circulation : Issues" podem ser alteradas as configurações de
impressora ou diretamente digitar o código do cliente ou parte de seu nome. Clicando em
"OK" ou digitando "enter" no teclado, será apresentada uma tela para que seja selecionado o
cliente correspondente se houver mais que um registro que corresponda ao parâmetro
informado, ou a tela de empréstimo se o dado informado se relacionar a apenas um cliente.
No quadro "Enter book barcode", use o leitor de código de barras ou digite o código
respectivo e tecle "Enter". Neste momento, pode aparecer um quadro solicitando a
confirmação do empréstimo, pois o Koha verifica as regras cadastradas e a situação dos itens
e do cliente antes de registrar o empréstimo, e se esta tela aparecer verifique a mensagem,
analisando, confirmando ou negando conforme o necessário. Se a mesma não aparecer ou se o
empréstimo for confirmado, este já está registrado e aparecerá um quadro abaixo de nome
"Previous issues" com o empréstimo efetuado. Se o cliente já possuir empréstimos anteriores,
este quadro já aparecerá após a confirmação dos dados do cliente. Digite o código de barras
ou use o leitor para cada item que será emprestado ao cliente.
Observe que a data do empréstimo pode ser alterada antes da entrada do código do
material, e apenas antes, utilizando os campos de dia, mês e ano. Se for desejado que estas
datas se repitam para cada item emprestado nesta operação, clique no campo "Stycky due
date".
A.7.2. Retornando material
Para retornar um item, clique em "Circulation -> Returns", e então a tela de retornos
será apresentada.
No quadro "Enter book barcode", digite o código de barras e tecle "Enter" ou use o
leitor para entrar com o código do item a ser retornado.
Será apresentado o nome e código do cliente que estava com o item, a descrição do
item para confirmação visual do que está sendo retornado, e o item estará novamente
disponível para novo empréstimo.
Se houver uma reserva pendente para o item, será apresentada uma mensagem, deve
ser clicado "OK" para continuar a retornar itens.
A.7.3. Verificando as reservas pendentes
As reservas pendentes podem ser verificadas clicando-se em "Circulation -> reserves

pending".
A.8. Considerações sobre o guia resumido
Estas são apenas algumas orientações a respeito deste sistema, e muito mais existe
sobre seu funcionamento e trabalho diário. É altamente recomendável a leitura do manual
disponível em <http://www.kohadocs.org/usersguide/index.html>. No momento da edição
deste trabalho, a versão de produção do Koha é a 2.2.5, disponível para download em
<http://download.savannah.nongnu.org/releases/koha/> .
REFERÊNCIAS BIBLIOGRÁFICAS
ALVES, WILLIAM PEREIRA. Fundamentos de Bancos de Dados. São Paulo : Érica, 2004.
DIÁRIO OFICIAL DA UNIÃO. Lei 9609/98 Propriedade intelectual de software e

comercialização. Brasília: 20/02/1998.
DIÁRIO OFICIAL DA UNIÃO. Lei 9610/98 Lei de Direitos Autorais. Brasília : 20/02/1998.
FERRARO, JOSHUA. Instaling Koha 2.2.7 On Debian GNU/Linux 3.1 "stable" (sarge).
.NET, 2006. Disponível em
<http://www.kohadocs.org/Installing_Koha_on_Debian_sarge.html>. Acesso em 20/05/2007.
FREE SOFTWARE FOUNDATION INC. Gnu General Public Licence. .NET, Boston, jun
1991. Disponível em <http://www.gnu.org/licences/gpl.html>. Acesso em 20/05/2007.
FREE SOFTWARE FOUNDATION. Introdução ao projeto GNU. .NET, Boston, mai. 2005.
Disponível em <http://www.gnu.org/gnu/gnu-history.pt.html>. Acesso em 19/05/2007.
LARMAN, CRAIG. Utilizando UML e padrões. 2. ed. Porto Alegre : Bookman, 2004.
MEDEIROS, MARCELO. Banco de dados para sistemas de informação. Florianópolis :

Visual Books, 2006.
MYSQL AB. Manual de referência do Mysql 4.1. .NET, 2007. Disponível em

<http://dev.mysql.com/doc/refman/4.1/pt/index.html>. Acesso em 20/05/2007.
PENDER, TOM. UML, a Bíblia. Rio de Janeiro : Elsevier, 2004.

PHP DOCUMENTATION GROUP. Manual do PHP. .NET, abr. 2007. Disponível em

<http://www.php.net/manual/pt_BR/>. Acesso em 20/05/2007.
POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL 7.4.17 Documentation.

.NET, 2003. Disponível em <http://www.postgresql.org/docs/7.4/static/index.html>. Acesso
em 20/05/2007.
PROJETO DEBIAN. Uma breve história do Debian. .NET, jul. 2002. Disponível em
<http://www.debian.org/doc/manuals/project-history/>. Acesso em 20/05/2007.
PROJETO DEBIAN. Contrato social. .NET, abr. 2004. Disponível em

<http://www.debian.org/social_contract>. Acesso em 20/05/2007.
PROJETO DEBIAN. Manual de instalação Debian GNU/Linux. .NET, 2007. Disponível em

<http://www.debian.org/releases/stable/i386/index.html.pt_BR>. Acesso em 20/05/2007.
REZENDE, DENIS ALCIDES. Engenharia de software e sistemas de informação. 3 ed. Rio

de Janeiro : Brasport, 2005.
ROBERT, KIRRILY. perlintro. .NET, 2007. Disponível em

<http://perldoc.perl.org/perlintro.html>. Acesso em 20/05/2007.
ROSASCO, NICHOLAS; BAKKE, ERIK. Koha Arquitetural Study. .Net, 2005. Disponível
em <http://www.kohadocs.org/Koha_architecture.html>. Acesso em 25 mar. 2007.
SCHILDT, HERB. C++ : the complete reference. 3 ed. Osborne : McGraw-Hill, 1998.
SILVA, GLEYDSON MAZIOLI DA. Guia Foca GNU/Linux. .NET, out. 2006. Disponível
em <http://focalinux.cipsga.org.br/guia/iniciante/ch-intro.htm>. Acesso em 20/05/2007.
STALLMAN, RICHARD. Linux e o Sistema GNU. .NET, 1996. Disponível em

<http://www.cipsga.org.br/sections.php?op=viewarticle&artid=49>. Acesso em 19/05/2007
STALLMAN, RICHARD. O projeto GNU. .NET, 1998. Disponível em

<http://www.cipsga.org.br/sections.php?op=viewarticle&artid=61>. Acesso em 20/05/2007.
SUN MICROSYSTEMS. Sobre a tecnologia Java. .NET. jan. 2002. Disponível em

<http://www.java.com/pt_BR/about/>. Acesso em 20/05/2007.
THE APACHE SOFTWARE FOUNDATION. About the apache HTTP Server Project.
.NET, 2005. Disponível em <http://httpd.apache.org/ABOUT_APACHE.html>. Acesso em
20/05/2007.
BIBLIOGRAFIA
ALVES, WILLIAM PEREIRA. Fundamentos de Bancos de Dados. São Paulo : Érica, 2004.
CHOI, WANKYU et al. Beginning PHP4. Birmingham : Wrox Press. 2000.
DIÁRIO OFICIAL DA UNIÃO. Lei 9609/98 Propriedade intelectual de software e

comercialização. Brasília: 20/02/1998.
DIÁRIO OFICIAL DA UNIÃO. Lei 9610/98 Lei de Direitos Autorais. Brasília : 20/02/1998.
ECKEL, BRUCE. Thinking in Java. Upper Saddle River : Printice Hall. 2000.
FERRARO, JOSHUA. Instaling Koha 2.2.7 On Debian GNU/Linux 3.1 "stable" (sarge).
.NET, 2006. Disponível em
<http://www.kohadocs.org/Installing_Koha_on_Debian_sarge.html>. Acesso em 20/05/2007.
FREE SOFTWARE FOUNDATION INC. Gnu General Public Licence. .NET, Boston, jun
1991. Disponível em <http://www.gnu.org/licences/gpl.html>. Acesso em 20/05/2007.
FREE SOFTWARE FOUNDATION. Introdução ao projeto GNU. .NET, Boston, mai. 2005.
Disponível em <http://www.gnu.org/gnu/gnu-history.pt.html>. Acesso em 19/05/2007.
KABIR, J. MOHAMMED. Apache Server 2 Bible. New York : Hungry Minds Inc. , 2002.
LARMAN, CRAIG. Utilizando UML e padrões. 2. ed. Porto Alegre : Bookman, 2004.
MEDEIROS, MARCELO. Banco de dados para sistemas de informação. Florianópolis :

Visual Books, 2006.
MOMJIAN, BRUCE. PostgreSQL : introduction and concepts. Boston : Addison-Wesley,

2001.
MYSQL AB. Manual de referência do Mysql 4.1. .NET, 2007. Disponível em

<http://dev.mysql.com/doc/refman/4.1/pt/index.html>. Acesso em 20/05/2007.
PEARSON, OSKAR. Squid Users Guide. .NET, 2006. Disponível em

<http://www.deckle.co.za/squid-users-guide/Main_Page>. Acesso em 20/05/2007.
PEEK, JERRY. TODINO, GRACE. STRANG, JOHN. Learnig the UNIX operating system.
OReilly . 1998.
PENDER, TOM. UML, a Bíblia. Rio de Janeiro : Elsevier, 2004.
PERES DA SILVA, NELSON. Projeto e Desenvolvimento de Sistemas. São Paulo : Érica.

2005.
PHP DOCUMENTATION GROUP. Manual do PHP. .NET, abr. 2007. Disponível em

<http://www.php.net/manual/pt_BR/>. Acesso em 20/05/2007.
POSTGRESQL GLOBAL DEVELOPMENT GROUP. PostgreSQL 7.4.17 Documentation.

.NET, 2003. Disponível em <http://www.postgresql.org/docs/7.4/static/index.html>. Acesso
em 20/05/2007.
PROJETO DEBIAN. Uma breve história do Debian. .NET, jul. 2002. Disponível em
<http://www.debian.org/doc/manuals/project-history/>. Acesso em 20/05/2007.
PROJETO DEBIAN. Contrato social. .NET, abr. 2004. Disponível em

<http://www.debian.org/social_contract>. Acesso em 20/05/2007.
PROJETO DEBIAN. Manual de instalação Debian GNU/Linux. .NET, 2007. Disponível em

<http://www.debian.org/releases/stable/i386/index.html.pt_BR>. Acesso em 20/05/2007.
REZENDE, DENIS ALCIDES. Engenharia de software e sistemas de informação. 3 ed. Rio

de Janeiro : Brasport, 2005.
ROBERT, KIRRILY. perlintro. .NET, 2007. Disponível em

<http://perldoc.perl.org/perlintro.html>. Acesso em 20/05/2007.
ROSASCO, NICHOLAS; BAKKE, ERIK. Koha Arquitetural Study. .Net, 2005. Disponível
em <http://www.kohadocs.org/Koha_architecture.html>. Acesso em 25 mar. 2007.
SCHILDT, HERB. C++ : the complete reference. 3 ed. Osborne : McGraw-Hill, 1998.
SCOTT, KENDALL, O processo unificado explicado. Porto Alegre : Bookman, 2003.
SIEVER, ELLEN. SPANHOUR, STEPHEN. PATWARDHAN, NATHAN. Perl-guia

completo. São Paulo. Ciência Moderna : 1999.
SILVA, GLEYDSON MAZIOLI DA. Guia Foca GNU/Linux. .NET, out. 2006. Disponível
em <http://focalinux.cipsga.org.br/guia/iniciante/ch-intro.htm>. Acesso em 20/05/2007.
STALLMAN, RICHARD. Linux e o Sistema GNU. .NET, 1996. Disponível em

<http://www.cipsga.org.br/sections.php?op=viewarticle&artid=49>. Acesso em 19/05/2007
STALLMAN, RICHARD. O projeto GNU. .NET, 1998. Disponível em

<http://www.cipsga.org.br/sections.php?op=viewarticle&artid=61>. Acesso em 20/05/2007.
SUN MICROSYSTEMS. Sobre a tecnologia Java. .NET. jan. 2002. Disponível em

<http://www.java.com/pt_BR/about/>. Acesso em 20/05/2007.
THE APACHE SOFTWARE FOUNDATION. About the apache HTTP Server Project.
.NET, 2005. Disponível em <http://httpd.apache.org/ABOUT_APACHE.html>. Acesso em
20/05/2007.
GLOSSÁRIO
Squid – programa de cache HTTP, através do qual o acesso à internet na faculdade é

realizado. Este programa interage com o sistema proposto obtendo a URL do site que será
entregue ao usuário, fornecendo para isto a URL desejada pelo usuário, o nome do usuário e o
endereço MAC do computador cliente. Através de análise de dados do cadastro, é identificado
o usuário como Aluno, Professor ou Administrador e analisadas as regras de acesso conforme
o caso.
URL – Uniform Resource Location, localização uniforme de recurso, forma padronizada de

nomes de domínios e hosts na internet. Representam o nome de um computador em seu
domínio em sua forma totalmente qualificada (FQDN).
GRASP – Os padrões GRASP descrevem princípios fundamentais de projeto baseado em

objetos e atribuição de responsabilidades aos mesmos. GRASP significa General
Responsibility Assignment software Patterns. São os seguintes os cinco primeiros padrões
GRASP : Especialista na informação, Criador, Coesão Alta, Acoplamento baixo e
Controlador.
WEB – originalmente significa teia, mas assume o conceito de serviço de páginas acessáveis
por outros computadores em informática.

TCC Versao Final

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TCC Versao Final

Uploaded by

Copyright:

Available Formats

Software livre e sistemas de informação na Fatec Praia Grande – 1

FACULDADE DE TECNOLOGIA PRAIA GRANDE

SOFTWARE LIVRE E SISTEMAS DE

AUTOR: MARIO SERGIO KIRDEIKA JUNIOR

ORIENTADOR : PROF. WAGNER ALVES

MARIO SERGIO KIRDEIKA JUNIOR

Monografia apresentada à Faculdade de

Orientador : Prof. Wagner Alves

A minha esposa, pela compreensão do tempo dispendido

À Fundação GNU e a Linus Torvalds, por iniciarem um verdadeira revolução

À Profª. Cybelle Rocha, pelo apoio e orientação na construção do trabalho.

Ao sr. Domingos Latorre, pela colaboração mútua no intenso trabalho no Centro de

Ao Prof. Nilson Duarte, pela compreensão do alcance do trabalho realizado, apoio e

Ao sr. Venâncio e a sra. Zilda, funcionários da biblioteca, pelo apoio e colaboração na

O presente trabalho tem por objetivo relacionar as informações e códigos sobre

Palavras-chave: software, livre, sistemas, informação, desenvolvimento, implantação.

Keywords: software, free, systems, information, development, implantation.

No estudo de sistemas de informação ao longo do curso da instituição não foi possível

Tendo em vista a restrição de acesso à documentação e ao código de sistemas

A primeira e mais incidente necessidade foi notada em relação aos procedimentos

A partir destes requisitos, considerando a estrutura de T.I. em uso na faculdade e as

1 Disponível em <http://www.google.com.br>. Acesso em 10/07/2006.

Foi então verificada a existência do sistema de gerência de bibliotecas Koha,

É possível implantar sistemas de Informação utilizando-os em sua função inicial, e

A existência de informações abertas e livres sobre sistemas de informação,

2 Disponível em <http://www.gnu.org/licenses/licenses.html#GPL>. Acesso em 19/05/2007.

Então, como obter tais informações, relacioná-las e disponibilizá-las de modo a

Com isto, foram relacionados os temas necessários ao entendimento de sistemas

Estas informações foram estruturadas na forma descrita neste trabalho.

No capítulo um são apresentadas as teorias essenciais sobre sistemas de informação,

No capítulo dois estão as ferramentas, softwares e sistemas auxiliares utilizados para a

No capítulo três consta a implantação do sistema Koha, a sua estrutura e utilização

No capítulo quatro, está relacionada a documentação sobre o desenvolvimento do

No capítulo cinco, está apresentada a forma com que foram disponibilizadas as

Ainda, no Anexo A, há o manual para o iniciante na utilização do sistema Koha, aqui

A definição dos conceitos fundamentais sobre dado, informação, sistemas e

1.1. Dado, informação, sistemas e T.I.

Conforme Rezende(2005), o dado é entendido como um elemento da informação, que

A organização e seleção de informações, com o objetivo de gerar cenários, simulações

Organizações humanas, como o propósito de confecção de produtos ou serviços,

Conforme Rezende ( 2005 ), toda empresa ( organização ) é um sistema, e assim

Para gerenciar a complexidade e volume de dados e informações gerados pelas

organizações, mantendo a sinergia dos sistemas estas utilizam-se dos recursos

Conforme a posição na pirâmide organizacional em que um sistema de informação

● operacionais : atuam com o nível mais baixo da pirâmide da organização, onde

● gerenciais : trabalham com os grupos de dados gerados pelos sistemas

● estratégicos : operam com os níveis mais altos da organização, trabalhando

Para propiciar a conquista destes objetivos comuns, é primordial a identificação das

Conforme Larman(2004), um processo de desenvolvimento de software descreve uma

1.4. O Processo Unificado

Nesta abordagem do P.U., outras práticas relacionadas são :

● enfrentar alto risco e alto valor nas primeiras iterações;

A organização de cada iteração possui quatro fases, descritas a seguir :

● Concepção - visão aproximada, escopo e estimativas vagas;

1.5. Linguagem de Modelagem Unificada - UML

Os sistemas descritos neste trabalho fazem uso desta linguagem de modelagem,

2. FERRAMENTAS PARA SISTEMAS ABERTOS

Neste capítulo serão apresentados os conceitos e programas utilizados em

Conforme a lei 9609, de 19 de fevereiro de 1998, em seu artigo 1º, software ou

2.2. Patentes de software

Empresas produtoras de software cobram pelo uso de seus programas. Isto

Free software Foundation (2006), as empresas e os programadores compartilhavam código

Conforme a Free Software Foundation(2006), em 1983 foi idealizado o projeto GNU,