INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE...

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SERGIPE –

CAMPUS ARACAJU

COORDENADORIA DO CURSO TÉCNICO EM INFORMÁTICA

CURSO DE PROGRAMAÇÃO E SUPORTE EM SISTEMAS COMPUTACIONAIS

Antônio Vinícius Menezes Medeiros

Estael David de Menezes Neto

ARGOS – SISTEMA DE CONTROLE DE MONITORIA

Aracaju

2010




Trabalho de Conclusão de Curso apresentado à Coordenadoria de Informática do Instituto Federal de Educação, Ciência e Tecnologia de Sergipe, como parte das exigências do curso técnico “Programação e Suporte em Sistemas Computacionais”, para a obtenção do título de Técnico de Nível Médio.

Orientador: Professor MSc. Marcus Aurelius de Oliveira Vasconcelos

Aracaju

2010




Trabalho de Conclusão de Curso apresentado à Coordenadoria de Informática do Instituto Federal de Educação, Ciência e Tecnologia de Sergipe, como parte das exigências do curso técnico “Programação e Suporte em Sistemas Computacionais”, para a obtenção do título de Técnico de Nível Médio.

Aprovado pela banca examinadora em ____ de ________________ de _______.

BANCA EXAMINADORA:

___________________________________________

Professor MSc. Marcus Aurelius de Oliveira Vasconcelos – IFS/SE

(Orientador)

___________________________________________

Professor MSc. Marcelo Machado Cunha – IFS/SE

___________________________________________

Professora Esp. Jislane Silva Santos de Menezes – IFS/SE

Dedicamos este trabalho às pessoas que mais amamos nesta vida, nossos pais, nossas mães, nossa família, pois sempre nos apoiaram incondicionalmente.

AGRADECIMENTOS

Agradecemos em primeiro lugar a Deus, que iluminou o nosso caminho durante

essa caminhada;

Agradecemos também aos nossos pais, pessoas muito especiais em nossas vidas,

que em todos os momentos nos deram apoio, nos incentivaram, nos encorajaram e

que de coração estiveram do nosso lado nos momentos em que mais precisamos;

Em especial queremos agradecer aos nossos colegas e amigos, Carlos David,

Hector Hiroshi, Givanildo, Kelvin Mendes e Nilton Bruno pela palavra amiga e pela

força nos momentos difíceis desta jornada;

Agradecemos a todos aqueles que, direta ou indiretamente, contribuíram para a

realização deste trabalho;

E por fim gostaríamos de agradecer ao nosso orientador Marcus Aurelius, que nos

ajudou e soube nos conduzir durante o desenvolvimento do trabalho.

“Nos tesouros da Sabedoria estão as máximas da ciência”Ecl. 1,25

RESUMO

Este trabalho é o resultado do desenvolvimento de uma aplicação do tipo cliente-

servidor para gerenciar a utilização dos computadores de uma monitoria via rede,

utilizando o ambiente de desenvolvimento integrado Borland Delphi e o banco de

dados MySQL. Trata-se de um projeto para atender às necessidades da biblioteca

do Instituto Federal de Educação, Ciência e Tecnologia de Sergipe (IFS) – Campus

Aracaju, que apesar de contar com computadores para catalogar os livros e

disponibilizar acesso a Internet aos alunos ainda não informatizou por completo este

setor. Diferentemente das demais aplicações cliente-servidor, essa aplicação é

formada por apenas um executável que pode atuar tanto como cliente quanto como

servidor. O trabalho atingiu seus objetivos uma vez que ele permitiu aos seus

desenvolvedores demonstrar os conhecimentos adquiridos durante o curso e ficará

disponibilizado na Internet para a posteridade para os que desejarem consultá-lo e

utilizá-lo como referência ou fonte de aprendizado.

Palavras-chave: Sistema de gerenciamento de monitoria, Aplicação cliente-servidor,

Banco de dados.

ABSTRACT

This work is the result of the development of a client-server application to manage

the use of computers of a LAN via network using the integrated development

environment Borland Delphi and the MySQL database. This project meets the needs

of the IFS – Campus Aracaju's library. Despite having computers to catalog its books

and provide Internet access to students, it isn't fully computerized sector yet. Unlike

other client-server applications, this application consists of only one executable that

can act as both client and server. This work achieved its goals since it allowed its

developers to show knowledge they acquired through the course and it will be

available on the Internet for posterity for those who wish to view it and use it as

reference or source for learning.

Keywords: LAN management system, Client-server application, Database.

LISTA DE FIGURAS

Figura 1 – Diagrama de Entidade-Relacionamento 27Figura 2 – Diagrama de casos de uso 36Figura 3 – Aplicação servidor – Tela de carregamento 70Figura 4 – Aplicação servidor – Tela principal 71Figura 5 – Aplicação servidor – Menus e barra de ferramentas 71Figura 6 – Aplicação servidor – Lista de alunos 72Figura 7 – Aplicação servidor – Cadastro de aluno 73Figura 8 – Aplicação servidor – Histórico do aluno – Aba "Seções" 73Figura 9 – Aplicação servidor – Histórico do aluno – Aba "Observações" 74Figura 10 – Aplicação servidor – Registro de observação 74Figura 11 – Aplicação servidor – Reserva de seção 75Figura 12 – Aplicação servidor – Fila de espera 75Figura 13 – Aplicação cliente – Tela de login 76Figura 14 – Aplicação cliente – Tela de login – Sair 77Figura 15 – Aplicação cliente – Tela de login – Encerrar aplicação 77Figura 16 – Aplicação cliente – Tela principal – Aba "Aluno" 78Figura 17 – Aplicação cliente – Tela principal – Aba "Seção" 78Figura 18 – Aplicação cliente – Aviso de tempo restante 79Figura 19 – Aplicação servidor – Envio de mensagem 79Figura 20 – Aplicação cliente – Aviso de mensagem recebida 80Figura 21 – Aplicação servidor – Expulsão de aluno 80Figura 22 – Aplicação servidor – Estender tempo 81Figura 23 – Aplicação servidor – Importação da base de dados 82Figura 24 – Aplicação servidor – Exportação da base de dados 82Figura 25 – Aplicação servidor – Lista de máquinas 83Figura 26 – Aplicação servidor – Histórico da máquina 84Figura 27 – Aplicação servidor – Ícone da área de notificação 84Figura 28 – Comunicação entre o sistema e o banco de dados através do

MDAC

96

Figura 29 – Hermes, Argos Panoptes e Io 100

LISTA DE TABELAS

Tabela 1 – Atributos da entidade ALUNO 56Tabela 2 – Atributos da entidade MAQUINA 57Tabela 3 – Atributos da entidade OBSERVACAO 58Tabela 4 – Atributos da entidade SECAO 59Tabela 5 – Atributos envolvidos no relacionamento POSSUI 60Tabela 6 – Atributos envolvidos no relacionamento RESERVA 61Tabela 7 – Atributos envolvidos no relacionamento RECEBE 61

SUMÁRIO

1 INTRODUÇÃO 13

2 AMBIENTE ENCONTRADO 14

3 AMBIENTE IDEAL 16

4 AMBIENTE PROPOSTO 184.1 Questões de segurança, desempenho e tolerância a falhas 22

5 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER) 275.1 Dicionarização do DER 275.1.1 Entidade ALUNO 275.1.2 Entidade MAQUINA 285.1.3 Entidade OBSERVACAO 295.1.4 Entidade SECAO 29

6 ANÁLISE DE REQUISITOS 306.1 Requisitos funcionais 306.2 Requisitos não-funcionais 326.2.1 Requisitos de produto 326.2.2 Requisitos de processo 346.2.3 Requisitos externos 35

7 DIAGRAMA DE CASOS DE USO 367.1 Documentação estendida dos casos de uso 377.1.1 Cadastrar máquina 377.1.2 Cadastrar aluno 387.1.3 Registrar observação 397.1.4 Reservar seção 407.1.5 Visualizar fila de espera 427.1.6 Iniciar seção 437.1.7 Monitorar tempo 44

7.1.8 Bloquear seção 457.1.9 Encerrar seção 467.1.10 Estender tempo 477.1.11 Expulsar aluno 497.1.12 Enviar mensagem 507.1.13 Retomar seção 517.1.14 Verificar comunicação entre as máquinas 517.1.15 Encerrar aplicação 527.1.16 Exportar base de dados 537.1.17 Importar base de dados 54

8 PROJETO DE ARQUIVOS 568.1 Entidade ALUNO 568.2 Entidade MAQUINA 578.3 Entidade OBSERVACAO 588.4 Entidade SECAO 588.5 Relacionamento POSSUI 608.6 Relacionamento RESERVA 608.7 Relacionamento RECEBE 61

9 SCRIPT DE CRIAÇÃO DA BASE DE DADOS 62

10 IMPLEMENTAÇÃO 6410.1 Ferramentas e técnicas utilizadas 6410.2 Possibilidade de integração com outros projetos 68

11 PROJETO DE INTERFACES 70

12 PROJETO DE RELATÓRIOS 85

13 CONCLUSÃO 86

REFERÊNCIAS 87

APÊNDICE A – CONHECIMENTOS COMPLEMENTARES 89Componentes Indy 89

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SERGIPE – CAMPUS ARACAJUCOORDENADORIA DO CURSO TÉCNICO EM INFORMÁTICA

Microsoft Data Access Components (MDAC) 92Funções da API do Windows 97

ANEXO A – ESCOLHA DO NOME ARGOS 100

ANEXO B – LICENÇA PÚBLICA GERAL DO GNU (GPL) 102Introdução 101Termos e condições para cópia, distribuição e modificação 103Exclusão de garantia 109

Argos – Sistema de controle de monitoria – 12


1 INTRODUÇÃO

Este trabalho objetiva demonstrar os conhecimentos de programação e

suporte em sistemas computacionais adquiridos durante o curso através do projeto,

desenvolvimento e implementação de um sistema do tipo cliente-servidor para

gerenciar o uso dos computadores da monitoria da biblioteca do Instituto Federal de

Educação, Ciência e Tecnologia de Sergipe (IFS) através da infraestrutura de rede

presente na mesma. Durante o desenvolvimento da aplicação foram utilizados o

ambiente de desenvolvimento integrado Borland Delphi 7 e o banco de dados

MySQL, ferramentas apresentadas pelos professores no decorrer do curso.



2 AMBIENTE ENCONTRADO

A biblioteca Dr. Augusto César Leite do Campus Aracaju do IFS possui a

serviço dos alunos uma monitoria com 10 computadores para a utilização de

programas e acesso a sites da Internet.

O controle do uso desses computadores é feito pelos funcionários da

biblioteca. Ao solicitar a utilização de um computador, o aluno deixa a sua carteirinha

da biblioteca com o funcionário responsável pela monitoria. Este anota em um

pedaço de papel o horário em que o aluno entrou na monitoria e anexa este papel à

carteirinha do aluno. As carteirinhas dos alunos são mantidas pelo funcionário no

balcão da biblioteca para que ele possa saber quem está utilizando a monitoria.

Os alunos dispõem de uma única conta de usuário do Windows, cujo nome de

usuário é “aluno” e cuja senha é também “aluno”, para acessar os computadores da

monitoria. Não há uma configuração individual para cada aluno, de modo que os

programas e arquivos do computador ficam acessíveis a todos os alunos, mesmo

àqueles que não necessitam utilizá-los. Na Área de Trabalho e na pasta Meus

Documentos podem ser encontrados arquivos e pastas de todos os alunos.

Os computadores da monitoria devem ser utilizados para fins de estudo

exclusivamente. Não é permitida na monitoria a utilização dos computadores para

visita de sites pornográficos, sites de e-mail, redes de relacionamentos, assim como

não é permitida a utilização de sites e programas de bate-papo e de jogos.

A instalação de programas e jogos nos computadores e o acesso aos sites

não é controlado pela monitoria nem pela biblioteca, mas pelos técnicos da

Coordenadoria de Tecnologia da Informação (CTI), responsáveis pela manutenção

dos computadores do Instituto. Há uma lista de sites já conhecidos que são

bloqueados pelo servidor que fornece às máquinas da monitoria o acesso à Internet

e a configuração feita em cada máquina não permite a instalação de programas

pelos alunos. Mesmo assim, há alunos que conseguem burlar o controle da CTI.

Como não há uma conta de usuário para cada aluno, não é possível

acompanhar a atividade individual de cada aluno e é mais difícil identificar possíveis

usuários abusivos da monitoria. Para garantir o cumprimento das normas da

monitoria, em intervalos de tempo regulares, o funcionário da biblioteca responsável



pelo controle do acesso aos computadores entra na monitoria e verifica as

atividades dos alunos. O aluno que não observar essas restrições é primeiramente

advertido e, em insistência da infração, é expulso da monitoria.

A partir do momento em que entra na monitoria, o aluno tem direito a utilizar o

computador que lhe foi cedido por meia hora (30 minutos). É permitido ao aluno

durante este tempo sair de uma máquina para utilizar outra, desde que a mudança

seja informada ao funcionário da biblioteca. Este, no entanto, nem sempre é

informado quando um aluno muda de computador, o que torna ainda mais difícil o

controle do acesso aos computadores da monitoria.

Uma vez encerrado o tempo que foi concedido para o aluno se utilizar da

monitoria, este deve encerrar as atividades que estava executando no computador e

deixá-la. Esse tempo pode ser ampliado caso não haja alunos necessitando utilizar

os computadores. Caso isto aconteça, o aluno deverá deixar o computador assim

que surgir outra pessoa necessitando utilizar os computadores, encerrando suas

atividades na máquina para que a outra pessoa possa utilizar o computador. Como

já foi dito, o aluno também deve deixar a monitoria se for solicitada a sua saída pelo

funcionário responsável por infração às normas da monitoria.



3 AMBIENTE IDEAL

A solução proposta pela equipe de desenvolvimento para tornar mais prático e

eficiente o gerenciamento dos computadores da monitoria foi o desenvolvimento de

uma aplicação do tipo cliente-servidor que, utilizando a infraestrutura de rede do

Instituto, permitisse ao funcionário responsável controlar o uso desses

computadores pelo computador que se encontra na recepção da biblioteca.

Neste computador seria instalada a aplicação servidor, responsável pela

gerência dos computadores da monitoria. Em cada computador da monitoria seria

instalada a aplicação cliente, que manteria constante comunicação com a aplicação

servidor, enviando a esta informações sobre a utilização da máquina – como hora de

entrada e saída do aluno, programas abertos e sites utilizados – e liberando ou

bloqueando seu uso conforme recebesse instruções dela para fazê-lo.

Um domínio de rede seria implementado com a função de armazenar as

contas de usuário e configurações personalizadas do Windows para cada aluno do

Instituto. As máquinas da monitoria seriam configuradas para utilizar as contas de

usuário configuradas nesse domínio e possuiriam contas locais apenas para os

administradores, que poderiam utilizar essas contas nas máquinas para resolver

eventuais problemas. Os alunos seriam então obrigados a utilizar suas próprias

contas de usuário configuradas no domínio. O sistema acompanharia o login e logoff

dessas contas nos computadores da monitoria, utilizando-as para controlar o acesso

dos alunos a esses computadores.

Um computador pertencente ao domínio da rede seria utilizado para

armazenar a base de dados do sistema, que conteria, além das informações

pessoais, utilizadas para identificação, o registro das atividades executadas por cada

aluno – mais especificamente, sites acessados e programas iniciados. A base de

dados do sistema também armazenaria as normas de uso dos computadores da

monitoria, ou seja, a lista de programas e sites que não poderiam ser utilizados

pelos alunos.

Em cada máquina da monitoria, a aplicação cliente acompanharia cada

atividade desempenhada pelo aluno que a estivesse utilizando e acessaria as

normas de uso para verificar se aquela atividade era permitida na monitoria. Caso



constasse nas normas de uso que ela deveria ser bloqueada, a aplicação cliente

automaticamente encerraria essa atividade e avisaria ao funcionário que o aluno

tentou executá-la.

Caso verificasse que um mesmo aluno estivesse infringindo as regras da

monitoria com frequência, o funcionário responsável poderia, a qualquer momento,

através de seu computador, acionar um comando que bloquearia o computador da

monitoria que estivesse sendo utilizado por aquele aluno, expulsando-o. Sua conta

de usuário seria bloqueada no domínio de rede, impossibilitando-o de acessar

qualquer uma das outras máquinas até que obtivesse nova permissão para uso pelo

funcionário.

O sistema também facilitaria a comunicação entre o funcionário e os alunos

quanto à questão da mudança de máquina: ele permitiria ao aluno sair de um

computador e entrar em outro qualquer que estivesse disponível para uso, utilizando

neste o tempo que lhe restava da sua concessão de acesso à monitoria. Toda a

transição seria feita pelas próprias aplicações clientes instaladas nas máquinas e o

funcionário seria apenas avisado pela aplicação servidor.

Além das funções de controle de entrada e saída de usuários e de

monitoramento das atividades destes, os funcionários da biblioteca solicitaram à

equipe de desenvolvimento que o sistema fornecesse informações estatísticas a

respeito da utilização dos computadores da monitoria, como, por exemplo, quais são

os programas e sites mais utilizados. Isso poderia ajudá-los na identificação dos

