relatorio 07-07-06.doc

PROTOREG – Programa piloto de registo de intoxicações alimentares

Biostrument, Lda

2005 / 2006

1020515 - Daniel Nogueira

Departamento de Engenharia Informática



Biostrument, Lda

2005 / 2006

1020515 – Daniel Nogueira

Departamento de Engenharia InformáticaJunho de 2006

Orientador ISEP: Constantino Martins

Supervisor Externo: Luís Meireles

Daniel Nogueira 3


À minha família, namorada e amigos

Daniel Nogueira v


Agradecimentos

Gostaria de agradecer a todas as pessoas que, de alguma forma

deram o seu contributo à realização do projecto.

Em especial:

- Ao Eng. Constantino Martins por ter aceite ser meu orientador de

estágio, e por todo o apoio prestado.

- Ao Dr. Luís Meireles pela oportunidade de estágio e por todo o

apoio na realização do projecto

- Ao meu colega de estágio Ivo Pereira, pelo conhecimentos

trocados e esclarecimentos de duvidas.

-Aos meus pais e irmãos pelo apoio nos momentos mais difíceis,

pois sem eles não teria chegado aqui.

-À minha tia e primas por todo o apoio.

-À minha namorada por toda a compreensão.

A todos o meu muito obrigado.

Amarante,

Daniel Nogueira

Daniel Nogueira vii

viii


Resumo

As toxinfecções alimentares são um problema de saúde pública a

nível nacional e europeu. Torna-se assim necessário um sistema de

registo destes casos para dar uma noção mais concreta do problema.

Para isso será criada uma plataforma para armazenamento e

tratamento dos dados, e um site de publicação dos mesmos.

Este relatório apresenta todo o processo de análise de

desenvolvimento deste projecto.

Numa primeira fase foram analisados todos os requisitos do sistema e

foi desenvolvida a base de dados para suportar toda a informação.

O site foi implementado em PHP, HTML, Ajax e XML. O PHP

juntamente com o HTML permitiram a criação dinâmica das páginas,

enquanto que o Ajax e XML foram úteis para fazer algumas

comunicações rápidas entre o cliente e o servidor sem a necessidade

a refrescamento das páginas.

Foram desenvolvidos vários módulos de funcionamento do site. Entre

eles salientam-se os mais importantes:

Zona de importação e tratamento de dados recebidos dos

hospitais; a esta secção apenas os administradores têm acesso.

Zona de publicação dos dados tratados, aos quais têm acesso

todos os indivíduos que visitem o site e depois de se registarem

gratuitamente. Esta parte terá gráficos estatísticos que de uma

forma intuitiva dão a conhecer a realidade deste problema que

são as intoxicações alimentares.

Zona de noticias, onde periodicamente serão publicadas novas

noticias relativas ao problema em questão;

Zona de registo para os utilizadores se registarem e terem

acesso à zona de publicação dos dados e à zona de noticias.

Daniel Nogueira ix


Actualmente o projecto já se encontra operacional, sendo que a

empresa ficou bastante satisfeita com o resultado final.

Palavras Chave (Tema): Intoxicações alimentares, hospitais,

ASAE

Palavras Chave (Tecnologias): Ajax, php, mysql, JavaScript

Daniel Nogueira x


Abstract

The food intoxications represent a national and European strong

public health problem. So it’s necessary to create a record system of

these cases in order to give a more solid perception of the problem. In

such a way, it will be shaped a storage proposal and data

management and a publication site for the same ones.

This report presents all the analysis process of development of this

project.

In a first stage all the system requirements were analyzed and the

database was developed to support all the information.

The site was applied in PHP, HTML, AJAX and XML. The PHP and HTML

had been used to the dynamic creation of the pages, while the Ajax

and the HTML had been used to do some fast communications

between the client and the server without need to refresh the page.

Some functioning modules of the site had been developed and the

most important are:

Importation area and data management received from the hospitals;

only the administrators have access to the restricted area.

Publication area of the treated data, where everybody can access to

the site after their free registration; this part will have statistical

graphs that will give us the knowledge to the reality of food

intoxications.

News area, where it will be published regularly the news about the

issue itself.

Daniel Nogueira xi


Registration area, where the users can be able to make their

registration and have all the access to the data publication and the

news area.

Nowadays the project is fully operational, which brings a lot of satisfaction to the company.

Daniel Nogueira xii


Índice

AGRADECIMENTOS............................................................................................................................VII

RESUMO...................................................................................................................................................IX

ABSTRACT...............................................................................................................................................XI

ÍNDICE...................................................................................................................................................XIII

ÍNDICE DE FIGURAS..........................................................................................................................XVI

ÍNDICE DE TABELAS......................................................................................................................XVIII

ÍNDICE DE EXTRACTOS DE CÓDIGO...........................................................................................XIX

1 INTRODUÇÃO..................................................................................................................................1

1.1 ENQUADRAMENTO......................................................................................................................1

1.2 APRESENTAÇÃO DO PROJECTO/ESTÁGIO.....................................................................................1

1.2.1 Objectivo................................................................................................................................2

1.2.2 Resultados previstos..............................................................................................................3

1.2.3 Planeamento de projecto.......................................................................................................3

1.2.4 Reuniões de acompanhamento...............................................................................................4

2 TECNOLOGIAS UTILIZADAS......................................................................................................6

2.1 HTML.........................................................................................................................................7

2.2 CSS.............................................................................................................................................7

2.3 JAVASCRIPT................................................................................................................................8

2.4 PHP.............................................................................................................................................8

2.5 APACHE.......................................................................................................................................9

2.6 MYSQL....................................................................................................................................10

2.7 JPGRAPH.................................................................................................................................10

2.8 XML.........................................................................................................................................12

2.9 AJAX........................................................................................................................................13

3 AJAX.................................................................................................................................................15

3.1 APARECIMENTO DO AJAX.........................................................................................................15

3.2 TECNOLOGIAS BASE..................................................................................................................18

HTML........................................................................................................................................18

DOM (Document Object Model)..............................................................................................18

XML..........................................................................................................................................18

XMLHttpRequest......................................................................................................................18

JavaScript.................................................................................................................................18

3.3 FUNCIONAMENTO CLÁSSICO DE UMA APLICAÇÃO WEB............................................................19

Daniel Nogueira xiii


3.4 FUNCIONAMENTO DE UMA APLICAÇÃO WEB USANDO AJAX.....................................................19

3.5 CLASSE SACK............................................................................................................................20

3.6 VANTAGENS E DESVANTAGENS................................................................................................22

Vantagens.................................................................................................................................22

Usabilidade...............................................................................................................................23

Tempos de espera mais curtos..................................................................................................23

Validações automáticas na submissão de formulários.............................................................23

Completação automática de campos........................................................................................23

Manipulação de dados altamente interactiva..........................................................................24

Navegação em estruturas em árvore profundas.......................................................................24

Interacção do utilizador com o site..........................................................................................25

Desempenho e compatibilidade................................................................................................25

Desvantagens............................................................................................................................25

Usabilidade...............................................................................................................................26

Implementação..........................................................................................................................27

Dispositivos Móveis..................................................................................................................28

3.7 CONCLUSÃO..............................................................................................................................28

4 ANÁLISE E ESTRUTURA DE DADOS.......................................................................................30

4.1 REQUISITOS DO SISTEMA...........................................................................................................30

4.2 MODELO DE DADOS...................................................................................................................30

4.2.1 Esquema da base de dados..................................................................................................32

4.2.2 Tabelas.................................................................................................................................33

1. Agentes................................................................................................................................................33

2. Antecedentes........................................................................................................................................33

3. Protoreg................................................................................................................................................34

4. proto_agentes.......................................................................................................................................36

5. Proto_ag_ident.....................................................................................................................................37

6. Proto_sintomas.....................................................................................................................................37

7. Proto_antecedentes...............................................................................................................................37

8. Proto_diario..........................................................................................................................................38

9. Proto_diag_base...................................................................................................................................38

10. Proto_trata............................................................................................................................................39

11. Proto_rast_comp_sint..........................................................................................................................39

12. Proto_analises......................................................................................................................................40

13. Faixa_etaria..........................................................................................................................................40

14. Noticia..................................................................................................................................................41

15. Visitas..................................................................................................................................................42

16. Utilizador.............................................................................................................................................42

Daniel Nogueira xiv


4.2.3 Sistema de autenticação.......................................................................................................43

4.3 CONCLUSÃO..............................................................................................................................44

5 PROTÓTIPOS..................................................................................................................................46

5.1 CONCLUSÃO..............................................................................................................................48

6 APLICAÇÃO FINAL....................................................................................................................49

6.1 ESTRUTURA DO SITE E FUNCIONAMENTO GERAL...................................................................49

6.2 ESTRUTURA DE FICHEIROS........................................................................................................52

6.3 FICHEIRO DE CONFIGURAÇÃO...................................................................................................53

6.4 SISTEMA DE AUTENTICAÇÃO.....................................................................................................55

6.4.1 Do lado do cliente................................................................................................................55

6.4.2 Do lado do servidor.............................................................................................................56

6.5 ADMINISTRAÇÃO.......................................................................................................................57

6.5.1 Importação de dados...........................................................................................................58

6.5.2 Inserir comentários nos registos.........................................................................................59

6.5.3 Tratamento de dados...........................................................................................................60

6.6 CONTADOR DE VISITAS.............................................................................................................69

6.7 ESTATÍSTICAS............................................................................................................................70

6.7.1 Estrutura da zona de estatística...........................................................................................74

6.7.2 Criação dos gráficos............................................................................................................74

6.7.3 Explicação do código...........................................................................................................76

6.8 NOTÍCIAS...................................................................................................................................81

6.8.1 Inserir notícias.....................................................................................................................84

6.9 REGISTO....................................................................................................................................91

6.10 CONCLUSÃO..............................................................................................................................98

7 CONCLUSÃO..................................................................................................................................99

7.1 OBJECTIVOS ATINGIDOS............................................................................................................99

7.2 MELHORAMENTOS POSSÍVEIS E TRABALHO FUTURO.................................................................99

7.3 DIFICULDADES ENCONTRADAS...............................................................................................100

7.4 CONHECIMENTOS ADQUIRIDOS...............................................................................................100

7.5 APRECIAÇÃO FINAL.................................................................................................................101

8 BIBLIOGRAFIA............................................................................................................................102

9 Anexos..............................................................................................................................................104

Daniel Nogueira xv


Índice de figuras

Figura 1 - Arquitectura do PHP [9]........................................................9

Figura 2 - Configurar biblioteca GD [4]...............................................11

Figura 3 – Configurar biblioteca GD [4]..............................................11

Figura 4 – Compilar PHP com GD [4]..................................................12

Figura 5 – Exemplo XML.....................................................................13

Figura 6 – Funcionamento clássico de uma aplicação web [6]...........19

Figura 7 – Funcionamento de uma aplicação web usando Ajax [6]....19

Figura 8 – Esquema da base de dados...............................................32

Figura 9 – Diagrama de actividade – autenticação.............................44

Figura 10 – Primeira versão do protótipo do site................................46

Figura 11 – Maqueta do site com base na Figura 10..........................47

Figura 12 – Layout final do site...........................................................48

Figura 13 – Estrutura de ficheiros.......................................................52

Figura 14 – Zona de Administração....................................................58

Figura 15 – Formato CSV dos dados recebidos...................................58

Figura 16 – Pop-up para importação dos dados.................................59

Figura 17 – Inserir comentário............................................................60

Figura 18 – Comentário inserido.........................................................60

Figura 19 – Pop-up para edição/inserção de dados............................61

Figura 20 – Inserção de sintomas e antecedentes.............................62

Figura 21 – Inserção de agentes.........................................................62

Figura 22 – Gráfico de totais presumíveis..........................................71

Figura 23 – Gráfico de totais presumíveis por sexo............................71

Figura 24 – Gráfico de totais presumíveis por faixa etária.................72

Figura 25 – Gráficos entre duas datas................................................72

Figura 26 – Gráficos personalizados...................................................72

Figura 27 – Personalização de gráficos...............................................73

Figura 28 – Pré-visualização dos gráficos para imprimir....................74

Figura 29 – Zona de notícias..............................................................81

Figura 30 – Visualização de uma notícia.............................................82

Figura 31 – Pesquisando por palavra-chave.......................................83

Daniel Nogueira xvi


Figura 32 – Zona de inserção de notícias...........................................84

Figura 33 – Popup para abrir notícia...................................................89

Figura 34 – Zona de registo................................................................91

Figura 35 – Mensagem de email já registado.....................................92

Figura 36 – Div com estado do pedido...............................................95

Figura 37 – Mensagem de erro ao registar.........................................97

Figura 38 – Mensagem de sucesso do registo....................................97

Daniel Nogueira xvii


Índice de tabelas

Tabela 1 – Planeamento do projecto....................................................3

Tabela 2 – Tabela Agentes.................................................................33

Tabela 3 – Tabela Agentes.................................................................33

Tabela 4 – Tabela Protoreg.................................................................35

Tabela 5 - Tabela proto_agentes........................................................36

Tabela 6 – Tabela proto_ag_ident.......................................................37

Tabela 7 – Tabela proto_sintomas......................................................37

Tabela 8 – Tabela proto_antecedentes...............................................37

Tabela 9 – Tabela proto_diario...........................................................38

Tabela 10 – Tabela proto_diag_base..................................................38

Tabela 11 – Tabela proto_trata...........................................................39

Tabela 12 – Tabela proto_rast_comp_sint...........................................39

Tabela 13 – Tabela proto_analises......................................................40

Tabela 14 – Tabela faixa_etaria..........................................................41

Tabela 15 – Tabela noticia..................................................................41

Tabela 16 – Tabela visitas..................................................................42

Tabela 17 – Tabela utilizador..............................................................43

Tabela 18 – View totaispres................................................................75

Tabela 19 – View pfe_2.......................................................................75

Tabela 20 – View sexopordia..............................................................76

Daniel Nogueira xviii


Índice de extractos de código

Extracto 1 – Exemplo de utilização da classe Sack............................21

Extracto 2 – Estrutura do site.............................................................50

Extracto 3 – Função que efectua o pedido das páginas por Ajax.......51

Extracto 4 – Ficheiro de Configuração................................................53

Extracto 5 – Módulo de inclusão do ficheiro de configuração.............54

Extracto 6 – Função validaLogin.........................................................55

Extracto 7 – Valida login do lado do servidor.....................................57

Extracto 8 – Função doit.....................................................................63

Extracto 9 – Primeira parte do script ‘insert_saa.php’........................65

Extracto 10 – Segunda parte do script ‘insert_saa.php’.....................66

Extracto 11 – Resposta XML (Repetido)..............................................66

Extracto 12 – Resposta XML (Inserido)...............................................67

Extracto 13 – Resposta XML (Erro).....................................................67

Extracto 14 – Função executada quando o pedido é completado......67

Extracto 15 – Primeira parte da função newCampo...........................68

Extracto 16 – Segunda parte da função newCampo...........................69

Extracto 17 – Chamada da função incrementa_visitas.......................69

Extracto 18 – Função incrementa_visitas...........................................70

Extracto 19 – Incluindo ficheiros.........................................................76

Extracto 20 – Definindo títulos e nome dos meses.............................76

Extracto 21 – Verificação de Variáveis...............................................77

Extracto 22 – Continuação do extracto anterior.................................78




Extracto 26 - Função que comunica com o servidor para tratar

notícias...............................................................................................85

Extracto 27 – Extracto da verificação da acção no servidor...............86

Extracto 28 – Função que escreve a resposta XML no servidor..........86

Extracto 29 – Função que trata a resposta XML recebida do servidor87

Extracto 30 – Variáveis de controlo....................................................87