interesses dos alunos, possibilitando a melhoria do acervo da biblioteca, assim como

na identificação de práticas abusivas que estivessem sendo praticadas com

frequência na monitoria.



4 AMBIENTE PROPOSTO

Diante da constatada impossibilidade de se implantar um domínio de rede na

instituição, que tornaria o sistema mais eficiente e funcional, a equipe de

desenvolvimento propôs a criação de uma aplicação mais simples, que utilizará a

estrutura de rede e a configuração de contas de usuário do Windows já existente na

biblioteca.

Os computadores da monitoria continuarão a utilizar apenas uma conta de

usuário do Windows para todos os alunos, cujo nome de usuário é “aluno” e cuja

senha é também “aluno”, como visto anteriormente, e o sistema possuirá seu próprio

cadastro de alunos, que será armazenado na base de dados. A aplicação servidor,

portanto, será a responsável pelo controle da entrada e saída de alunos nos

computadores da monitoria, e não mais o domínio de rede.

Nas máquinas da monitoria, a aplicação cliente será iniciada assim que for

feito login na conta de usuário “aluno” e mostrará sua própria tela de login, que

impedirá o aluno de acessar o sistema operacional. Os alunos deverão utilizar esta

tela para entrar no sistema, informando sua matrícula. Já na máquina da recepção, a

aplicação servidor será iniciada na máquina da recepção assim que o funcionário

fizer login na conta de usuário “administrador”. Mais informações sobre esse assunto

serão fornecidas na seção 4.1.

O monitoramento e registro das atividades dos alunos – sites acessados e

programas iniciados – também não pôde ser implementado, dada a insuficiência de

documentação sobre recursos da linguagem de programação adotada que

permitissem desenvolver essa funcionalidade. Como consequência, a geração de

estatísticas com base no registro das atividades dos alunos também não pôde ser

implementada.

Informados disso, os funcionários entrevistados disseram que sua

necessidade primária era o controle da entrada e saída de alunos da monitoria e que

a ausência das funcionalidades que não poderiam ser implementadas não afetava

seu interesse pelo desenvolvimento do sistema. Assim sendo, a equipe de

desenvolvimento deu continuação ao projeto.



A base de dados armazenará informações pessoais de cada aluno para

facilitar sua identificação. Essas informações – matrícula, nome completo, nome do

curso, turma, endereço, bairro, CEP, cidade, estado, telefone residencial, celular,

identidade, CPF e e-mail – deverão ser informadas pelo aluno na primeira vez em

que ele solicitar a utilização de uma máquina da monitoria para que o funcionário

cadastre-o na base de dados.

Os funcionários da biblioteca também poderão fazer observações a respeito

de cada aluno – poderão registrar, por exemplo, pendências do aluno com a

biblioteca, momento em que o mesmo trancar a matrícula ou deixar de estudar no

Instituto –, que serão armazenadas na base de dados, de forma que o funcionário

responsável pela monitoria possa visualizar essas anotações antes de liberar a

máquina para uso, permitindo ou negando o acesso de determinados alunos às

máquinas.

Diante disso, o que será armazenado na base de dados se restringirá à

identificação e às observações relativas a cada aluno e o histórico das seções

iniciadas pelos mesmos, com informações simples, como a data, a hora e em que

máquina cada seção foi iniciada.

No computador da recepção da biblioteca será instalada a aplicação servidor,

que será manuseada por um funcionário da biblioteca, responsável pela gerência

dos computadores da monitoria. Em cada computador da monitoria será instalada a

aplicação cliente, que manterá constante comunicação com a aplicação servidor e

liberará ou bloqueará o uso do computador conforme receba instruções da mesma

para fazê-lo. Tanto a aplicação servidor quanto as aplicações cliente acessarão a

base de dados, que poderá ser instalada no próprio computador que receberá a

aplicação servidor ou em outro computador, contanto que este seja acessível pelas

demais máquinas da rede.

O controle do uso dos computadores da monitoria continuará sendo feito

pelos funcionários da biblioteca. Ao solicitar a utilização de um computador, o aluno

informará ao funcionário responsável a sua matrícula e a máquina que deseja

utilizar, caso possua alguma preferência. Este passará essas informações à

aplicação servidor, juntamente com o tempo ao qual o aluno terá direito a usar a

máquina (que será, por padrão, 30 minutos, mas poderá ser qualquer outra



quantidade de tempo informada pelo funcionário ou mesmo tempo indeterminado,

deixando neste caso o aluno livre para usar o computador o tempo que desejar). A

solicitação do aluno será registrada.

Se houver uma máquina disponível para uso (e, caso o aluno tenha informado

uma máquina de sua preferência, seja essa máquina), o aluno poderá se dirigir a

essa máquina e informar sua matrícula na tela inicial do sistema. Após verificar na

base de dados que o aluno solicitou a utilização daquela máquina, a aplicação

cliente nela instalada armazenará na base de dados o horário em que o aluno

começou a utilizar a máquina e dará início à contagem do tempo restante para o fim

da seção. A aplicação servidor será avisada pela aplicação cliente do início da seção

e automaticamente informará ao funcionário sua ocorrência.

Se não houver uma máquina ou se a máquina solicitada pelo aluno não

estiver disponível para uso, o mesmo deverá permanecer nas dependências da

biblioteca para que seja avisado quando for possível sua entrada na monitoria.

Quando isso acontecer (quando uma máquina, ou quando a máquina solicitada,

caso tenha sido especificada, estiver disponível), a aplicação servidor mostrará ao

funcionário da biblioteca um aviso, informando que aquele aluno tem preferência

pela utilização da máquina liberada. O funcionário então prosseguirá à liberação da

máquina para uso do aluno, como descrito anteriormente.

Os alunos que estiverem utilizando os computadores da monitoria poderão

visualizar em suas telas quanto tempo lhes resta para utilizar o computador e serão

avisados automaticamente pelo sistema quando estiver se aproximando o fim deste

tempo. O sistema também facilitará a comunicação entre o funcionário que está

administrando a monitoria e os alunos permitindo que aquele envie mensagens a

estes, dispensando assim seu deslocamento da biblioteca para a monitoria apenas

para dar avisos.

Caso verifique que um mesmo aluno está infringindo as regras da monitoria

com frequência e decida que este aluno deve ser expulso, o funcionário poderá, a

qualquer momento, através de seu computador, acionar um comando que encerrará

a seção deste aluno. Essa expulsão será computada no registro de atividades

daquele aluno e sua matrícula será bloqueada na base de dados, impossibilitando-o

então de acessar qualquer uma das outras máquinas até que obtenha nova



permissão para uso do funcionário responsável pela administração da monitoria.

Para evitar abusos, as aplicações cliente encerrarão automaticamente as

seções em suas máquinas caso verifiquem que não apresentam atividade dentro de

certo tempo, garantindo assim que não haja máquinas da monitoria reservadas para

alunos que não as estejam utilizando. Da mesma forma, elas não aceitarão que um

aluno inicie uma seção caso verifiquem que certo tempo já se passou desde que o

funcionário autorizou sua entrada. Esse tempo será, por padrão, 5 minutos, mas

poderá ser alterado na configuração do sistema.

Encerrado o tempo que foi concedido para o aluno utilizar o computador da

monitoria, sua seção será inicialmente bloqueada pela aplicação cliente, as

atividades que estavam em execução não serão encerradas imediatamente. Caso

não haja alunos esperando um computador ser liberado, a seção permanecerá

bloqueada, permitindo ao aluno retomá-la caso o funcionário conceda-lhe mais

tempo para continuar utilizando a máquina em que estava. Caso contrário, ela será

automaticamente encerrada.

Se não houver alunos esperando um computador, o aluno pode solicitar ao

funcionário mais tempo para continuar utilizando a máquina em que estava. Este

informará à aplicação servidor a quantidade de tempo que deve ser acrescida à

concessão de uso original (que será, por sugestão do programa, 30 minutos, mas

poderá ser qualquer outra quantidade de tempo informada pelo funcionário ou

mesmo tempo indeterminado, deixando neste caso o aluno livre para usar o

computador o tempo que desejar).

A aplicação servidor então registrará o acréscimo na base de dados e o aluno

poderá se dirigir à máquina que estava utilizando, digitar sua matrícula na tela de

login e retomar a seção, utilizando a partir de então o acréscimo concedido pelo

funcionário. O sistema também permitirá ao funcionário encerrar a qualquer

momento esta nova concessão de uso, caso surja outro aluno necessitando utilizar

os computadores da monitoria.

Caso o aluno não solicite mais tempo ou o faça mas não retome a seção

bloqueada, ela poderá ser finalizada pelo funcionário acionando um comando na

aplicação servidor ou será automaticamente finalizada pela aplicação cliente dentro

de algum tempo, segundo o princípio das seções que não apresentam atividade,



explicado anteriormente.

Uma vez que a seção seja encerrada, por qualquer motivo, a aplicação cliente

reiniciará o computador, finalizando assim todas as atividades que estavam em

execução. O aluno que estava utilizando aquela máquina só poderá voltar a utilizá-la

ou utilizar outro computador solicitando ao funcionário da biblioteca a utilização de

um computador da monitoria, passando por todo o processo descrito novamente (ver

o 10º parágrafo desse mesmo capítulo).

Vale lembrar que se o motivo do encerramento da seção for uma expulsão, a

matrícula do aluno estará bloqueada para acesso e ele só poderá utilizar uma

máquina da monitoria novamente se o funcionário responsável registrar uma

observação que libere sua matrícula (ver o 14º parágrafo desse mesmo capítulo).

4.1 Questões de segurança, desempenho e tolerância a falhas

Um dos pedidos feitos à equipe de desenvolvimento pelos funcionários foi que

o sistema não questionasse por senhas, o que evitaria problemas que poderiam

ocorrer caso algum funcionário esquecesse sua senha, e manteria a organização já

presente na biblioteca (as únicas senhas lá estabelecidas são as das contas de

usuário do Windows).

Para atender a esse pedido, a equipe de desenvolvimento decidiu

implementar apenas um executável, que seria instalado em todos os computadores,

no servidor e nos clientes, e não dois executáveis diferentes, um para o cliente e

outro para o servidor, como normalmente acontece com as aplicações do tipo

cliente-servidor.

A decisão se a aplicação se comportará como cliente ou servidor será tomada

no momento em que a mesma for iniciada: ela verificará se a conta de usuário do

Windows ativa no momento possui privilégios de administrador (a que somente os

funcionários têm acesso); se isso acontecer, será iniciada como servidor, senão

(caso da conta de usuário "aluno"), será iniciada como cliente.

Isso não apenas atende ao pedido dos funcionários, aumentando a

praticidade do sistema, como também torna sua implementação mais simples e



aumenta a flexibilidade do mesmo em caso de queda no servidor, como será

explicado mais adiante.

Para evitar que algum aluno encerre a aplicação cliente no intervalo de tempo

em que é feito login na conta de usuário "aluno" e a aplicação é iniciada (isso pode

ser feito, por exemplo, acionando o Gerenciador de Tarefas), a equipe de

desenvolvimento recomenda que as máquinas da monitoria sejam configuradas para

fazer login automático na conta de usuário “aluno” assim que o computador for

ligado. Isso traz não apenas o benefício da segurança, como também dispensa ao

aluno realizar login primeiro no Windows para só depois fazer login no sistema,

tornando mais fácil seu acesso às máquinas da monitoria.

Uma vez exibida a tela de login da aplicação cliente, que ocupará toda a tela

e não poderá ser fechada ou minimizada, impedindo assim o acesso do aluno ao

sistema operacional, ela bloqueará quaisquer recursos que possam ser utilizados

pelo aluno para burlá-la ou encerrá-la, como o Gerenciador de Tarefas, a alternância

entre janelas (realizada pela combinação de teclas Alt + Tab) e o acesso ao menu

Iniciar ou à Área de Trabalho. Todos esses bloqueios, com exceção do bloqueio ao

Gerenciador de Tarefas, serão desfeitos assim que o aluno iniciar sua seção,

permitindo que o mesmo tenha acesso ao sistema operacional condizente com os

privilégios definidos para sua conta de usuário pelo administrador.

Será adotada para o banco de dados uma política de usuários que dificultará

o acesso à base de dados do sistema: as aplicações cliente e a aplicação servidor

acessarão a base de dados através de um usuário restrito que será criado apenas

para essa finalidade; o usuário administrador do banco de dados não será, portanto,

utilizado pelo sistema. Sua senha será reservada ao funcionário responsável pela

manutenção para realizar possíveis correções na base de dados, que serão feitas

manualmente utilizando um Sistema de Gerenciamento de Banco de Dados (SGBD).

A troca de informações entre as aplicações servidor e cliente será feita

preferencialmente através do banco de dados para evitar redundância e minimizar o

tráfego de informações pela rede. Na ocorrência de alteração em algum registro,

uma aplicação apenas avisará à outra, para que esta verifique na base de dados a

alteração e execute as ações relativas à mesma.



A única exceção a essa regra serão as mensagens enviadas pelo funcionário

aos alunos, que serão transmitidas pela rede de um computador para outro e não

serão armazenadas na base de dados, pois os funcionários da biblioteca

entrevistados não encontraram utilidade no registro dessas mensagens.

As aplicações cliente instaladas nas máquinas da monitoria estarão

verificando constantemente sua comunicação com a aplicação servidor e o banco de

dados instalados no computador da recepção. Se houver alguma falha nessa

comunicação (isso pode acontecer devido a, por exemplo, uma falha no

fornecimento de energia, no switch, em algum cabo de rede, no sistema operacional

da máquina servidor ou da máquina cliente, um travamento da aplicação servidor ou

da aplicação cliente instalada na máquina, etc.), o acompanhamento da entrada e

saída de usuários da monitoria será prejudicado.

Tanto a equipe de desenvolvimento quanto os próprios funcionários

entrevistados não acharam interessante manter a aplicação cliente em

funcionamento caso houvesse alguma interrupção na comunicação entre esta e a

aplicação servidor ou a base de dados, porque a partir do momento em que essa

comunicação fosse interrompida não haveria como o funcionário acompanhar pela

aplicação servidor a entrada e saída de alunos na monitoria, o que contraria

completamente os objetivos do sistema.

Diante disso, decidiu-se que, para garantir a integridade do sistema, a

aplicação cliente só desempenhará suas atividades se for possível sua comunicação

com a aplicação servidor e o banco de dados e bloqueará a seção na máquina em

que está sendo executada caso essa comunicação seja interrompida. Essa seção

não será imediatamente finalizada, permitindo ao aluno voltar a utilizar o computador

caso a comunicação entre este e o servidor ou o banco de dados seja restabelecida.

Se a falha ocorrer na comunicação entre as aplicações cliente e servidor, é

possível também encerrar a aplicação cliente em qualquer uma das máquinas da

monitoria e iniciar nessa mesma máquina uma aplicação servidor, uma vez que o

único critério utilizado pela aplicação para decidir se deve ser iniciada como servidor

ou cliente é o nível de privilégio da conta de usuário do Windows na qual está sendo

iniciada, como explicado anteriormente. Para isso, o funcionário deve fazer logoff da

conta de usuário "aluno" nessa máquina e fazer login na sua conta administrativa,



iniciando assim a aplicação servidor nessa conta.

Durante sua inicialização, a aplicação servidor verificará se já existe uma

aplicação servidor em execução em alguma máquina na rede, pois não pode haver

na rede duas aplicações servidoras em execução ao mesmo tempo. Se houver, ela

questionará ao funcionário se deve substituir a que está em execução no momento.

Caso o funcionário opte por isso, ela iniciará normalmente, e a outra, percebendo

que uma nova aplicação servidor foi iniciada, se encerrará automaticamente. Caso

contrário, ela abortará sua inicialização e a aplicação servidor que já estava sendo

executada permanecerá em execução normalmente.

Quando os problemas de comunicação entre as máquinas forem resolvidos, o

aluno que estava na monitoria deverá se dirigir à máquina que estava utilizando e

digitar sua matrícula. Verificando que sua seção estava bloqueada, a aplicação

cliente liberará a máquina para seu uso e retomará a contagem do tempo restante

para o fim de sua seção. Haverá, no entanto, um limite de tempo para que a seção

seja retomada. Se transcorrido esse tempo a seção não for retomada, ela será

automaticamente encerrada como se fosse uma seção que não apresenta atividade.

Caso não seja possível retomar imediatamente a comunicação entre as

máquinas, para que o aluno não seja prejudicado em suas atividades, será permitido

ao funcionário da biblioteca encerrar a aplicação cliente para que o aluno termine o

que estava fazendo, guarde seus arquivos e saia. Para isso, o funcionário deverá

acionar o devido comando na tela de login da aplicação cliente e fornecer-lhe o

nome de usuário e senha de uma conta administrativa do Windows. Após verificar

que a conta possui privilégios de administrador, a aplicação cliente se encerrará sem

fazer logoff da conta de usuário “aluno”, permitindo que o aluno utilize livremente o

computador.

É importante observar que, caso encerre a aplicação cliente em execução na

conta de usuário “aluno”, o funcionário deverá se responsabilizar por acompanhar a

utilização do computador pelo aluno.

Haverá também comandos na tela de login da aplicação cliente que permitirão

aos funcionários fazer logoff da conta “aluno”, caso precisem utilizar suas contas

nesses computadores, ou ainda desligar ou reiniciar o computador, sem precisar

alternar para suas contas de usuário para depois fazê-los.



Para realizar qualquer uma dessas três operações não será necessária

nenhuma validação, pois o próprio aluno poderia executá-los se a tela de login da

aplicação cliente não estivesse sendo exibida e ele tivesse acesso ao sistema

operacional. Uma vez acionado um desses comandos, a própria aplicação se

encarregará de executá-los, sem contudo fechar sua tela de login ou conferir acesso

ao sistema operacional antes que sejam concluídos, evitando assim que alunos

fraudulentos acionem esses comandos numa tentativa de burlar sua segurança.



5 DIAGRAMA ENTIDADE-RELACIONAMENTO (DER)

A partir do ambiente proposto (ver capítulo 4), foi elaborado um Diagrama de

Entidade-Relacionamento (DER), mostrado na Figura 1. Para isso foi utilizada a

notação de Abrial (1974), abordada em Elmasri & Navathe (2006).

Figura 1 – Diagrama de Entidade-Relacionamento

5.1 Dicionarização do DER

As explicações a seguir sobre as entidades e seus atributos foram elaboradas

com base na notação estudada em Elmasri & Navathe (2006).

5.1.1 Entidade ALUNO

Definição: aluno matriculado na escola.


MAQUINA

POSSUI

(1,1)

(0,n)

RESERVA SECAO

OBSERVACAO

ALUNO

RECEBE

(0,n)

(0,n)

(1,1)

(1,1)


Atributos:

• Matrícula (PK): matrícula do aluno

• Nome: nome completo do aluno

• Curso: nome do curso do aluno

• Turma: turma do aluno

• Endereço: endereço do aluno, com logradouro, número e complemento

• Bairro: bairro onde o aluno mora

• CEP: CEP do logradouro onde o aluno mora

• Cidade: cidade onde o aluno mora

• Estado: estado onde o aluno mora

• Telefone: telefone residencial do aluno com área

• Celular: celular do aluno com área

• RG: número do documento de identidade do aluno com órgão expedidor

• CPF: número do CPF do aluno

• E-mail: e-mail do aluno

• Status: situação do aluno com relação à escola e a biblioteca

5.1.2 Entidade MAQUINA

Definição: computador da monitoria.

Atributos:

• Código (PK): código da máquina

• Nome: nome de rede (hostname) da máquina

• Processador: breve descrição do processador da máquina, com frabricante,

nome, modelo e clock interno

• Memória: quantidade de memória RAM da máquina

• Sistema: nome e versão do sistema operacional instalado na máquina



5.1.3 Entidade OBSERVACAO

Definição: observação feita por um funcionário da biblioteca a respeito de

determinado aluno.

Atributos:

• Código (PK): código da observação

• Matrícula do aluno (FK): matrícula do aluno que recebeu a observação

• Data: data em que a observação foi feita

• Hora: hora em que a observação foi feita

• Texto: conteúdo da observação

5.1.4 Entidade SECAO

Definição: concessão de tempo que é feita pelo funcionário da biblioteca a um aluno

para que este possa utilizar um computador da monitoria.

Atributos:

• Código (PK): código da seção

• Matrícula do aluno (FK): matrícula do aluno que iniciou a seção

• Código da máquina (FK): código da máquina na qual a seção foi iniciada

• Data: data em que a seção foi iniciada

• Hora: hora em que a seção foi iniciada

• Tempo concedido: tempo que foi concedido ao aluno para utilizar a máquina

• Tempo usado: tempo que o aluno utilizou a máquina

• Status: situação da seção



6 ANÁLISE DE REQUISITOS

Como visto em Sommerville (2007), os requerimentos de um sistema

consistem nas descrições dos serviços oferecidos pelo sistema e suas restrições

operacionais. Podem ser classificados em requisitos funcionais ou requisitos não-

funcionais.

6.1 Requisitos funcionais

Os requisitos funcionais de um sistema descrevem o que ele deve fazer.

Durante o levantamento dos requisitos do Sistema de controle de monitoria,

os requisitos funcionais identificados foram:

a) Cadastrar máquina: o sistema cadastrará na base de dados a máquina

na qual estiver sendo executado. Tal cadastro ocorrerá automaticamente

na primeira vez em que ele for executado nessa máquina;

b) Cadastrar aluno: o sistema possibilitará ao funcionário todas as

operações referentes a cadastro de alunos: adição, alteração, busca e

exclusão;

c) Registrar observação: o funcionário poderá registrar observações a

respeito de determinado aluno na base de dados. Uma observação

poderá permitir ou proibir o acesso de um aluno aos computadores da

monitoria;

d) Reservar seção: quando um aluno solicitar a utilização de um

computador, o sistema registrará sua solicitação na base de dados. Se

houver uma máquina disponível, o aluno poderá se dirigir à mesma e

iniciar a seção. Se não, a aplicação avisará ao funcionário quando uma

máquina for liberada para que o aluno possa utilizá-la;

e) Visualizar fila de espera: o sistema deverá possibilitar ao funcionário

visualizar a lista de alunos que solicitaram uma seção no momento em

que não havia computadores disponíveis e estão aguardando que um

computador seja liberado;



f) Iniciar seção: quando o aluno iniciar uma seção em uma máquina da

monitoria, o sistema deverá registrar a hora de início da seção, avisar ao

funcionário que uma nova seção foi iniciada e iniciar a contagem do

tempo restante para o término da seção;

g) Monitoramento de tempo: a partir do momento em que o aluno iniciar

uma seção, o sistema realizará a contagem do tempo restante para o

término da seção, avisando ao aluno quando o fim da seção estiver

próximo. O sistema também verificará quanto tempo se passou desde a

última atividade iniciada pelo aluno e encerrará a seção caso nenhuma

nova atividade tenha sido iniciada dentro de certo tempo;

h) Bloquear seção: o sistema bloqueará a seção caso o tempo concedido

ao aluno seja encerrado ou a comunicação com o servidor seja

interrompida, impedindo o acesso do aluno ao computador. As atividades

em execução não serão encerradas, permitindo que o aluno retome a

seção caso o funcionário estenda seu tempo ou a comunicação com o

servidor seja reestabelecida. O sistema deverá finalizar automaticamente

a seção bloqueada caso não seja retomada dentro de certo tempo;

i) Encerrar seção: a seção será encerrada caso apresente inatividade,

caso o funcionário ordene seu encerramento ou expulse o aluno. A

aplicação cliente então registrará o fim da seção e reiniciará o

computador, garantindo que todas as atividades em execução sejam

encerradas;

j) Estender tempo: o sistema possibilitará ao funcionário da biblioteca

estender o tempo da seção de um aluno ou mesmo liberar por tempo

indeterminado sua permanência dentro da monitoria;

k) Expulsar aluno: quando o funcionário ordenar que um aluno seja expulso

da monitoria, o sistema encerrará a seção do aluno e registrará uma

observação informando que o mesmo foi expulso, bloqueando sua

matrícula para acesso da monitoria;

l) Enviar mensagem: o sistema permitirá que o funcionário envie

mensagens a todos alunos que estiverem utilizando os computadores da

monitoria ou a um aluno em particular;



m) Retomar seção: uma vez que a seção esteja bloqueada, o aluno poderá

retomá-la e voltar a utilizar a máquina caso o funcionário lhe conceda

mais tempo ou caso a comunicação da aplicação cliente com a aplicação

servidor e a base de dados seja retomada;

n) Verificar comunicação entre as máquinas: a aplicação cliente deverá

constantemente verificar se é possível sua comunicação com a aplicação

servidor e o banco de dados, impedindo o aluno de utilizar a máquina se

esta comunicação for interrompida;

o) Encerrar aplicação: a aplicação cliente deverá possibilitar ao funcionário

seu encerramento;

p) Backup da base de dados: o sistema deverá possibilitar ao funcionário

gerar e restaurar cópias de segurança da base de dados.

6.2 Requisitos não-funcionais

Os requisitos não-funcionais de um sistema são requisitos que não estão

diretamente relacionados com suas funções específicas, mas são restrições a essas

funções.

De acordo com a classificação proposta em Sommerville (2007), os requisitos

não-funcionais identificados durante o levantamento de requisitos podem ser

divididos em requisitos de produto, requisitos de processo e requisitos externos.

6.2.1 Requisitos de produto

Os requisitos de produto especificam o comportamento do produto. São eles:

a) Requisitos de usabilidade:- Interface gráfica amigável: a interface do sistema deverá ser mais

simples e intuitiva possível. Para que isto se torne realidade, conceitos

de usabilidade serão amplamente usados pelos desenvolvedores do

projeto, tudo isso com a finalidade de que o tempo de aprendizado seja



pequeno e o sistema ofereça maior produtividade ao usuário;

- Mensagens de erro claras: a fim de auxiliar o funcionário em seu

trabalho, erros bem definidos e claros deverão ser levados em

consideração no momento do desenvolvimento;

b) Requisitos de performance:- Garantia de disponibilidade constante: como se trata de um sistema de

controle de toda a monitoria, é interessante o funcionamento do mesmo

em situações extremas,

- Tempo de resposta: o sistema deverá garantir que qualquer das

operações seja efetuada no menor tempo possível.

- Manter os computadores atualizados: os computadores nos quais o

sistema será instalado deverão ser revisados quanto à capacidade de

processamento e memória, a fim de que o sistema possa neles

apresentar máximo desempenho.

c) Requisitos de armazenamento:- Banco de dados: o sistema utilizará uma base de dados para

armazenar os dados que utilizar. É recomendável que um computador

seja utilizado apenas para abrigar a base de dados.

d) Requisitos de confiabilidade:- Uso de nobreak: é recomendável a utilização de nobreak para garantir

que o sistema não vai cair por falta de energia elétrica ou queda na

tensão da rede elétrica, impedindo assim a perda de dados.

- Utilização de uma estrutura de rede estável: a estrutura de rede que

será utilizada para proporcionar a comunicação entre as máquinas deve

ser projetada de modo a ser a mais veloz possível. Deve, além disso,

possuir mecanismos que evitem o tráfego de informações

desnecessárias e garantam a segurança na rede, como switches,

roteadores e firewalls.

- Uso de SGBD: o uso de um SGBD, além garantir a integridade dos

dados, proporciona mais velocidade nas operações de consulta,

inserção e remoção de itens na base de dados.



- Correto ajuste do relógio do sistema: a fim de que a operação entre as

máquinas seja sincronizada, os relógios dos computadores nos quais o

sistema for instalado devem estar sincronizados com um servidor de

hora da rede.

- Fornecimento de dados consistentes: toda informação armazenada

deve ser processada de forma que possa ser facilmente re-extraída da

base de dados. Também deverá haver algum mecanismo de

cancelamento de operações em caso de algum problema de

comunicação.

e) Requisitos de manutenibilidade:- Log de erros: a fim de auxiliar na manutenção do sistema, mensagens

de erro bem definidas e claras deverão ser armazenadas em um

arquivo de texto sempre que um erro ocorrer com o sistema.

- Modularidade: o sistema deverá possuir uma arquitetura modular para

possibilitar menor custo de extensão ou substituição de partes do

software.

6.2.2 Requisitos de processo

Os requisitos de processo derivam das políticas e procedimentos adotados

pelos clientes e desenvolvedores em suas organizações. São eles:

a) Requisitos de entrega:- Entrega de sistema: o sistema deverá ser entregue até o final do ano de

2010.

b) Requisitos de implementação:- Utilização da linguagem de programação Borland Delphi: deverá ser

utilizada a linguagem de programação Borland Delphi, que possibilita o

desenvolvimento do sistema segundo o paradigma de programação

orientado a objetos.

- Utilização do banco de dados MySQL: o sistema deverá utilizar o banco

de dados MySQL para gerir suas informações.



- Utilização da Structured Query Language (SQL): para realizar consultas

à base de dados, o sistema deverá utilizar a SQL, que é uma linguagem

padronizada e específica para esse tipo de operação.

6.2.3 Requisitos externos

A designação requisitos externos abrange todos os requisitos que derivam de

fatores externos ao sistema e seu processo de desenvolvimento. São eles:

a) Requisitos de segurança:- Definição de privilégios no Windows: em cada máquina que executará o

sistema, deverá ser criada uma conta de usuário limitada do Windows

para acesso dos alunos e uma conta administrativa para eventual

utilização dos funcionários.

- Criação de uma conta de usuário para o sistema no banco de dados:

deverá ser criada uma conta de usuário no banco de dados para uso

exclusivo do sistema, com permissões para realizar as operações

CREATE TABLE, SELECT, INSERT, UPDATE e DELETE.

b) Restrições éticas:- Privacidade de um aluno em relação a outro: o sistema deverá garantir

que nenhum aluno tenha acesso a informações sobre outros alunos.



7 DIAGRAMA DE CASOS DE USO

Para a elaboração do diagrama de casos de uso mostrado na Figura 2 foi

utilizada a notação abordada em Larman (2002).

Figura 2 – Diagrama de casos de uso



7.1 Documentação estendida dos casos de uso

O detalhamento dos casos de uso exibido a seguir foi feito utilizando a

notação abordada em Larman (2002).

7.1.1 Cadastrar máquina

Atores: funcionário.

Pré-condição: o arquivo de configuração estar ausente.

Pós-condição: o sistema cadastra a máquina na base de dados e gera o arquivo de

configuração, contendo o código que foi atribuído à máquina.

Entrada: as características da máquina (ver 5.1.2).

Saída: nenhuma.

Fluxo de eventos principal:

1. O caso de uso começa quando o sistema é executado pela primeira vez

em uma máquina;

2. O sistema obtém do sistema operacional as informações sobre a

máquina;

3. O sistema verifica se já possui uma máquina cadastrada com o mesmo

nome de rede;

4. O sistema armazena na base de dados o cadastro da nova máquina;

5. O sistema armazena em um arquivo localmente o código da máquina e o

caso de uso termina.



Fluxo de eventos secundário:

1. Se no passo 3 o sistema encontrar na base de dados uma máquina

cadastrada com o mesmo nome de rede:

a) O usuário será questionado se a máquina já cadastrada corresponde

à máquina que se deseja cadastrar;

b) Caso a resposta do usuário seja positiva, o sistema obterá o código

da máquina já cadastrada na base de dados e prosseguirá ao passo

5;

c) Caso a resposta do usuário seja negativa, o sistema prosseguirá ao

passo 4, realizando um novo cadastro.

2. Se no passo 4 o sistema não conseguir armazenar na base de dados o

cadastro da nova máquina, uma mensagem de erro será exibida e a

operação será abortada. O sistema será então encerrado.

7.1.2 Cadastrar aluno


Pré-condição: nenhuma.

Pós-condição: o sistema cadastra o aluno na base de dados.

Entrada: as informações sobre o aluno (ver 5.1.1).

Saída: confirmação do cadastro.


1. O caso de uso começa quando o funcionário clica em “Cadastrar aluno”;

2. O sistema solicita ao funcionário que digite as informações sobre o aluno;



3. O funcionário fornece ao sistema os dados do aluno: matrícula, nome

completo, nome do curso, etc;

4. O sistema verifica se já existe aluno cadastrado com a mesma matrícula

do aluno a ser cadastrado;

5. O sistema armazena na base de dados o cadastro do novo aluno;

6. O sistema retorna uma mensagem de confirmação ao funcionário e o



1. Se no passo 4 o sistema constatar que a matrícula informada já foi

cadastrada, uma mensagem será mostrada e a operação será abortada.

O sistema retornará então ao passo 2;

2. Se no passo 5 o sistema não conseguir armazenar na base de dados o

cadastro do novo aluno, uma mensagem de erro será exibida e a

operação será abortada.

7.1.3 Registrar observação


Pré-condição: o aluno estar cadastrado na base de dados.

Pós-condição: o sistema registra uma observação sobre o aluno na base de dados.

Entrada: a data e a hora atuais, a matrícula do aluno, a observação em si e se o

aluno pode ou não utilizar a monitoria.

Saída: confirmação do registro da observação.




1. O caso de uso começa quando o funcionário seleciona um aluno na lista e

clica em “Registrar observação”;

2. O sistema solicita ao funcionário que digite as informações sobre a

observação;

3. O funcionário fornece ao sistema a matrícula do aluno, a observação a

ser registrada e define se o sistema deve bloquear (ou liberar, caso já

esteja bloqueada) a matrícula do aluno para acesso à monitoria;

4. O sistema obtém a data e a hora atuais e armazena na base de dados a

observação a respeito do aluno;

5. Se no passo 3 o funcionário definiu que o acesso do aluno à monitoria

deveria ser bloqueado (ou liberado), o sistema altera na base de dados o

status do aluno;



7.1.4 Reservar seção


Pré-condição: a máquina estar cadastrada na base de dados e conectada ao

servidor.

Pós-condição: o sistema registra na base de dados uma reserva de seção para o

aluno.

Entrada: a matrícula do aluno e a máquina que ele deseja utilizar (se houver

preferência) e o tempo que será concedido para que ele utilize a máquina.

Saída: confirmação da reserva.