Daniel Nogueira xix


Extracto 31 – Variáveis temporárias de controlo................................88

Extracto 32 – Continuação da função trataResposta..........................88

Extracto 33 – Utilizando a API do FCKEditor.......................................89

Extracto 34 – Função abrir..................................................................90

Extracto 35 – Função abrir (no ficheiro abrir_noticia.js).....................90

Extracto 36 – Resposta XML do servidor............................................90

Extracto 37 – Função para validar email............................................92

Extracto 38 – Variáveis globais...........................................................93

Extracto 39 – Função para criar o objecto XMLHttpRequest...............93

Extracto 40 – Função que faz a comunicação com o servidor............94

Extracto 41 – Função handleHttpResponse........................................95

Extracto 42 – Código no servidor que verifica se o email já está

registado............................................................................................96

Extracto 43 – Função para gerar a password.....................................98

Extracto 44 – Gerar email a enviar.....................................................98

Extracto 45 - Classe Sack (Parte 1)..................................................105





Daniel Nogueira xx


1 Introdução

Neste capítulo pode encontrar uma breve apresentação do projecto e

da empresa, o enquadramento, os objectivos do trabalho e os

resultados previstos. Assim como o planeamento do projecto.

1.1 Enquadramento

A Biostrument enquadra-se na área das novas tecnologias,

estabelecendo sinergias entre o conhecimento científico académico e

as empresas.

O principal objectivo da Biostrument é o de desenvolver, propor e

implementar soluções tecnologicamente eficazes para problemas

reais das empresas.

Pretende ser o interlocutor activo entre as empresas e o meio

científico, promovendo a rápida e eficaz transferência do know-how

adquirido.

A Biostrument proporciona o acesso a tecnologias de ponta na

implementação e/ou automatização de processos nas áreas da

química, bioquímica e biotecnologia e dá apoio científico directo às

empresas de modo a optimizar recursos e valorizar os seus índices

tecnológicos, colocando-as na vanguarda da tecnologia a nível de

mercado europeu.

1.2 Apresentação do projecto/estágio

As toxinfecções alimentares são um problema de saúde pública a

nível nacional e europeu. Existem várias razões e diversas fontes para

os níveis de incidência destas infecções, nomeadamente o incorrecto

manuseamento e preparação, acondicionamento, distribuição, etc.

dos alimentos ao longo da cadeia alimentar. Os microrganismos

causadores de intoxicações alimentares possuem normalmente

características muito distintas originando em muitos dos casos um

quadro clínico tipificado mas com consequências muito diversas.

Daniel Nogueira 1


A inexistência de um mecanismo de registo sistemático destes casos

não permite neste momento elaborar estatísticas nacionais do

número de casos e suas consequências dificultando por um lado a

elaboração de planos de prevenção e por outro a validação e da

eficácia dos mesmos. Para a criação e implementação de sistemas

eficazes de higiene e segurança alimentar é fundamental a avaliação

dos riscos, nomeadamente riscos de contaminação microbiológica

e/ou química. Deste modo, é necessário, que existam estudos que

permitam avaliar correctamente os riscos associados aos vários

produtos alimentares de forma a criar mecanismos de prevenção

adequados que possam ser correctamente implementados.

A falta de documentação organizada e tratamento de informação

sobre esta matéria, não permite saber qual a dimensão e tipo de

toxinfecções alimentares em Portugal, criando um obstáculo à

correcta avaliação dos riscos na cadeia alimentar e

consequentemente à prevenção. Além disso, dificulta o diagnóstico

clínico e a identificação do(s) alimento(s) causador(es) de tais

problemas, não permitindo a avaliação do impacto das medidas de

prevenção já existentes ou entretanto criadas.

1.2.1 Objectivo

Pretende-se com este projecto a criação de um sistema de registo dos

casos das toxinfecções alimentares em Hospitais Nacionais que

permita efectuar um estudo sistemático e estatístico dos dados.

Para tal, será criada:

Uma base de dados para inserção sistemática de todo o

processo clínico, salvaguardando o anonimato dos utentes, que

permita um tratamento eficaz dos dados;

Ao longo do projecto serão criados modelos estatísticos que

permitam não só a identificação da taxa de incidência cada tipo

de toxinfecção mas também a possibilidade de associar

sintomas aos diversos tipos de agentes infecciosos e alimentos

contaminados.

Daniel Nogueira 2


Um portal de divulgação dos dados através de gráficos

estatísticos;

Uma zona de notícias.

1.2.2 Resultados previstos

Os resultados deste projecto serão periodicamente publicados num

portal específico e dedicado para o efeito que estará disponível para

todos os interessados das comunidades científicas. Desenvolver mais

o conhecimento real e actualizado das principais fontes de exposição

para os humanos ao longo da cadeia alimentar, e o respectivo agente

etiológico poderá servir de base para a criação de novas medidas de

prevenção, fiscalização e controlo da Segurança Alimentar.

1.2.3 Planeamento de projecto

Tarefa Início Fim

Análise 13-FEV-2006 24- FEV -2006

Estudo das tecnologias 27- FEV -2006 10-MAR-2006

Implementação 13-MAR-2006 05-MAI-2006

Testes 08-MAI-2006 11-MAI-2006

Relatório 12-MAI-2006 02-JUN-2006

Tabela 1 – Planeamento do projecto

Análise – esta fase compreendeu o estudo do problema e a

definição do modelo de dados para dar suporte a toda a

informação necessária;

Estudo das tecnologias – esta fase incidiu no estudo das

diferentes tecnologias. No caso do PHP e do Ajax recorreu-se a

alguns exemplos para compreender o seu funcionamento. Esta

fase prolongou-se também durante a fase de implementação,

uma vez que à medida das necessidades eram adquiridos novos

conhecimentos;

Daniel Nogueira 3


Implementação – esta fase compreendeu a execução do

projecto em si, passando pela elaboração da base de dados, do

protótipo até chegar à versão final;

Testes – nesta fase foram efectuados alguns testes para

detecção de bugs correcção dos mesmos.

Relatório – nesta fase foi elaborado o relatório do projecto.

1.2.4 Reuniões de acompanhamento

Data: 14 de Fevereiro de 2006

Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP),

Dr. Luís Meireles (Biostrument)

Local: ISEP

Temas Debatidos: Apresentação do projecto ao orientador;

Apresentação do supervisor de estágio ao orientador; Tecnologias

usadas;

Conclusão: Nesta reunião ficaram definidas algumas tecnologias que

iram ser utilizadas. Ficaram definidos os prazos para a conclusão do

projecto.

Data: 5 de Abril de 2006

Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP),

Dr. Luís Meireles (Biostrument).

Local: ISEP

Temas Debatidos: Ponto de situação do projecto;

Conclusão: Em resumo desta reunião ficaram definidas novas tarefas,

e novos métodos de trabalho.

Data: 15 de Maio de 2006

Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP)

Local: ISEP

Temas Debatidos: Ponto de situação do projecto;

Daniel Nogueira 4


Conclusão: Após esta reunião percebeu-se que o tempo disponível

para acabar o projecto poderia não ser cumprido. Definiram-se então

novos prazos.

Data: 6 de Junho de 2006