1. O caso de uso começa quando o funcionário clica em “Reservar seção”;

2. O sistema solicita ao funcionário que informe a matrícula do aluno, a

máquina que ele deseja utilizar (se houver preferência) e o tempo que

será concedido para que ele utilize a monitoria. O sistema sugere uma

quantidade de tempo padrão predeterminada pelo funcionário na sua

configuração;

3. O funcionário fornece ao sistema as informações solicitadas;

4. O sistema verifica se o aluno está cadastrado na base de dados;

5. O sistema verifica se o aluno possui permissão para acessar a monitoria;

6. O sistema verifica se o aluno já pode entrar na monitoria: se ele não

definiu nenhuma preferência de máquina, o sistema verifica se há alguma

máquina disponível para uso, senão o sistema verifica se a máquina

solicitada encontra-se disponível;

7. O sistema armazena na base de dados a reserva de seção;




1. Se no passo 4 for constatado que o aluno não está cadastrado na base

de dados:

a) O sistema informará que o aluno não está cadastrado e oferecerá ao

funcionário a opção de cadastrá-lo;

b) Se o funcionário optar pelo cadastro, o cadastro de aluno será

iniciado (<<extend>> Cadastrar aluno);

c) O sistema retornará ao passo 2.

2. Se no passo 5 for constatado que o aluno não possui permissão para

acessar a monitoria:

a) O sistema informará que o aluno não possui permissão para acessar

a monitoria e oferecerá ao funcionário a opção de visualizar as



observações feitas a respeito daquele aluno;

b) O funcionário poderá registrar uma observação que permitirá que o

aluno acesse a monitoria novamente (<<extend>> Registrar

observação);

c) O sistema retornará ao passo 2.

3. Se no passo 6 for constatado que o aluno ainda não pode entrar na

monitoria:

a) O sistema armazenará na base de dados a solicitação do aluno e

informará ao funcionário da impossibilidade do mesmo entrar na

monitoria;

b) O sistema retornará ao passo 6.

7.1.5 Visualizar fila de espera


Pré-condição: haver alunos aguardando que um computador seja liberado.

Pós-condição: os alunos continuarão aguardando a liberação de um computador.

Entrada: nenhuma.

Saída: lista dos alunos que estão aguardando que um computador seja liberado.


1. O caso de uso começa quando o funcionário clica em “Fila de espera”;

2. O sistema obtém da base de dados a lista das seções que não foram

iniciadas porque no momento em que foram solicitadas não havia

computadores disponíveis;

3. O sistema lista essas seções informando, para cada uma, o código da



seção, a matrícula e o nome do aluno, a máquina que foi solicitada (se

houve essa solicitação), a hora em que a seção foi solicitada e o tempo

que foi concedido pelo funcionário e o caso de uso termina.

7.1.6 Iniciar seção

Atores: funcionário e aluno.

Pré-condição: a seção ter sido reservada e a aplicação cliente estar conectada à

aplicação servidor e ao banco de dados.

Pós-condição: o sistema registra na base de dados o início da seção e avisa ao

funcionário que a seção foi iniciada.

Entrada: a matrícula do aluno e o código da máquina na qual ele iniciou a seção.

Saída: aviso do início da seção.


1. O caso de uso começa quando o aluno digita sua matrícula na tela de

login da aplicação cliente e clica em “Login”;

2. A aplicação cliente verifica na base de dados se há uma seção reservada

para o aluno;

3. A aplicação cliente registra na base de dados o início da seção e fecha a

tela de login;

4. A aplicação cliente envia uma mensagem à aplicação servidor, que

informa ao funcionário o início da seção e o caso de uso termina.




1. Se no passo 2 for constatado que não há uma seção reservada para o

aluno, a aplicação cliente exibirá na tela de login uma mensagem de erro

e a operação será abortada.

7.1.7 Monitorar tempo


Pré-condição: a seção estar em andamento ou bloqueada e a aplicação cliente

estar conectada à aplicação servidor e ao banco de dados.

Pós-condição: a seção pode permanecer em andamento, ser bloqueada ou

encerrada.

Entrada: hora atual.

Saída: quanto tempo resta ao aluno para ele utilizar a máquina em que se encontra.


1. O caso de uso é iniciado de minuto em minuto, enquanto uma seção está

em andamento ou bloqueada;

2. Se a seção estiver em andamento:

a) A aplicação cliente verifica há quanto tempo o aluno não mexeu o

mouse ou apertou alguma tecla e se esse tempo é igual ao tempo

para considerar uma seção inativa;

b) A aplicação cliente verifica quanto tempo se passou desde seu início

e se o tempo concedido para o aluno utilizar a máquina se esgotou;



3. Se a seção estiver bloqueada, a aplicação cliente verifica quanto tempo

se passou desde seu bloqueio e se esse tempo é igual ao tempo para

considerar uma seção inativa;

4. O caso de uso termina.


1. Se no passo 2, item a, a aplicação cliente verificar que a máquina não

apresenta atividade, o monitoramento do tempo será suspenso e a seção

será encerrada (<<extend>> Encerrar seção);

2. Se no passo 2, item b, a aplicação cliente verificar que o tempo concedido

para o aluno utilizar a máquina se esgotou, a seção será bloqueada

(<<extend>> Bloquear seção);

3. Se no passo 2, item b, a aplicação cliente verificar que o tempo concedido

para o aluno utilizar a máquina está próximo de acabar, uma mensagem

será exibida alertando-o que o fim da seção está próximo;

4. Se no passo 3 a aplicação cliente verificar que já se passou muito tempo

desde que a seção foi bloqueada, o monitoramento do tempo será

suspenso e a seção será encerrada (<<extend>> Encerrar seção).

7.1.8 Bloquear seção

Atores: aluno.

Pré-condição: a seção estar em andamento.

Pós-condição: a aplicação cliente registra na base de dados o bloqueio da seção,

exibe a tela de login e informa o motivo pelo qual a seção foi bloqueada.

Entrada: o código da seção e o motivo pelo qual ela foi bloqueada.



Saída: mensagem informando o motivo pelo qual a seção foi bloqueada.


1. O caso de uso começa quando o tempo concedido ao aluno esgota ou

quando a comunicação entre as máquinas é interrompida;

2. A aplicação cliente tenta registrar na base de dados que a seção foi

bloqueada;

3. A aplicação cliente tenta enviar uma mensagem à aplicação servidor para

informar ao funcionário que a seção foi bloqueada;

4. A aplicação cliente exibe a tela de login, impossibilitando o aluno de

acessar o sistema operacional e exibindo uma mensagem que informa o

motivo pelo qual a seção foi bloqueada, e o caso de uso termina.


1. Se no passo 2 a aplicação cliente não conseguir acessar a base de

dados, este erro será ignorado, pois a perda da comunicação com a base

de dados é um dos motivos que pode desencadear o bloqueio da seção,

e o sistema prosseguirá ao passo 3;

2. Se no passo 3 a aplicação cliente não conseguir enviar uma mensagem à

aplicação servidor, este erro será ignorado, pois a perda da comunicação

com a aplicação servidor é um dos motivos que pode desencadear o

bloqueio da seção, e o sistema prosseguirá ao passo 4;

7.1.9 Encerrar seção


Pré-condição: a seção estar em andamento ou bloqueada.



Pós-condição: a aplicação cliente registra na base de dados o encerramento da

seção e reinicia o computador.

Entrada: o código da seção e o motivo pelo qual ela foi encerrada.

Saída: nenhuma.


1. O caso de uso começa quando a seção é considerada inativa, quando o

tempo para retomá-la é encerrado, quando o funcionário solicita o

encerramento de uma seção bloqueada ou a expulsão do aluno;

2. A aplicação cliente tenta registrar na base de dados que a seção foi

encerrada;

3. A aplicação cliente reinicia o computador e o caso de uso termina.



dados, este erro será ignorado, pois a seção pode estar bloqueada devido

à perda da comunicação com a base de dados, e o sistema prosseguirá

ao passo 3;

7.1.10 Estender tempo


Pré-condição: a seção estar em andamento ou bloqueada e a aplicação cliente

estar conectada à aplicação servidor.



Pós-condição: a aplicação cliente registra na base de dados o acréscimo de tempo

e informa ao aluno que seu tempo foi estendido.

Entrada: o código da seção e a quantidade de tempo que deve ser acrescentada.

Saída: mensgem informando ao aluno que seu tempo foi estendido.


1. O caso de uso começa quando o funcionário seleciona a seção na lista e

clica em "Estender tempo";

2. A aplicação servidor solicita ao funcionário que informe a quantidade de

tempo que deve ser acrescentada;

3. O funcionário fornece à aplicação servidor a quantidade de tempo que

deve ser acrescentada;

4. A aplicação servidor registra na base de dados o acréscimo de tempo e

envia uma mensagem à aplicação cliente;

5. A aplicação cliente exibe uma mensagem ao aluno informando-lhe o novo

limite de tempo e o caso de uso termina.



dados, uma mensagem será mostrada e a operação será abortada.

2. Se no passo 5 a seção estiver bloqueada:

a) A aplicação cliente fechará a tela de login;

b) A aplicação cliente registrará na base de dados o início de uma nova

seção com o tempo adicional que foi concedido ao aluno;

c) A aplicação cliente retornará ao passo 5.



7.1.11 Expulsar aluno


Pré-condição: a seção estar em andamento e a aplicação cliente estar conectada à

aplicação servidor.

Pós-condição: a aplicação cliente registra a expulsão do aluno, encerra sua seção

e bloqueia sua matrícula.

Entrada: o código da seção e o motivo pelo qual o aluno foi expulso.

Saída: mensagem informando ao aluno sua expulsão.



clica em "Expulsar aluno";

2. A aplicação servidor solicita ao funcionário que informe o motivo da

expulsão do aluno;

3. O funcionário fornece à aplicação servidor o motivo da expulsão do aluno;

4. A aplicação servidor registra na base de dados que o aluno foi expulso

(<<include>> Registrar observação) e envia uma mensagem à aplicação

cliente;

5. A aplicação cliente avisa ao aluno de sua expulsão, encerra a seção

(<<include>> Encerrar seção) e o caso de uso termina.


1. Se no passo 4 o sistema não conseguir armazenar a expulsão do aluno

na base de dados, uma mensagem de erro será exibida e a operação

será abortada.



7.1.12 Enviar mensagem


Pré-condição: a seção estar em andamento e a aplicação cliente estar conectada à

aplicação servidor.

Pós-condição: a aplicação cliente exibe a mensagem na tela para o aluno.

Entrada: o código da seção e a mensagem em si.

Saída: mensagem enviada pelo servidor.



clica em "Enviar mensagem";

2. A aplicação servidor solicita ao funcionário que informe a mensagem a ser

enviada;

3. O funcionário fornece à aplicação servidor a mensagem a ser enviada;

4. A aplicação servidor envia a mensagem à aplicação cliente;

5. A aplicação cliente exibe a mensagem recebida da aplicação servidor e o



1. Se no passo 4 a aplicação servidor não conseguir enviar a mensagem à

aplicação cliente, uma mensagem de erro será exibida e a operação será

abortada.



7.1.13 Retomar seção


Pré-condição: a seção estar bloqueada e a aplicação cliente estar conectada à

aplicação servidor e ao banco de dados.

Pós-condição: o sistema registra na base de dados o início de uma nova seção e

avisa ao funcionário que a seção foi retomada.

Entrada: a matrícula do aluno e o código da máquina na qual a seção foi retomada.

Saída: aviso do início da seção.


1. O caso de uso começa quando a seção está bloqueada, a tela de login da

aplicação cliente está em exibição e o aluno digita sua matrícula e clica

em “Login”;

2. A aplicação cliente verifica quanto tempo restava para o aluno utilizar da

seção que foi bloqueada e registra na base de dados o início de uma

nova seção com esse tempo (<<include>> Iniciar seção);

3. A aplicação cliente fecha a tela de login;

4. A aplicação cliente envia uma mensagem à aplicação servidor, que

informa ao funcionário o início da seção e o caso de uso termina.

7.1.14 Verificar comunicação entre as máquinas


Pré-condição: as aplicações cliente e servidor estarem em conexão entre si e com

o banco de dados.



Pós-condição: as aplicações cliente e servidor permanecerem em conexão entre si

e com o banco de dados.

Entrada: nenhuma.

Saída: nenhuma.


1. O caso de uso é iniciado de segundo em segundo, enquanto a aplicação

está em execução;

2. A aplicação cliente envia uma mensagem à aplicação servidor

confirmando o status da conexão e aguarda uma resposta;

3. A aplicação servidor recebe e responde a mensagem da aplicação cliente;

4. A aplicação cliente verifica a conexão com o banco de dados e o caso de

uso termina.


1. Se no passo 2 a aplicação cliente enviar uma mensagem à aplicação

servidor e não receber uma resposta, ela bloqueará a seção em

andamento na sua máquina, se houver (<<extend>> Bloquear seção), e a

operação será abortada;

2. Se no passo 4 a aplicação cliente verificar que não está conectada ao

banco de dados, ela bloqueará a seção em andamento na sua máquina,

se houver (<<extend>> Bloquear seção), e a operação será abortada.

7.1.15 Encerrar aplicação




Pré-condição: a aplicação cliente estar em execução.

Pós-condição: a aplicação cliente é encerrada.

Entrada: o nome de usuário e a senha de uma conta administrativa do Windows.

Saída: nenhuma.


1. O caso de uso começa quando o funcionário clica em "Encerrar

aplicação";

2. A aplicação cliente solicita ao funcionário que informe o nome de usuário

e a senha de uma conta administrativa do Windows;

3. A aplicação cliente verifica se a conta fornecida possui privilégios

administrativos e se a senha foi digitada corretamente;

4. A aplicação cliente é encerrada e o caso de uso termina.


1. Se no passo 3 a aplicação cliente verificar que a conta fornecida não

possui privilégios administrativos ou a senha informada não confere com

a senha da conta informada, uma mensagem de erro será exibida e a

operação será abortada.

7.1.16 Exportar base de dados


Pré-condição: a aplicação servidor estar em execução.



Pós-condição: uma cópia de segurança da base de dados é gerada.

Entrada: a localização do utilitário de backup do banco de dados e o local onde a

cópia de segurança será salva juntamente com o nome do arquivo.

Saída: confirmação da exportação.


1. O caso de uso começa quando o funcionário clica em "Exportar base de

dados";

2. O sistema solicita ao funcionário que informe a localização do utilitário de

backup do banco de dados e o local onde a cópia de segurança será

salva juntamente com o nome do arquivo;

3. O sistema executa o utilitário de backup do banco de dados, que cria um

script SQL no local especificado pelo funcionário;

4. O sistema compacta o script SQL;




1. Se no passo 3 o sistema verificar que o utilitário de backup do banco de

dados não se encontra na localização informada, uma mensagem de erro

será exibida e a operação será abortada;

2. Se no passo 4 o sistema não conseguir compactar o script SQL, uma

mensagem de erro será exibida e a operação será abortada.

7.1.17 Importar base de dados




Pré-condição: a aplicação servidor estar em execução.

Pós-condição: a base de dados é recuperada.

Entrada: a localização do utilitário de linha de comando do banco de dados e o local

onde se encontra a cópia de segurança a ser recuperada.

Saída: confirmação da importação.


1. O caso de uso começa quando o funcionário clica em "Importar base de

dados";

2. O sistema solicita ao funcionário que informe a localização do utilitário de

linha de comando do banco de dados e o local onde se encontra a cópia

de segurança a ser recuperada;

3. O sistema extrai o script SQL do arquivo compactado;

4. O sistema invoca o utilitário de linha de comando do banco de dados, que

executa os comandos contidos no script SQL extraído;

5. O sistema exclui o script SQL;




1. Se no passo 3 o sistema não conseguir extrair o script SQL do arquivo

compactado, uma mensagem de erro será exibida e a operação será

abortada;

2. Se no passo 4 o sistema verificar que o utilitário de backup do banco de

dados não se encontra na localização informada, uma mensagem de erro

será exibida e a operação será abortada.



8 PROJETO DE ARQUIVOS

A partir do DER (ver capítulo 5), foi elaborado o projeto de arquivos do

sistema, detalhado nas seções a seguir. A notação utilizada foi baseada na adotada

em Elmasri & Navathe (2006).

8.1 Entidade ALUNO

Representa um aluno matriculado na escola.

Tabela 1 – Atributos da entidade ALUNO

Atributo Tipo PK FK NN AI Descriçãoalu_matricula varchar(20) X X Matrícula do aluno e identificador

único dos alunos.alu_nome varchar(50) Nome completo do aluno.alu_curso varchar(50) Nome do curso do aluno.alu_turma varchar(20) Turma do aluno.alu_endereco varchar(255) Endereço do aluno, com logradouro,

número e complemento.alu_bairro varchar(50) Bairro onde o aluno mora.alu_cep varchar(8) CEP do logradouro onde o aluno

mora, apenas caracteres numéricos.alu_cidade varchar(50) Cidade onde o aluno mora.alu_estado varchar(2) Sigla do estado onde o aluno mora.alu_telefone varchar(10) Telefone residencial do aluno com

área, apenas caracteres numéricos.alu_celular varchar(10) Celular do aluno com área, apenas

caracteres numéricos.alu_rg varchar(20) Número do documento de identidade

do aluno com órgão expedidor.



alu_cpf varchar(11) Número do CPF do aluno, apenas

caracteres numéricos.alu_email varchar(50) E-mail do aluno.alu_status varchar(1) Situação do aluno com relação à

escola e a biblioteca: 0 = regular, sem

pendências com a biblioteca (pode

usar a monitoria); 1 = irregular, com

pendências com a biblioteca; 2 = não

estuda mais na instituição (não pode

usar a monitoria).

8.2 Entidade MAQUINA

Representa o computador que executa a aplicação servidor ou um

computador da monitoria, que executa a aplicação cliente.

Tabela 2 – Atributos da entidade MAQUINA

Atributo Tipo PK FK NN AI Descriçãomaq_codigo integer X X X Código da máquina e identificador

único das máquinas.maq_nome varchar(65) Nome de rede (hostname) da

máquina.maq_processador varchar(100) Breve descrição do processador

da máquina, com frabricante,

nome, modelo e clock interno.maq_memoria integer Quantidade de memória RAM da

máquina em megabytes (MB).maq_sistema varchar(50) Nome e versão do sistema

operacional instalado na máquina.



8.3 Entidade OBSERVACAO

Representa uma observação feita por um funcionário da biblioteca a respeito

de determinado aluno.

Tabela 3 – Atributos da entidade OBSERVACAO

Atributo Tipo PK FK NN AI Descriçãoobs_codigo integer X X X Código da observação e identificador

único das observações.alu_matricula varchar(20) X Matrícula do aluno que recebeu a

observação. O registro se relaciona

com um registro da entidade ALUNO

através do conteúdo desse campo (ver

8.7).obs_data varchar(8) Data em que a observação foi feita, no

formato AAAAMMDD.obs_hora varchar(4) Hora em que a observação foi feita, no

formato HHMM.obs_texto varchar(255) Conteúdo da observação.

8.4 Entidade SECAO

Representa uma concessão de tempo que é feita pelo funcionário da

biblioteca a um aluno para que este possa utilizar um computador da monitoria.



Tabela 4 – Atributos da entidade SECAO

Atributo Tipo PK FK NN AI Descriçãosec_codigo integer X X X Código da seção e

identificador único das seções.alu_matricula varchar(20) X Matrícula do aluno que iniciou

a seção. O registro se

relaciona com um registro da

entidade ALUNO através do

conteúdo desse campo (ver

8.6).maq_codigo integer X Código da máquina na qual a

seção foi iniciada. O registro

se relaciona com um registro

da entidade MAQUINA através

do conteúdo desse campo (ver

8.5).sec_data varchar(8) Data em que a seção foi

iniciada, no formato

AAAAMMDD.sec_hora varchar(4) Hora em que a seção foi

iniciada, no formato HHMM.sec_tempo_concedido integer Tempo em minutos que foi

concedido ao aluno para

utilizar a máquina.sec_tempo_utilizado integer Tempo em minutos que o

aluno utilizou a máquina. O

valor desse campo é

incrementado a cada minuto

de utilização da máquina.sec_status varchar(1) Situação da seção: 0 = em

espera; 1 = reservada; 2 = em

andamento; 3 = finalizada pelo



aluno ou por tempo esgotado;

4 = finalizada pelo funcionário;

5 = finalizada por inatividade; 6

= finalizada por expulsão; 7 =

finalizada por problemas

técnicos.

8.5 Relacionamento POSSUI

Relacionamento que ocorre entre as entidades SECAO e MAQUINA. Cada

máquina pode estar relacionada a (isto é, possui) qualquer número de seções

(nenhuma, uma ou mais de uma seção), mas uma seção pode estar relacionada a

(isto é, pertence a) uma e somente uma máquina. Isso caracteriza um

relacionamento 1:N, onde SECAO representa a entidade fraca e MAQUINA

representa a entidade forte, havendo um atributo na entidade SECAO que identifica

a máquina a qual ela está relacionada.

Tabela 5 – Atributos envolvidos no relacionamento POSSUI

Atributo Entidade de origem Entidade de destinomaq_codigo MAQUINA SECAO

8.6 Relacionamento RESERVA

Relacionamento que ocorre entre as entidades ALUNO e SECAO. Cada aluno

pode estar relacionado a (isto é, reserva) qualquer número de seções (nenhuma,

uma ou mais de uma seção), mas uma seção pode estar relacionada a (isto é, é

reservada por) um e somente um aluno. Isso caracteriza um relacionamento 1:N,

onde SECAO representa a entidade fraca e ALUNO representa a entidade forte,

havendo um atributo na entidade SECAO que identifica o aluno ao qual ela está



relacionada.

Tabela 6 – Atributos envolvidos no relacionamento RESERVA

Atributo Entidade de origem Entidade de destinoalu_matricula ALUNO SECAO

8.7 Relacionamento RECEBE

Definição: relacionamento que ocorre entre as entidades ALUNO e OBSERVACAO.

Cada aluno pode estar relacionado a (isto é, recebe) qualquer número de

observações (nenhuma, uma ou mais de uma observação), mas uma observação

pode estar relacionada a (isto é, é recebida por) um e somente um aluno. Isso

caracteriza um relacionamento 1:N, onde OBSERVACAO representa a entidade

fraca e ALUNO representa a entidade forte, havendo um atributo na entidade

OBSERVACAO que identifica o aluno ao qual ela está relacionada.

Tabela 7 – Atributos envolvidos no relacionamento RECEBE

Atributo Entidade de origem Entidade de destinoalu_matricula ALUNO OBSERVACAO



9 SCRIPT DE CRIAÇÃO DA BASE DE DADOS

A base de dados modelada conceitualmente no ambiente proposto (ver

capítulo 4), logicamente no DER (ver capítulo 5) e fisicamente no projeto de arquivos

(ver capítulo 8) pode ser criada através da execução do script SQL exibido no

Quadro 1 em qualquer ferramenta de gerenciamento de banco de dados. A equipe

de desenvolvimento recomenda a utilização do MySQL Workbench, ferramenta

fornecida pelo próprio desenvolvedor do MySQL.

Quadro 1 – Script de criação da base de dados

CREATE SCHEMA àrgos` DEFAULT CHARACTER SET latin1;

USE àrgos`;

CREATE TABLE àrg_aluno` ( àlu_matricula` varchar(20) NOT NULL, àlu_nome` varchar(50) DEFAULT NULL, àlu_curso` varchar(50) DEFAULT NULL, àlu_turma` varchar(20) DEFAULT NULL, àlu_endereco` varchar(255) DEFAULT NULL, àlu_bairro` varchar(50) DEFAULT NULL, àlu_cep` varchar(8) DEFAULT NULL, àlu_cidade` varchar(50) DEFAULT NULL, àlu_estado` varchar(2) DEFAULT NULL, àlu_telefone` varchar(10) DEFAULT NULL, àlu_celular` varchar(10) DEFAULT NULL, àlu_rg` varchar(20) DEFAULT NULL, àlu_cpf` varchar(11) DEFAULT NULL, àlu_email` varchar(50) DEFAULT NULL, àlu_status` varchar(1) DEFAULT NULL, PRIMARY KEY (àlu_matricula`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE àrg_maquina` ( `maq_codigo` integer NOT NULL AUTO_INCREMENT, `maq_nome` varchar(65) DEFAULT NULL, `maq_processador` varchar(100) DEFAULT NULL, `maq_memoria` integer DEFAULT NULL, `maq_sistema` varchar(50) DEFAULT NULL, PRIMARY KEY (`maq_codigo`)) ENGINE=InnoDB DEFAULT CHARSET=latin1;



CREATE TABLE àrg_observacao` ( òbs_codigo` integer NOT NULL AUTO_INCREMENT, àlu_matricula` varchar(20) DEFAULT NULL, òbs_data` varchar(8) DEFAULT NULL, òbs_hora` varchar(4) DEFAULT NULL, òbs_texto` varchar(255) DEFAULT NULL, PRIMARY KEY (òbs_codigo`), KEY `recebe` (àlu_matricula`), CONSTRAINT `recebe` FOREIGN KEY (àlu_matricula`) REFERENCES àrg_aluno` (àlu_matricula`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE TABLE àrg_secao` ( `sec_codigo` integer NOT NULL AUTO_INCREMENT, àlu_matricula` varchar(20) DEFAULT NULL, `maq_codigo` integer DEFAULT NULL, `sec_data` varchar(8) DEFAULT NULL, `sec_hora` varchar(4) DEFAULT NULL, `sec_tempo_concedido` integer DEFAULT NULL, `sec_tempo_utilizado` integer DEFAULT NULL, `sec_status` varchar(1) DEFAULT NULL, PRIMARY KEY (`sec_codigo`), KEY `reserva` (àlu_matricula`), KEY `possui` (`maq_codigo`), CONSTRAINT `possui` FOREIGN KEY (`maq_codigo`) REFERENCES àrg_maquina` (`maq_codigo`) ON DELETE CASCADE ON UPDATE CASCADE, CONSTRAINT `reserva` FOREIGN KEY (àlu_matricula`) REFERENCES àrg_aluno` (àlu_matricula`) ON DELETE CASCADE ON UPDATE CASCADE) ENGINE=InnoDB DEFAULT CHARSET= latin1;



10 IMPLEMENTAÇÃO

Para o desenvolvimento do sistema foi utilizada a linguagem de programação

Delphi, que é uma linguagem que permite a criação de aplicações desktop utilizando

o paradigma de programação orientado a objetos. Para agilizar o desenvolvimento,

foi utilizado o ambiente de desenvolvimento integrado Borland Delphi 7.0.

Optou-se por utilizar o MySQL 5.1 como banco de dados, por ser uma

aplicação robusta, amplamente utilizada e conhecida pelo mercado e também por

apresentar os recursos necessários para a implementação da base de dados do

sistema.

Para modelar e gerenciar o banco, foi utilizada a ferramenta MySQL

Workbench, que é oferecida pelo próprio desenvolvedor do MySQL.

10.1 Ferramentas e técnicas utilizadas

O processamento de dados, a comunicação entre as máquinas e o acesso ao

banco de dados foi encapsulado em classes com o objetivo de melhor empregar o

paradigma de programação orientado a objetos, tornando o sistema modular e

permitindo a separação entre processamento e interface. Para a implementação

desta, foram utilizados principalmente os componentes padrão fornecidos com o

Borland Delphi 7. Além deles, foram utilizados dois componentes de terceiros, o

ZipMaster e o CoolTrayIcon, e um componente foi desenvolvido, o

SortListViewEx. Os códigos-fonte desses componentes acompanham o código-

fonte do sistema. Uma breve descrição e explanação dessas classes e componentes

será vista nessa seção.

As classes foram desenvolvidas utilizando a notação padrão do Delphi: seus

nomes equivalem aos nomes das entidades que abstraem precedidos da consoante

T, que indica tipo. São elas: TAluno, TMáquina, TObservação, TSeção,

TConfiguração, TLog e TRede. No código-fonte do sistema, há uma unit para

cada uma dessas classes.



As quatro primeiras representam abstrações das entidades identificadas

durante a modelagem do sistema (ver 5.1) e encapsulam todos os dados e

operações referentes a essas entidades, entre elas o cadastro, o carregamento, a

modificação e a exclusão de registros na base de dados. Para realizar tais

operações, os objetos dessas classes possuem métodos que geram os comandos

SQL correspondentes, executam esses comandos utilizando um componente não-

visual AdoQuery (ver Apêndice A) e retornam verdadeiro ou falso como resultado de

sua execução, permitindo que a interface exiba as mensagens de sucesso ou de

erro correspondentes às operações.

As classes TConfiguração e TLog abstraem o armazenamento de

informações em arquivos locais: a primeira tem como função gerar, abrir, ler e

atualizar o arquivo de configuração gerado por cada aplicação cliente, que contém o

código da máquina cadastrado no banco de dados, o endereço e a porta do servidor;

a última representa o arquivo de texto que registra os eventos ocorridos durante a

execução da aplicação (ver 6.2.1, alínea e) e tem capacidade para gerar, abrir, ler e

atualizar esse arquivo.

A comunicação entre as aplicações cliente e servidor é abstraída pela classe

TRede. Ela se utiliza dos componentes não-visuais IdTCPClient, IdUDPClient,

ADOConnection, IdTCPServer e IdUDPServer (ver Apêndice A), todos

pertencentes ao conjunto de componentes padrão do Delphi, para efetuar a

comunicação entre as aplicações servidor e cliente e entre essas e o banco de

dados. Ela apresenta funções distintas a depender da aplicação que seja iniciada.

Quando o executável é iniciado como uma aplicação servidor, o objeto criado

com base na classe TRede é responsável por se conectar ao banco de dados e aos

clientes, armazenar uma lista dos clientes conectados, das seções em andamento

nesses clientes e dos alunos que os estão utilizando, se houver. Tem capacidade

para enviar ordens de encerramento de seção, expulsão de aluno e mensagens de

texto aos clientes. Também dispara eventos quando um cliente é conectado ou

desconectado, quando o acesso ao banco é interrompido ou retomado e quando

uma seção é iniciada, bloqueada, retomada, encerrada ou tem seu tempo estendido

em algum dos clientes, para que os componentes da interface possam realizar a

devida interação com o funcionário que está utilizando a aplicação servidor.



Na aplicação cliente, o objeto da classe TRede realiza a conexão com o

servidor e o banco de dados, verifica a comunicação do cliente com os mesmos e

dispara eventos quando o cliente é conectado ou desconectado ao servidor ou ao

banco de dados, quando a seção é iniciada, bloqueada, retomada, encerrada ou tem

seu tempo estendido e quando uma mensagem é recebida do servidor, para que os

componentes responsáveis pela interface possam realizar a devida comunicação

com o aluno que está utilizando o cliente em questão.

Todas as telas do sistema que aparecem para o usuário são formadas pelo

componente Form. Sobre este componente são depositados os outros componentes

que formam a interface de interação do usuário com a ferramenta.

A tela principal da aplicação servidor (ver Figura 4) é composta de um

componente ActionMenu, onde é formado o menu com as opções para o usuário,

um componente ActionToolBar, que exibe as mesmas opções que o menu mas

em formato de botões, para os usuários que prefererirem assim os acionarem, dois

componentes SortListViewEx, que serão explicados mais adiante, mas nessa

tela servem para listar os cliente conectados e os últimos eventos ocorridos e um

componente StatusBar, que forma a barra de status onde aparecem avisos para o

usuário. Nessa tela estão as chamadas para as demais telas da aplicação servidor

conforme a seleção do usuário a partir do menu ou da barra de ferramentas.

Nas telas do sistema de uma forma em geral o componente Image foi

utilizado para exibir o ícone que representa cada tela, foram utilizados os

componentes Edit, MaskEdit, Memo e ComboBox para visualização e entrada de

dados, componentes Label para exibir o título e identificar os campos,

componentes GroubBox para agrupar campos, componentes ActionManager para

armazenar e habilitar ou desabilitar as ações e, componentes BitBtn para permitir

ao usuário acionar a execução das ações.

Nas telas de histórico do aluno (ver Figuras 8 e 9) e histórico da máquina

(Figura 26) na aplicação servidor e na tela principal da aplicação cliente (Figuras 16

e 17), os componentes PageControl e TabSheet foram utilizados para dividir a

tela em guias como se fossem um arquivo fichário.

A tela principal da aplicação cliente não apresenta muitas opções de ações a



serem executadas, sendo principalmente informativa.

Nas telas principais das aplicações servidor e cliente há dois componentes

Image e um componente Shape na parte superior, que são utilizados para exibir o

logotipo do sistema. Há também em cada uma delas um componente

CoolTrayIcon, que será explicado mais adiante.

Para centralizar os componentes de rede e banco de dados usou-se o

DataModule, que é uma espécie de tela para o desenvolvedor, no qual estão os

componentes relativos ao acesso às máquinas da rede – IdTCPClient,

IdUDPClient, IdTCPServer e IdUDPServer – e ao banco de dados –

ADOConnection e AdoQuery. Nele encontram-se ainda os objetos que são

criados durante a inicialização da aplicação seja ela cliente ou servidor e que são

acessíveis por todo o sistema: TConfiguração, TLog e TRede.

Como os componentes possuem propriedades e eventos, utilizou-se de

algumas de suas propriedades para definir as características iniciais de cada

componente, bem como adequá-lo à necessidade do protótipo. Em alguns eventos

efetuou-se a programação de cada um destes, dentre as quais as consistências,

chamadas de telas, chamadas de funções, tratamento dos dados, execução de

comandos SQL dentre outros. Maiores informações sobre o funcionamento de cada

componente bem como sobre o ambiente Delphi e sua estrutura de linguagem, pode

ser encontradas em Cantù (2003).

O componente ZipMaster foi utilizado nas operações de exportação e

importação da base de dados, para compactar e descompactar, respectivamente, o

script SQL gerado. No código-fonte do sistema, esse componente se encontra

inserido no DataModule. Há, na mesma unit que contém o DataModule, duas

rotinas que o manuseiam, compactando ou descompactando o arquivo que lhes é