Participantes: Eng. Constantino Martins (ISEP), Daniel Nogueira (ISEP

Local: ISEP

Temas Debatidos: Discussão da estrutura do relatório;

Conclusão: Ficou definida a estrutura do relatório a realizar.

Daniel Nogueira 5


2 Tecnologias utilizadas

Para o desenvolvimento do projecto, foram utilizadas várias

tecnologias escolhidas pela empresa por vários motivos: já eram

utilizadas na empresa daí a continuidade na sua utilização, e o

aspecto mais importante é que todas as tecnologias usadas são de

uso livre.

HTML para definir a estrutura do site;

CSS para definir a apresentação visual do site;

JavaScript para tratamento dinâmico da páginas utilizando

HTML DOM, validação de forms e para utilizar o objecto

XMLHttpRequest para pedir ou enviar informação ao servidor

sem ser necessário actualizar a página completa;

PHP foi utilizado para fazer a ligação ao Sistema de Gestão de

Base de Dados (SGBD) e para permitir páginas dinâmicas;

Apache como servidor web;

MySQL foi o SGBD escolhido uma vez que já era utilizado na

empresa, é muito rápido para aplicações web;

JPGraph é uma classe que permitiu incluir facilmente gráficos

estatísticos no site;

XML teve um papel fundamental, pois foi utilizado para auxiliar

a transferência de dados entre o cliente (JavaScript) e o servidor

(PHP);

AJAX foi bastante utilizado para fazer a comunicações entre o

cliente e o servidor sem ser necessário a actualização completa

das páginas. Basicamente este processo resume-se a: o cliente

faz um pedido ao servidor por GET ou POST, enquanto a

resposta não é recebida o cliente pode ir executando outras

tarefas que não dependam da resposta do servidor, por sua vez

o servidor processa o pedido e envia a resposta para o cliente

em formato XML, ao receber a resposta o cliente analisa o XML

recebido e efectua as acções programadas.

Daniel Nogueira 6


2.1 HTML

A linguagem HTML (HyperText Markup Language) é uma linguagem

de formatação de documentos, não é uma linguagem de

programação, e é composta por tags (etiquetas), tags esses que

permitem descrever a estrutura do documento.

A linguagem HTML tem por base a linguagem Standard Generalized

Markup Language (SGML), linguagem esta que é utilizada para

descrever a estrutura geral de vários tipos de documentos.

A linguagem HTML é um padrão mantido pelo World Wide Web

Consortium (W3C) que integra empresas, universidades e institutos.

Os documentos HTML podem conter diferentes tipos de conteúdo

como texto, imagem, som e vídeo. Esse conteúdo pode depois ser

visualizado por qualquer pessoa que utilize um browser e que esteja a

consultar documentos HTML (páginas web) independentemente do

tipo de terminal utilizado (computador, pda, telemóvel ou outro). [1]

2.2 CSS

Cascading Style Sheets (CSS) ou em português, folhas de estilo, é

uma tecnologia que permite ao programador criar graficamente

páginas Web de uma maneira muito mais precisa permitindo que os

resultados finais sejam praticamente idênticos em qualquer browser

com algumas excepções.

Com CSS o programador pode manipular margens, tipos de letra,

fundos, cores, espaçamento de caracteres, e um sem número de

outras propriedades, o objectivo da utilização de folhas de estilo, é

separar o estilo do conteúdo da página, do conteúdo em si.

Existem duas formas de utilizar folhas de estilo, ou incluindo o código

directamente no HTML (definindo os estilos no seu header), ou no

caso de já se possuir alguma experiência, esse código pode ser

escrito num ficheiro à parte e incluída apenas uma referência (link)

para o mesmo no header da página em questão.

Usualmente a cada estilo é atribuído um nome e esse nome é depois

usado dentro da tag do elemento na propriedade class. [2]

Daniel Nogueira 7


2.3 JavaScript

O JavaScript é uma linguagem de programação criada para dar mais

interactividade e maior funcionalidade às páginas da Web. Tendo sido

inicialmente desenvolvida pela Netscape, a linguagem JavaScript

acabou por dar origem à especificação técnica ECMAScript, que é um

padrão oficial reconhecido pela indústria. Apesar de esta linguagem

ser mais conhecida pelo nome de JavaScript, e de a versão produzida

pela Microsoft ter recebido o nome de JScript, a verdade é que se

tratam de implementações que sendo fiéis à norma ECMAScript lhe

acrescentaram novas funcionalidades úteis, mas respeitando sempre

as especificações oficiais.

O código escrito em JavaScript destina-se a ser executado pelo

browser quando a página HTML que o contém é visualizada. Ele é

uma parte integrante da página e permite que o browser seja capaz

de tomar decisões quanto ao modo como o conteúdo é apresentado

ao utilizador e como pode ser manipulado.

2.4 PHP

O PHP (Hypertext Preprocessor) é uma linguagem de Scripting. Tem

este nome porque o código PHP é interpretado e não compilado. Isto

quer dizer que, ao contrário de outras linguagens como o C, que o seu

código é compilado, e depois executado como um programa normal,

o PHP necessita sempre de um "parser" para interpretar o seu código.

A sua principal função é a de desenvolver conteúdos web dinâmicos,

e foi para essa finalidade que foi criado. [3]

Daniel Nogueira 8


Figura 1 - Arquitectura do PHP [9]

O cliente solicita a página a partir do browser ao servidor http. Este

verifica que o código html contém embebido um script PHP e chama o

módulo PHP para efectuar o processamento.

Se no script existirem comandos que abrem uma ligação a uma base

de dados, o PHP trata de efectuar essa ligação.

Os dados pretendidos são então extraídos da base de dados sendo

enviados pelo PHP ao servidor HTTP.

O servidor web envia os dados ao browser cliente sendo estes

visualizados numa página html devidamente formatada. Deste modo

ao visualizarmos no browser o código fonte, apenas veremos HTML,

pois o que o servidor enviou foi o output devidamente processado,

sendo este o resultado final visível.

2.5 Apache

É um software servidor http totalmente gratuito, sendo este o mais

usado no mundo (cerca de 68,4% no final de Janeiro de 2005,

segundo dados da Netcraft (Netcarft 2005)). Contudo corre em vários

sistemas operativos, tais como BSD, GNU/Linux, MacOS e Windows

sendo bastante flexível em termos de configuração.

Das vantagens que o servidor apresenta salientam-se as seguintes:

É gratuito, o que permite aos programadores descarregarem-no

e adaptarem-no às suas necessidades, sem pagarem por isso;

Daniel Nogueira 9


É modular, facilitando a interligação do servidor Web com

outras aplicações ou o acréscimo de funcionalidades ao

servidor;

A documentação para configuração e/ou programação está

disponível publicamente;

Implementa todas as funcionalidades do HTTP/1.1.

2.6 MYSQL

O MySQL é um SGBD relacional, eficiente e optimizada para

aplicações Web. Este SGBD é multi-plataforma, sendo compatível com

vários sistemas operativos. As tabelas criadas podem atingir o

tamanho de 4 GB. O MySQL é compatível com várias linguagens de

programação, tais como PHP, C, Java, Visual Basic, entre outros. O

MySQL não tem recursos sofisticados, mas para aplicações não muito

complexas, ele é uma óptima indicação. O facto de utilizar apenas

recursos essenciais (o que atende à maioria das aplicações de base

de dados existentes) fez com que sua adopção e consequente

suporte fosse grande. Trata-se da base de dados de código livre mais

utilizado no mundo. [11]

2.7 JPGRAPH

O JPGraph é uma biblioteca para criação de gráficos que tem como

base a biblioteca GD do PHP. O JPGRAPH simplifica a criação de

gráficos através de scripts PHP.

Para adicionar a biblioteca GD ao PHP na plataforma windows basta a

alterar no ficheiro php.ini a seguinte linha: [4]

Daniel Nogueira 10


Figura 2 - Configurar biblioteca GD [4]

Para descomentar a linha, é só retirar o ; (ponto é vírgula) do início da

linha.

Figura 3 – Configurar biblioteca GD [4]

Em linux terá que fazer download das seguintes bibliotecas:

ftp://ftp.uu.net/graphics/jpeg/

http://www.libpng.org/pub/png/libpng.html

http://www.freetype.org/

Instale os devidos pacotes e compile o PHP com os seus parâmetros

acrescidos dos seguintes comandos:

Daniel Nogueira 11

http://www.freetype.org/

http://www.libpng.org/pub/png/libpng.html

ftp://ftp.uu.net/graphics/jpeg/


Figura 4 – Compilar PHP com GD [4]

O que está em negrito é o directório de instalação de cada pacote.

2.8 XML

Extensible Markup Language (XML) é uma ferramenta extremamente

poderosa no que respeita à gestão, organização e visualização de

bases de dados textuais.

Os principais objectivos do XML são:

Separação do conteúdo e da formatação

Legibilidade tanto por humanos quanto por máquinas

Possibilidade de criação de tags sem limitação

Criação de arquivos para validação de estrutura

Com o seu uso podem-se interligar bases de dados distintas

Simplicidade

XML concentra-se na estrutura da informação e não na sua

aparência. [5]

Daniel Nogueira 12


Figura 5 – Exemplo XML

2.9 AJAX

Asynchronous JavaScript and XML (Ajax) é uma técnica de

desenvolvimento Web para a criação de aplicações bastante

interactivas. Para tal Ajax utiliza um conjunto de tecnologias já

existentes há algum tempo.

HTML e CSS para a apresentação dos dados.

JavaScript e DOM, de forma a mostrar informação

dinamicamente.

XMLHttpRequest como forma de trocar informação com o

servidor web de forma assíncrona.

O seu nome advém desse conjunto de tecnologias: “Asynchronous

JavaScript and XML”.

No capítulo 3 é aprofundado o estudo da tecnologia Ajax, visto que é

uma “tecnologia” recente e que não é leccionada no curso de

Engenharia informática.

Daniel Nogueira 13


3 AJAX

A utilização de Ajax permite a criação de aplicações web com um

comportamento parecido com aplicações que correm em desktop.

Numa aplicação web normal o utilizador efectua um pedido ao

servidor e fica à espera do resultado. Normalmente é necessário

esperar que o servidor responda, que a página faça refresh e que o

pedido volte, para gerar uma nova página. Grande parte do tempo o

utilizador tem que estar à espera, ou seja, não é tão interactiva como

uma aplicação de desktop em que os resultados são obtidos

instantaneamente.

Do ponto de vista do utilizador não faz sentido que após o

carregamento da interface, sempre que interaja com a aplicação web,

tenha de ficar à espera que esta comunique com o servidor.

Ajax tenta eliminar a diferença em termos de funcionalidades e

interactividade que existe entre aplicações web e de desktop, permite

que seja possível a utilização de interfaces dinâmicas e formas de

interacção mais avançadas. Assim Ajax apresenta uma nova forma de

desenvolvimento para os programadores web na qual se conta com

as limitações que se pensavam existir, trazendo uma maior gama de

possibilidades para a criação de aplicações web.

3.1 Aparecimento do Ajax

Não se pode atribuir uma data para o aparecimento da aplicação de

Ajax. No entanto o nome foi dado por Jesse James Garrett da Adaptive

Path em 18 de Fevereiro de 2005. A primeira técnica de remote

scripting assíncrono foi criada pela Microsoft em 1998. Ainda não

fazendo uso do objecto XMLHttpRequest, funcionando sobre uma

JavaApplet, no entando a Microsoft não aproveitou esta inovação.

Mais tarde, por volta 2001/2002, a Netscape através do DevEdge

começou a suportar esta tecnologia através de um IFRAME.

Daniel Nogueira 14


Hoje em dia é impossível ler um site qualquer de notícias orientado

para tecnologia (como slashdot.org ou digg.com) sem sermos

inundados por um número abismal de artigos que referem Ajax, seja

de um modo positivo seja de um modo negativo ou apenas de uma

maneira imparcial.

Apesar de, como já foi referido na anteriormente, esta maneira de

desenvolver para a web já exista há algum tempo, apenas nestes

últimos meses tem tomado esta proeminência.

Isto sucede em grande parte devido à adopção alargada da Google

pelo Ajax: podemos ver pedaços em todos os seus produtos web de

maior popularidade, seja o caso das sugestões dadas

automaticamente e instantaneamente aquando da inserção de

caracteres para uma pesquisa dada pelo Google Suggest, ou então

pela facilidade da manipulação de mapas (zoom in, zoom out,

arrastar) no Goggle Maps, no uso do GMail, a aplicação web que veio

revolucionar a maneira como usamos o webmail, com a sua interface

simples, eficaz e não intrusiva, e ainda na personalização da

homepage do Google, que usa mecanismos de “drag and drop” para

manipular os seus conteúdos, apresentada na figura 1.

Pode-se dizer então que a Google é a responsável pelo actual buzz

que circula em praticamente todo o Silicon Valley, apesar de não ter

sido nem o criador de Ajax nem quem primeiro utilizou esse termo

para definir o conjunto de técnicas usadas.

Mas isto não quer dizer que apenas eles usem Ajax: por todo lado

novas empresas começam a usar e ficar curiosas das suas

potencialidades, mesmo sem saber muito bem porque é que toda a

gente usa, como por exemplo uma empresa que faz software

colaborativo, Zimbra, em que o seu CEO quando fundou a empresa

apenas pensava que Ajax era um produto de limpeza de casas de

banho, mas actualmente juntou 16 milhões de dólares em capital de

risco, tudo isto para o desenvolvimento de aplicações que usem Ajax.

Mas até a Microsoft actualmente está virada para toda este novo

modo de “fazer a net” como se pode ver pelos seus esforços com a

Daniel Nogueira 15


introdução do portal http://www.live.com no aparecimento da sua

nova estratégia e de aplicações totalmente web, como por exemplo

uma versão do seu muito popular Microsoft Office, sendo esta

estratégia “live” parte também do lançamento do seu novo sistema

operativo (Windows Vista). Por isso o que se pode ver hoje em dia é

não só o uso de Ajax como, digamos, um brinquedo dos

programadores, como foi usado pela Google no inicio, mas a tornar-se

uma opção completamente viável, usável, uma moda que toda a

gente quer usar, que ninguém quer perder. Claro que todo este

falatório à sua volta e toda esta ânsia de uso leva a todos os

exageros.

A tentativa de incorporar Ajax em todas as páginas em todo lado seja

para o que for leva a que existam muitos detractores do seu uso,

indicando que apenas dificulta a fluidez.

Nesta altura observa-se uma luta acesa entre aqueles que valorizam

Ajax indicando praticamente como a nova ordem na web e aqueles

que vêm apenas Ajax como uma moda algo para não ser levado a

sério que apenas traz coisas negativas a toda a experiência de uso da

Internet.

Qual destes dois terá razão apenas o tempo dirã, mas o rumo actual

leva a pensar que apesar de ser uma moda e de ter tomado a

Internet de assalto, Ajax está para ficar e cada vez mais a ser objecto

de estudo e de uso não apenas por aqueles que acham interessante e

querem experimentar mas também cada vez maiores e mais

importantes empresas: Microsoft, Google e até a Yahoo! com a sua

aquisição, por exemplo, do Flickr que usa Ajax. Inclusive, através de

publicações de tutoriais por parte de pessoas com provas dadas no

mundo sancionadas por essas empresas, sendo um dos últimos

exemplos um artigo publicado no site da IBM da autoria de Brett

McLaughlin, autor e editor pertencente à bem conhecida O’Reilly and

Associates, intitulado “Mastering Ajax, Part 1: Introduction to Ajax,

Understanding Ajax, a productive approach to building Web sites, and

Daniel Nogueira 16


how it works”. Tudo isto inerente à revolução que muitos chamam de

Web 2.0 que está a caminho.

3.2 Tecnologias base

Ajax não é uma tecnologia. Ajax é um modelo para aplicações web

composto por várias tecnologias que se ligaram para o criar. Essas

tecnologias são:

HTML

Para a apresentação das páginas no browser.

DOM (Document Object Model)

Permite aceder e manipular os elementos XML DOM para tratar a

resposta que vem do servidor, e os elementos do HTML DOM para

manipular a página dinamicamente.

XML

XML é o meio de transporte dos dados no sentido servidor-cliente. Os

dados são encapsulados em tags XML, de modo a que sejam

extraídos e tratados pelo cliente quando os recebe.

XMLHttpRequest

Para receber dados assincronamente, o XMLHttpRequest permite ao

JavaScript fazer pedidos HTTP ao servidor remoto sem ser necessário

recarregar a página.

JavaScript

JavaScript é a linguagem que vai ser usada para construir um motor

que coordena e controla toda a aplicação do lado do cliente, que faz o

XMLHttpRequest, que recebe o XML do servidor e que é responsável

pela actualização da página para o cliente, bem como da sua

interactividade.

Daniel Nogueira 17


3.3 Funcionamento clássico de uma aplicação web

Figura 6 – Funcionamento clássico de uma aplicação web [6]

No modelo clássico a interface está no browser do cliente: este lança

um HTTP Request para o servidor, que processa e retorna o HTML e

CSS correspondentes.

3.4 Funcionamento de uma aplicação web usando Ajax

Figura 7 – Funcionamento de uma aplicação web usando Ajax [6]

Daniel Nogueira 18


Com Ajax a interface em vez de lançar um HTTP Request lança uma

chamada de JavaScript para uma aplicação Ajax que se encontra do

lado do cliente. Esta por sua vez lança o HTTPRequest para o servidor

que trata do pedido e retorna os dados correspondentes para a

aplicação Ajax, que por fim os mostra ao utilizador. A grande

diferença entre estes dois modelos é que enquanto que no clássico é

necessário recarregar toda a página de cada vez que é feito um

pedido, com Ajax não, uma vez que depois do carregamento inicial só

se vão alterando os dados na área onde estes vão ser colocados de

cada vez que é feito um pedido. O facto de ser assíncrono também

permite que se continue a processar outros dados enquanto se

espera pela resposta do servidor.

3.5 Classe Sack

A “espinha dorsal” de Ajax é o XMLHttpRequest e a maneira como a

aplicação em JavaScript é construída. Para simplificar o uso de Ajax

foi usada uma classe JavaScript (anexo 1).

Breve explicação da utilização da classe sack:

Daniel Nogueira 19


var ajax = new sack(); //instancia um objecto da classe

sack

ajax.element = "div"; //define o elemento onde vai ser

//exibida aa interacção do cliente com

//o servidor

ajax.requestFile = "page.php"; //URL da página no servidor

ajax.setVar("var",variavel); //define as variáveis

ajax.method = "POST";//define metodo do pedido http ‘GET’

ou‘POST’

ajax.onLoading = function whenLoading(){

//quando está a enviar os dados

ajax.element.innerHTML = "Sending Data..."; };

ajax.onLoaded = function whenLoaded(){

//quando os dados são recebidos no servidor

ajax.element.innerHTML = "Data Sent..."; };

ajax.onInteractive = function whenInteractive(){

//quando os dados estão a ser recebidos

ajax.element.innerHTML = "Getting data..."; };

ajax.onCompletion = function(){

//quando os dados sao recebidos totalmente no cliente

ajax.element.innerHTML = "Finished..."; };

ajax.runAJAX();

Extracto 1 – Exemplo de utilização da classe Sack

Inicialmente é instanciado um objecto da classe ‘sack’, depois

definem-se as variáveis internas:

ajax.element é o elemento onde vai aparecer a informação

sobre o estado do pedido, que permite ao utilizador saber que

está a haver interacção.

ajax.requestFile é o URL do script do lado do servidor que vai

ser chamado, se for utilizado o método ‘GET’ as variáveis

podem ser passadas explicitamente no URL.

ajax.method é o método do pedido http, que pode ser “GET” ou

“POST”.

Daniel Nogueira 20


ajax.onLoading é a função que é chamada quando os dados

estão a ser enviados para o servidor;

ajax.onLoaded é chamada quando os dados foram

completamente enviados;

ajax.onInteractive é executada quando os dados estão a ser

recebidos pelo cliente;

ajax.onCompletion é a função que é chamada quando a

resposta foi totalmente recebida pelo cliente.

Quando a resposta chega o cliente trata os dados recebidos.

3.6 Vantagens e desvantagens

Como acontece com a maioria das tecnologias, o seu sucesso

depende do uso que as pessoas lhes dão. Indiscutivelmente, usar

Ajax levanta algumas questões, tanto para os programadores web

como para os utilizadores, que podem pôr em causa o seu uso, mas

quando usado correctamente, existem diversas vantagens que não

podem ser ignoradas por quem desenvolve aplicações web, como o

demonstram os grandes sucessos que se têm observado nos últimos

anos como é o caso do GMail da Google.

As opiniões divergem neste assunto, sendo que se podem definir

claramente dois pólos: os “idealistas”, que tendem a levar mais em

conta os aspectos que se prendem com a arquitectura dos sites e as

questões tecnológicas subjacentes, e os “pragmáticos” que colocam a

experiência que o utilizador tem ao visitar um site no topo das suas

prioridades, independentemente do que isso representa para quem

desenvolve o site.

Vantagens

As principais vantagens decorrentes do uso de Ajax são as

observáveis pelos utilizadores dos respectivos sites. Do ponto de vista

de quem desenvolve um site as vantagens não são tão óbvias (não se

pode dizer que o seu desenvolvimento ou manipulação de dados seja

necessariamente mais simples), contudo estas não deixam de existir,

Daniel Nogueira 21


principalmente se se considerar que o uso de Ajax pode alterar a

forma como questões de usabilidade serão abordadas no futuro.

Usabilidade

As vantagens mais visíveis para um utilizador de um site que use Ajax

são as que dizem respeito à sua interactividade e usabilidade. O

ganho na interactividade faz com que o comportamento das

aplicações web se aproxime do das aplicações de desktop,

possibilitando acções como “drag and drop” e dando no geral uma

maior fluidez à navegação entre diferentes páginas de um mesmo

site. Alguns dos aspectos que mais se destacam a nível da

interactividade que Ajax possibilita são:

Tempos de espera mais curtos

Não sendo necessário carregar toda a página novamente, há uma

grande redução na largura de banda gasta quando se compara um

pedido Ajax com um pedido HTTP feito pelo browser para abrir uma

página. Menor gasto de largura de banda implica tempos de espera

inferiores, o que é vantajoso para qualquer website uma vez que não

provoca tantas quebras no acesso à informação.

Validações automáticas na submissão de formulários

Esta questão coloca-se especialmente para formulários longos e que

requerem validação de diversos campos. Através de Ajax não é

necessário esperar que a submissão do formulário termine para saber

se um dado username está disponível, ou ter de esperar que uma

nova página abra para ver todos os campos do formulário quando

parte destes depende do input do utilizador.

Completação automática de campos

Ao preencher campos de texto é frequente que os dados que o

utilizador vai inserir sejam previsíveis, quer seja por outro utilizador já

os ter inserido (como é o caso de queries repetidas em motores de

Daniel Nogueira 22


busca) quer seja por estarem directamente associados ao utilizador

em questão (por exemplo no preenchimento automático do campo

“endereço” em aplicações de webmail usando o livro de endereço do

utilizador). Neste tipo de campos faz sentido usar Ajax para ir buscar

dinamicamente as entradas mais frequentes começadas pelas letras

que o utilizador já escreveu, reduzindo assim o tempo necessário

para escrever entradas de texto longas e eventualmente ajudando o

utilizador a escrever aquilo que pretende quando este não sabe

exactamente o que escrever (quer seja um endereço de e-mail ou

uma palavra-chave de uma pesquisa).

Manipulação de dados altamente interactiva

Quando se pretende executar acções como reordenar uma lista de

resultados ou até fazer qualquer tipo de filtragem pode valer a pena

usar Ajax para não ter de carregar a página novamente. Este tipo de

situação aplica-se a todos os acessos a dados que dependem

fortemente do input do utilizador.

Navegação em estruturas em árvore profundas

Por vezes não é viável carregar todos os dados relacionados com o

assunto de uma dada página, sendo informação adicional remetida

para nós mais profundos da vista da árvore que está a ser

apresentada. Um exemplo desta situação é nos tópicos de alguns

foros nos quais as respostas estão encadeadas (isto é, é possível

responder a uma resposta de outro utilizador dentro de um tópico),

sendo que não é viável mostrar toda a árvore de respostas

(mostrando-se apenas um nível da árvore de cada vez). Nestas

situações é vantajoso usar Ajax para expandir um nó da árvore, por

oposição a abrir uma página nova com o conteúdo (respostas) desse

nó.

Daniel Nogueira 23


Interacção do utilizador com o site

Acções como votar em um inquérito (e ver imediatamente os totais

da votação) ou colocar uma questão através de um formulário online

ganham uma dimensão completamente diferente quando a resposta

do site é imediata. O uso de Ajax neste tipo de acções encoraja os

utilizadores a darem feedback ao site, o que promove a aproximação

utilizador-site e leva os detentores do site a adequarem-se melhor às

necessidades dos seus utilizadores.

Desempenho e compatibilidade

Os ganhos em usabilidade de Ajax são muitos, mas convém não

esquecer que já era possível ter elevados índices de interactividade

recorrendo a outras tecnologias. O uso de applets Java ou de

elementos Flash em sites não é uma novidade e já era possível

através destes melhorar a experiência que o utilizador tem ao visitar

um site, porém há dois aspectos a ter em conta neste tipo de

elementos: por um lado, trata-se de elementos que

computacionalmente são, por vezes, muito pesados para um

computador processar, limitando assim o número de utilizadores que

conseguem tirar proveito do seu uso; por outro lado, estes elementos

requerem frequentemente a instalação de software adicional no

computador do utilizador, que muitas vezes não é desejável (tempo

necessário para descarregar o software e espaço que ocupa, entre

outros).

Com Ajax estas questões não são tão importantes, uma vez que cerca

de 80% dos sistemas já suportam todos os elementos necessários

para a visualização de um site em Ajax sem qualquer tipo de software

adicional.

Desvantagens

Ajax não deixa de ter as suas desvantagens [8]. A maioria destas

podem ser contornadas pelos programadores web, mas por um lado

poucas pessoas têm estes cuidados e por outro tratam-se, de facto,

Daniel Nogueira 24


de “truques” para contornar estas dificuldades. Parte destas

desvantagens devem-se também ao facto de Ajax ser usado em

contextos em que não é adequado: o melhor contexto para usar estas

tecnologias é em aplicações web e não em “páginas web”.

Usabilidade

Navegar em sites que usem Ajax pode tornar-se um pesadelo quando

se pretende executar acções como usar o botão Back ou mostrar o

conteúdo que estamos a observar a outra pessoa. Apesar de haver

implementações que permitem criar um endereço (URI) que identifica

univocamente o recurso que está a ser acedido, como é o caso do

Google Maps, a maioria das aplicações não tem esse cuidado. Outra

questão que se prende com a navegação entre páginas é o facto de

não ser dado feedback ao utilizador sobre o estado dos seus pedidos,

isto é, se a página a que o utilizador pretende aceder está

efectivamente a ser aberta. Para além disto, há a questão do

scrolling: numa página longa em que seja necessário descer o scroller

da página para ver um determinado conteúdo, caso o motor Ajax

retire um parágrafo acima do conteúdo que está a ser visto todo o

texto será “puxado” para cima.

Os novos paradigmas de usabilidade possibilitados por Ajax são, por

si só, fonte de discórdia. Ainda que existam novas possibilidades a

nível de interface, os programadores web devem ter o cuidado de não

romper completamente com as convenções existentes uma vez que

correm o risco de os utilizadores não saberem como usar os seus

sites.

Outro aspecto que é negligenciado é o facto de em Ajax haver a

necessidade de fazer constantemente pedidos ao servidor para

aceder às páginas. Isto torna-se um problema para pessoas com

fracas condições de conectividade e para as quais o uso de cache é

importante.

Daniel Nogueira 25


Há ainda a ter em conta o facto de que a indexação dos conteúdos

por parte de motores de busca não é possível nos conteúdos que são

acedidos através de Ajax.

Para estes casos seria necessário disponibilizar uma versão acessível

sem usar Ajax.

Por fim, há ainda a considerar a possibilidade de o browser da

máquina do cliente não suportar JavaScript. De acordo com o W3C,

cerca de 11% dos utilizadores da web usam browsers que não

suportam JavaScript, pelo que têm de se contentar com as versões

sem JavaScript que existam ou, no caso de os programadores web

não criarem estas versões, simplesmente não podem utilizar o site.

Implementação

Relativamente à implementação, há vários aspectos que sofrem com

o uso de Ajax.

Por um lado, uma vez que depende da máquina do cliente é

necessário ter um maior cuidado a nível de testes para garantir que

os sites funcionam em todos os sistemas e browsers a que o site se

destina.

Por outro, uma vez que os sites ficam muito dependentes da

comunicação com o servidor para aceder a conteúdos e esta é feita

de modo assíncrono é necessário ter cuidados redobrados em termos

de segurança, algo que a generalidade dos programadores web não

têm. Há ainda uma questão mais prezada pelos “idealistas” de

desenvolvimento web que se refere à arquitectura dos sites.

Idealmente, o modelo cliente-servidor deveria ser adoptado porém

usando Ajax passa-se alguma da lógica da aplicação web para o HTML

queé retornado para o cliente. Para além de revelar algum do

processamento de dados ao utilizador, que pode não ser desejável,

depende-se da capacidade dos browsers do cliente para processar os

dados retornados pelo utilizador e mostrá-los convenientemente. Por

fim, a actualização de conteúdos com Ajax pode levar a

inconsistências se não houver um tratamento adequado: caso se

Daniel Nogueira 26


esteja a ler uma primeira página de um documento, por exemplo, ao

actualizar o conteúdo com outras páginas pode ser preciso actualizar

também o título da página (no head) e alguns headers, entre outros.

Dispositivos Móveis

Uma outra aplicação de Ajax que já começa a surgir é a que diz

respeito ao seu uso em dispositivos móveis. Para além das questões

de usabilidade, há a considerar nestes dispositivos o ganho em

termos de consumo de tráfego, já que em dispositivos móveis esta

questão se coloca em duas vertentes: tempo de arregamento e

custos associados. Recentemente, os developers do browser Opera

lançaram um toolkit que permite lidar com este tipo de pedidos de

uma forma mais transparente, de modo a que não seja necessário

desenvolver sites específicos para determinados sistemas operativos,

como actualmente sucede. Este toolkit traz ainda grandes benefícios

no desenvolvimento de interfaces para smart phones e uma vez que

a tecnologia Ajax está apenas agora a ganhar notoriedade é provável

que venha a surgir maior suporte para este tipo de dispositivos [7].

3.7 Conclusão

Ajax é uma técnica bastante poderosa para o desenvolvimento de

aplicações web. No entando tem que se ter cuidado com a sua

utilização pois um mau uso desta técnica pode criar aplicações

difíceis de utilizar e inseguras. Ultimamente cada vez mais empresas

utilizam Ajax para a criação de projectos, de dia para dia esse número

aumenta, Ajax pode ser considerado uma moda, mas esta moda está

para ficar. Actualmente está a ter um papel muito importante na

evolução das aplicações web, sendo impossível ignorar o efeito

dessas aplicações sobre a world wide web e da maneira como a

entendemos. Hoje em dia é mais que um repositório de páginas soltas

com informação associada: é uma comunidade emergente sendo

considerada na actualidade, mais que um luxo, uma necessidade.

Move ainda as direcções das grandes empresas, não havendo maior

Daniel Nogueira 27


que a Microsoft, estando a focar-se nesta nova ”web social”muitas

vezes também chamada de Web 2.0.

Como vertiginoso aumento da sua utilização verifica-se neste

momento uma grande discussão na comunidade de programadores

web sobre as suas vantagens e desvantagens, se deve ser usado ou

não. Técnicas como Ajax já existem há alguns anos e nunca vingaram

nem perduraram, porque passou-se a centralizar todo o

desenvolvimento em tecnologias server-side em detrimento de uma

arquitectura mais client-side.

As vozes críticas são bastantes devido a várias desvantagens que

apresenta o seu mau uso e principalmente da forma como corta com

arquitecturas base de HTTP request e resposta de HTML e CSS, em

que toda a lógica está do lado do servidor.

No entanto todas as vantagens em termos de fluidez e percepção

para o utilizador da aplicação, bem como da rapidez de resposta,

tornam aliciante o seu uso.

Por isso, e como em qualquer tecnologia, não é só por si que é

determinado se vale a pena ou não o seu uso, mas sim a forma como

se faz esse uso, por isso Ajax sendo usada nas situações correctas

pode verificar-se muito vantajosa, por outro lado quando usada de

uma maneira errada, a experiência de uso fica completamente

destruída.

Usando uma analogia com um tema bem conhecido de todos os

interessados em ficção-científica (Star Wars):

“Ajax seems to be like Darth Vader... Powerful, yet dangerous”.

Daniel Nogueira 28


4 Análise e estrutura de dados

Neste capítulo pretende-se descrever o processo de análise feito bem

como a descrição da estrutura de dados que suporta o site

desenvolvido. Serão apresentados todos os requisitos funcionais da

aplicação.

4.1 Requisitos do sistema

Nesta secção serão apresentados os requisitos funcionais do site e

dos utilizadores.

Os requisitos funcionais do site são a criação de uma zona de

administração para importação e tratamento de dados, uma zona de

publicação de dados com gráficos estatísticos e uma zona de inserção

e publicação de notícias;

O administrador tem acesso zonas cruciais do site que são elas a

zona de importação de dados, a zona de tratamento dos dados e a

zona de inserir notícias.

O utilizador registado poderá visualizar a zona de publicação dos

dados, e à zona de notícias.

O utilizador não registado poderá se registar para ter outro nível de

acesso, e visualizar informações básicas no site como consultar os

contactos e ler uma introdução sobre o tema do site.

4.2 Modelo de dados

A base de dados foi desenvolvida com base numa lista de requisitos

elaborado pela empresa [Anexo 2], e teria que suportar toda a

informação pretendida. Teria também que permitir o registo de

utilizadores e a criação de uma zona de notícias.

Daniel Nogueira 29


O tipo de tabelas do MySQL aconselhado a usar pelo supervisor de

estágio foi MyISAM, uma vez que o seu uso não implica custos. Como

este tipo de tabelas não suporta chaves estrangeiras, logo é na

camada de programação que são efectuadas as validações

necessárias para garantir a integridade dos dados.

Daniel Nogueira 30


4.2.1 Esquema da base de dados

Figura 8 – Esquema da base de dados

Como se pode visualizar nesta figura a tabela principal é a tabela protoreg, que faz a ligação entre todas as outras

tabelas através do atributo id_proto, que é o código do registo de cada caso.

Daniel Nogueira 31


4.2.2 Tabelas

Com este sub-capítulo, pretende-se descrever cada tabela, bem como

salientar alguns aspectos importantes em cada uma delas. Para isso

será usado uma espécie de Dicionário de Dados em forma de tabela.

1. Agentes

Campo Tipo de Dados Comentário

id Int(3) Código do agente

agente varchar(255) Nome do agente

tipo tinyint(1) Tipo de agente

Tabela 2 – Tabela Agentes

A tabela agentes guarda a informação sobre os diferentes agentes.

O campo id e chave primária, e auto_increment como a maior parte

dos identificadores das tabelas que se seguem, o que significa que a

cada registo inserido o valor do campo id é incrementado

automaticamente.

O atributo tipo pode assumir três valores:

1 – Vírus;

2 – Bactérias;

3 – Protozoários

2. Antecedentes


id Int(3) Código do antecedente

antecedente varchar(255) Descrição do antecedente

Tabela 3 – Tabela Agentes

Foi criada esta tabela para guardar os diferentes tipos de

antecedentes, pois já estavam definidos a partida vários tipos de

antecedentes. Sendo assim evita-se a repetição de dados.

Daniel Nogueira 32


3. Protoreg


id_proto bigint(11) Código do registo

dta_admissao date Data do registo

idade tinyint(2) Idade do doente

sexo varchar(9) Sexo do doente

distrito varchar(50) Distrito do doente

diag text Diagnóstico provável

confirma bool Se o diagnóstico é confirmado

comentario text Permite inserir um comentário

estado bool Se o registo já foi revisto ou nao

base_diag varchar(255) Diagnóstico com base em

alta bool Se o doente teve alta

inicio_sintomat varchar(255) Inicio da sintomatologia

evo_cli varchar(255) Evolução clínica

alimento varchar(255) Alimentos suspeitos

analisado bool Se o caso foi analisado

dias_antes tinyint(2)Quantos dias antes da consulta foi

ingerido o alimento

local_ingestao varchar(255) Local de ingestão do alimento

outras_pessoas boolSe outras pessoas apresentaram a

mesma sintomatologia

is_diag_reg_med

icobool

Se o diagnostico foi registado pelo

médico

diag_reg_medico varchar(255) Se foi registado pelo médico qual foi

Tabela 4 – Tabela Protoreg

Daniel Nogueira 33


Esta é a tabela principal, é nela que é guardada toda a informação

sobre cada registo de cada possível intoxicação alimentar. A chave

primária é o atributo id_proto.

A seguir é apresentada uma descrição mais detalhada de todos os

campos desta tabela e em alguns casos os possíveis valores que

podem tomar:

id_proto – este é um campo de controlo do número de registo. A

cada registo é incrementado;

dta_admissao – data em que a possível intoxicação alimentar foi

registada no hospital;

idade – idade do paciente;

sexo – sexo do paciente;

distrito – distrito do paciente;

diag – diagnóstico feito ao paciente na triagem do hospital;

confirma

o 0 – caso de intoxicação não confirmado;

o 1 – caso de intoxicação confirmado;

comentário – este campo permite ao administrador inserir um

comentário acerca do registo actual aquando da revisão do

registo no sistema de administração.

estado

o 0 – o registo ainda não foi completamente tratado pela

administração;

o 1 – o registo foi tratado e está pronto para ser publicado;

base_diag – indica no que se baseou o diagnóstico

alta

o 0 – o doente não teve alta na altura que se deslocou ao

hospital, ficando internado;

o 1 – o doente teve alta;

inicio_sintomat – quando se registou o inicio dos sintomas, este

campo aceita texto;

Daniel Nogueira 34


evo_cli – guarda um pequeno texto com a descrição da

evolução clínica do paciente;

alimento – pode ser um só alimento ou então vários, até um

máximo de 255 caracteres.

analisado

o 0 – indica que o alimento não foi analisado;

o 1 – indica que o alimento foi analisado;

dias_antes – número de dias que passaram desde a data de

ingestão do alimento suspeito e a data do aparecimento dos

sintomas;

local_ingestao – o local onde o alimento foi ingerido;

outras_pessoas

o 0 – indica que não houveram outras pessoas a apresentar

a mesma sintomatologia;

o 1 – indica que outras pessoas que comeram o mesmo

alimento apresentaram a mesma sintomatologia;

is_diag_reg_medico

o 0 – o diagnóstico não foi registado pelo médico;

o 1 – o diagnóstico foi registado pelo médico;

diag_reg_medico – se o diagnóstico foi registado pelo médico

este campo guarda um pequeno texto com a sua descrição;

4. proto_agentes


id_proto bigint(11) Código do registo na tabela protoreg

id_agente int(3) Código do agente

Tabela 5 - Tabela proto_agentes

A tabela proto_agentes é uma tabela de relacionamento entre a

tabela agentes e a tabela protoreg. Serve para registar os agentes

possíveis em cada caso. Os dois campos em conjunto definem a

chave primária.

Daniel Nogueira 35


5. Proto_ag_ident



id_agente int(3) Código do agente

Tabela 6 – Tabela proto_ag_ident

A tabela proto_ag_ident é uma tabela de relacionamento entre a

tabela agentes e a tabela protoreg. É nela que se registam todos os

agentes identificados. A chave primária é composta pelos dois

atributos.

6. Proto_sintomas



id_agente int(3) Código do sintoma

Tabela 7 – Tabela proto_sintomas

A tabela proto_sintomas relaciona as tabelas protoreg e sintomas.

Cada caso registado pode ter vários sintomas associados. A chave

primária é composta pelos dois campos.

7. Proto_antecedentes



id_antecedente int(3) Código do antecedente

Tabela 8 – Tabela proto_antecedentes

Esta tabela armazena todas as relações entre um caso registado na

tabela protoreg e um ou mais antecedentes. A chave primária é

composta pelos dois campos.

8. Proto_diario


Daniel Nogueira 36


id bigint(11) Código do diário


diario longtext Texto com a descrição completa do diário

Tabela 9 – Tabela proto_diario

A cada registo da tabela protoreg pode corresponder um ou mais

diários, por isso, para além do id_proto (código do registo na tabela

protoreg) é usado o campo id (código da tabela proto_diario) como

chave que é um auto_increment.

9. Proto_diag_base



sintomas bool Código do antecedente

diag_clinico boll Se o diagnóstico foi feito pelo médico

anal_gerais boolSe o diagnóstico teve como base

análises gerais

anal_micro bollSe teve como base análises

microbiológicas

outra bool Se teve base noutro método

p_analisado varchar(255) Produto analisado

outro varchar(255) Descrição de outro método

Tabela 10 – Tabela proto_diag_base

Está tabela armazena a informação relativa ao método no qual foi

baseado o diagnóstico. Se foi com base em sintomas, se foi

diagnóstico clínico, com base em análises gerais, com base em

análises microbiológicas, ou outra. Se teve como base analise

microbiológicas o campo p_analisado diz-nos qual foi o produto

analisado. Cada registo pode ter por base todos os métodos.

Daniel Nogueira 37


10.Proto_trata



a_biotico bool Se o tratamento é à base de antibiótico

tratamento longtext Texto com a descrição do tratamento

Tabela 11 – Tabela proto_trata

A cada registo desta tabela corresponde um registo da tabela

protoreg relacionado pelo atributo id_proto. Aqui é guardada a

informação relativa ao tratamento de cada caso, se esse tratamento

foi à base de antibióticos o a_biotico tem o valor 1 e o atributo

tratamento guardará qual ou quais os antibióticos administrados.

Caso contrário o campo a_biotico estará a 0 (zero) e o campo

tratamento guardará a descrição do tratamento.

11.Proto_rast_comp_sint



compativel boolSe o rastreio é compatível com os

sintomas

comentario longtextTexto com um comentário se não é

compatível

Tabela 12 – Tabela proto_rast_comp_sint

Esta tabela indica para cada caso se o rastreio é compatível com os

sintomas. No caso de não ser compatível o campo comentario

permite guardar um pequeno comentário.

12.Proto_analises



Daniel Nogueira 38


p_medico bool Se as analises foram pedidas pelo médico

p_hospital boll Se as analises foram pedidas pelo hospital

estado bool Se as analises pedidas estão prontas

diag_conf bool Se as analises confirmaram o diagnostico

geral bool Se foram pedidas analises gerais

micro bool Se foram pedidas analises microbiológicas

outra bool Se foi pedido outro método

outra_txt varchar(255) Descrição do outro método pedido

Tabela 13 – Tabela proto_analises

Esta tabela engloba toda a informação necessária acerca dos pedidos

de análises. Se as análises foram pedidas pelo médico na altura da

consulta podem neste caso ser pedidas ao hospital, o estado desse

pedido será guardado no campo estado que ficará com o valor 0

(zero) se o pedido ainda não está completo, caso contrário terá o

valor 1.

13.Faixa_etaria


id int(1) Código da faixa etária

idade_i int(3) Idade inicial

idade_f int(3) Idade final

Tabela 14 – Tabela faixa_etaria

Esta tabela foi criada para definir as faixas.

Estão predefinidas 5 faixas etárias a partida:

0 – 5

6 - 15

16 -30

31 – 65

Daniel Nogueira 39


66 – 100

Em qualquer altura podem-se alterar os intervalos, assim não implica

ter que se alterar o código programado.

14.Noticia


id bigint(11) Código da noticia

titulo Varchar(255) Titulo da noticia

texto text Texto da noticia

data datetime Data de criação da noticia

apagada bool Se a noticia está “apagada”

publicar bool Se a noticia pode ser publicada

Tabela 15 – Tabela noticia

A tabela noticia armazena todas as noticias inseridas e que poderam

estar publicadas no site ou não, dependendo do estado do campo

publicar. Se o campo ‘apagada’ estiver a 1 a noticia é considerada

como apagada, podendo sempre ser recuperada.

15.Visitas


nvisitas bigint(11) Numero total de visitas do site

uvisita datetime Data da ultima visita feita ao site

Tabela 16 – Tabela visitas

A tabela visitas é usada para controlar o número de visitas ao site e a

data da última visita.

Daniel Nogueira 40


16.Utilizador


id_utilizador int(5) Identificador único de utilizador

tipo varchar(10) Tipo de utilizador

nome varchar(255) Nome do utilizador

apelidos varchar(255) Apelidos

morada varchar(255) Morada

cod_postal int(4) Código postal

cod_postal2 int(3) Código postal 2

cidade varchar(255) Cidade

telefone int(9) Telefone

sEmail varchar(255) Email do utilizador

profissao varchar(255) Profissão

empresa varchar(255) Empresa

cargo varchar(255) Cargo que ocupa na empresa

sPassword varchar(255) Passord de acesso ao site

visitas int(11) Numero de visitas do utilizador

ultimo_login datetimeData do ultimo login que o utilizador

efectuou

Tabela 17 – Tabela utilizador

A tabela utilizador contém campos para armazenar a informação

pessoal de cada utilizador.

Explicação de alguns campos:

cod_postal e cod_postal2 – Ex: para o código postal 4000-123,

cod_postal será 4000 e cod_postal será 123;

sEmail – é o email do utilizador para onde será enviada a

palavra passe de acesso ao site. E servirá também para

efectuar a autenticação juntamente com a palavra passe.

Daniel Nogueira 41


sPassword – é a palavra passe de acesso ao site, está passe é

encriptada com o algoritmo MD5 e ninguém excepto o utilizador

terá acesso a ela.

visitas – é o número total de visitas, ou de autenticações que o

utilizador efectuar no site.

ultimo_login – é a data da ultima autenticação.

4.2.3 Sistema de autenticação

O sistema de autenticação existe em quase todos as e aplicações. O

seu objectivo é diferenciar o acesso às diferentes partes do site.

Neste caso a autenticação é feita do seguinte modo:

O utilizador acede pelo seu browser ao endereço do site;

Introduz o email e a palavra passe;

Caso os dados estejam incorrectos aparece uma mensagem de

erro;

Caso contrário o utilizador é autenticado e tem acesso as

funcionalidades de acordo com o seu nível de permissões;

Quando o utilizador faz logout deixa de estar autenticado e só

pode aceder às informações mínimas no site.

Daniel Nogueira 42


Figura 9 – Diagrama de actividade – autenticação

Para as outras funcionalidades não se revelou necessário este tipo de

análise.

4.3 Conclusão

Este capítulo deu a conhecer a arquitectura física e lógica dos dados.

O dicionário lógico de dados apresentou uma descrição detalhada de

cada tabela da BD.

A análise do projecto foi composta pelo levantamento dos requisitos e

pelo dicionário de dados.

Existem dois tipos de requisitos, os funcionais e os não funcionais. Os

funcionais foram apresentados sob a perspectiva de cada perfil de

utilizador. A gestão dos requisitos é importante para o sucesso de

uma aplicação.

Daniel Nogueira 43


5 LayoutsProtótipos

O aspecto gráfico do site foi sendo alterado ao longo do tempo.

Inicialmente o design era muito simples e foi feito mais com o

objectivo de poder ver alguma interactividade e para testar as

funcionalidades implementadas.

Foi-me dito para utilizar tons azuis, então o resultado foi este (Figura

10).

Figura 10 – Primeira versão do layout protótipo do site

Este não era definitivamente um design atractivo, e era necessário

fazer alterações.

Falou-se então com o designer que nos deu uma ajudinha no aspecto

visual baseando-se no modelo anterior e ainda desenhou um logótipo.

O resultado foi o foi o seguinte (Figura 11).

Daniel Nogueira 44


Figura 11 – Layout Maqueta do site com base na Figura 10

Nesta altura era necessário alterar toda a estrutura do site, ou seja,

montar o novo esqueleto da página. Foram usadas tabelas para

conseguir implementar em HTML o desenho apresentado.

Recortaram-se as imagens e definiram-se como fundo das tabelas. O

menu de botões já estava implementado com tabelas e javascript,

bastou portanto alterar para as novas cores.

Mesmo assim, este novo layout estava muito ‘morto’ e precisava de

mais vida. O menu de botões teria que ser na horizontal, pois

começava a ocupar uma grade parte da página. Então o designer fez

um novo trabalho e criou uma imagem para colocar no topo da

página e assim dar mais vitalidade.

Este resultado é o layout final do site. (Figura 12)

Daniel Nogueira 45


Figura 12 – Layout final do site

5.1 Conclusão

Este capítulo deu a conhecer os dois protótipos que deram origem ao

site final.

O primeiro protótipo mais numa perspectiva de suportar as

funcionalidades a implementar. O segundo já com uma perspectiva

de aperfeiçoamento e para a versão final.

Ambos os protótipos contribuíram para a construção do site final. Foi

essencial a existência deste capítulo para perceber como se chegou à

versão final do site.

Daniel Nogueira 46


6 Aplicação final

Este capítulo descreve a versão final do site. Esta versão resultou do

melhoramento das versões anteriores a nível de código e de design.

Nos seguintes sub-capítulos serão explicadas todas as

funcionalidades implementadas.

6.1 Estrutura do site e funcionamento geral

A estrutura do site é o esqueleto sobre o qual o site está montado.

Este esqueleto é feito com base em tabelas HTML (Extracto XX2) e o

aspecto visual como tipos de letras, cores e imagens de fundo são

definidos por CSS.

Existe uma tabela com uma linha e uma coluna que se ajusta ao

tamanho da janela do browser. Dentro desta tabela existe uma outra

que vai conter 4 células de margem para permitir que em diferentes

resoluções estas ocupem o espaço que poderá sobrar, pois a célula

central onde aparecerá o conteúdo do site tem tamanho fixo.

Também ao redimensionar a janela serão estas margens que se vão

ajustar.

A célula central ira conter mais uma tabela que será incluída através

do ficheiro ‘tabela_central.php’. Este ficheiro define então toda a

estrutura da página propriamente dita. Tem então uma tabela

principal com uma célula para se ajustar à célula central da tabela

anterior, e dentro desta nova célula contém uma nova tabela com 4

linhas. Na primeira linha aparece a imagem de topo e o menu de

botões, na segunda linha aparece o número de visitas, a zona de

login ou a barra de estado, na terceira linha, e muito importante para

o modo como se carregam as paginas, temos uma célula vazia que

tem como id ‘contentor’. O porque desta célula com id será explicado

mais à frente. E na última linha da tabela está alguma informação

sobre o site, como o email de apoio e data de actualização.

Daniel Nogueira 47


Extracto 2 – Estrutura do site

Este site não tem um funcionamento normal semelhante à maioria

dos sites. Normalmente num site com tabelas é criada primeiramente

a estrutura base, e a partir daí fazem-se todas as páginas com base

nessa estrutura. Quando se faz uma mudança de página, esta é

totalmente carregada, ou seja, as partes comuns que não

necessitariam de actualização são sempre carregadas, o que implica

maior tráfego de informação e maior tempo de carregamento.

Em alguns casos podem-se usar iframes para evitar o refrescamento

de uma página completa, então só o conteúdo do iframe será

actualizado.

FUNCIONAMENTO GERAL DO SITE

Neste site optei por fazer uso da ‘tecnologia’ Ajax do seguinte modo:

Como já foi referido atrás, existe uma célula que contém um id. Esta

célula será tratada como um contentor. Contentor este que vai ser o

suporte para o aparecimento dos dados relativos às novas páginas.

Assim sendo, só este contentor será actualizado na mudança de

página.

Existem vários ficheiros que contêm os dados que irão aparecer neste

contentor. Agora só falta fazer com que essa informação seja

Daniel Nogueira 48


carregada. Por exemplo, quando se clica no menu de botões para

vizualizar outras partes do site, a informação pretendida que estará

previamente definida em ficheiros terá que ser mostrada.

Para fazer aparecer o conteúdo desses ficheiros no contentor é usado

Ajax e DOM. Ajax para efectuar o pedido da página ao servidor, e

DOM para fazer aparecer o conteúdo da página no contentor.

Cada vez que é click um botão do menu é chamada uma função

(Extracto XX3) JavaScript que trata de efectuar o pedido das páginas.

Extracto 3 – Função que efectua o pedido das páginas por Ajax

Esta função faz o pedido da página pretendida e quando recebe os

dados do servidor, coloca-os no contentor.

Problemas deste método

Existem algumas desvantagens na utilização de Ajax para carregar as

páginas:

O código JavaScript contido nessas partes carregadas por Ajax

não funcionará, pois não é feito o parse do código.

Não será possível retroceder para as páginas visitadas.

Para resolver o primeiro problema, todas as funçoes JavaScript

necessárias para que as partes incluídas por Ajax funcionem existirá

Daniel Nogueira 49


num ficheiro ficheiro JavaScript de nome igual ao nome da pagina,

mas com extensão ‘.js’, e serão incluídos todos na pagina inicial.

Assim estarão disponíveis quando a parte da página correspondente

for carregada.

6.2 Estrutura de ficheiros

O site tem o nome de Protoreg e a estrutura de ficheiros é a seguinte:

Figura 13 – Estrutura de ficheiros

A pasta principal tem o nome de protoreg, dentro dela encontram-

se três pastas:

Img – pasta de imagens;

Includes – nesta pasta encontram-se várias pastas:

o Classes – está pasta contém uma classe PHP (phpmailer)

para o envio de mensagens de email;

o Css – contém os ficheiros de css;

o Funcs – contém uma função que faz a ligação à base de

dados quando é incluída num ficheiro php. Contém

também uma função para gerar as passwords.

o JPGraph – contém a classe JPGraph;

o Js – contém todos os ficheiros javascript

o Paging – contém um ficheiro para paginação que é usado

para paginar as notícias.

o Noticias – onde estão todos os ficheiros usados para as

notícias.

Daniel Nogueira 50


6.3 Ficheiro de configuração

Foi definido um ficheiro de configuração onde se definem vários

parâmetros. Se quisermos alterar a estrutura de ficheiros ou a

localização do site, basta-nos alterar as várias definições neste

ficheiro.

Também podemos mudar aqui os parâmetros de ligação à base de

dados.

Extracto 4 – Ficheiro de Configuração

Para que o ficheiro de configuração tenha a utilidade pretendida terá

que ser incluído em todos os ficheiros.

Surgiu um problema quando se tentava incluir este ficheiro, pois

dependendo da localização dos outros ficheiros o caminho variava. E

quando um ficheiro incluía outro que por sua vez incluía o ficheiro de

configuração o caminho relativo assumido era em relação ao primeiro

ficheiro. Então para resolver este problema foi criado um pequeno

módulo (Figura 12) que foi inserido em todos os ficheiros para fazer

incluir correctamente o ficheiro de configuração.

Daniel Nogueira 51


Extracto 5 – Módulo de inclusão do ficheiro de configuração

Explicação do funcionamento deste pequeno módulo:

A variável $level define o número de directórios a percorrer

para chegar à raiz. Se o ficheiro já se encontra na raiz o nível é

zero, se se encontra acima da raiz um directório o nível é 1;

Em primeiro lugar verificamos se está definida a variável $level

(nível);

o se não estiver definida, significa que o ficheiro não está a

ser incluído a partir de outro, e então o nível será o nível

desse ficheiro é relação à raiz;

o Se estiver definida, significa que o ficheiro está a ser

incluído noutro ficheiro e então a variável já terá o valor

correcto do nível do ficheiro que o incluiu.

Depois faz-se um pequeno ciclo que vai criar uma string com a

primeira parte do caminho relativo; Por exemplo:

o $level = 0; $x = “”;

o $level = 1; $x = “../”;

o $level = 2; $x = “../../”;

E por último inclui o ficheiro de configuração. Se o ficheiro já

tiver sido incluído antes não volta a ser incluído.

Daniel Nogueira 52


6.4 Sistema de autenticação

O sistema de autenticação permite que um utilizador não registado

na tenha acesso a algumas partes do site. Para fazer o controlo das

autenticações recorreu-se ao uso de variáveis de sessão.

Quando um utilizador entra no site, depois de inserir o email e a

palavra passe são criadas várias variáveis de sessão com alguma

informação sobre ele, como o nome, o tipo de utilizador, o número de

visitas e a data da última visita.

A validação do utilizador quando este introduz o email e a palavra

passe é efectuada utilizando uma função JavaScript e Ajax.

6.4.1 Do lado do cliente

Extracto 6 – Função validaLogin

Esta função em JavaScript recebe dois parâmetros, email e password

que foram inseridos pelo utilizador.

É criado um objecto da classe ‘sack’ responsável pela comunicação

com o servidor.

Define-se o ficheiro que se encontra no servidor e que vai ser

responsável pelo tratamento do pedido e envio da resposta, que é o

ficheiro “valida_login_ajax.php”.

Daniel Nogueira 53


Definem-se as variáveis email e password, e o método http de

transferência de dados, neste caso “POST”.

Pode também definir-se um elemento html HTML onde irá aparecer o

estado da comunicação.

Depois definimos quatro funções que vão sendo chamadas de acordo

com a evolução do pedido resposta.

Quando o pedido foi enviado e a resposta foi recebida a última função

analise o conteúdo da resposta e verifica então se o script do servidor

validou ou não o email e a password.

Se a resposta for “1” a autenticação foi bem sucedida, se a resposta

for diferente não teve sucesso e será apresentada uma mensagem de

erro.

A última linha de código desta função faz com que o pedido seja

efectuado. Só pode ser feito o pedido depois de bem definido o

objecto ‘sack’.

6.4.2 Do lado do servidor

O ‘server side script’ que valida o email e a password é apresentado a

seguir.

Daniel Nogueira 54


Extracto 7 – Valida login do lado do servidor

Este script recebe por “POST” as variáveis definidas no cliente (Figura

10). Efectua uma query à base de dados para verificar se o email e a

password existem e correspondem.

Se existe e correspondem então é actualizado o número de

autenticações do utilizador e são criadas as diferentes variáveis de

sessão.

6.5 Administração

Neste sub-capitulo vai ser apresentado o sistema de administração do

site. O sistema de administração é uma área do site onde só os

administradores têm acesso. É nesta área que os dados vão ser

importados através de ficheiros em formato (csv) recebidos dos

hospitais relativos aos casos de intoxicações alimentares.

Posteriormente esses dados serão tratados por uma pessoa

responsável.

Daniel Nogueira 55


Figura 14 – Zona de Administração

6.5.1 Importação de dados

Os dados hospitalares são recebidos através de ficheiros no formato

Comma Separated Value (csv). Para os introduzir na base de dados

foi criado um script que automaticamente faz essa importação.Este

script sofreu várias alterações desde a primeira versão porque os

dados recebidos nem sempre se encontravam no mesmo formato.

Figura 15 – Formato CSV dos dados recebidos

O primeiro valor (COD_PROTOREG) vai ser o código de registo na

tabela ‘Protoreg’, e a cada registo pode ter vários ‘DIARIO’. No

ficheiro csv várias linhas eram repetidas diferindo só no valor

‘DIARIO’. Ao ler o ficheiro linha a linha quando se encontra um novo

‘COD_PROTOREG’ diferente inserem-se todos os valores na tabela

‘Protoreg’ à excepção do ‘DIARIO’, que é inserido na tabela

‘Proto_diario’ juntamente com ‘COD_PROTOREG’ para que haja

associação entre o código e o diário.

Para cada linha em que o ‘COD_PROTOREG’ se repita são inseridos

somente o código e o diário na tabela ‘Protoreg’.

A cada código diferente é também inserido nas tabelas

‘Proto_diag_base’, ‘Proto_trata’ e ‘Proto_analises’ um registo para

Daniel Nogueira 56


fazer a relação entre estas tabelas e a tabela ‘PROTOREG’.

Inicialmente era um trigger que se encarregava de fazer esta

operação, mas SGBD onde iria ficar alojada toda a informação era de

uma versão anterior de MySQL que ainda não suportava triggers.

Figura 16 – Pop-up para importação dos dados

O ficheiro a importar terá que estar no formato correcto, caso

contrário aparecerá uma mensagem de erro não há alterações da

base de dados.

6.5.2 Inserir comentários nos registos

É possível que o responsável aquando do tratamento de dados queria

introduzir um comentário ou uma pequena nota sobre cada registo.

Para isso existe a possibilidade de inserir e editar o campo

comentário.

Esta funcionalidade utiliza a ‘tecnologia’ Ajax para comunicar com o

servidor e DOM para manipular dinamicamente os elementos HTML.

Ao carregar na imagem de editar aparece dinamicamente uma

caixa de texto que herda o texto que possa estar na célula

correspondente ao comentário. Então o utilizador insere o seu

comentário, e tanto pode cancelar como aceitar a mudança .

Se cancelar a caixa de texto desaparece e volta tudo ao estado

inicial;

Se aceita, é feito um pedido para o servidor onde é enviado o

texto com o comentário através de um HTTPRequest. Assim o

Daniel Nogueira 57


texto é gravado na base de dados quando o pedido chega ao

servidor, e o texto da célula é alterado para o texto que está na

caixa de texto e esta desaparece.

Isto tudo ocorre sem que haja refrescamento da página.

Entretanto, mesmo que o pedido de mudança não seja completo, o

utilizador poderá ir efectuando outras tarefas.

Figura 17 – Inserir comentário

Figura 18 – Comentário inserido

6.5.3 Tratamento de dados

A zona propriamente dita de tratamento dos é apresentada a seguir.

Aqui a pessoa responsável após ler e analisar o diário do paciente vai

introduzir alguns dados nesta área de acordo com vários parâmetros

que vão reflectir no fundo o porque da deslocação ao hospital entre

outros.

Daniel Nogueira 58


Figura 19 – Pop-up para edição/inserção de dados

Esta imagem é o pop-up que aparece quando se clica no número de

código na zona de administração (Figura 15).

Cada barra azul quando clicada, mostra ou esconde partes do

formulário que permite a introdução de dados. Depois de todos ou

alguns dados serem introduzidos, existem duas opções:

Aceitar – neste caso os dados contidos nos formulários são

submitidos por POST para outro script que se vai encarregar de

tratar os dados, fazer a ligação ao servidor e inserir ou

actualizar todos os dados. Quando este processo acabar

aparece uma mensagem a confirmar o sucesso da operação, e

volta-se automaticamente para a página de administração

inicial (Figura 15).

Fechar – os dados serão todos descartados e volta-se à página

inicial (Figura 15).

Daniel Nogueira 59


Figura 20 – Inserção de sintomas e antecedentes

Quando são expandidas as abas dos sintomas e antecedentes,

aparece a imagem anterior (Figura 21).

Na caixa da direita aparecem as opções. Podem ser seleccionados

vários ao mesmo tempo e envia-los para a caixa da esquerda.

Se o sintoma ou antecedente pretendido ainda não constar da base

de dados existe a possibilidade de adicionar um novo, inserindo na

caixa de texto e clicando em inserir.

Figura 21 – Inserção de agentes

Da mesma forma se procede para inserir novos agentes, com a

particularidade de que um agente pode ter tipo:

“bactéria”;

”vírus”;

“protozoário”.

Então existe uma caixa de selecção para indicar que tipo de agente

se vai introduzir.

Daniel Nogueira 60


O processo responsável por fazer estas inserções é feito recorrendo à

‘tecnologia’ Ajax e DOM e será apresentado a seguir com extractos de

código explicados.

Extracto 8 – Função doit

A função ‘doit’ recebe vários parâmetros e é capaz de tratar tanto da

inserção de sintomas, antecedentes, agentes possíveis e

identificados.

Explicação dos parâmetros recebidos:

campo – este parâmetro tem 3 valores possíveis,

o sintoma – no caso de sintoma;

o antecedente – no caso de antecedente;

o agente – para a inserção de agentes;

tipo – quando se trata de um agente este campo refere que tipo

de agente se trata:

o 1 – bactéria;

Daniel Nogueira 61


o 2 – vírus;

o 3 – protozoário;

o null – não existe tipo, pois não se trata de um agente.

value – é o texto que é inserido na caixa de texto, ou seja, o

nome do sintoma, do agente ou do antecedente;

tObj1 – este parâmetro é em todos os casos a caixa de selecção

mais à esquerda, que é onde vai ser inserida dinamicamente

através do DOM a nova opção inserida.

tObj2 – relativamente aos agentes, existem dois sítios

diferentes onde podem ser inseridos, na zona dos agentes

possíveis e nos agentes identificados (Figura 22). Então tem

que existir um segundo objecto de destino da nova opção. Este

último objecto é então a caixa da direita da zona onde não foi

inserido o agente, isto para que o agente fique logo disponível

nos dois lados.

Verificam-se depois estes parâmetros para identificar que tipo de

inserção vai ser efectuada. Usa-se mais uma vez a classe sack para

comunicar com o servidor. Então vão ser enviadas as seguintes

variáveis por POST:

value – esta variável é enviada com o nome igual ao campo. Por

exemplo: setVar(‘sintoma’,’nome do sintoma’) e

setVar(‘antecendete’,’nome do antecedente’). Então no lado do

servidor dependendo do tipo de campo vai existir uma variável

POST: $_POST[‘sintoma’] ou $_POST[‘antecedente’] …

tipo – se o tipo for deferente de null é enviada também uma

variável para dar informação do tipo de agente.

É enviado entaoentão então o pedido ao script ‘insert_saa.php’ que se

encontra no servidor e que se vai responsabilizar por inserir a

informação na base de dados.

Daniel Nogueira 62


Extracto 9 – Primeira parte do script ‘insert_saa.php’

Esta é a primeira parte do código do script que recebe o pedido do

lado do servidor. Começa-se por definir uma variável de controlo e

um cabeçalho XML.

Verifica-se então as variáveis POST recebidas para determinar qual

vai ser a inserção.

Daniel Nogueira 63


Extracto 10 – Segunda parte do script ‘insert_saa.php’

Se a variável de controlo tiver activa (com valor 1) significa que já

está definida qual a acção a tomar. Tem que se descodificar o texto

recebido por POST, pois este sofre uma codificação antes de ser

enviado ao servidor. De seguida é definida uma query sql

dependendo do tipo e campo, que vai ser executada para verificar se

o valor a inserir já se encontra na tabela correspondente. Se for

repetido não se vai inserir novamente, e é então criado um pequeno

texto XML que vai ser enviado ao cliente com dando a informação que

está repetido. No caso texto XML é o seguinte:

Extracto 11 – Resposta XML (Repetido)

Se não está repetido é criada a string sql adequada para fazer a

inserção, e regista-se qual foi o id com que o registo ficou e envia-se

como resposta para o cliente:

Daniel Nogueira 64


Extracto 12 – Resposta XML (Inserido)

Se por algum motivo ocorrer algum erro ao fazer o insert na base de

dados é enviada a seguinte resposta:

Extracto 13 – Resposta XML (Erro)

Quando a resposta é recebida pelo cliente, este analisa o texto XML

para determinar o sucesso da operação. Se ocorreu com sucesso o

sintoma, agente ou antecedente é inserido dinamicamente através de

DOM na caixa de selecção. A função responsável por tratar a resposta

XML é explicada mais à frente e é chamada quando o pedido ao

servidor é totalmente completo:

Extracto 14 – Função executada quando o pedido é completado

No extracto seguinte pode-se visualizar a chamada da referida

função, que leva como parâmetro a string XML contida na resposta.

Daniel Nogueira 65


Extracto 15 – Primeira parte da função newCampo

Nesta função é criado um objecto XML com base na string recebida.

Existem diferenças no modo de criação deste objecto entre o Internet

Explorer e o FireFox, para isso é necessário identificar qual o browser

que está a ser usado. Depois de criado o objecto, existem também

algumas diferenças nos métodos para percorrer o objecto XML

nomeadamente para aceder ao valor de um nodo. No caso do Internet

Explorer é usada a propriedade node.text enquanto que no FireFox é

node.firstChild.data.

A informação útil que vai ser retirada deste objecto é o nome do

primeiro nodo, o atributo id e o texto. O nome do nodo dá-nos

indicação se estamos perante um sintoma, um antecedente ou um

agente.

Daniel Nogueira 66


Extracto 16 – Segunda parte da função newCampo

Verificamos se o id é -1 ou -2 para o caso de ter ocorrido alguma

excepção. Caso contrário é criado um objecto HTML (Option) que vai

ser adicionado através do HTML DOM na caixa de selecção destino

(targetObj1). Se ‘targetObj2’ está definido, no caso dos agentes, é

criado outro objecto Option e é inserido na outra caixa de selecção

como foi referido anteriormente.

6.6 Contador de visitas

O contador de visitas é controlado por uma variável de sessão. O

objectivo dessa variável é impedir que seja contabilizada uma visita

pelo simples facto de se fazer um refresh à página.

Extracto 17 – Chamada da função incrementa_visitas

Daniel Nogueira 67


Quando carrega a página principal (index.php), verifica se existe já

definida a variável de sessão. Se não existe significa que é a primeira

vez na sessão que o utilizador acede à página, e neste caso é então

criada a variável que vai ficar com o número de visitas actual mais

um.

Extracto 18 – Função incrementa_visitas

Para isso usa-se a função incrementa_visitas que determina qual o

número de visitas que se encontra na base de dados na tabela

‘visitas’, depois incrementa o valor em um, actualiza o campo e

retorna o valor actual para a variável de sessão.

Enquanto esta estiver definida, ou seja, enquanto o browser não for

desligado o número de visitas não será mais aumentado. Evitando

assim a incrementação abusiva do número de visitas.

6.7 Estatísticas

O sistema de divulgação estatística dos dados é talvez a parte mais

importante do site. Permite os utilizadores registados de uma forma

simples e intuitiva ter a noção destes problemas que são as

intoxicações alimentares. Nesta primeira fase do projecto apenas

foram criados gráficos 3 tipos de gráficos:

Totais presumíveis;

Totais presumíveis por sexo;

Totais presumíveis por faixa etária.

Estes gráficos estão predefinidos, e reflectem os dados existentes a

cada momento na base de dados. Estão constantemente

actualizados.

Daniel Nogueira 68


Figura 22 – Gráfico de totais presumíveis

Figura 23 – Gráfico de totais presumíveis por sexo

Daniel Nogueira 69


Figura 24 – Gráfico de totais presumíveis por faixa etária

O utilizador poderá ainda obter gráficos personalizados:

Entre duas datas (Figura 25);

De vários meses de vários anos, isto é, por exemplo (Figura 26):

o Vários meses de um ano;

o Vários meses de vários anos;

o Um mês de vários anos;

Figura 25 – Gráficos entre duas datas

Figura 26 – Gráficos personalizados

Quando é definido e visualizado um gráfico (Figura 27) é sempre

possível imprimir, para que este possa ficar registado em papel.

Daniel Nogueira 70


Figura 27 – Personalização de gráficos

Quando se clica em ‘imprimir’ aparece-nos um pop up com o gráfico a

imprimir. A razão pela qual se cria este pop up é que a função print()

de JavaScript imprime tudo o que estiver na janela, por isso com o

pop up só se imprime o gráfico evitando imprimir as partes que não

nos interessam (Figura 28).

Figura 28 – Pré-visualização dos gráficos para imprimir

Daniel Nogueira 71


6.7.1 Estrutura da zona de estatística

Todo este processo de construção e visualização dos gráficos tem por

base o uso da classe JPGraph. A esta classe possibilita a criação de

vários tipos de gráficos, mas vão ser só usados os gráficos de barras.

Resumidamente, existem três scripts PHP que recebem alguns dados

por GET da página de personalização (Figura 26 e 27). Estes scripts

tratam os dados e retornam uma imagem que corresponde ao

gráfico. Na página de personalização existe um div escondido que

contem uma imagem sem url. Através de funções JavaScript vão ser

validados os valores inseridos na página, e então é dinamicamente

através de DOM atribuído um novo url à imagem dentro do div

escondido e este é mostrado. O url será o nome do script PHP

responsável pela criação e retorno do gráfico pretendido.

6.7.2 Criação dos gráficos

Para auxiliar a criação dos gráficos a informação das tabelas foi

organizada em views:


data datetime Data do registo

ano bigint(21) Ano do registo

mes bigint(21) Mês do registo

totais bigint(21)Totais de casos agrupados relativos ao

ano/mes

confmedico bigint(21)Totais de casos agrupados relativos ao

ano/mes

confanalise bigint(21)Totais de casos agrupados relativos ao

ano/mes

Tabela 18 – View totaispres

Esta view agrupa os dados por ano e por mês, assim dá-nos a

informação mais organizada dos totais de casos. O campo ‘data’ é do

tipo date, e serve exclusivamente para permitir ordenar e agrupar os

valores na tabela por data. Os campos ‘ano’ e ‘mes’

Daniel Nogueira 72




f1 bigint(21) Totais da faixa etária 1





Tabela 19 – View pfe_2

Esta view agrupa os dados por data e por faixa etária.



masculino bigint(21) Totais masculino

feminino bigint(21) Totais feminino

Tabela 20 – View sexopordia

Esta view agrupa os dados por dia, depois teremos que ‘pegar’ nesta

view e agrupar da forma necessária.

6.7.3 Explicação do código

Para ser possível a criação dos gráficos de barras é necessário incluir

os seguintes ficheiros:

Extracto 19 – Incluindo ficheiros

Define-se o título do gráfico, o título das abcissas e um array com as

iniciais dos meses que vão ser usadas para identificar a que mês

corresponde as barras dos gráficos.

Extracto 20 – Definindo títulos e nome dos meses

Daniel Nogueira 73


Determinam-se quais os dados recebidos para se identificar qual vai

ser o processo para criação do gráfico. Existem as duas possibilidades

já referidas:

Entre duas datas;

Vários meses/vários anos

Para cada um deles os dados enviados por GET variam.

Se estão definidas as variáveis $GET[‘ini’] e $_GET[‘fim’] então é

entre duas datas, caso contrário é a outra possibilidade.

Com dois ciclos for aninhados, o primeiro a percorrer os anos a

começar no ano inicial até ao final, o segundo a percorrer do mês

inicial até ao final. Para cada iteração vão sendo criados os arrays

com os valores para cada mês de cada ano inicializados a zero, e um

array com a string mês/ano correspondente.

Depois é criada a string sql responsável por extrair os dados da base

de dados com base nas views acima referidas.

Daniel Nogueira 74


Extracto 21 – Verificação de Variáveis

Se não estão definidas estas variáveis GET então o processo é

diferente.

Verificam-se então outras variáveis definidas, e de acordo com a

existência ou não de certas variáveis, vai ser definido um tipo de filtro

diferente que vai ser útil para determinar qual a string sql que terá de

ser usada.

Daniel Nogueira 75


Extracto 22 – Continuação do extracto anterior

Depois de determinado o tipo de filtro define-se a string sql. Caso o

filtro seja zero, é logo executada a query e determinados os valores.


Se o filtro for diferente de zero é necessário executar a query definida

para determinar os arrays de dados e determinar a escala com base

no valor mais alto.

Daniel Nogueira 76


Como os arrays podem conter valores meses/anos inicializados a zero

que não foram reescritos com dados novos, então serão eliminados

com os ciclos foreach no extracto de código a seguir.


Neste momento os arrays de dados estão prontos, e só nos resta

definir o gráfico e os seus atributos.

A largura e altura do gráfico é calculada em função do tamanho de

posições dos arrays, ou seja, quantos mais posições no array mais

largo terá que ser o gráfico.

O extracto a seguir está bem comentado e percebe-se facilmente

qual é o objectivo de cada método.

Daniel Nogueira 77



Daniel Nogueira 78


6.8 Notícias

As notícias podem ser consultadas por todos os utilizadores

registados. Existe uma barra de navegação que permite ao utilizador

saltar de página em página, e um campo de pesquisa em que se pode

pesquisar por palavra.

Figura 29 – Zona de notícias

Toda a zona onde aparecem as noticias, a barra de pesquisa e a barra

de navegação é um iframe, assim evita que tenha que se refrescar a

página toda só para saltar de uma página para outra.

Na base de dados o título e o texto da notícia não necessitam ter

estilo definido, pois quando são escritas na página são inseridas

dentro de tabelas que contém aplicado um estilo CSS. Portanto, se

por qualquer motivo for necessário alterar a cor, o tipo ou tamanho

de letra, etc, basta alterar o estilo CSS correspondente.

Daniel Nogueira 79


Ao serem carregadas as notícias na página, só aparece o texto inicial.

Isto permite que o utilizador identifique melhor as notícias que lhe

interessam.

Para visualizar todo o texto de uma notícia basta clicar no título ou

nos três pontinhos entre parênteses (…).

Ao ser clicado um destes itens, a página de notícias anterior (Figura

29) vai ser escondida e é mostrado um div que contém o texto

completo da notícia (Figura 30).

Figura 30 – Visualização de uma notícia

Depois de lida a notícia, ao clicar em ‘voltar’ ou na imagem o div

com o texto é escondido e a página de notícias passa para o estado

visível.

Ao ser pesquisada uma palavra, aparecem todas as notícias onde

essa palavra ocorre, e a palavra aparecerá com fundo amarelo como

na Figura 31.

Daniel Nogueira 80


Figura 31 – Pesquisando por palavra-chave

Problemas encontrados:

Para que apareça apenas o texto inicial das notícias nas páginas, é

necessário dividir o texto. O método utilizado foi:

Ler o texto da notícia;

Criar um array com as palavras todas;

Escrever só as primeiras 100 palavras;

Como o texto pode conter código HTML, algumas tags poderiam não

ser fechadas, e isso iria causar má formatação no resto da página.

Para contornar esse problema foi criada uma classe (ANEXO X3) que

processa uma string com as primeiras 100 palavras do texto. Caso

nessa string existam tags HTML abertas e não sejam terminadas, esta

classe tratará de as fechar. Assim o código HTML fica correcto e a

página ficará como se pretende.

Daniel Nogueira 81


Caso o código HTML esteja mal formatado já na base de dados, esta

classe poderá não ser eficaz. Pois só serão fechadas correctamente as

últimas tags abertas.

6.8.1 Inserir notícias

Os administradores serão as pessoas responsáveis pela inserção de

notícias. O link para esta página (Figura 14) está na zona de

administração (Figura 14).

Figura 32 – Zona de inserção de notícias

É usado um editor HTML, FCKEditor [10]. Este editor funciona todo

sobre JavaScript, é um editor muito completo e muito parecido com o

Microsoft Word.

Este processo de inserção de notícias funciona com a ‘tecnologia’

Ajax e JavaScript DOM, e que faz com que se assemelhe a uma

aplicação desktop.

Funcionamento

Depois de inserido o título e texto da notícia, podemos escolher se a

noticia vai ficar logo publicada, ou se vai só ficar guardada.

Daniel Nogueira 82


Ao clicar em guardar é usado um objecto da classe sack como já foi

explicado anteriormente.

Extracto 26 - Função que comunica com o servidor para tratar notícias

Esta função é responsável por efectuar o pedido ao servidor, onde

define a acção e os dados a enviar.

O script ‘inserir_s.php’ está à espera do lado do servidor, e quando o

pedido chega verificam-se os dados recebidos e determina-se a acção

a executar.

Inserir – determina o texto, o título e se a notícia vai ser

publicada ou não.

o Determina a data de sistema para atribuir à data de

criação da notícia;

o Cria a string sql para inserir a notícia na base de dados;

o Depois de inserido na base de dados determina o id

inserido;

o Prepara a resposta XML e envia para o cliente;

Daniel Nogueira 83


Extracto 27 – Extracto da verificação da acção no servidor

Extracto 28 – Função que escreve a resposta XML no servidor

A razão pela qual o texto é codificado é que não podemos colocar

código HTML dentro de tags XML, pois não há distinção entre as tags,

e as tags seriam tratadas como se fossem todas XML.

Assim o texto é codificado para poder ser enviado, e quando chega ao

cliente, depois deste ter retirado a informação que cada tag contém é

então descodificado para se obter o valor original.

A função que trata da resposta é a seguinte:

Daniel Nogueira 84


Extracto 29 – Função que trata a resposta XML recebida do servidor

Na página de inserção de notícias existem algumas variáveis globais

que dão informação a cerca do estado da notícia em processamento.

Extracto 30 – Variáveis de controlo

Extracto 31 – Variáveis temporárias de controlo

A função ‘trataResposta’ (Extracto 29) percorre o objecto XML e retira

toda a informação necessária para preencher as variáveis

temporárias.

Daniel Nogueira 85


Depois disto, e dependendo da acção executada, as variáveis

temporárias vão ser atribuídas às outras variáveis.

Extracto 32 – Continuação da função trataResposta

No caso de uma inserção ou actualização, o tratamento é igual. Caso

seja abrir, para além desta atribuição de variáveis, tem que se

introduzir o texto e título recebido no editor. Para isso é usada a API

do FCKEditor, em que instanciamos a caixa de texto do editor e

usando o método SetHTML conseguimos definir qual o texto para

aparecer no editor (Extracto 33).

Extracto 33 – Utilizando a API do FCKEditor

Em qualquer altura é possível abrir uma notícia, para editar ou alterar

o estado de publicação.

Daniel Nogueira 86


Ao clicar em abrir aparece o seguinte popup, que carrega por Ajax o

título das notícias disponíveis e cria a combo box com esses títulos.

Quando se atingir um número grande de noticias este método deixa

de ser eficaz, e terá que ser alterado. Serão inicialmente carregadas

apenas as últimas notícias, com opção de escolher entre duas datas.

Uma vez que o projecto vai ser continuado, será implementado mais

tarde.

Figura 33 – Popup para abrir notícia

Este popup é gerado dinamicamente e em tempo de execução

quando se clica em ‘abrir’ (Ffigura XX32) que chama a seguinte

função.

Extracto 34 – Função abrir

O extracto anterior contém o código responsável pelo aparecimento

do popup da Figura 33.

Seleccionando uma notícia e carregando em ‘Abrir notícia’ será

chamada outra função ‘abrir’ que está definida no ficheiro

‘abrir_noticia.js’ incluído.

Daniel Nogueira 87


Extracto 35 – Função abrir (no ficheiro abrir_noticia.js)

Esta função por sua vez chama a função ‘ajax’ explicada

anteriormente (extracto 26) com os argumentos ‘accao = abrir’ e ‘id

= id_noticia’. Então como já foi visto é feito um pedido ao servidor

com a acção de abrir.

O servidor envia o XML como resposta para o cliente em que o

formato é o seguinte.

Extracto 36 – Resposta XML do servidor

6.9 Registo

O formulário de registo (Figura XX34) é uma parte muito importante

do site, uma vez que é o caminho que um utilizador tem que

percorrer para poder aceder a todas as funcionalidades do site.

Daniel Nogueira 88


Figura 34 – Zona de registo

Os campos obrigatórios são assinalados com asteriscos. O conteúdo

destes campos é validado por funções JavaScript com expressões

regulares, como é o exemplo da validação do email (Figura XX35).

Extracto 37 – Função para validar email

Depois de todos os campos estarem validados, antes de submeter o

formolário, vamos ainda verificar se o email já está em uso. Caso o

Daniel Nogueira 89


email esteja já a ser utilizado não será possível efectuar o registo.

Entao aparecerá uma mensagem JavaScript a avisar da repetição de

email e o campo ficará vermelho.

Figura 35 – Mensagem de email já registado

O processo de verificação do email é feito no servidor e é efectuado

recorrendo ao Ajax. Neste caso não foi utilizada a classe sack, pois

ainda não tinha sido descoberta.

Extracto 38 – Variáveis globaisVariáveis globais

Este é um método mais primitivo de usar Ajax e é a melhor maneira

para compreender o seu funcionamento.

São então definidas 4 variáveis globais (Extracto 38):

http – objecto XMLHttpRequest criado pela função

‘getHTTPObject’;

url – localização do server side script;

Daniel Nogueira 90


isWorking – para controlar que só pode estar a fazer um pedido

de cada vez.

EmailValido – no fim da resposta recebida esta variável diz-nos

se o email foi validado ou não.

Extracto 39 – Função para criar o objecto XMLHttpRequest

Esta função é multi-plataforma, funciona em Mozilla, Firefox, Safari,

Opera e Internet Explorer.

Extracto 40 – Função que faz a comunicação com o servidor

Daniel Nogueira 91


Esta função faz o pedido por Ajax. Verifica se o objecto http está

definido e se não está a ser usado. Acrescenta a string email no url

para enviar por GET, e faz o pedido ao servidor.

Este pedido passa por 4 estados (http.readyState):

1 – os dados estão a ser enviados;

2 – os dados foram enviados;

3 – a resposta esta a ser recebida;

4 – a resposta foi totalmente recebida.

Cada mudança de estado é detectada pela propriedade

onreadystatechange que vai chamar a função responsável por

verificar qual o estado do pedido e efectuar as operações necessárias.

A função seguinte (Extracto 41) é chamada sempre que o estado do

pedido muda, verificando qual é o estado. Para os estados 1,2 e 3 faz

aparecer apenas um div com a informação do estado do pedido

(Figura 36).

Daniel Nogueira 92


Extracto 41 – Função handleHttpResponse

Figura 36 – Div com estado do pedido

Daniel Nogueira 93


Quando o estado é 4 o div com a informação é escondido, e é

verificada a resposta do servidor:

‘0’ – o email já existe, então não pode ser registado novamente;

‘1’ – o email ainda não está registado.

O script que trata o pedido no servidor e verifica se o email pode ou

não ser registado é tem como nome ‘_validaEmail.php’ e é

apresentado a seguir:

Extracto 42 – Código no servidor que verifica se o email já está

registado

Este script é simples, apenas faz uma query à base de dados para

verificar se o email já existe. Se existe a resposta é negativa, caso

contrário e resposta é positiva e o email poderá ser registado.

Depois de verificado o último estado do pedido (Extracto 41) a

resposta é analisada, e temos entao duas possibilidades:

‘EmailValido = 0’ – aparecerá uma mensagem de erro (Figura

37);

‘EmailValido = 1’ – aparecerá uma mensagem a confirmar o

sucesso do registo (Figura 37);

Daniel Nogueira 94


Figura 37 – Mensagem de erro ao registar

Figura 38 – Mensagem de sucesso do registo

Daniel Nogueira 95


No caso de sucesso do registo, é enviado um email com a password

de acesso ao site.

É utilizada uma função que gera a password (Extracto 43) e uma

classe de envio de email para gerar o email a enviar (Extracto 44).

Extracto 43 – Função para gerar a password

Extracto 44 – Gerar email a enviar

6.10 Conclusão

A versão final do site é o conjunto de todas as funcionalidades

implementadas agregadas ao desenho que é a interface.

Este capítulo descreve o princípio fundamental de funcionamento

geral do site. São apresentados a estrutura de ficheiros e os métodos

tomados para a resolução dos problemas. Através da explicação de

extractos de código e imagens da interface tenta-se dar a entender

as soluções tomadas para as funcionalidades mais importantes.

Daniel Nogueira 96


7 Conclusão

Neste capítulo será feito o rescaldo final do trabalho realizado, serão

focados vários pontos como: objectivos atingidos, melhoramentos

possíveis e trabalho futuro, dificuldades encontradas, conhecimentos

adquiridos e uma apreciação final.

7.1 Objectivos atingidos

O objectivo inicial era o desenvolvimento de um site que permitisse a

criação de uma plataforma de tratamento e divulgação de dados

relativos a intoxicações alimentares sob a forma de gráficos e uma

zona de registo de utilizadores.

Estes objectivos foram atingidos. O sistema é capaz de dar suporte ao

tratamento dos dados e à sua divulgação, e é possível o registo de

utilizadores.

As zonas de administração e publicação de notícias surgiram como

objectivos secundários e foram também cumpridos. O sistema é

capaz de dar suporte à criação e publicação de notícias.

No decorrer do projecto houve bastantes alterações ao nível dos

requisitos e a base de dados foi constantemente alterada. Esta

situação provocou algum atraso na calendarização planeada.

Neste momento o projecto encontra-se concluído e operacional,

estando a empresa bastante satisfeita com o resultado final.

O site pode ser consultado no seguinte link: www.protoreg.org.

7.2 Melhoramentos possíveis e trabalho futuro

Com os testes à aplicação chegou-se a conclusão que algumas

funcionalidades e outras novas poderiam ser alteradas ou

acrescentadas, nomeadamente:

Criação de um fórum de discussão;

Criação de novos tipos de gráficos para darem outros tipos de

informação, como por exemplo: números de casos por distrito,

Daniel Nogueira 97

http://www.protoreg.org/


quais os distritos mais afectados por determinado tipo de

intoxicações, etc.

Criação de outras funcionalidades como por exemplo:

possibilidade de alteração de password, etc.

7.3 Dificuldades encontradas

Foram encontradas algumas dificuldades ao longo da vida do projecto

que estão explicadas a seguir.

Constante alteração dos requisitos

Ao longo do desenvolvimento do projecto surgiram novos requisitos, e

algumas alterações que não estavam pensadas no início. Isso teve

implicações ao nível da base de dados mas que foram facilmente

analisadas e ultrapassadas. Em consequência destas alterações,

também algumas partes do site tiveram que ser repensadas,

nomeadamente na área de tratamento dos dados na zona de

administração, mas que foram também facilmente ultrapassadas.

Falta de experiência

A falta de experiência é sempre um contra-tempo, pois é necessário

mais tempo para perceber o problema, pensar nas soluções, definir

um algoritmo e implementar numa linguagem que estamos a

aprender. Também para definir a interface é um processo moroso.

O objectivo deste estágio foi no sentido de melhorar essas lacunas,

algo que foi plenamente alcançado.

7.4 Conhecimentos adquiridos

Foram aprofundados conhecimentos de HTML, XML, CSS e JavaScript.

Este projecto permitiu aprofundar conhecimentos de HTML, XML, CSS

e JavaScript e obter novos conhecimentos de tecnologias não

abordadas durante o curso, por exemplo:

PHP – Foi muito importante adquirir conhecimentos de PHP, pois

é uma linguagem muito interessante, muito útil e é muito

utilizada;

Daniel Nogueira 98


Ajax – Aprender Ajax foi uma experiência muito enriquecedora,

pois permitiu adquirir conhecimentos desta nova tecnologia e

entender quais as suas potencialidades e as verdadeiras

vantagens do seu uso;

JPGraph – Explorar a criação de gráficos estatísticos em PHP

recorrendo à classe JPGraph.

MySQL – Foram adquiridos conhecimentos no uso deste SGBD,

assim como do utilitário phpMyAdmin que permite interagir com

o MySQL.

7.5 Apreciação final

O desenvolvimento deste site foi um grande desafio. Não só permitiu

a aquisição de conhecimentos de novas tecnologias, como a

realização de um site de raiz. Isto levou a uma maior motivação, pois

foi possível ganhar conhecimentos a todos os níveis, tanto a nível de

programação, como na análise do problema.

Inicialmente, o que mais me motivou no projecto foi a ideia de utilizar

tecnologias novas que não são leccionadas no curso de engenharia

informática como o caso do PHP, AJAX, Apache e MySQL o que

permitiu obter conhecimentos muito alargados.

Em jeito de conclusão e em traços genéricos, o projecto foi muito

gratificante de realizar, pois, como já referi anteriormente, permitiu

adquirir um vasto número de conhecimentos e experiência

profissional.

Daniel Nogueira 99


8 Bibliografia

[1]

Introdução à linguagem HTML,

http://www.infodesktop.com/web/html/artigocompleto/1,

último acesso em 24-06-2006

[2]

Introdução ao CSS

http://www.hugoduraes.com/2006/05/04/introducao-as-

cascading-style-sheets-css/,


[3]

Introdução ao PHP,

http://www.truquesedicas.com/tutoriais/php/basico/00001a.htm,


[4]

Trabalhando com imagens em PHP

http://www.imasters.com.br/artigo/2116,


[5]

XML nas bibliotecas digitais,

http://www.bibliosoft.pt/projectoxml/_introducao.htm, último

acesso em 24-06-2006

[6]

Ajax: A New Approach to Web Applications,

http://www.adaptivepath.com/publications/essays/archives/

000385.php, último acesso em 24-06-2006

[7]

http://www.informationweek.com,


[8]

Daniel Nogueira 100

http://www.informationweek.com/nopagefound.jhtml

http://www.adaptivepath.com/publications/essays/archives/000385.php

http://www.adaptivepath.com/publications/essays/archives/000385.php

http://www.bibliosoft.pt/projectoxml/_introducao.htm

http://www.imasters.com.br/artigo/2116

http://www.truquesedicas.com/tutoriais/php/basico/00001a.htm

http://www.hugoduraes.com/2006/05/04/introducao-as-cascading-style-sheets-css/

http://www.hugoduraes.com/2006/05/04/introducao-as-cascading-style-sheets-css/

http://www.infodesktop.com/web/html/artigocompleto/1


Ajax mistake, http://swik.net/Ajax/Ajax+Mistakes, último acesso

em 24-06-2006

[9]

Daniela Costa (2005), “Gestor de conteúdos”, ISEP, Porto,

Portugal, Set 2005

[10]

The editor for Internet,

http://www.fckeditor.net/,


[11]

Banco de dados PostgreSQL e MySQL,

http://www.infowester.com/postgremysql.php,


Daniel Nogueira 101

http://www.infowester.com/postgremysql.php

http://www.fckeditor.net/

http://swik.net/Ajax/Ajax+Mistakes


9 Anexos

Daniel Nogueira 102


ANEXO 1

function sack() {

this.xmlhttp = null;

this.resetData = function() {

this.method = "POST";

this.queryStringSeparator = "?";

this.argumentSeparator = "&";

this.URLString = "";

this.encodeURIString = true;

this.execute = false;

this.element = null;

this.elementObj = null;

this.requestFile = file;

this.vars = new Object();

this.responseStatus = new Array(2);

this.mimeType=mType;

};

this.resetFunctions = function() {

this.onLoading = function() { };

this.onLoaded = function() { };

this.onInteractive = function() { };

this.onCompletion = function() { };

this.onError = function() { };

this.onFail = function() { };

};

this.reset = function() {

this.resetFunctions();

this.resetData();

};

Extracto 45 - Classe Sack (Parte 1)

Esta classe é muito útil para trabalhar com a tecnologia Ajax,

simplifica a criação do objecto XMLHttpRequest e os pedidos ao

servidor.

Daniel Nogueira 103


this.createAJAX = function() {

try {

this.xmlhttp = new ActiveXObject("Msxml2.XMLHTTP");

} catch (e1) {

try {

this.xmlhttp = new ActiveXObject("Microsoft.XMLHTTP");

} catch (e2) {

this.xmlhttp = null;

}

}

if (! this.xmlhttp) {

if (typeof XMLHttpRequest != "undefined") {

this.xmlhttp = new XMLHttpRequest();

if(this.mimeType != "")//adicionado por DANOG

this.xmlhttp.overrideMimeType(this.mimeType

} else {

this.failed = true;

}

}

};

this.setVar = function(name, value){

this.vars[name] = Array(value, false);

};

this.encVar = function(name, value, returnvars) {

if (true == returnvars) {

return Array(encodeURIComponent(name),encodeURIComponent(value));

} else {

this.vars[encodeURIComponent(name)]=

Array(encodeURIComponent(value), true);

}

}


Daniel Nogueira 104


this.processURLString = function(string, encode) {

encoded = encodeURIComponent(this.argumentSeparator);

regexp = new RegExp(this.argumentSeparator + "|" + encoded);

varArray = string.split(regexp);

for (i = 0; i < varArray.length; i++){

urlVars = varArray[i].split("=");

if (true == encode){

this.encVar(urlVars[0], urlVars[1]);

} else {

this.setVar(urlVars[0], urlVars[1]);

}

}

}

this.createURLString = function(urlstring) {

if (this.encodeURIString && this.URLString.length) {

this.processURLString(this.URLString, true);

}

if (urlstring) {

if (this.URLString.length) {

this.URLString += this.argumentSeparator + urlstring;

} else { this.URLString = urlstring; }

}

// prevents caching of URLString

this.setVar("rndval", new Date().getTime());

urlstringtemp = new Array();

for (key in this.vars) {

if(false==this.vars[key][1]&& true == this.encodeURIString){

encoded = this.encVar(key, this.vars[key][0], true);

delete this.vars[key];

this.vars[encoded[0]] = Array(encoded[1], true);

key = encoded[0];

}

urlstringtemp[urlstringtemp.length]=key+"="+this.vars[key][0];

}

this.URLString += urlstringtemp.join(this.argumentSeparator);

}


Daniel Nogueira 105


this.runAJAX = function(urlstring) {

if (this.failed) {

this.onFail();

} else {

this.createURLString(urlstring);

if (this.element) {

this.elementObj =

document.getElementById(this.element);

}

if (this.xmlhttp) {

var self = this;

if (this.method == "GET") {

totalurlstring=this.requestFile+

this.queryStringSeparator+this.URLString;

this.xmlhttp.open(this.method, totalurlstring, true);

} else {

this.xmlhttp.open(this.method, this.requestFile,

true);

try {

this.xmlhttp.setRequestHeader("Content-Type",

"application/x-www-form-urlencoded")

} catch (e) { }

}


Daniel Nogueira 106


this.xmlhttp.onreadystatechange = function() {

switch (self.xmlhttp.readyState) {

case 1: self.onLoading(); break;

case 2: self.onLoaded(); break;

case 3: self.onInteractive();break;

case 4: self.response =

self.xmlhttp.responseText;

self.responseXML = self.xmlhttp.responseXML;

self.responseStatus[0] = self.xmlhttp.status;

self.responseStatus[1] = self.xmlhttp.statusText;

if (self.execute) {self.runResponse();}

if (self.elementObj) {

elemNodeName = self.elementObj.nodeName;

elemNdeName.toLowerCase();

if (elemNodeName == "input"|| elemNodeName == "select"

|| elemNodeName == "option"

|| elemNodeName == "textarea") {

self.elementObj.value = self.response;

} else { self.elementObj.innerHTML = self.response; }

}

if(self.responseStatus[0]== "200") { self.onCompletion();

} else { self.onError(); }

self.URLString = "";

break;

}

};

this.xmlhttp.send(this.URLString);

}

}

};

this.reset(); this.createAJAX();

}


Daniel Nogueira 107


ANEXO 2

Este documento apresentado a seguir foi a base para a análise do

problema proposto.

Dados do doente

Data de admissão:

Idade:

Sexo:

Distrito:

Motivo de deslocação ao hospital

Sintomas:

a) vómitos b) diarreia (características)c) dores abdominais fortesd) febree) dores muscularesf) suoresg) dores nas articulaçõesh) visão dupla i) pálpebras caídasj) dificuldade de deglutiçãok) abortamento ou parto prematurol) cor da urina alteradam) icterícian) outros

Factores de predisposição/Antecedentes:

a) Transplantadob) Doente oncológicoc) Diabetesd) HIVe) Alcoolismof) Gravidezg) Doença hepática crónicah) outros

Diagnóstico Provável

a) Intoxicação/Infecção Alimentar

b) Outro

Diagnóstico com base

a) sintomasb) análises laboratoriais (qual o produto analisado)*

Daniel Nogueira 108


c) outro

Doente tem alta

a) Simb) Não

Tratamento

a) antibioterapia

b) outro

Duração da sintomatologia

Evolução clínica

Agentes etiológicos possíveis

Bactérias

Brucella spp.

Bacillus cereus

Campylobacter spp.

Clostridium botulinum

Clostridium perfringens

Escherichia coli (em particular O157:H7)

Listeria monocytogenes

Salmonella spp.

Shigella spp.

Staphylococcus aureus

Vibrio cholerae

Vibrio parahaemolyticus

Vibrio vulnificus

Yersinia enterocolitica

Yersinia pseudotuberculosis

Vírus

Hepatite A

Daniel Nogueira 109


Norovirus

Rotavírus

Protozoários

Giardia lamblia

Toxoplasma gondii

Cryptosporidium spp.

Análises Pedidas

a)Sim

b)Não

Pedir resultados de análises ao hospital