passado como parâmetro. Maiores informações sobre o funcionamento desse

componente podem ser encontradas em DelphiZip (2010) ou no arquivo de ajuda

que acompanha o seu código-fonte.

O componente CoolTrayIcon foi utilizado nas telas principais das

aplicações cliente e servidor para gerar o ícone que é exibido na área de notificação

do sistema quando essas telas são fechadas ou minimizadas. Para restaurar a

aplicação, o usuário pode efetuar um duplo-clique sobre o ícone ou clicar com o



botão direito e escolher no menu que aparece a opção de restaurar a janela. Esse

menu também permite o encerramento da plicação, no caso da aplicação servidor,

ou o encerramento da seção, no caso das aplicações cliente. Quando a aplicação é

restaurada ou fechada, esse ícone deixa de ser exibido. Maiores informações sobre

o funcionamento desse componente podem ser encontradas em Jakobsen (2006) ou

no arquivo de ajuda que acompanha o seu código-fonte.

O componente SortListViewEx foi desenvolvido a partir de dois

componentes de terceiros cujo código-fonte pode ser obtido da Internet: o

SortListView e o ListViewEx. Ele foi utilizado nas telas de listagem de

registros. Seu desenvolvimento se deu para suprir a necessidade de recursos que

não eram oferecidos pelo componente ListView que acompanha o Delphi, como a

ordenação por determinada coluna ao clicar em seu nome ou a seleção de quais

colunas devem ser exibidas ou ocultadas através de um menu, que pode ser exibido

com o clique do botão direito do mouse. Maiores informações sobre os componentes

nos quais o SortListViewEx se baseia podem ser encontradas em Priyatna

(2007) e Below (2010).

10.2 Possibilidade de integração com outros projetos

Além deste projeto, outros projetos desenvolvidos pela turma este ano tiveram

como objetivo atender a alguma necessidade do Instituto:

a) Sistema de controle de biblioteca, por Amanda Hellen Cerqueira

Santos, Amanda Menezes de Oliveira Lima e Fábio Nascimento Santos;

b) Sistema de gerenciamento de manutenção de equipamentos, por

Alice Rodrigues Santos e Vivia Monique de Souza Lima;

c) Sistema de integração aluno-escola, por Kelvin Mendes Sampaio,

Matheus Oliveira Garcia e Nilton Bruno Feitosa Santana.

Foi questionado durante o desenvolvimento do Sistema de controle da

monitoria a possibilidade de integrar a ele esses outros sistemas:



a) A integração com o Sistema de controle de biblioteca poderia gerar

automaticamente observações sobre pendências de um aluno com a

biblioteca, bloqueando sua matrícula e impedindo seu acesso a monitoria

quando surgisse uma pendência;

b) O Sistema de gerenciamento de manutenção de equipamentos poderia

ser utilizada para gerar e armazenar o cadastro das máquinas da

monitoria;

c) O Sistema de integração aluno-escola poderia ser utilizado para gerir as

informações pessoais referentes a cada aluno e automaticamente

atualizar seu status quando o mesmo deixasse a escola.

Se isso fosse feito, esses outros sistemas poderiam desempenhar funções

que não são específicas do Sistema de controle da monitoria, enquanto este seria

responsável somente por gerir a monitoria, que é a sua especificidade. No entanto, o

tempo disponível para a implementação do programa não foi suficiente para que

essa integração fosse analisada e implementada. Decidiu-se então que o sistema

desempenharia as funções que não lhe são específicas de maneira simples, como já

havia sido planejado.



11 PROJETO DE INTERFACES

Para atender ao requisito não-funcional "Interface gráfica amigável" (ver 6.2.1,

alínea a), procurou-se simplificar a interface do sistema ao máximo. Os ícones

possuem identidade visual, pois todos eles pertencem ao tema de ícones Oxygen.

Além disso, seu significado foi padronizado: comandos semelhantes em telas

diferentes possuem os mesmos ícones. Um exemplo dessa padronização é a tela

principal da aplicação servidor, mostrada na Figura 4, cujos menus e barra de

ferramentas apresentam os mesmos ícones dispostos na mesma sequência (ver

Figura 5). É possível acionar os mesmos comandos por qualquer um dos dois.

Para facilitar a assimilação da interface pelo usuário, os comandos também

foram nomeados de acordo com os requisitos funcionais (ver seção 6.1) e os casos

de uso (ver capítulo 7) levantados durante a fase de análise. Isso também pode ser

percebido na tela principal da aplicação servidor.

A seguir, as telas do programa serão exibidas simulando uma sequência

lógica de funcionamento parecida com a sequência em que o programa foi descrito

no ambiente proposto (ver capítulo 4). Mais informações sobre o tema de ícones

utilizado podem ser obtidas em Oxygen (2010).

Figura 3 – Aplicação servidor – Tela de carregamento



Figura 4 – Aplicação servidor – Tela principal

Figura 5 – Aplicação servidor – Menus e barra de ferramentas



Figura 6 – Aplicação servidor – Lista de alunos


Figura 7 – Aplicação servidor – Cadastro de aluno Figura 8 – Aplicação servidor – Histórico do aluno – Aba "Seções"

Figura 9 – Aplicação servidor – Histórico do aluno – Aba "Observações"Figura 10 – Aplicação servidor – Registro de observação


Figura 11 – Aplicação servidor – Reserva de seção

Figura 12 – Aplicação servidor – Fila de espera


Figura 13 – Aplicação cliente – Tela de login


Figura 14 – Aplicação cliente – Tela de login – Sair

Figura 15 – Aplicação cliente – Tela de login – Encerrar aplicação



Figura 16 – Aplicação cliente – Tela principal – Aba "Aluno"

Figura 17 – Aplicação cliente – Tela principal – Aba "Seção"



Figura 18 – Aplicação cliente – Aviso de tempo restante

Figura 19 – Aplicação servidor – Envio de mensagem



Figura 20 – Aplicação cliente – Aviso de mensagem recebida

Figura 21 – Aplicação servidor – Expulsão de aluno



Figura 22 – Aplicação servidor – Estender tempo


Figura 23 – Aplicação servidor – Importação da base de dados Figura 24 – Aplicação servidor – Exportação da base de dados


Figura 25 – Aplicação servidor – Lista de máquinas


Figura 26 – Aplicação servidor – Histórico da máquina

Figura 27 – Aplicação servidor – Ícone da área de notificação


12 PROJETO DE RELATÓRIOS

Consta das solicitações feitas pelos funcionários responsáveis pela monitoria

que o sistema fizesse relatórios estatísticos sobre a utilização das máquinas que

informassem os programas e sites mais utilizados pelos alunos (ver último parágrafo

do capítulo 3), mas tais relatórios não puderam ser desenvolvidos devido a ausência

de documentação sobre recursos da linguagem de programação adotada que

permitissem desenvolver essa funcionalidade (ver 4º parágrafo do capítulo 4). Sendo

assim, o sistema não gera nenhum relatório que possa ser impresso.



13 CONCLUSÃO

O desenvolvimento deste trabalho foi interessante para os integrantes da

equipe, pois os mesmos foram expostos a uma situação real, que os possibilitou

vivenciar a rotina dos profissionais já formados e atuantes na área, como também

exigiu que conhecimentos complementares ao curso fossem adquiridos para que se

pudesse desenvolver determinadas especificidades do sistema.

Espera-se que o aprendizado adquirido com esse trabalho não se restrinja

apenas aos seus desenvolvedores, mas a todos alunos do curso ou mesmo de

outras instituições de ensino que tenham o interesse em consultá-lo. Para isso, todo

o material referente ao corrente trabalho – apresentação, especificação, código-

fonte, instalador e vídeos explicativos – foi disponibilizado na Internet sob licença

GPL (ver Anexo A) em um site criado apenas com a finalidade de armazená-lo

(<http://argoslan.sourceforge.net/>). A licença GPL garante que qualquer um tenha

acesso livre e irrestrito aos documentos disponibilizados nesse site.

Como um projeto de software livre, esse sistema não se encontra e jamais se

encontrará finalizado, sendo passível de mudanças, correções e melhorias pela

comunidade. Todos os interessados encontram-se convidados a contribuir com o seu

aperfeiçoamento, seja sugerindo novas funcionalidades, propondo alterações ou

enviando códigos para serem incorporados ao programa, ou até mesmo obtendo

cópias, instalando e testando em suas máquinas para que esse projeto possa

sempre crescer e o resultado desse crescimento seja compartilhado por todos.



REFERÊNCIAS

ABOUT.COM. About Delphi Programming - For Novice and Expert CodeGear Delphi Developers. Disponível em: <http://delphi.about.com/>. Acesso em: 26 novembro 2010.

ALVES, William Pereira. Fundamentos de banco de dados. 1 ed. São Paulo: Érica, 2004.

BELOW, Peter. ListViewEx. Versão 1.0: Peter Below, 2010. Disponível em: <http://delphi.about.com/library/weekly/aa053105a.htm>. Acesso em: 23 dezembro 2010.

CANTÙ, Marco. Dominando o Delphi 7 – A Bíblia. São Paulo: Pearson Makron Books, 2003.

DELPHIZIP. ZipMaster. Versão 1.9.0: DelphiZip, 2010. Disponível em: <http://www.delphizip.org>. Acesso em: 23 dezembro 2010.

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4 ed. São Paulo: Pearson Addison-Wesley, 2006.

FREE SOFTWARE FOUNDATION. GNU General Public License. Traduzido por: Creative Commons. Versão 2.0: Free Software Foundation, 1991. Disponível em: <http://creativecommons.org/licenses/GPL/2.0/legalcode.pt>. Acesso em: 23 dezembro 2010.

HOWER, Chad Z. ZipMaster. Versão 1.9.0: DelphiZip, 2010. Disponível em: <http://www.delphizip.org>. Acesso em: 23 dezembro 2010.

JAKOBSEN, Troels. CoolTrayIcon. Versão 4.4.0: Troels Jakobsen, 2006. Disponível em: <http://subsimple.com>. Acesso em: 23 dezembro 2010.

LARMAN, Craig. Applying UML and Patterns: an Introduction to Object-Oriented Analysis and Design and Iterative Development. 2. ed. Upper Saddle River: Prentice Hall PTR, 2002.



MICROSOFT. MSDN – Microsoft Developer Network. Disponível na Internet em: <http://msdn.microsoft.com>. Último acesso em: 26/11/2010.

ORACLE. MySQL :: MySQL 5.1 Reference Manual. Disponível na Internet em: <http://dev.mysql.com/doc/refman/5.1/en/>. Último acesso em: 27/11/2010.

OXYGEN. Oxygen Icons. Versão 1.0: Oxygen, 2010. Disponível em: <http://www.oxygen-icons.org/>. Acesso em: 23 dezembro 2010.

PRESSMAN, Roger S. Engenharia de software. 6 ed. São Paulo: McGraw-Hill, 2007

PRIYATNA. SortListView. Versão 1.01: Priyatna, 2007. Disponível em: <http://www.priyatna.org>. Acesso em: 23 dezembro 2010.

SOMMERVILLE, Ian. Software engineering. 8 ed. Harlow: Pearson Addison-Wesley, 2007.

THE INDY PROJECT. Indy. Disponível em: <http://www.indyproject.org/>. Acesso em: 26 dezembro 2010.



APÊNDICE A – CONHECIMENTOS COMPLEMENTARES

Durante a realização deste trabalho, a aquisição de conhecimentos

complementares aos obtidos pelo curso se fez necessária para que se fosse

possível desenvolver determinadas especificidades do sistema proposto. Este

apêndice tem como objetivo fornecer noções acerca desses conhecimentos

adquiridos.

Componentes Indy

Entre os componentes padrão que acompanham o Borland Delphi, há um

conjunto de componentes chamado Indy (Internet Direct). Trata-se de um projeto de

componentes código-aberto, cuja equipe de desenvolvimento é liderada por Chad Z.

Hower, que oferece suporte aos protocolos de rede mais conhecidos e utilizados.

Antigamente, esses componentes eram chamados WinShoes, como um trocadilho

com WinSocks, abreviação de Windows Sockets, o nome da biblioteca de sockets

do Windows.

Um socket é uma combinação de um endereço IP com uma porta. Representa

uma conexão entre dois processos, que podem estar em uma mesma máquina ou

em máquinas diferentes. A biblioteca WinSocks é utilizada como um padrão para a

criação de programas que utilizem Internet, Intranet ou qualquer outro tipo de

comunicação por rede no Windows, independentemente do protocolo utilizado.

Normalmente, ela é utilizada para fornecer o protocolo TCP/IP para os programas,

mas também pode fornecer outros protocolos, como Novell (IPX/SPX), UDP, ICMP,

NetBIOS, entre outros.

A proposta dos componentes Indy é encapsular os protocolos fornecidos por

essa e outras bibliotecas do Windows, provendo esses protocolos às aplicações

desenvolvidas utilizando a linguagem de programação Delphi. Eles oferecem

suporte aos procolos IP, TCP, UDP, RAW, SMTP, POP3, NNTP, HTTP, entre outros,

em um total de mais de 100 protocolos de alto nível.



A versão 7 do ambiente de desenvolvimento Borland Delphi vem com os

componentes Indy versão 9, que foi a versão utilizada no desenvolvimento do

sistema. No Borland Delphi 7 os componentes Indy estão distribuídos em 5 paletas:

a) Indy Clients: contém os componentes que encapsulam os clientes, que,

por definição, são os que iniciam a comunicação. Normalmente, um

cliente se comunica com apenas um servidor por vez. Se um programa

necessita se comunicar com vários servidores ao mesmo tempo, deve

apresentar vários clientes. Dessa paleta foram utilizados na

implementação do sistema os componentes IdTCPClient e

IdUDPClient, que representam os clientes dos protocolos TCP e UDP,

respectivamente;

b) Indy Servers: contém os componentes que encapsulam os servidores,

que, por definição, são os que recebem, processam e respondem a

requisições dos clientes. Normalmente, um servidor pode se conectar a

vários clientes simultaneamente. Cada conexão com um cliente

representa, no entanto, um socket diferente. Dessa paleta foram utilizados

na implementação do sistema os componentes IdTCPServer e

IdUDPServer, que representam os servidores dos protocolos TCP e

UDP, respectivamente;

c) Indy Intercepts: novidade dos componentes Indy 9 em relação à versão

anterior (Indy 8), que acompanhava o Borland Delphi 6. Contém

componentes que realizam encriptação, decriptação, compressão e

descompressão dos dados que trafegam pela rede e também depuração

e registro de eventos de rede. Nenhum desses componentes foi utilizado

na implementação do sistema;

d) Indy I/O Handlers: outra novidade da versão 9 dos componentes Indy em

relação à anterior. Contém componentes que permitem implementar

clientes ou servidores partindo do baixo nível. Nenhum desses

componentes foi utilizado na implementação do sistema;

e) Indy Misc: contém componentes com funções diversas, que podem estar

relacionadas ou não à comunicação em rede. Dessa paleta foi utilizado na



implementação do sistema o componente IdAntiFreeze, que melhora o

tempo de resposta de interface do programa enquanto o mesmo

encontra-se realizando alguma comunicação pela rede.

Os componentes Indy podem ser facilmente reconhecidos, pois todos eles

têm seu nome iniciado pelo prefixo Id. No código-fonte do sistema, eles se

encontram inseridos no DataModule e são utilizados pelo objeto Rede para realizar

a comunicação entre as aplicações cliente e servidor.

Sua utilização é bastante simples, porque seus desenvolvedores seguiram o

padrão da Borland em termos de notação e funcionamento. Assim, para tentar

estabelecer conexão com o servidor, deve-se chamar o método Connect (conectar,

em inglês). Se a conexão não for estabelecida, uma exceção será gerada. Os

componentes clientes e servidores também dispoem de eventos que são disparados

quando uma nova conexão é estabelecida ou quando uma requisição é recebida.

Já em termos de funcionamento, as rotinas dos componentes Indy se

assemelham às rotinas de operações de leitura e escrita em arquivos da linguagem

Delphi, uma vez que há comandos para "escrever" (enviar mensagens) e "ler"

(receber respostas) dados através da rede. Sua velocidade nessas operações, no

entanto, pode ser menor, pois depende da velocidade da conexão.

Atualmente, a versão 9 ainda é a versão mais estável dos componentes Indy,

encontrada nas versões mais recentes do Delphi e do C++ Builder, lançadas em

2010. Há uma nova versão dos componentes Indy ainda em desenvolvimento, que

está disponível para várias linguagens de programação além do Delphi, como C#,

C++, Visual Basic.NET e outras linguagens baseadas na plataforma .NET, e ainda

será portada para a linguagem Free Pascal, o equivalente livre do Borland Delphi.

Como o projeto Indy se expandiu e passou a englobar outros projetos menores em

outras áreas, aqueles componentes passaram a ser chamados Indy Sockets, para

diferenciar dos outros projetos pertencentes ao projeto Indy.

Mais informações sobre os componentes Indy podem ser obtidas em

About.com (2010), Cantù (2003), The Indy Project (2010) ou ainda consultando-se a

ajuda do Borland Delphi 7, que é a fonte de informação mais completa e detalhada a

respeito desses componentes.