a)Sim

b) Não

Diagnóstico confirmado

a) Simb) Não

Agentes etiológicos identificado

Bactérias

Brucella spp.

Bacillus cereus

Campylobacter spp.

Clostridium botulinum

Clostridium perfringens

Escherichia coli (em particular O157:H7)

Listeria monocytogenes

Salmonella spp.

Shigella spp.

Staphylococcus aureus

Vibrio cholerae

Vibrio parahaemolyticus

Vibrio vulnificus

Yersinia enterocolitica

Yersinia pseudotuberculosis

Daniel Nogueira 110


Vírus

Hepatite A

Norovirus

Rotavírus

Protozoários

Giardia lamblia

Toxoplasma gondii

Cryptosporidium spp.

Alimentos suspeitos

a)Ingestão do alimento xxxx, n dias antes do aparecimento dos sintomas

b) Alimento suspeito analisado?

Local de ingestão do alimento contaminado?

Outras pessoas apresentaram a mesma sintomatologia?

Daniel Nogueira 111


ANEXO 3

A classe e as funções apresentadas a seguir foram desenvolvidas

para tratar strings com código html em que as últimas tags não são

fechadas.

Daniel Nogueira 112


Daniel Nogueira 113


Daniel Nogueira 114

Documents

relatorio 07-07-06.doc