Microsoft Data Access Components (MDAC)

Alguns sistemas que utilizam bancos de dados são desenvolvidos em torno

de tecnologias em que o mecanismo de acesso ao banco de dados fica embutido na

aplicação, sendo de responsabilidade do programador desenvolver esse

mecanismo. Em outros casos, a aplicação depende que o próprio SGBD execute as

operações de consulta ao banco, como acontece com os sistemas desenvolvidos

utilizando Paradox, Access e Visual FoxPro.

À medida que os aplicativos comerciais foram se tornando mais sofisticados,

os programadores passaram a buscar mecanismos que os dispensassem de

implementar o acesso ao banco de dados e os permitissem dedicar suas horas de

trabalho a desenvolver os recursos específicos de suas aplicações. Tem se tornado

cada vez mais comum a utilização de um mecanismo intermediário entre a aplicação

e o banco de dados, com o objetivo não apenas de simplificar a aplicação, como

também permitir que o acesso aos dados seja feito de forma mais flexível, e o

programa possa se conectar aos mais variados tipos de fontes de dados.

Uma das empresas que ao longo dos anos tem pesquisado e criado várias

tecnologias nesse sentido é a Microsoft. Como parte integrante de seu sistema

operacional, o Windows, ela distribui o Microsoft Data Access Components (MDAC),

que é um framework de tecnologias correlacionadas que permitem aos

programadores desenvolverem aplicações que acessem dados de maneira uniforme

em praticamente qualquer fonte de dados existente. O objetivo de sua utilização é

permitir ao programador focar seu desenvolvimento no acesso aos dados em si, sem

se preocupar com seus pormenores, como o hardware, a arquitetura, o banco de

dados, as rotinas ou programas que são utilizados para promover esse acesso.

O MDAC também é conhecido por Windows Data Access Components

(Windows DAC), por ser distribuído como parte integrante do Windows. As principais

tecnologias que o constituem são as interfaces Open Database Connectivity

(ODBC), OLE DB e ActiveX Data Objects (ADO). Esta seção dedica-se a explicar os

conceitos que as envolvem e como elas foram implementados no sistema.



A interface ODBC, criada em 1992, é uma interface de acesso padrão a

SGBDs. Ela é implementada a nível de sistema operacional, sendo portanto de

baixo nível e alta performance. Possui uma versão própria da linguagem SQL com a

qual um programa pode se comunicar com diferentes aplicações de banco de dados

de forma transparente. Utilizando a interface ODBC, um mesmo programa pode

utilizar, por exemplo, ora o MySQL, ora o Access, ora o SQL Server sem a

necessidade de implementar, para cada um deles, uma rotina de acesso específica.

A utilização da interface ODBC é caracterizada pela interação entre três

componentes:

a) Uma aplicação com suporte a ODBC: é a aplicação que o usuário

visualiza na tela do seu computador, que deve acessar um banco de

dados via ODBC, sendo por isso chamada "cliente ODBC". É fácil

desenvolver aplicações com suporte a ODBC, uma vez que várias

linguagens de programação já trazem rotinas próprias para a utilização

dessa interface, como Delphi, Free Pascal, Visual Basic, entre outras;

b) Um SGBD: é a aplicação de banco de dados ao qual o cliente ODBC será

conectado, sendo por isso chamado "servidor ODBC" ou "fonte de dados

ODBC". Esse componente é invisível ao usuário;

c) Um conector ODBC: é o componente que fará a comunicação entre o

cliente e o servidor ODBC. Esse componente também é invisível ao

usuário.

A comunicação entre esses três componentes acontece da seguinte forma: o

cliente ODBC envia comandos ODBC ao SGBD, solicitando a realização de alguma

operação em determinada base de dados. No entanto, o SGBD não recebe a

solicitação até que o comando seja interpretado pelo seu conector ODBC, que

transformará o comando enviado pelo cliente ODBC em um comando que o SGBD

possa interpretar. Este então recebe a solicitação, realiza o devido processamento, e

responde ao cliente ODBC. A resposta, assim como a requisição, não é feita de

forma direta: a resposta do SGBD passa primeiramente pelo conector ODBC, que a

transformará em uma resposta passível de interpretação pelo cliente ODBC.



A principal limitação da interface ODBC é que ela se aplica apenas a SGBDs

relacionais. Alguns anos após seu lançamento, à medida se intensificou a utilização

de linguagens e bancos de dados orientados a objetos, novas formas de acesso aos

dados se fizeram necessárias. Foi então que, após ter lançado várias tecnologias

que posteriormente foram descontinuadas, a Microsoft lançou em 1996 a OLE DB.

Como sucessora da interface ODBC, a interface OLE DB é muito mais

funcional e geral, pois não impõe nenhuma limitação específica à sintaxe dos

comandos utilizados para realizar a consulta ou à forma dos dados acessados,

exigindo apenas que os mesmos possam ser obtidos em forma de tabelas.

Dessa forma, ela permite não apenas o acesso a bancos de dados, como

também a todos os tipos de dados, estejam eles armazenados em bancos de dados

ou arquivos físicos, como planilhas eletrônicas, por exemplo. Seu funcionamento, no

entanto, é semelhante ao da interface ODBC no sentido de que a aplicação que a

utiliza necessita de um conector para prover sua comunicação com uma fonte de

dados.

O primeiro conector OLE DB desenvolvido foi o Microsoft OLE DB Provider for

ODBC (MSDASQL), que fornece às aplicações desenvolvidas utilizando a interface

OLE DB acesso aos bancos de dados que dispõem de conectores ODBC. A

interface ODBC portanto não foi descontinuada, passando a ser utilizada em

conjunto com a interface OLE DB para conectar aplicações a bancos de dados,

enquanto a utilização exclusiva da OLE DB se tornou reservada a casos mais

complexos, que necessitassem uma maior sofisticação, como acesso a planilhas.

Uma limitação apresentada pela OLE DB, por sua vez, é o fato de ela ainda

ser uma interface de baixo nível, semelhante à interface ODBC. Ela não poderia,

portanto, ser utilizada pelas aplicações web, que começavam naquela época a

emergir no mercado. O surgimento de novas necessidades faz com que surjam

novas tecnologias e foi então que a Microsoft lançou no mesmo ano a interface

ADO, que representa uma abstração de alto nível das fontes de dados que antes

eram acessadas por meio da interface OLE DB.

A partir de então, a interface ADO se tornou, dentre as disponibilizadas pelo

MDAC, a interface definitiva a ser utilizada por qualquer sistema, seja ele desktop ou



web, para se conectar aos bancos de dados, ainda que existam outras interfaces

intermediárias nessa conexão, o que é invisível à aplicação. É possível desenvolver

uma aplicação em linguagens de baixo nível, como o C++, que acessem diretamente

uma fonte de dados via OLE DB ou ODBC, mas não é usual.

Dentre os componentes padrão que acompanham o ambiente de

desenvolvmento Borland Delphi, encontram-se os componentes dbGo, agrupados

na paleta ADO, que fazem uso da interface ADO para prover a comunicação entre

as aplicações nele desenvolvidas e os bancos de dados. Durante a implementação

do sistema, dois desses componentes, o AdoConnection e o AdoQuery, foram

utilizados para promover a comunicação entre as aplicações cliente e servidor e o

banco de dados MySQL através do seu conector ODBC. A Figura 28 ilustra de forma

mais simples e resumida essa comunicação.

A preferência pela utilização dessas tecnologias para realizar a conexão do

sistema com o banco de dados se deu inicialmente não por sua flexibilidade, mas

pela falta de outro mecanismo que conseguisse promover a conexão efetiva do

sistema com a versão mais recente do MySQL. A decisão foi tomada após várias

tentativas de conexão frustradas utilizando tecnologias como a Borland Database

Engine (BDE), os componentes dbExpress, os componentes ZeosLib e do sucesso

obtido com a combinação de ADO e ODBC. Uma pesquisa mais profunda sobre

essas tecnologias acabou por tornar a decisão em utilizá-las definitiva.

Há basicamente três vantagens na comunicação entre aplicação e banco de

dados através das interfaces ADO e ODBC:

a) Os desenvolvedores de aplicativos não precisam se preocupar quanto ao

SGBD que será utilizado pelos usuários de suas aplicações. Qualquer

aplicação com suporte a ODBC pode acessar qualquer SGBD para o qual

exista um conector ODBC. Exemplos de SGBDs que dispõem de

conectores ODBC incluem Access, DB2, Firebird, Informix, MySQL,

Oracle, Paradox, PostgreSQL, SQL Server, SQLBase, entre outros. Se o

usuário necessitar mudar o banco de dados utilizado, basta mudar o

conector utilizado pela sua aplicação para fazer o acesso ao banco;



Figura 28 – Comunicação entre o sistema e o banco de dados através do MDAC

b) Como consequência, os desenvolvedores também não precisam se

preocupar com possíveis atualizações do SGBD utilizado por suas

aplicações: caso o SGBD sofra um atualização e por isso se torne

inacessível à aplicação, basta atualizar o conector ODBC;

c) Finalmente, para o desenvolvedor de bancos de dados, oferecer suporte

à interface ODBC significa facilitar o acesso ao seu produto: lançando um

conector ODBC específico para seu SGBD, ele permitirá que qualquer

aplicação que já possua suporte a ODBC o utilize.

Apesar de não terem sido realizados testes nesse sentido, acredita-se, pelas

informações obtidas durante as pesquisas, que o sistema seja capaz de utilizar

qualquer SGBD desde que seja instalado no sistema operacional um conector

ODBC apropriado para o mesmo.

Mais informações sobre interfaces, fontes de dados e conectores ODBC, OLE

DB e ADO e componentes dbGo podem ser obtidas em About.com (2010), Cantù

(2003), Microsoft (2010) e na ajuda do Borland Delphi 7.


SISTEMA DE GERENCIAMENTO DE MONITORIA

INTERFACE ADO

INTERFACE OLE DBCONECTOR: MSDASQL

INTERFACE ODBCCONECTOR: MYSQL ODBC CONNECTOR

BANCO DE DADOSMYSQL


Funções da API do Windows

Uma Application Programming Interface (API) é um conjunto de

especificações e rotinas que um programa pode seguir para acessar e utilizar

serviços e recursos oferecidos por outro programa, que implementa a API. Ela serve

como uma interface entre diferentes programas e facilita a interação entre os

mesmos da mesma maneira como a interface gráfica facilita a interação entre seres

humanos e computadores.

O sistema operacional Windows é composto pelo núcleo do sistema e por

várias bibliotecas (ou, abreviadamente, DLLs, do inglês Dynamic Link Libraries) que

complementam os recursos desse núcleo. Essas bibliotecas contêm dentro de si

diversas constantes, estruturas de dados, funções e procedimentos que compõem a

chamada API do Windows e podem ser acessadas por qualquer aplicação em

execução sobre o sistema operacional. Na verdade, enquanto estão sendo

executados, os programas fazem chamadas à API do Windows o tempo todo, ainda

que isso seja invisível ao usuário ou ao desenvolvedor.

A maioria dos desenvolvedores certamente desconhece esse fato devido à

utilização do Borland Delphi, que, sendo um ambiente de desenvolvimento

integrado, tem como função facilitar e agilizar o desenvolvimento, e uma de suas

características nesse sentido é dispensar ao desenvolvedor a utilização das funções

da API do Windows para executar tarefas rotineiras: as próprias units que compõem

a linguagem de programação Delphi definem objetos, classes, tipos de dados e

componentes que encapsulam em si os elementos da API do Windows.

Para exibir um form na tela, por exemplo, tudo que o desenvolvedor precisa

codificar no seu programa é a chamada ao método Show do objeto Form, quando na

verdade são necessárias chamadas a diversas funções da API do Windows para

desenhar o form desejado na tela. O que acontece é que esse método encapsula

essas chamadas. Assim, elas são feitas durante a execução do programa de forma

transparente pelo objeto Form.Quando uma aplicação necessita de mais recursos do que os oferecidos pela

linguagem de programação, no entanto, torna-se necessário utilizar as próprias



funções da API do Windows para implementá-los.

As funções mais comuns da API do Windows são declaradas na unit

Windows, que acompanha o ambiente de desenvolvimento Borland Delphi. Assim, o

usuário não precisa saber quais bibliotecas as implementam nem fazer nenhum tipo

de preparação prévia quando necessitar utilizá-las. Uma vez que a unit Windows esteja declarada na cláusula uses do código-fonte do programa, é possível chamar

qualquer função da API do Windows simplesmente invocando seu nome, assim

como é feito com qualquer outra função da própria linguagem de programação.

Outras units que declaram funções da API do Windows são a ShellAPI, a ComObj e a ShlObj.

Se a função desejada não se encontrar declarada em nenhuma dessas units,

será necessário declará-la na unit em que se deseja utilizá-la. Isso pode ser feito

provendo sua declaração na cláusula interface e sua definição externa na

cláusula implementation ou unir ambas em uma só sentença na cláusula

implementation da unit. Uma vez que a função esteja corretamente declarada e

definida, é possível chamá-la simplesmente invocando seu nome, assim como é

feito com qualquer outra função definida dentro do programa.

Todas as funções da API do Windows que foram utilizadas para desenvolver o

Sistema de controle de monitoria foram encapsuladas pelo objeto

SistemaOperacional, cujo código-fonte se encontra dentro da unit

uSistemaOperacional. Os outros componentes do sistema fazem utilização

dessas funções de forma indireta através desse objeto.

Houve uma função da API do Windows que era necessária ao

desenvolvimento do programa e não foi implementada dentro das units do Delphi.

Ela teve que ser implementada dentro da unit uSistemaOperacional. Foi a

CreateProcessWithLogonW, pertencente à biblioteca advapi32.dll. Sua

utilização se deu como explicado acima: sua declaração foi feita na cláusula

interface e sua definição externa na cláusula implementation. Ela é chamada

dentro do método ExecutarComo, cuja finalidade é executar um programa com os

níveis de privilégio de outro usuário do Windows.



Maiores informações a respeito das funções da API do Windows podem ser

obtidas através da análise do código-fonte das units anteriormente citadas, que se

encontram na pasta "Source\Rtl\Win" dentro do diretório onde o Borland Delphi é

instalado, ou consultar a ajuda, que contém informações a respeito de todas as

funções da API do Windows já implementadas pela linguagem de programação

Delphi.

A Microsoft oferece também suporte aos desenvolvedores através do portal

Microsoft Developer Network (MSDN), onde podem ser encontradas documentação

e ferramentas necessárias para desenvolver programas baseados na API do

Windows e em outras tecnologias relacionadas ao sistema.

É importante observar que as funções da API do Windows são sempre

documentadas para as linguagens C ou C++, uma vez que são desenvolvidas

nessas linguagens. Assim, é necessário ter um conhecimento mínimo das estruturas

de dados presentes nessas linguagens antes de procurar informações sobre essas

funções.

Um exemplo disso são as funções que retornam valores lógicos como

resultado de sua execução: se fossem documentadas para a linguagem Delphi, seus

possíveis valores de retorno seriam apenas True ou False, mas como são

documentadas para as linguagens C e C++, outros possíveis valores são 0 e 1, pois

nessas linguagens de programação os valores 0 e 1 são equivalentes a True e

False, respectivamente.



ANEXO A – ESCOLHA DO NOME ARGOS

Figura 29 – Hermes, Argos Panoptes e IoImagem retirada da Internet. Disponível em

<http://mithologywithapurpose.wordpress.com/2007/07/04/argus-panoptes/>. Acesso em 27/12/2010.

[...] Outro episódio de ciúme de Hera foi quando Zeus, por saber que Hera

estava chegando e ele estava com uma de suas amantes (Io), a transforma

rapidamente em uma vaca. Hera, muito desconfiada, pede para Zeus aquela vaca

de presente e Zeus não podendo negar um presente, o dá para sua esposa. Ela

então coloca aquela novilha aos cuidados de Argos, um monstro de muitos olhos,

que ao dormir nunca fechava todos com isso a novilha estava sempre sendo

observada. Mas Zeus ao ver o sofrimento da amante pede para que Hermes mate

Argos. Então, Hermes toca uma música, fazendo Argos dormir completamente,

fechando todos os olhos. Após isso, Hermes arranca-lhe a cabeça.

Hera muito triste pelo acontecimento, pega todos os olhos e coloca na cauda

de seu pavão, onde eles estão até hoje. [...] (Texto retirado da Internet. Disponível

em: <http://www.infoescola.com/mitologia-grega/hera/> Acesso em 27/12/2010)



ANEXO B – LICENÇA PÚBLICA GERAL DO GNU (GPL)

This is an unofficial translation of the GNU General Public License into Portuguese.

It was not published by the Free Software Foundation, and does not legally state the

distribution terms for software that uses the GNU GPL--only the original English text

of the GNU GPL does that. However, we hope that this translation will help

Portuguese speakers understand the GNU GPL better.

Esta é uma tradução não-oficial da GNU General Public License para o Português.

Ela não é publicada pela Free Software Foundation e não traz os termos de

distribuição legal do software que usa a GNU GPL – estes termos estão contidos

apenas no texto da GNU GPL original em inglês. No entanto, esperamos que esta

tradução ajudará no melhor entendimento da GNU GPL em Português.

Versão 2, Junho de 1991 Direitos Autorais Reservados © 1989, 1991 Free Software

Foundation, Inc. 59 Temple Place, Suite [conjunto] 330, Boston, MA [Massachusetts]

02111-1307 USA [Estados Unidos da América]

É permitido a qualquer pessoa copiar e distribuir cópias sem alterações deste

documento de licença, sendo vedada, entretanto, qualquer modificação.

Introdução

As licenças da maioria dos softwares são elaboradas para suprimir sua

liberdade de compartilhá-los e modificá-los. A Licença Pública Geral do GNU, ao

contrário, visa garantir sua liberdade de compartilhar e modificar softwares livres

para assegurar que o software seja livre para todos os seus usuários. Esta Licença

Pública Geral é aplicável à maioria dos softwares da Free Software Foundation

[Fundação do Software Livre] e a qualquer outro programa cujos autores se



comprometerem a usá-la. (Em vez dela, alguns outros softwares da Free Software

Foundation são cobertos pela Licença Pública Geral de Biblioteca do GNU). Você

também poderá aplicá-la aos seus programas.

Quando falamos de software livre, estamos nos referindo à liberdade, não ao

preço. Nossas Licenças Públicas Gerais visam garantir que você tenha a liberdade

de distribuir cópias de software livre (e cobrar por isso se desejar), que receba

código-fonte ou possa obtê-lo se desejar, que possa modificá-lo ou usar partes dele

em novos programas livres; finalmente, que você tenha ciência de que pode fazer

tudo isso.

Para proteger seus direitos, necessitamos fazer restrições que proíbem que

alguém negue esses direitos a você ou que solicite que você renuncie a eles. Essas

restrições se traduzem em determinadas responsabilidades que você deverá

assumir, se for distribuir cópias do software ou modificá-lo.

Por exemplo, se você distribuir cópias de algum desses programas, tanto

gratuitamente como mediante uma taxa, você terá de conceder aos receptores todos

os direitos que você possui. Você terá de garantir que, também eles, recebam ou

possam obter o código-fonte. E você terá a obrigação de exibir a eles esses termos,

para que eles conheçam seus direitos.

Protegemos seus direitos através de dois passos: (1) estabelecendo direitos

autorais sobre o software e (2) concedendo a você esta licença, que dá permissão

legal para copiar, distribuir e/ou modificar o software.

Além disso, para a proteção de cada autor e a nossa, queremos ter certeza

de que todos entendam que não há nenhuma garantia para este software livre. Se o

software for modificado por alguém e passado adiante, queremos que seus

receptores saibam que o que receberam não é o original, de forma que quaisquer

problemas introduzidos por terceiros não afetem as reputações dos autores

originais.

Finalmente, qualquer programa livre é constantemente ameaçado por

patentes de software. Queremos evitar o risco de que redistribuidores de um

programa livre obtenham individualmente licenças sob uma patente, tornando o

programa, com efeito, proprietário. Para impedir isso, deixamos claro que qualquer



patente deve ser licenciada para o uso livre por parte de qualquer pessoa ou, então,

simplesmente não deve ser licenciada.

Os exatos termos e condições para cópia, distribuição e modificação seguem

abaixo.

Termos e condições para cópia, distribuição e modificação

0. Esta Licença se aplica a qualquer programa ou outra obra que contenha

um aviso inserido pelo respectivo titular dos direitos autorais, informando

que a referida obra pode ser distribuída em conformidade com os termos

desta Licença Pública Geral. O termo "Programa", utilizado abaixo, refere-

se a qualquer programa ou obra, e o termo "obras baseadas no

Programa" significa tanto o Programa, como qualquer obra derivada nos

termos da legislação de direitos autorais: isto é, uma obra contendo o

Programa ou uma parte dele, tanto de forma idêntica como com

modificações, e/ou traduzida para outra linguagem. (Doravante, o termo

"modificação" inclui também, sem reservas, a tradução). Cada licenciado,

doravante, será denominado "você".

Outras atividades que não a cópia, distribuição e modificação, não são

cobertas por esta Licença; elas estão fora de seu escopo. O ato de

executar o Programa não tem restrições e o resultado gerado a partir do

Programa encontra-se coberto somente se seu conteúdo constituir uma

obra baseada no Programa (independente de ter sido produzida pela

execução do Programa). Na verdade, isto dependerá daquilo que o

Programa faz.

1. Você poderá fazer cópias idênticas do código-fonte do Programa ao

recebê-lo e distribui-las, em qualquer mídia ou meio, desde que publique,

de forma ostensiva e adequada, em cada cópia, um aviso de direitos

autorais (ou copyright) apropriado e uma notificação sobre a exoneração

de garantia; mantenha intactas as informações, avisos ou notificações



referentes a esta Licença e à ausência de qualquer garantia; e forneça a

quaisquer outros receptores do Programa uma cópia desta Licença junto

com o Programa.

Você poderá cobrar um valor pelo ato físico de transferir uma cópia, e

você pode oferecer, se quiser, a proteção de uma garantia em troca de

um valor.

2. Você poderá modificar sua cópia ou cópias do Programa ou qualquer

parte dele, formando, dessa forma, uma obra baseada no Programa, bem

como copiar e distribuir essas modificações ou obra, de acordo com os

termos da Cláusula 1 acima, desde que você também atenda a todas as

seguintes condições:

a) Você deve fazer com que os arquivos modificados contenham avisos,

em destaque, informando que você modificou os arquivos, bem como

a data de qualquer modificação.

b) Você deve fazer com que qualquer obra que você distribuir ou

publicar, que no todo ou em parte contenha o Programa ou seja dele

derivada, ou derivada de qualquer parte dele, seja licenciada como

um todo sem qualquer custo para todos terceiros nos termos desta

licença.

c) Se o programa modificado normalmente lê comandos interativamente

quando executado, você deverá fazer com que ele, ao começar a ser

executado para esse uso interativo em sua forma mais simples,

imprima ou exiba um aviso incluindo o aviso de direitos autorais (ou

copyright) apropriado, além de uma notificação de que não há

garantia (ou, então, informando que você oferece garantia) e

informando que os usuários poderão redistribuir o programa de

acordo com essas condições, esclarecendo ao usuário como

visualizar uma cópia desta Licença. (Exceção: se o Programa em si

for interativo mas não imprimir normalmente avisos como esses, não

é obrigatório que a sua obra baseada no Programa imprima um

aviso).



Essas exigências se aplicam à obra modificada como um todo. Se

partes identificáveis dessa obra não forem derivadas do Programa e

puderem ser consideradas razoavelmente como obras independentes

e separadas por si próprias, nesse caso, esta Licença e seus termos

não se aplicarão a essas partes quando você distribui-las como obras

separadas. Todavia, quando você distribui-las como parte de um todo

que constitui uma obra baseada no Programa, a distribuição deste

todo terá de ser realizada em conformidade com esta Licença, cujas

permissões para outros licenciados se estenderão à obra por

completo e, conseqüentemente, a toda e qualquer parte,

independentemente de quem a escreveu.

Portanto, esta cláusula não tem a intenção de afirmar direitos ou

contestar os seus direitos sobre uma obra escrita inteiramente por

você; a intenção é, antes, de exercer o direito de controlar a

distribuição de obras derivadas ou obras coletivas baseadas no

Programa.

d) Além do mais, a simples agregação de outra obra que não seja

baseada no Programa a ele (ou a uma obra baseada no Programa)

em um volume de mídia ou meio de armazenamento ou distribuição,

não inclui esta outra obra no âmbito desta Licença.

3. Você poderá copiar e distribuir o Programa (ou uma obra baseada nele,

de acordo com a Cláusula 2) em código-objeto ou formato executável de

acordo com os termos das Cláusulas 1 e 2 acima, desde que você

também tome uma das providências seguintes:

a) Incluir o código-fonte correspondente completo, passível de leitura

pela máquina, o qual terá de ser distribuído de acordo com as

Cláusulas 1 e 2 acima, em um meio ou mídia habitualmente usado

para intercâmbio de software; ou,

b) Incluir uma oferta por escrito, válida por pelo menos três anos, para

fornecer a qualquer terceiro, por um custo que não seja superior ao

seu custo de fisicamente realizar a distribuição da fonte, uma cópia



completa passível de leitura pela máquina, do código-fonte

correspondente, a ser distribuído de acordo com as Cláusulas 1 e 2

acima, em um meio ou mídia habitualmente usado para intercâmbio

de software; ou,

c) Incluir as informações recebidas por você, quanto à oferta para

distribuir o código-fonte correspondente. (Esta alternativa é permitida

somente para distribuição não-comercial e apenas se você tiver

recebido o programa em código-objeto ou formato executável com

essa oferta, de acordo com a letra b, acima).

O código-fonte de uma obra significa o formato preferencial da obra

para que sejam feitas modificações na mesma. Para uma obra

executável, o código-fonte completo significa o código-fonte inteiro de

todos os módulos que ela contiver, mais quaisquer arquivos de

definição de interface associados, além dos scripts usados para

controlar a compilação e instalação do executável. Entretanto, como

uma exceção especial, o código-fonte distribuído não precisa incluir

nada que não seja normalmente distribuído (tanto no formato fonte

como no binário) com os componentes principais (compilador, kernel e

assim por diante) do sistema operacional no qual o executável é

executado, a menos que este componente em si acompanhe o

executável.

Se a distribuição do executável ou código-objeto for feita mediante a

permissão de acesso para copiar, a partir de um local designado,

então, a permissão de acesso equivalente para copiar o código-fonte

a partir do mesmo local será considerada como distribuição do

código-fonte, mesmo que os terceiros não sejam levados a copiar a

fonte junto com o código-objeto.

4. Você não poderá copiar, modificar, sublicenciar ou distribuir o Programa,

exceto conforme expressamente estabelecido nesta Licença. Qualquer

tentativa de, de outro modo, copiar, modificar, sublicenciar ou distribuir o

Programa será inválida, e automaticamente rescindirá seus direitos sob



esta Licença. Entretanto, terceiros que tiverem recebido cópias ou direitos

de você de acordo esta Licença não terão suas licenças rescindidas,

enquanto estes terceiros mantiverem o seu pleno cumprimento.

5. Você não é obrigado a aceitar esta Licença, uma vez que você não a

assinou. Porém, nada mais concede a você permissão para modificar ou

distribuir o Programa ou respectivas obras derivativas. Tais atos são

proibidos por lei se você não aceitar esta Licença. Conseqüentemente, ao

modificar ou distribuir o Programa (ou qualquer obra baseada no

Programa), você estará manifestando sua aceitação desta Licença para

fazê-lo, bem como de todos os seus termos e condições para copiar,

distribuir ou modificar o Programa ou obras nele baseadas.

6. Cada vez que você redistribuir o Programa (ou obra baseada no

Programa), o receptor receberá, automaticamente, uma licença do

licenciante original, para copiar, distribuir ou modificar o Programa, sujeito

a estes termos e condições. Você não poderá impor quaisquer restrições

adicionais ao exercício, pelos receptores, dos direitos concedidos por este

instrumento. Você não tem responsabilidade de promover o cumprimento

por parte de terceiros desta licença.

7. Se, como resultado de uma sentença judicial ou alegação de violação de

patente, ou por qualquer outro motivo (não restrito às questões de

patentes), forem impostas a você condições (tanto através de mandado

judicial, contrato ou qualquer outra forma) que contradigam as condições

desta Licença, você não estará desobrigado quanto às condições desta

Licença. Se você não puder atuar como distribuidor de modo a satisfazer

simultaneamente suas obrigações sob esta licença e quaisquer outras

obrigações pertinentes, então, como conseqüência, você não poderá

distribuir o Programa de nenhuma forma. Por exemplo, se uma licença

sob uma patente não permite a redistribuição por parte de todos aqueles

que tiverem recebido cópias, direta ou indiretamente de você, sem o

pagamento de royalties, então, a única forma de cumprir tanto com esta

exigência quanto com esta licença será deixar de distribuir, por completo,



o Programa.

Se qualquer parte desta Cláusula for considerada inválida ou não

executável, sob qualquer circunstância específica, o restante da cláusula

deverá continuar a ser aplicado e a cláusula, como um todo, deverá ser

aplicada em outras circunstâncias.

Esta cláusula não tem a finalidade de induzir você a infringir quaisquer

patentes ou direitos de propriedade, nem de contestar a validade de

quaisquer reivindicações deste tipo; a única finalidade desta cláusula é

proteger a integridade do sistema de distribuição do software livre, o qual

é implementado mediante práticas de licenças públicas. Muitas pessoas

têm feito generosas contribuições à ampla gama de software distribuído

através desse sistema, confiando na aplicação consistente deste sistema;

cabe ao autor/doador decidir se deseja distribuir software através de

qualquer outro sistema e um licenciado não pode impor esta escolha.

Esta cláusula visa deixar absolutamente claro o que se acredita ser uma

conseqüência do restante desta Licença.

8. Se a distribuição e/ou uso do Programa for restrito em determinados

países, tanto por patentes ou por interfaces protegidas por direito autoral,

o titular original dos direitos autorais que colocar o Programa sob esta

Licença poderá acrescentar uma limitação geográfica de distribuição

explícita excluindo esses países, de modo que a distribuição seja

permitida somente nos países ou entre os países que não foram

excluídos dessa forma. Nesse caso, esta Licença passa a incorporar a

limitação como se esta tivesse sido escrita no corpo desta Licença.

9. A Free Software Foundation poderá de tempos em tempos publicar novas

versões e/ou versões revisadas da Licença Pública Geral. Essas novas

versões serão semelhantes em espírito à presente versão, mas podem

diferenciar-se, porém, em detalhe, para tratar de novos problemas ou

preocupações.

Cada versão recebe um número de versão distinto. Se o Programa

especificar um número de versão desta Licença que se aplique a ela e a



"qualquer versão posterior", você terá a opção de seguir os termos e

condições tanto daquela versão como de qualquer versão posterior

publicada pela Free Software Foundation. Se o Programa não especificar

um número de versão desta Licença, você poderá escolher qualquer

versão já publicada pela Free Software Foundation.

10. Se você desejar incorporar partes do Programa em outros programas

livres cujas condições de distribuição sejam diferentes, escreva ao autor

solicitando a respectiva permissão. Para software cujos direitos autorais

sejam da Free Software Foundation, escreva para ela; algumas vezes,

abrimos exceções para isso. Nossa decisão será guiada pelos dois

objetivos de preservar a condição livre de todos os derivados de nosso

software livre e de promover o compartilhamento e reutilização de

software, de modo geral.

Exclusão de garantia

11. COMO O PROGRAMA É LICENCIADO SEM CUSTO, NÃO HÁ

NENHUMA GARANTIA PARA O PROGRAMA, NO LIMITE PERMITIDO

PELA LEI APLICÁVEL. EXCETO QUANDO DE OUTRA FORMA

ESTABELECIDO POR ESCRITO, OS TITULARES DOS DIREITOS

AUTORAIS E/OU OUTRAS PARTES, FORNECEM O PROGRAMA "NO

ESTADO EM QUE SE ENCONTRA", SEM NENHUMA GARANTIA DE

QUALQUER TIPO, TANTO EXPRESSA COMO IMPLÍCITA, INCLUINDO,

DENTRE OUTRAS, AS GARANTIAS IMPLÍCITAS DE

COMERCIABILIDADE E ADEQUAÇÃO A UMA FINALIDADE

ESPECÍFICA. O RISCO INTEGRAL QUANTO À QUALIDADE E

DESEMPENHO DO PROGRAMA É ASSUMIDO POR VOCÊ. CASO O

PROGRAMA CONTENHA DEFEITOS, VOCÊ ARCARÁ COM OS

CUSTOS DE TODOS OS SERVIÇOS, REPAROS OU CORREÇÕES

NECESSÁRIAS.



12. EM NENHUMA CIRCUNSTÂNCIA, A MENOS QUE EXIGIDO PELA LEI

APLICÁVEL OU ACORDADO POR ESCRITO, QUALQUER TITULAR DE

DIREITOS AUTORAIS OU QUALQUER OUTRA PARTE QUE POSSA

MODIFICAR E/OU REDISTRIBUIR O PROGRAMA, CONFORME

PERMITIDO ACIMA, SERÁ RESPONSÁVEL PARA COM VOCÊ POR

DANOS, INCLUINDO ENTRE OUTROS, QUAISQUER DANOS GERAIS,

ESPECIAIS, FORTUITOS OU EMERGENTES, ADVINDOS DO USO OU

IMPOSSIBILIDADE DE USO DO PROGRAMA (INCLUINDO, ENTRE

OUTROS, PERDAS DE DADOS OU DADOS SENDO GERADOS DE

FORMA IMPRECISA, PERDAS SOFRIDAS POR VOCÊ OU TERCEIROS

OU A IMPOSSIBILIDADE DO PROGRAMA DE OPERAR COM

QUAISQUER OUTROS PROGRAMAS), MESMO QUE ESSE TITULAR,

OU OUTRA PARTE, TENHA SIDO ALERTADA SOBRE A

POSSIBILIDADE DE OCORRÊNCIA DESSES DANOS.


INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE...

Documents

Transcript of INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE...