Faculdade de Engenharia de Universidade do Porto · Faculdade de Engenharia de Universidade do...

Faculdade de Engenharia de Universidade do Porto

Plataforma multimédia na Web para a gestão colaborativa de bases de dados terminológicas

Paula Suzana Duarte Carvalho

Licenciada em Tradução e Interpretação Especializadas

pelo Instituto Politécnico do Porto

Dissertação submetida para satisfação dos requisitos necessários à obtenção do grau de Mestre em Multimédia

Dissertação realizada sob a orientação

do Engenheiro João Isidro Araújo Vila Verde

do Departamento de Engenharia Informática

da Faculdade de Engenharia da Universidade do Porto

Porto, Outubro de 2009

| iii

À minha família, aos meus amigos e ao Jorge

Agradecimentos | v

Agradecimentos

Esta dissertação é o resultado de dois anos de trabalho e de conhecimento adquirido no

decurso do Mestrado em Multimédia da Universidade do Porto. Durante este período de

tempo foram criados laços de afinidade e foi revelado um estreito espírito de união,

cooperação e entreajuda no seio de uma turma repleta de potencialidade, ambição e

dinamismo. A todos os meus colegas com quem trabalhei de forma mais próxima, àqueles com

quem trabalhei por momentos mais breves e ainda àqueles com quem não trabalhei

directamente mas que estiveram sempre presentes, deixo o meu sincero agradecimento.

Agradeço todo o apoio, incentivo e estímulo, principalmente nos momentos menos fáceis.

Agradeço a todos os meus colegas de trabalho, docentes e não docentes, que participaram

activamente neste projecto e que contribuíram para o seu desenvolvimento, a todos aqueles

que me incentivaram e mostraram o seu apoio, e ainda a quem me instigou a ultrapassar os

momentos mais difíceis com um sorriso. Pelas longas horas de conversas, pela preocupação

sincera e pela procura incessante em ajudar, muito obrigada. À Coordenação do Centro

Multimédia de Línguas, onde exerço funções, e aos órgãos executivos do ISCAP agradeço o

apoio demonstrado e as condições que proporcionaram para que este projecto pudesse ser

realizado.

Agradeço à minha família, em particular aos meus pais e irmã, toda a confiança depositada em

mim e a compreensão e tolerância demonstradas pela minha ausência em momentos mais

complicados. Agradeço ainda o respeito incondicional que mostraram pelas opções

académicas e profissionais que tomei ao longo da vida sem tentarem interferir ou impor

vontades pessoais.

A todos aqueles que estão comigo nos bons e maus momentos, deixo o meu reconhecimento

e o compromisso de amizade.

Ao meu orientador, o Eng.º Isidro Vila Verde, pelo seu apoio, presença, disponibilidade e

paciência constantes e incondicionais e, acima de tudo, pela confiança em mim depositada

deixo um profundo agradecimento e reconhecimento. O seu valioso empenho e envolvimento

neste projecto revelaram‐se fundamentais.

Por fim, agradeço ao Jorge a confiança incondicional e a convicção inabalável demonstradas

mesmo nos momentos de maior pressão, bem como a voluntariedade no apoio a todas as

tarefas que me proponho a realizar. A ele agradeço porque nunca duvidou ou hesitou.

vi | Resumo

Resumo

O ensino tradicional tem vindo a ser, senão substituído, pelo menos complementado por

metodologias assentes na inovação tecnológica. O desafio está no aproveitamento adequado

de todas as ferramentas que advêm de sistemas de informação e comunicação como a

Internet ou aplicações locais dedicadas a áreas de conhecimento específicas.

Tanto no contexto educativo como no contexto profissional da Tradução é perceptível uma

adaptação gradual a este novo desafio, essencialmente na adopção de novos recursos e uma

aposta na renovação de estratégias e de meios.

Partindo destes princípios, propõe‐se um protótipo de plataforma multimédia na Web para a

gestão colaborativa de bases de dados terminológicas, e sua eventual aplicação prática no

contexto educativo da Tradução, cujo desenvolvimento assenta em tecnologias livres, de

código aberto, já firmemente implementadas e bastante desenvolvidas. A eventual

disponibilização da plataforma no contexto educativo contribuiria para um ambiente de

aprendizagem cada vez mais dinâmico, integrando as vertentes virtual e presencial, a

ciência e a técnica, o saber‐saber e o saber‐fazer.

A plataforma desenvolvida assenta no conceito de Web 2.0 e tem como objectivo principal

ser disponibilizada ao maior número de utilizadores possível, independentemente do

sistema operativo ou restrições existentes no computador de trabalho que possuam.

Nesta dissertação são apresentadas as motivações que levaram à sua realização, é

analisado o estado da arte na área de engenharia de software aplicada à gestão

colaborativa de terminologia, definem‐se as metodologias de investigação, os moldes de

desenvolvimento, as tecnologias utilizadas e perspectiva‐se o possível desenvolvimento e

adequação da plataforma para uma eventual aplicação prática.

Abstract | vii

Abstract

The traditional teaching process is being, if not replaced, at least complemented by

methodologies based on technological innovation. The challenge lies on the adequate and

optimal use of all the tools provided by the information and communication systems, such as

the Internet or local applications dedicated to specific knowledge areas.

Regarding both the educational context of Translation, and the professional one, one can

perceive a gradual adaptation to this new challenge, mainly as far as the adoption of new

resources or the renewal of existing strategies and means are concerned.

With these principles in mind, this study puts forward a prototype for a Web multimedia

platform that allows the collaborative management of terminology with special focus on its

practical application in an educational environment. The development of the platform is based

on free, open source, firmly implemented and fully developed technologies. Its possible

release in the educational context would allow an ever more dynamic teaching and learning

environment, by integrating distance and in‐class learning, science and technique, knowledge

and know‐how.

The developed platform is based on the Web 2.0 concept and its main purpose is to be made

available to the largest possible number of users, regardless of the operating system or ant

restrictions pertaining to the working computer they possess.

In summary, in this dissertation the motivations that led to its production are presented; then

the state of the art regarding software engineering applied to collaborative terminology

management is analysed and the investigation methodologies are defined, as well as the

development frameworks and used technologies. Finally, a possible development and

adjustment scope for an eventual practical application is suggested.

viii | Abstract

Índice | ix

Índice

Índice

0 Glossário de siglas e acrónimos ................................................................................................ xvii

1 Capítulo I ‐ Introdução .................................................................................................................. 1

1.1 Contextualização .......................................................................................................... 3

1.2 Motivação ..................................................................................................................... 4

1.3 Objectivos ..................................................................................................................... 5

1.4 Anteproposta para uma metodologia de investigação .............................................. 8

1.5 Estrutura da Dissertação ............................................................................................. 10

2 Capítulo II – Estado da arte ......................................................................................................... 13

2.1 Web .............................................................................................................................. 14

2.1.1 DicMil – Dicionário de Termos Militares do Exército .............................................. 14

2.1.2 e‐Termos ................................................................................................................... 16

2.1.3 GLOBS ....................................................................................................................... 17

2.1.4 Wiktionary ................................................................................................................. 19

2.2 Software ...................................................................................................................... 20

2.2.1 SDL MultiTerm ......................................................................................................... 20

2.3 Conclusões ................................................................................................................... 23

3 Capítulo III – Metodologias de Investigação ............................................................................. 25

3.1 Tipo de metodologia .................................................................................................. 26

3.1.1 Método Quantitativo e Método Quantitativo ........................................................ 27

3.2 Abordagem ................................................................................................................. 28

3.2.1 Estudo de Mercado (Survey) e Pesquisa – Acção ................................................. 28

3.3 Técnicas de recolha de dados .................................................................................... 29

3.3.1 Inquérito .................................................................................................................. 29

3.3.2 Análise dos resultados obtidos ............................................................................... 30

3.3.3 Análise de Documentos .......................................................................................... 34

x | Índice

4 Capítulo IV – Desenvolvimento e implementação da plataforma ........................................... 37

4.1 Metodologia utilizada ................................................................................................. 40

4.1.1 Metodologia ágil de desenvolvimento .................................................................. 40

4.2 O processo de desenvolvimento ............................................................................... 42

4.2.1 Análise de requisitos ............................................................................................... 43

4.2.2 Tecnologia ................................................................................................................ 43

4.2.3 Funcionalidades ....................................................................................................... 44

4.2.4 Actores e níveis de permissão ................................................................................ 46

4.3 Estudo e proposta de sistema .................................................................................... 48

4.3.1 CMS .......................................................................................................................... 48

4.3.2 Wiki ........................................................................................................................... 49

4.3.3 RIA (Rich Internet Application) ............................................................................... 51

4.3.4 Bibliotecas de JavaScript ........................................................................................ 53

4.4 Decisão ........................................................................................................................ 53

4.5 Arquitectura ................................................................................................................ 54

4.5.1 Tecnologia do lado do cliente ................................................................................. 54

4.5.2 Tecnologia do lado do servidor .............................................................................. 58

4.5.3 Servidor Web ............................................................................................................ 61

4.5.4 Middleware .............................................................................................................. 63

4.5.5 Bases de dados relacionais ..................................................................................... 68

4.5.6 Utilização simultânea de PHP e MySQL ................................................................. 70

4.6 Arquitectura e modelo de dados ................................................................................ 71

4.6.1 Modelo Conceptual de Dados (MCD) ...................................................................... 71

4.6.2 Modelo Lógico de Dados (MLD) ............................................................................. 72

4.6.3 Modelo Físico de Dados (MFD) .............................................................................. 72

4.6.4 Regras de Edgar Frank Codd ................................................................................... 73

4.6.5 Estruturação da base de dados .............................................................................. 76

4.7 Modulação da plataforma ........................................................................................... 81

Índice | xi

4.7.1 Codificação da plataforma ....................................................................................... 81

4.8 A plataforma ............................................................................................................... 98

4.8.1 O nome .................................................................................................................... 98

4.8.2 O logótipo ................................................................................................................ 99

4.8.3 Navegação .............................................................................................................. 101

4.8.4 Resolução ............................................................................................................... 101

4.8.5 Exploradores .......................................................................................................... 105

4.9 Testes/detecção de erros .......................................................................................... 106

4.10 Pré‐produção ............................................................................................................. 107

5 Capítulo V – Perspectivas de trabalho futuro .......................................................................... 109

5.1 Objectivos propostos ................................................................................................ 109

5.2 Implementação .......................................................................................................... 109

5.3 Integração .................................................................................................................. 110

5.4 Adequação .................................................................................................................. 111

5.5 Conclusões .................................................................................................................. 112

6 Capítulo VI – Considerações finais............................................................................................. 115

7 Capítulo VII – Bibliografia .......................................................................................................... 117

7.1 Bibliografia .................................................................................................................. 117

7.2 Fontes electrónicas ................................................................................................... 120

8 Capítulo VIII – Anexos ............................................................................................................... 127

8.1 Anexo A – Questões colocadas no inquérito efectuado ......................................... 129

8.2 Anexo B1a – Relatório geral ...................................................................................... 134

8.2.1 Número de respostas completas vs. número de respostas incompletas ........... 134

8.2.2 Localização geográfica dos inquiridos .................................................................. 134

8.3 Anexo B2 – Relatório de respostas à Questão n.º 1 ................................................. 135

8.4 Anexo B3 – Relatório de respostas à Questão n.º 2 ................................................. 136

8.5 Anexo B4 – Inquérito: Relatório de respostas à Questão n.º 3 ............................... 137


xii | Índice

8.7 Anexo B6a – Inquérito: Relatório de respostas à Questão n.º 5 ............................. 139

8.7.1 Valores Sim/Não...................................................................................................... 139

8.8 Anexo B6b – Inquérito: Relatório de respostas à Questão n.º 5 ............................. 139

8.8.1 Outra opção: Discriminação. .................................................................................. 139

8.9 Anexo B7 – Inquérito: Relatório de respostas à Questão n.º 6 .............................. 140



8.12 Anexo B10 – Inquérito: Relatório de respostas à Questão n.º 9 ............................. 143

8.13 Anexo B11 – Inquérito: Relatório de respostas à Questão n.º 10 ............................. 144

8.14 Anexo C – Paleta de cores seguras para a Web ....................................................... 145

8.15 Anexo D – Índice de utilização dos vários exploradores nos últimos anos (tabela

completa) .................................................................................................................. 146

8.16 Anexo E – Inquérito a apresentar aos utilizadores após uma sessão experimental

da plataforma ............................................................................................................ 148

Índice de Figuras | xiii

Índice de Figuras

Figura 1 ‐ Interface do IATE ....................................................................................................... 14

Figura 2 ‐ Estrutura do Dicionário de Termos Militares do Exército ....................................... 16

Figura 3 ‐ Página inicial da plataforma e‐Termos ...................................................................... 17

Figura 4 ‐ Página Web inicial da plataforma GLOBS ................................................................. 18

Figura 5 ‐ Página inicial do Wiktionary ...................................................................................... 19

Figura 6 ‐ Texto introdutório do Wikcionário .......................................................................... 20

Figura 7 ‐ Interface do software SDL MultiTerm Desktop 2009 ................................................ 21

Figura 8 ‐ Configuração geral do SDL MultiTerm Server .......................................................... 22

Figura 9 ‐ Evolução da Web ...................................................................................................... 38

Figura 10 ‐ Interacção simples com um servidor Web ............................................................ 39

Figura 11 ‐ Triângulo de projecto .............................................................................................. 42

Figura 12 ‐ Metodologia de desenvolvimento adoptada ........................................................ 43

Figura 13 ‐ Progressive enhancement ........................................................................................ 56

Figura 14 ‐ Exemplo de código HTML utilizado na plataforma ............................................... 57

Figura 15 ‐ Desenvolvimento em três camadas ....................................................................... 59

Figura 16 ‐ Arquitectura de uma aplicação Web ...................................................................... 61

Figura 17 ‐ Índice de utilização de servidores Web ................................................................. 62

Figura 18 ‐ Exemplo de código PHP embebido em código HTML (ficheiro: checklogin.php)65

Figura 19 ‐ Código fonte (ficheiro: checklogin.php) ................................................................ 65

Figura 20 ‐ Visualização no explorador Web (ficheiro: checklogin.php) ................................ 66

Figura 21 ‐ Interacção entre computador local e servidor Web (com e sem ficheiros PHP) 67

Figura 22 ‐ Tipos de motores de armazenamento disponíveis numa base de dados MySQL

................................................................................................................................................... 69

xiv | Glossário de siglas e acrónimos

Figura 23 ‐ Utilização da função mysql_connect() em PHP para ligação à base de dados

MySQL .............................................................................................................................. 71

Figura 24 ‐ Pormenor do mapa de relações com relações do tipo um‐para‐muitos ............. 76

Figura 25 ‐ Mapa de relações da base de dados ...................................................................... 77

Figura 26 ‐ Fluxograma de pedido de um novo registo .......................................................... 83

Figura 27 ‐ Fluxograma do processo de pedidos de acesso ................................................... 84

Figura 28 ‐ Estrutura de controlo if… else ......................................................................... 85

Figura 29 ‐ Sintaxe de um ciclo while(); ............................................................................ 86

Figura 30 ‐ Logótipo da plataforma ......................................................................................... 99

Figura 31 ‐ Logótipo de cor bordeaux ..................................................................................... 100

Figura 32 ‐ Logótipo de cor verde ........................................................................................... 100

Figura 33 ‐ Comparação entre área total e área útil de um monitor com resolução de 1024 x

768 pixéis ....................................................................................................................... 103

Figura 34 ‐ Contraste entre proporções de monitores de diferentes resoluções ............... 104

Índice de Tabelas | xv

Índice de Tabelas

Tabela 1 ‐ Categorização dos métodos de investigação e suas características gerais .......... 26

Tabela 2 ‐ Plataformas mencionadas no inquérito e respectivo número de referências ...... 31

Tabela 3 ‐ Funcionalidades apontadas pelos inquiridos por ordem de relevância ............... 44

Tabela 4 ‐ Paralelismo entre utilizadores em ambiente educativo e ambiente profissional 48

Tabela 5 ‐ Dados sobre a activação de JavaScript nos exploradores Web ............................55

Tabela 6 ‐ Tabela de cores utilizadas no logótipo e respectivas referências por sistema de

cor ................................................................................................................................... 100

Tabela 7 ‐ Índice de resoluções de monitores mais utilizadas .............................................. 102

Tabela 8 ‐ Comparação entre área total e área útil de um monitor de acordo com a

resolução ........................................................................................................................ 103

Tabela 9 ‐ Índice de utilização dos vários exploradores nos últimos anos ........................... 105

Glossário de siglas e acrónimos | xvii

0 Glossário de siglas e acrónimos

1FN Primeira Forma Normal

2FN Segunda Forma Normal

3FN Terceira Forma Normal

AJAX Asynchronous JavaScript And XML

API Application Programming Interface

ASP Active Server Pages

AVI Audio Video Interleave

BCNF Forma Normal de Boyce/Codd

CMS Content Management System

CMYK Cian, Magenta, Yellow e Black

CSS Cascade Style Sheet

CSV Comma Separated Values

DOM Document Object Model

DHTML Dynamic Hypertext Markup Language

FLV Flash Video

GIF Graphics Interchange Format

GNU GNU's not Unix

HSB Hue, Saturation and Brightness

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

IMAP Internet Message Access Protocol

JPG Joint Photographic Experts Group

JSP JavaServer Pages

Lab Lightness, chroma A and chroma B

xviii | Glossário de siglas e acrónimos

MP3 MPEG‐1/2 Audio Layer 3

MPEG Moving Picture Experts Group

MSDE Microsoft SQL Server 2000 Desktop Engine

LDAP Lightweight Directory Access Protocol

PHP PHP: Hypertext Preprocessor

PNG Portable Network Graphics

RGB Red, Green and Blue

RIA Rich Internet Application

RTF Rich Text Format

SGBDR Sistema de Gestão de Bases de Dados Relacionais

SQL Structured Query Language

SWF Shockwave Flash

USB Universal Serial Bus

W3C World Wide Web Consortium

WAV Waveform audio format

WMA Windows Media Audio

WMV Windows Media Video

WWW World Wide Web

XAMPP XML, Apache, MySQL, PHP e Perl

XML eXtensible Markup Language

XLSX Microsoft Excel 2007 spreadsheet document

Capítulo I ‐ Introdução | 1

1 Capítulo I ‐ Introdução

The fruits of tomorrow are in the seeds of today.

Autor desconhecido

É inegável a relevância da utilização da tecnologia no processo de ensino‐aprendizagem. Do

retroprojector aos quadros interactivos, passando pelo computador pessoal e pela Internet, a

preponderância de equipamento tecnológico enraizou‐se na vida académica, tendo sentido

forte impulso ao longo da última década.

A multimédia emergiu, no decorrer desse tempo, como recurso coerente no ensino, e os seus

ambientes incluem formas tão vastas como ensino em ambiente virtual, plataformas de

simulação na aprendizagem de determinadas competências, cursos electrónicos presenciais e

a distância, portefólios digitais, ou apresentações electrónicas e o seu impacto no processo de

ensino‐aprendizagem é, hoje, amplamente reconhecido. Mayer (2005) [38.] formula mesmo

aquela a que chama a hipótese da aprendizagem multimédia, hipótese esta baseada na seguinte

proposição: “There is reason to believe that – under certain circumstances – people can learn

more deeply from words and pictures than from words alone.”

As áreas da Tradução e da Linguística não escapam a esta (r)evolução, sendo já a multimédia

parte integrante da construção do saber‐saber por parte dos formandos de todos os níveis de

ensino, dotando‐os de novas apetências e levando‐os à formação em campos não previstos

nos seus horizontes académicos há algumas décadas atrás.

Longe vai o tempo em que o tradutor e/ou o escritor recorriam apenas aos seus dicionários de

papel, prontuários ou guias de estilo para fazer o seu trabalho, ou, na falta destes recursos, se

deslocavam à biblioteca em busca de fontes adicionais.

Actualmente, é comum ver o ambiente de trabalho do tradutor constituído por um

computador pessoal ligado permanentemente e com ligação de banda larga à Internet, dois

monitores, dois ou mais programas de tradução assistida por computador em todas as suas

vertentes a serem executados em simultâneo e em reciprocidade, e um telemóvel sempre por

perto para contactar especialistas das diversas áreas de conhecimento a qualquer hora.

2 | Capítulo I ‐ Introdução

A solução mais frequente no mercado de trabalho/profissional da tradução passa pela compra

de ferramentas proprietárias. Por outro lado, ao quererem simular um ambiente empresarial

nas suas salas de aula (ou nos seus laboratórios multimédia, mais comuns hoje no ensino da

Linguística e da Tradução), o custo financeiro dessas aplicações pode tornar‐se insuportável

para instituições de ensino, principalmente as de natureza pública e aquelas de parcos

recursos financeiros. Além disso, não é invulgar que tais ferramentas tenham inerentemente

um elevado grau de complexidade, quer por altura da sua instalação, quer na sua utilização

quotidiana. Na verdade, um tradutor com formação em Humanidades e em Línguas

dificilmente saberá por que razão a actualização de uma determinada versão de Java não

permite que o seu software (de custos avultados) continue a funcionar normalmente e, mais

dificilmente, saberá resolver o problema.

Este facto é igualmente aplicável à gestão de terminologia. Neste caso, são já várias as

propostas alternativas ao software proprietário existente no mercado e estas surgem,

essencialmente, na Web. No entanto, as alternativas existentes baseiam‐se na partilha de

informação e não na colaboração da construção de conhecimento e o actual cenário

tecnológico associado à área da tradução e da terminologia revela uma forte lacuna na oferta

de aplicações/plataformas vocacionadas para o ensino‐aprendizagem nesta área.

Na sequência de uma análise aprofundada do estado da arte da tecnologia aplicada à

tradução, propõe‐se a construção de uma plataforma multimédia na Web para a gestão

colaborativa de bases de dados terminológicas e perspectiva‐se a sua aplicação prática no

contexto educativo da tradução.

A relevância da construção de tal plataforma é corroborada por um breve estudo elaborado

com base num inquérito apresentado a docentes, discentes e profissionais da área de

tradução. As respostas permitem não só detectar as vantagens e expectativas como também

as fragilidades e reservas relativamente a uma plataforma Web de gestão colaborativa de

terminologia.

Há uma tentativa de responder aos requisitos colocados, bem como de superar as

compreensíveis reservas sobre o ainda frágil universo do trabalho colaborativo através da

criação de um ambiente de colaboração, embora controlado, da utilização de tecnologia livre,

mas consolidada, e da disponibilização de uma ferramenta cujo controlo de qualidade esteja

sempre presente, quer seja pela presença de especialistas em diversas áreas de conhecimento,

bem como de docentes altamente qualificados e com larga experiência no ensino‐

aprendizagem da tradução.


Numa perspectiva de trabalho futuro são propostas várias linhas de conduta que apenas agora

se começam a coser, ligando essencialmente as instituições de formação superior em

tradução.

1.1 Contextualização

Actualmente, é escasso (embora não inexistente) o recurso do tradutor profissional a fontes e

referências bibliográficas em papel e raramente, também, recorre ao papel para transcrever o

texto de chegada. O seu ambiente de trabalho é invariavelmente constituído por uma panóplia

de equipamentos electrónicos, entre os quais o computador pessoal ligado permanentemente

e com ligação de banda larga à Internet, um scanner com reconhecimento óptico de

caracteres, um disco externo ou uma caneta USB, várias aplicações electrónicas de tradução

assistida por computador a ser executadas em simultâneo e cujas janelas abertas se estendem

por dois monitores. O formato de eleição para a entrega do trabalho final é, frequentemente,

o correio electrónico ou o suporte digital.

A presença da multimédia na área de gestão terminológica é também significativa. No final da

década de 90 do século XX, os dicionários de editoras de renome começaram a publicar,

juntamente com o dicionário de papel, um CD‐ROM com a versão digital ilustrada e com

possibilidade de ouvir a pronunciação do termo. Na verdade, remonta já à década de 60 do

século XX a ligação entre a terminologia e a informática. Esta ligação visa a facilitação do

armazenamento e a difusão de dados terminológicos na criação e gestão de grandes bases de

dados terminológicas especializadas. A integração entre estas duas áreas tornou‐se de tal

forma sólida e potencial que a mesma deu origem ao neologismo terminótica (Almeida et. al

2006) [2.], um novo conceito que inaugura um novo paradigma metodológico nas pesquisas

terminológicas.

O estudo e o trabalho terminológico pressupõem, hoje, a existência de um conjunto de

procedimentos automatizados ou semi‐automatizados que contribuam para um apoio activo

às tarefas envolvidas neste processo, como por exemplo a criação e constante actualização de

bases de dados, a normalização terminológica, a inclusão de termos em ontologias ou mapas

conceptuais ou a difusão de informação para interligação com outras aplicações e/ou

utilizadores.


Porém, a normalização de bases de dados terminológicas torna‐se bastante difícil, pois a

evolução linguística não consegue acompanhar o rápido avanço tecnológico. Ao longo dos

últimos anos, a língua portuguesa tem vindo a sofrer fortes, e até violentas, influências de

estrangeirismos, especialmente de anglicismos.

Há uma tendência generalizada para institucionalizar a terminologia técnica numa só língua de

modo a facilitar a comunicação entre profissionais de diversas nacionalidades. No entanto, tal

empobrece a língua com a agravante de se incorrer no risco de marginalizar leitores que não

estejam familiarizados com o texto ou com a temática em causa. Assim, torna‐se imperativo

que tradutores, terminólogos e especialistas em textos técnicos e científicos tomem iniciativas

de recolha de informação terminológica nas várias áreas com o objectivo de catalogar e

normalizar bases de dados específicas da língua portuguesa. Esta iniciativa, como tantas na

área da tradução técnica, não pode estar dissociada de uma estreita colaboração com

especialistas das mais diversas áreas, o que neste caso concreto significa a colaboração com

especialistas em tecnologias da informação e da comunicação.

1.2 Motivação

A criação e gestão terminológicas são parte integrante e fundamental do processo tradutivo.

No entanto, as ferramentas consolidadas no mercado para este efeito são escassas,

proprietárias e implicam uma curva de aprendizagem acentuada. A aplicação de referência em

gestão terminológica, tanto para profissionais como para docentes da área, é o SDL MultiTerm

[114.], software desenvolvido apenas para o sistema operativo Windows que pressupõe uma

instalação local e requer licenciamento mono‐utilizador, isto é, as licenças apenas podem ser

utilizadas numa determinada máquina (o preço unitário por licença é aproximadamente €485).

O SDL MultiTerm suporta a edição colaborativa de bases de dados terminológicas, mas tal

exige a instalação centralizada de um servidor que não dispensa a aquisição das licenças por

parte dos computadores‐cliente e obriga à aquisição de uma licença adicional para o servidor.

A compra de um servidor MultiTerm já inclui um determinado número de licenças, mas o

acesso a esse servidor é limitado em número de ligações simultâneas.

O ensino de ferramentas de gestão terminológica é parte integrante do programa de algumas

unidades curriculares ligadas à Tradução e tal implica um avultado investimento financeiro em

software para as instituições de ensino, nomeadamente as de natureza pública. Um exemplo

destas instituições é o ISCAP, Instituto Superior de Contabilidade e Administração do Porto. A


Licenciatura em Assessoria e Tradução e o Mestrado em Tradução e Interpretação

Especializadas fundamentaram, até à data, a aquisição de 55 licenças do software profissional

SDL MultiTerm da SDL TRADOS. Se por um lado esta instituição pode contar com a

compreensão dos seus órgãos de gestão relativamente às necessidades inerentes à

leccionação destes cursos, outras instituições haverá que, independentemente da

disponibilidade e aceitação dos seus órgãos de gestão, não possuem financiamento suficiente

para a aquisição de software. O mesmo acontece com a comunidade discente. Adquirir

software profissional pode não estar ao alcance de todos os alunos, nomeadamente aqueles

de classes sociais menos favorecidas ou mesmo de discentes não trabalhadores que não

pretendam imputar mais uma despesa aos seus encarregados de educação.

Assim, a motivação para o desenvolvimento deste projecto nasce de um conjunto de factores,

sendo que a principal está intrinsecamente ligada à utilidade que uma plataforma Web de

trabalho colaborativo poderá desempenhar no processo de ensino‐aprendizagem de unidades

curriculares ligadas às áreas de Línguas e Tradução. Globalmente, foram factores decisivos:

• Disponibilizar uma solução acessível a qualquer utilizador, independentemente do tipo de

máquina, sistema operativo, explorador Web ou outras condicionantes;

• Promover a interactividade entre professores, alunos e especialistas através de uma

plataforma de trabalho colaborativo;

• Reduzir custos na implementação de novas metodologias de ensino‐aprendizagem;

• Permitir a partilha pública do conhecimento produzido.

1.3 Objectivos

O objectivo primário deste projecto assenta no conceito “plataforma multimédia na Web para

a gestão colaborativa de bases de dados terminológicas: aplicação prática no contexto

educativo da tradução.”

Nenhuma das ferramentas electrónicas disponíveis (sejam elas aplicações locais ou

plataformas na Internet) prevê a formação académica de que a comunidade profissional é alvo

antes de ingressar no mercado de trabalho. Ferramentas electrónicas que prevejam a

construção de um saber, como o software de tradução assistida por computador, permitem

armazenar dados que facilitem um trabalho futuro (como o alinhamento de textos, a

construção de memórias de tradução ou a criação de bases de dados terminológicas). No


entanto, e uma vez que não estão originalmente vocacionadas para o ensino, estas

ferramentas não ponderam o papel do professor e do especialista, actores preponderantes em

todo o processo terminológico e a quem cabe, em última instância, assegurar a qualidade do

trabalho produzido.

Mas se, por um lado, o objectivo primário do desenvolvimento desta plataforma é servir

propósitos educativos, por outro não se restringe a ele.

A utilização desta plataforma poderá eventualmente ser aplicável também no contexto

profissional da tradução como solução a implementar por pequenas empresas ou

trabalhadores independentes com baixos recursos financeiros.

A projecção de uma plataforma de gestão terminológica que contribua equitativamente para a

formação académica superior e para a produtividade profissional poderá ser contraditória pois

a finalidade de ambas as actividades é distinta.

O rumo a tomar tem como meta atingir objectivos que satisfaçam, primordialmente, a área do

ensino e apenas secundariamente a área profissional. Idealmente, o resultado servirá

propósitos complementares.

Assim, os seguintes objectivos foram considerados essenciais aquando da projecção da

plataforma:

• criação de glossários;

• definição de obrigatoriedade de preenchimento de um determinado campo;

• distinção entre sublínguas, por exemplo: Português (Portugal) ou Português (Brasil);

• fácil usabilidade da plataforma (interface intuitivo);

• inserção automática da classe gramatical do termo;

• inserção de conteúdo multimédia;

• possibilidade adicionar várias línguas ao mesmo glossário;

• possibilidade de contactar criadores e gestores para colocar dúvidas ou sugerir alterações;

• registo e gestão de utilizadores com vários níveis de permissão.

Um objectivo mais abrangente, mas confluente aos acima propostos, é manter o

desenvolvimento da plataforma a longo prazo. Isto permitirá a adequação da plataforma a


várias actividades, bem como o seu aperfeiçoamento e desenvolvimento de novas

funcionalidades que facilitem o processo tradutivo.

Ainda que numa fase posterior do desenvolvimento da plataforma, são também objectivos:

• consulta do registo de alterações efectuadas num determinado termo;

• criação de vários níveis hierárquicos na estrutura da árvore da base de dados

terminológica;

• desenvolvimento de um módulo de avaliação do aluno;

• disponibilização de glossários criados a utilizadores visitantes (não registados) apenas

para consulta;

• existência de vários níveis de permissão;

• exportação de bases de dados terminológica (para um ficheiro *.csv, *.xlsx, *.xml ou

outro);

• importação de bases de dados terminológicas (de um ficheiro *.csv, *.xlsx, *.xml ou

outro);

• integração da plataforma com outras ferramentas existentes no computador (editor de

texto, editor de apresentações, folha de cálculo, etc.);

• transcrição sonora (pronunciação) do termo;

• registo de alterações efectuadas por utilizadores;

• registo do tempo dispendido por utilizador em tempo útil de trabalho.

O objectivo final deste projecto consiste em disponibilizar uma ferramenta de trabalho que

permita a aprendizagem e a construção de um saber‐saber na área da gestão terminológica

aliada ao contexto da tradução na actual sociedade de informação.

A versatilidade e usabilidade da plataforma serão factores fulcrais a ter em conta, bem como a

sua disponibilização ao maior número de pessoas possível.

O ponto de partida é o conceito de Web 2.0 e tem como fio condutor a noção de trabalho

colaborativo e partilha de conhecimento sem esquecer a sua adequação à evolução

tecnológica não só da Web como de todo o espectro que a envolve.


1.4 Anteproposta para uma metodologia de investigação

A condução do processo de investigação exige uma estruturação prévia para que lhe transmita

coerência e inteligibilidade. Esta delineação prévia irá permitir, também, que seja delimitado

quer o objecto de estudo quer as técnicas e procedimentos a utilizar na recolha, tratamento e

análise de dados.

Sousa (2005) [51.] defende mesmo que é necessária prudência para que não sejam aplicados

“processos de investigação cuja utilização (…) possa conduzir a resultados inadequados, ou (…)

que o leitor pode não considerar credíveis”.

Qualquer área de conhecimento exige uma estruturação metodológica que permita a

inferência clara das conclusões formuladas, mas caberá à génese, à especificidade e à

finalidade do projecto a determinação da metodologia a seguir.

A presente dissertação teórica e o projecto prático realizado no seu âmbito abraçam duas

ciências que, apesar de distintas, se complementam. Por um lado existe a necessidade de

dotar o sistema educativo de novas metodologias e novos recursos que levem os alunos a

adoptar novos métodos de trabalho e consigam adquirir competências colaborativas na

construção, gestão e partilha do conhecimento e, por outro, existe o recurso à tecnologia e à

multimédia para dar corpo ao projecto.

Sabendo que as metodologias e as investigações efectuadas no âmbito das ciências sociais e

humanas e aquelas efectuadas no âmbito das ciências exactas se categorizam e ocorrem,

regra geral, de forma distinta e, como já foi referido, este projecto abraça domínios no âmbito

de ambas as ciências, torna‐se então necessário compreender até que ponto esta distinção

influenciará a metodologia a utilizar (ponto aprofundado no Capítulo III – Metodologias de

Investigação).

Após algumas considerações, optou‐se pela adopção de um cruzamento metodológico,

globalizante de características quantitativas e qualitativas.

Numa fase prévia ao desenvolvimento da plataforma, a escolha recaiu na elaboração um

inquérito sobre a pertinência e utilidade da existência de uma plataforma multimédia na Web

para a gestão de bases de dados terminológicas e sua aplicação ao contexto educativo da

tradução. O objectivo consistia em dirigir o inquérito em causa às comunidades profissional,

docente e discente para dar resposta


ao problema:

“Qual o grau de relevância de uma plataforma multimédia de gestão terminológica na Web

enquadrada no contexto educativo da tradução?”

e à questão:

“Qual a finalidade, quais os constrangimentos e quais as características mais relevantes numa

plataforma multimédia de gestão terminológica na Web?”

O recurso a um inquérito como instrumento de recolha de dados não implicará, no entanto,

que o estudo em si seja inevitavelmente quantitativo, conforme considera Bell (1997) [5.]. O

objectivo será não só compreender qual o grau de relevância de uma plataforma deste género

no contexto educativo (e eventualmente profissional) da tradução, como também dados mais

específicos como faixa etária, grau académico e experiência docente/profissional dos

inquiridos.

A um conjunto de procedimentos que antecedem a investigação em si, como a definição do

problema ou a colocação de hipóteses e/ou de questões de investigação, segue‐se um estudo

pormenorizado dos dados: planeamento, recolha, organização, validação, selecção, etc. O

confronto das hipóteses e/ou das questões de investigação com os resultados obtidos

determina as metodologias e procedimentos a seguir.

Também o estudo e análise do estado da arte constituem um ponto de referência para a

realização deste projecto na medida em que permitem avaliar as diferentes plataformas já

existentes, o que ainda permanece por fazer, o que funciona e o que falha. As metodologias já

utilizadas em outros casos podem ainda permitir estabelecer novos padrões de actuação ou

desenvolver mais aprofundadamente o que já está enraizado.

Durante a fase de pré‐produção do desenvolvimento da plataforma, a mesma será testada por

potenciais utilizadores. Para aferir o grau de satisfação do uso da plataforma, o instrumento

utilizado será o inquérito, que permitirá não só a recolha de informação, sugestões e opiniões

para não só consolidar ou reconsiderar futuras metodologias e novos procedimentos de

investigação, como também a avaliação das características, funcionalidades e usabilidade da

própria plataforma.

Resumidamente, o procedimento adoptado é o seguinte:


• Antes do desenvolvimento da plataforma:

Inquérito: PollDaddy [106.]

Aferição do grau de relevância do projecto

• Durante a fase de pré‐produção do desenvolvimento da plataforma:

Inquérito: PollDaddy

Aferição do grau de satisfação por parte dos utilizadores e recolha de

informação generalizada, sugestões e opiniões.

Em última análise pretende avaliar‐se se a plataforma poderá ou não contribuir como

instrumento de apoio nos processos de ensino‐aprendizagem, construção de um saber‐saber e

partilha de informação na actual sociedade de informação.

1.5 Estrutura da Dissertação

Até ao momento foram já abordadas, de uma forma global, as questões mais pertinentes a

aprofundar durante a redacção desta dissertação.

Estruturalmente, a presente dissertação compreende cinco partes essenciais, as quais serão

subdivididas de acordo com os tópicos abordados.

O primeiro capítulo da dissertação apresentará, globalmente, as questões gerais inerentes ao

projecto e abordará a contextualização, a motivação para o seu desenvolvimento, os

objectivos a atingir, as metodologias de investigação e procedimentos precedentes e

simultâneos ao desenvolvimento da plataforma, bem como uma referência à estruturação da

própria dissertação.

O segundo capítulo será dedicado à análise do estado da arte, tendo em conta as plataformas

já desenvolvidas e respectiva implementação, bem como as tecnologias utilizadas, suas

vantagens e desvantagens.

No terceiro capítulo serão aprofundadas as metodologias de investigação utilizadas, bem

como a análise dos resultados obtidos. Dar‐se‐á, nesta fase, algum destaque aos resultados do

inquérito precedente à construção da plataforma, pois são estes que determinam, em grande

parte, a arquitectura e o modelo de dados.


O quarto capítulo terá como base não só a análise do estado da arte como também as

conclusões retiradas do inquérito realizado às comunidades docente, discente e profissional

na área da tradução e compreenderá a análise da arquitectura e do modelo de dados, incluindo

a estruturação da base de dados e a modulação da plataforma.

No quinto capítulo é efectuada uma análise metodológica da implementação e

desenvolvimento da plataforma, incluindo a tecnologia utilizada, os procedimentos de teste

realizados para verificação e correcção de erros, a usabilidade da plataforma e a aplicação

prática da plataforma em contexto educativo. Nesta fase será dado destaque à eventual

aferição do grau satisfação relativo à plataforma através de um inquérito realizado após a sua

utilização por parte de docentes, discentes e profissionais.

Em forma de epílogo, serão abordadas as conclusões retiradas do trabalho realizado:

metodologia de desenvolvimento, objectivos alcançados por oposição aos objectivos

propostos, informação obtida pelos utilizadores da plataforma e, numa tentativa de

perspectivar trabalho futuro e potencialidades de maior desenvolvimento da plataforma

averiguar‐se‐á a aplicação da mesma em contexto educativo contínuo e profissional, bem

como a adequação da mesma à Web Semântica (Web 3.0) [124.].

Capítulo II – Estado da arte | 13

2 Capítulo II – Estado da arte

Being busy does not always mean real work. The object of all work is production or accomplishment

and to either of these ends there must be forethought, system, planning, intelligence, and honest

purpose, as well as perspiration. Seeming to do is not doing.

Thomas Alva Edison

A gestão terminológica de um dado domínio centra‐se essencialmente na utilização de

recursos (tais como corpora ou editores de terminologia) para fins específicos, como seja a

partilha de conhecimento, a disponibilização de glossários ou a manutenção de bases de dados

terminológicas.

A disponibilização de bases de dados terminológicas tem vindo a generalizar‐se. Bases de

dados como o IATE (InterActive Terminology for Europe) [80.] têm vindo a ganhar relevância na

comunidade de tradutores e docentes de tradução devido aos seus contributos na tradução

assistida e/ou automática, na pesquisa terminológica em geral e na pesquisa de informação

técnica e científica. Esta base de dados, em particular, adquiriu um elevado grau de fiabilidade,

fruto de ter a sua gestão sobre a alçada de uma parceria de instituições da União Europeia e de

ver o seu conteúdo constantemente actualizado. Esta é também a base de dados

terminológica mais divulgada no meio académico e mais utilizada inter‐institucionalmente a

nível da União Europeia, o que lhe confere um nível de relevância considerável.

No entanto, plataformas como esta baseiam‐se em recursos privados e são geridas por

especialistas de áreas muito concretas, como a informática ou a engenharia.

14 | Capítulo II – Estado da arte

São poucas as plataformas existentes que permitam a gestão colaborativa do conteúdo, tanto

na Web como em aplicações locais, e são em menor número ainda as soluções implementadas,

sendo que nenhuma das plataformas reúne todos os requisitos pretendidos.

Será apresentado, de seguida, o estado da arte referente às aplicações de gestão

terminológica disponíveis tanto na Web como a nível local. Proceder‐se‐á à sua análise global,

tendo em particular consideração a tecnologia na qual assentam, bem como os objectivos com

que foram concebidas e respectiva implementação.

2.1 Web

2.1.1 DicMil – Dicionário de Termos Militares do Exército

O Dicionário de Termos Militares do Exército (DicMil) [63.] foi desenvolvido no âmbito de um

Projecto de Investigação do CInAMil, Centro de Investigação da Academia Militar. O seu

objectivo específico é servir de agente facilitador ao Oficial do Exército, quer na preparação de

tarefas que exijam conhecimento pleno e exacto, numa língua estrangeira, dos termos ligados

à profissão, quer na execução de tarefas quotidianas que exijam prontidão e rapidez na

apresentação de resultados e que estejam directamente relacionadas com a utilização de

termos ligados ao Exército em inglês.

Figura 1 ‐ Interface do IATE


A plataforma sobre a qual assenta o projecto permite a gestão de referências terminológicas

de âmbito militar e a sua consulta através de um interface Web, cujos acessos podem ser

efectuados através da Internet, sendo o nível de acesso ditado pelo tipo de utilizador que

utiliza o sistema. A plataforma contempla a importação de termos para a base de dados,

utilizando o formato XML e foi desenvolvida utilizando as seguintes tecnologias:

• Servidor Web

Apache;

• Motor de Bases de Dados

MySQL;

• Linguagem do lado do Servidor

PHP;

• Apresentação

Flash CS3 – Actionscript 3;

• Comunicação Servidor/Cliente

Flash/XML.

Apesar de estar já disponível, a plataforma não reúne vários dos critérios estipulados, como

por exemplo, a atribuição de várias línguas ao glossário, ou a criação de vários glossários em

áreas de conhecimento diversas.

Por ter sido desenvolvida com um objectivo tão específico, a plataforma apresenta uma

estrutura rígida disponibilizando os campos necessários para a criação do glossário, não sendo

possível ao “criador” definir a estrutura ou os campos que quer inserir (ver figura 2).

A camada de apresentação da plataforma foi desenvolvida com recurso ao software

proprietário Adobe Flash CS3 e utilizando ActionScript 3. Se por um lado este factor pode

proporcionar uma estética interessante sem recurso a muito espaço, por outro implica que o

utilizador tenha instalada uma versão do Flash Player para ter acesso à plataforma (o que

poderá constituir um problema se o mesmo não estiver instalado no computador cliente e este

não tiver, por sua vez, permissões para o fazer).


A adequação da plataforma ao contexto específico do exército enquanto agente facilitador do

fluxo de trabalho e a estrutura rígida do glossário em apenas duas línguas não torna exequível

a sua aplicação num contexto educativo da tradução.

2.1.2 e‐Termos

A plataforma e‐Termos [72.] está a ser desenvolvida no âmbito de um projecto académico em

parceria entre a Universidade de São Paulo (USP – Campus de São Carlos – SP) e Universidade

Federal de São Carlos (UFSCar), representados pelos laboratórios de pesquisa do NILC (Núcleo

Interinstitucional de Linguística Computacional) e do GETerm (Grupo de Estudos e Pesquisas

em Terminológicos), localizados nas duas Universidades, respectivamente.

Com base em pressupostos terminológicos de cariz linguístico, a plataforma e‐Termos

disponibiliza um ambiente Web colaborativo de desenvolvimento terminológico composto por

seis módulos de trabalho independentes, mas inter‐relacionados, cujo propósito é automatizar

ou semi‐automatizar as tarefas de criação e gestão terminológicas. O ponto inovador da

plataforma está na característica colaborativa que o ambiente disponibiliza. Com base em

processos de apoio e cooperação de um conjunto diversificado de profissionais, é possível a

colaboração e a partilha de informação para melhorar o fluxo de trabalho de grupos de

Figura 2 ‐ Estrutura do Dicionário de Termos Militares do Exército


utilizadores com interesses e objectivos comuns. A colaboração permite ainda a harmonização

e o mapeamento do fluxo de actividades de todos os envolvidos no processo de criação

terminológica, com resultados mais céleres e fiáveis.

A plataforma permite que os diferentes utilizadores de uma mesma equipa de trabalho

acedam, editem, actualizem, insiram e extraiam informações de todos os módulos,

procedimento este que pode ser utilizado na interacção com os especialistas do domínio. A

participação colaborativa nesta plataforma tem início numa proposta, por parte do utilizador,

de um projecto e num convite feito após a apreciação do mesmo.

No entanto, esta plataforma está em fase de implementação e muitos dos módulos propostos

pelo projecto não estão ainda disponíveis. Ela permite ainda uma variedade de acções que não

se adequam, pelo menos numa fase embrionária, aos objectivos propostos, como por exemplo

a utilização de corpora e ferramentas de processamento de linguagem natural.

Não foi possível encontrar qualquer referência documentada relativa à tecnologia utilizada no

desenvolvimento da plataforma.

2.1.3 GLOBS

O Globs [121.] é uma plataforma Web que nasce no âmbito de uma Licenciatura em Engenharia

Informática da Universidade do Minho.

Desenvolvida com base na ferramenta Drupal [71], a plataforma tem como objectivo ser um

gestor colaborativo de terminologia/glossários através da implementação de um sistema de

Figura 3 ‐ Página inicial da plataforma e‐Termos


gestão terminológica em que a estrutura pode ser definida de forma independente para cada

terminologia de acordo com os objectivos para os quais está a ser desenvolvida.

Actualmente o Globs inclui algumas funcionalidades básicas (como gestão de utilizadores,

gestão de permissões sobre glossários, criação básica de glossários orientados ao conceito,

adição de línguas e propriedades a cada conceito do glossário, comunicação inter‐

colaboradores de um glossário) e prevê a adição de novas funcionalidades, não estando ainda

totalmente implementada.

Alberto Simões e Nuno Veloso (2008) [113.], autores da plataforma, afirmam mesmo que o

facto de a plataforma assentar no Sistema de Gestão de Conteúdos (ou CMS, Content

Management System) Drupal, pode influenciar negativamente o número de possíveis

programadores e/ou colaboradores que contribuam para o desenvolvimento e implementação

do GLOBS. Por outro lado, a utilização do CMS Drupal permitiu um bom resultado gráfico,

como se pode constatar na figura 4, mas uma breve utilização da plataforma permite concluir

que o seu elemento “intuitivo” pode ser de difícil interiorização e o elemento “contexto

educativo”, por não ser um dos objectivos inerentes à sua implementação, não está nela

contemplado.

Figura 4 ‐ Página Web inicial da plataforma GLOBS


2.1.4 Wiktionary

Concebido como apêndice lexical à Wikipedia [132.], o Wiktionary [134.], ou Wikicionário [133.],

é um projecto colaborativo cujo objectivo é produzir um dicionário multilingue de conteúdo

livre e inclui, já, um dicionário de sinónimos, um guia de rimas, estatísticas linguísticas entre

outros complementos.

A plataforma está disponível em várias línguas e todo o conteúdo está sob uma Licença de

Documentação Livre GNU. As entradas podem conter não só a definição da palavra como

também as etimologias, sinónimos, antónimos e traduções.

Quer a Wikipedia quer o Wiktionary são, como o próprio nome sugere, plataformas wiki e

apresentam fragilidades e constrangimentos inerentes a plataformas deste tipo, como, por

exemplo, a disponibilização para edição por qualquer utilizador, independentemente da sua

origem ou intenção.

Esta e outras fragilidades inerentes às plataformas Wiki serão abordadas mais

aprofundadamente no Capítulo IV desta dissertação.

Figura 5 ‐ Página inicial do Wiktionary


Um constrangimento que esta plataforma em particular apresenta é a impossibilidade de

divisão de uma língua em várias sublínguas. O caso concreto do portal português é

reconhecimento deste facto, cujo texto introdutório está escrito numa mescla de algumas

variantes da língua portuguesa.

A miscelânea de variantes da mesma língua numa mesma entrada atenta contra o princípio de

normalização terminológica, pressuposto essencial para a existência da plataforma.

A figura 6 realça alguns dos exemplos encontrados numa navegação muito breve pelo

Wikcionário.

2.2 Software

2.2.1 SDL MultiTerm

O SDL MultiTerm Desktop 2009 é a principal referência em software de edição e gestão

terminológicas. Já com alguns anos de tradição, o programa tem vindo a desenvolver

funcionalidades cada vez mais arrojadas, tais como a extracção de terminologia, a conversão

de ficheiros e a interligação com o Microsoft Word ou outras ferramentas da SDL International.

Figura 6 ‐ Texto introdutório do Wikcionário


O programa foi concebido para um público‐alvo de utilizadores que trabalhe com terminologia

em configurações mono‐utilizador.

No entanto, o programa é proprietário e a sua licença é bastante dispendiosa. O preço unitário

por licença é aproximadamente de €485 (conforme já referido atrás). Em instituições de ensino

públicas ou com escassos recursos financeiros, este pode ser um grande entrave à dinâmica

educativa da criação e gestão terminológicas.

O software encontra‐se desenvolvido apenas para o sistema operativo Windows, o que se

revela um constrangimento adicional pois impossibilita definitivamente a sua instalação num

computador com um outro sistema operativo, como Mac OS X ou Linux. Por sua vez, este facto

poderá traduzir‐se numa redução mais ou menos significativa do número de possíveis

utilizadores, questão esta que não se coloca caso estejamos a falar de uma plataforma na

Web.

Figura 7 ‐ Interface do software SDL MultiTerm Desktop 2009


Os utilizadores que possuam um Macintosh, por exemplo, poderão sempre optar por uma

instalação do Windows no seu computador, mas também esta solução poderá ter implicações

a nível de desempenho da própria máquina, caso o hardware não seja standard. Actualmente,

o hardware desenvolvido pela Apple é standard, ao contrário do que se verificava há alguns

anos, no entanto também não podemos descartar a hipótese de alguns utilizadores

possuírem, ainda, um computador Macintosh não actualizado.

Uma agravante que não pode ser esquecida é o facto de o Windows ser um software

proprietário, o que acarreta um custo adicional a quem já investiu num computador com um

sistema operativo, também ele proprietário.

Relativamente ao trabalho colaborativo proporcionado pelo SDL MultiTerm Desktop 2009, este

existe mas está dependente de uma ligação a um servidor central. Este servidor é a

implementação cliente/servidor do MultiTerm, concebido para configurações de vários

utilizadores. Funcionando como hub do sistema, o MultiTerm Server providencia aos

utilizadores o acesso a bases de dados armazenadas centralmente no servidor, onde se

encontra um sistema de gestão de bases de dados, tal como o Microsoft SQL Server, o seu

equivalente MSDE, ou Oracle.

A figura 8 mostra uma configuração geral em que os clientes MultiTerm trabalham

simultaneamente com bases de dados locais e remotas utilizando a interface Web para aceder

às bases de dados em linha.

Figura 8 ‐ Configuração geral do SDL MultiTerm Server


Numa instalação cliente/servidor do MultiTerm, a utilização do MultiTerm Server está sujeita a

uma licença adicional, aumentando o custo financeiro desta solução. Esta licença é utilizada

para controlar as ligações simultâneas de clientes em número e em espécie. As restrições

aplicadas afectam, sempre que necessário, cada um dos componentes clientes que utilizam o

MultiTerm Server para aceder a bases de dados remotas.

A licença estipula ainda o número máximo de utilizadores que efectua ligações simultâneas ao

servidor. Ao atingir o número permitido de utilizadores da rede, é barrado o acesso para

edição de conteúdo ao utilizador até que um dos utilizadores já na rede termine a sua ligação,

sendo, no entanto, permitido o acesso para consulta e pesquisa.

2.3 Conclusões

Apesar das várias soluções já existentes no mercado e na Web para a gestão de terminologia,

verifica‐se que não há um consenso globalizante no tipo de funcionalidades disponibilizadas.

Em suma, estas revelam‐se:

• Dependentes de sistema operativo;

• De utilização complexa ou pouco intuitiva;

• Incompletas (ainda em fase de desenvolvimento);

• Inadequadas, pois não reúnem todos os requisitos pretendidos;

• Não direccionadas para o ambiente educativo;

• Por implementar;

• Indisponíveis;

• Proprietárias.

Se de uma forma geral se verifica uma lacuna na oferta de uma solução globalizante para a

gestão colaborativa de terminologia, então estas conclusões poderão servir de mote para

embarcar numa nova direcção, seguindo um rumo que permita:


• Reunir as principais funcionalidades numa mesma plataforma;

• Disponibilizar a ferramenta;

• Aplicar a plataforma a um contexto educativo prático.

Capítulo III – Metodologias de Investigação | 25

3 Capítulo III – Metodologias de Investigação

If we knew what we were doing, we wouldn't call it research, would we?

Albert Einstein

A condução do processo de investigação deste projecto exigiu uma estruturação prévia para

que lhe fosse transmitida coerência e inteligibilidade. A consciência de que a génese do

trabalho deverá determinar, após algumas considerações, o método de investigação, e que

cada método pode conduzir em diferentes sentidos, a principal preocupação deste

planeamento prévio foi permitir, essencialmente, a delimitação quer do objecto de estudo

quer das técnicas e procedimentos a utilizar na recolha, tratamento e análise de dados.

Qualquer área de conhecimento exige uma estruturação metodológica que permita a

inferência clara das conclusões formuladas, mas caberá à génese, à especificidade e à

finalidade do projecto a determinação da metodologia a seguir.

Como já foi referido, a presente dissertação teórica e o projecto prático realizado no seu

âmbito abraçam duas ciências que, apesar de distintas, têm como papel a complementaridade.

Por um lado existe a necessidade de dotar o sistema educativo de novas metodologias e novos

recursos que levem os alunos a adoptar novos métodos de trabalho e consigam adquirir

competências colaborativas na construção, gestão e partilha do conhecimento. Por se referir

ao estudo do comportamento humano num contexto social, esta necessidade recai no âmbito

das ciências sociais (Punch 2005) [44.]. Por outro, optou‐se pelo recurso à tecnologia e à

multimédia para dar corpo ao projecto.

A componente tecnológica e multimédia e as especificações formais inserem‐se no âmbito das

ciências naturais e exactas (Myers 1997) [42.].

Macedo et al. [35.] propõem três etapas numa metodologia de investigação:

1) Definição do propósito e orientação da investigação;

2) Recolha de dados;

3) Análise e Síntese.

26 | Capítulo III – Metodologias de Investigação

A primeira etapa prende‐se com a definição do objectivo da investigação e com a metodologia

a adoptar.

Durante a segunda etapa são recolhidos os dados obtidos pela aplicação das metodologias.

A terceira e última etapa tem como objectivo conduzir o investigador numa dada direcção

dependendo das conclusões retiradas durante a análise dos dados recolhidos, e poderá ou não

mudar o sentido da direcção tomada inicialmente ou identificar soluções.

3.1 Tipo de metodologia

As metodologias e as investigações efectuadas no âmbito das ciências sociais e humanas, bem

como aquelas efectuadas no âmbito das ciências naturais e exactas categorizam‐se e ocorrem,

regra geral, de forma distinta, conforme é possível observar pela Tabela 1 (adaptada de Pereira

& Paiva, 2008) [43.]:

Tabela 1 ‐ Categorização dos métodos de investigação e suas características gerais

Métodos Quantitativos Métodos Qualitativos

Aspectos Gerais

Resultados numéricos. Resultados verbais.

Filosofia: positivismo lógico. Filosofia: naturalmente fenomenológica.

Tem como objectivo explicar fenómenos e estabelecer relações causais.

Tem como objectivo compreender os fenómenos do ponto de vista dos participantes.

Métodos e processos de investigação

Conjunto de procedimentos que antecedem a Investigação.

É durante a Investigação que se tomam decisões quanto à recolha de dados (maior flexibilidade).

Estudos típicos

Utiliza planos experimentais e não experimentais para controlar variáveis parasitas.

Recorre a planos etnográficos e analíticos.

Papel do investigador

Investigador distante da investigação. Investigador insere‐se, implica‐se na situação.


Importância dada ao contexto

Procura estabelecer generalizações universais. Tem em vista generalizações limitadas ao contexto (importante para compreender a acção).

Técnica de recolha de dados

Observação estruturada e baseada em categorias pré‐estabelecidas de observação.

Observação etnográfica (típica dos antropólogos) e acompanhada de notas suficientemente esclarecedoras.

Entrevistas normalizadas (perguntas feitas). Entrevista etnográfica aprofundada, não estruturada. O entrevistado exprime‐se livremente.

Testes, questionários (estruturação).

Após algumas considerações e após a análise das técnicas, instrumentos e outros aspectos

relativos ao tratamento de dados, optou‐se pela adopção de um cruzamento metodológico,

globalizante de características quantitativas e qualitativas.

3.1.1 Método Quantitativo e Método Quantitativo

De uma forma simplista, é possível definir método quantitativo como aquele em que os dados

estão na forma de números e o método qualitativo como aquele em que os dados não estão

sob a forma de números, o que significa que, na maioria das vezes (mas não sempre) estão na

forma de palavras (Punch 2005) [44.].

O método quantitativo é geralmente utilizado em investigação nas ciências naturais e na área

de engenharia, enquanto o método qualitativo surge no âmbito da investigação nas ciências

sociais e tem como objectivo potenciar o estudo das pessoas e respectiva integração no meio

que as rodeia (Myers 1997) [42.].

Ambos os métodos são igualmente relevantes, ambos apresentam vantagens e fragilidades e

devem ser utilizados em conjunto, se necessário (Punch 2005) [44.].

Os métodos quantitativos e qualitativos podem articular‐se de diferentes maneiras no plano de

pesquisa de um estudo mantêm‐se autónomos, funcionando lado a lado, tendo como ponto

de encontro o assunto estudado (Flick 2005) [24.].


As metodologias de investigação permitem definir um conjunto de abordagens, técnicas e

instrumentos para conduzir todo o processo.

3.2 Abordagem

3.2.1 Estudo de Mercado (Survey) e Pesquisa – Acção

No decurso desta dissertação, é efectuado um cruzamento das abordagens utilizadas durante

a investigação. Por um lado procedeu‐se à recolha de dados através de um inquérito que

permitiu inferir sobre a relevância de uma plataforma Web para a gestão colaborativa de

terminologia, sobre as principais preocupações e finalidade, e também sobre a relevância da

inclusão de conteúdo multimédia na mesma. Esta abordagem, denominada Estudo de mercado

(Survey) é quantitativa e insere‐se no Positivismo, corrente filosófica que defende que a

realidade é objectiva, independentemente do observador (Macedo et al.) [35.].

A segunda metodologia abordada denomina‐se Pesquisa – Acção, tem o investigador como

elemento activo na investigação, baseia‐se na análise de resultados obtidos em determinados

momentos da investigação e é um método qualitativo inserido, por sua vez, no

Interpretativismo, ciência filosófica que defende que o conhecimento sobre a realidade só

pode ser alcançado através da interpretação dos fenómenos observados (Macedo et al.) [35.].

De acordo com Cohen e Manion (1989) [18.], esta abordagem aplica‐se sempre que haja um

conhecimento específico, sobre uma questão específica, numa situação específica, ou sempre

que haja vontade de efectuar uma nova abordagem a um sistema existente. Estes autores

sublinham ainda que uma das características fundamentais desta abordagem é o facto de o

trabalho continuar para além do final do projecto.

Brown e McIntyre (1981) [10.] descrevem esta abordagem no contexto educativo escocês e,

segundo eles, as questões relacionadas com a investigação surgem da análise de um problema

por parte de alguém envolvido na situação, dando lugar à necessidade da sua resolução. Ainda

segundo estes autores, o investigador formula princípios gerais e especulativos que levarão à

colocação de hipóteses para a tomada de atitudes que deverão levar, por sua vez, a novas

informações e à melhoria desejada. As informações retiradas das acções experimentadas

servirão o propósito de contribuir para a revisão das hipóteses iniciais e a colocação de novas

que se adeqúem às novas informações. As novas hipóteses geradas são postas em prática e


permitirão a retirada de novas conclusões e a alteração de princípios. Este processo é

recorrente até que haja uma aproximação à resolução do problema.

São várias as técnicas para a recolha de dados. Estas técnicas podem ser utilizadas

isoladamente ou em conjunto.

A corrente investigação decorrerá em vários momentos. O primeiro decorre antes de se dar

início à concepção da plataforma e em duas etapas:

I. Inquérito a uma amostra da população com questões pertinentes para o projecto;

II. Análise de documentos relativos à área de actuação.

3.3 Técnicas de recolha de dados

3.3.1 Inquérito

O inquérito, enquanto técnica de recolha de dados numa metodologia de investigação, visa a

obtenção de dados para análise, extracção de modelos de análise e estabelecimento de

comparações (Bell 1997) [5.].

Numa fase prévia ao desenvolvimento da plataforma, optou‐se assim por elaborar um

inquérito sobre a pertinência e utilidade da existência de uma plataforma multimédia na Web

para a gestão de bases de dados terminológicas e sua aplicação ao contexto educativo da

tradução (ver anexo A). O objectivo consistiu em dirigir o inquérito em causa às comunidades

profissional, docente e discente para dar resposta às questões:

1. “Qual o grau de relevância de uma plataforma multimédia de gestão colaborativa de

terminologia na Web?”

2. “Qual a finalidade, quais os constrangimentos e quais as características mais relevantes

numa plataforma multimédia de gestão colaborativa de terminologia na Web?”

3. “Qual a relevância do conteúdo multimédia numa plataforma de gestão colaborativa de

terminologia na Web?”

O recurso a um inquérito como instrumento de recolha de dados não implicará, no entanto,

que o estudo em si seja inevitavelmente quantitativo (Bell 1997) [5.]. O objectivo será não só

compreender qual o grau de relevância de uma plataforma deste género no contexto


educativo (e eventualmente profissional) da tradução, como também dados mais específicos

como faixa etária, grau académico e experiência docente/profissional dos inquiridos. Um outro

objectivo é aferir qual o conhecimento dos inquiridos sobre a existência de outras plataformas

semelhantes.

De forma a atingir uma amostra da vasta da população, foi utilizada uma plataforma de

inquéritos na Web [106.] e o inquérito elaborado (disponível através do endereço

http://www.polldaddy.com/s/A1418758C74CDD71) foi enviado por correio electrónico para

uma lista de contactos na área da tradução com um pedido de divulgação. Verificou‐se um

total de 40 resposta completas, das quais 36 provenientes de Portugal, 1 proveniente de

Espanha e 1 proveniente da Finlândia. Em 2 dos 40 casos, a origem é desconhecida (ver anexo

B1).

A um conjunto de procedimentos que antecedem a investigação em si, como a definição do

problema ou a colocação de hipóteses e/ou de questões de investigação, segue‐se um estudo

pormenorizado dos dados: planeamento, recolha, organização, validação, selecção, etc. O

confronto das hipóteses e/ou das questões de investigação com os resultados obtidos

determina as metodologias e procedimentos a seguir.

3.3.2 Análise dos resultados obtidos

Uma análise geral dos resultados obtidos permite aferir que 42,5% dos inquiridos são jovens

adultos entre os 26 e 35 anos de idade, e 22, 5% são adultos entre os 36 e os 45 anos de idade

(ver anexo B2).

Sobre o grau de instrução (ver anexo B3), 65% (aproximadamente dois terços) dos inquiridos

frequentam ou já concluíram o 2º ciclo de formação académica (Mestrado) e 22,5%

(aproximadamente um quarto) dos inquiridos frequentam ou já concluíram o 3º ciclo de

formação académica (Doutoramento). Estes dados revelam um elevado grau de instrução por

parte da amostra inquirida.

A maioria, 52,5%, revelou não ter experiência na área da docência, embora 25% dos inquiridos

afirmem ter mais de 10 anos de experiência na área. Relativamente à experiência enquanto

profissionais de tradução, apenas 12,5% admitem não ter qualquer experiência e 30% afirmam

trabalhar profissionalmente na área há mais de 10 anos (ver anexo B4).


A análise de resultados permitiu ainda constatar que 27,5% dos inquiridos trabalham sempre

com terminologia (ver anexo B5). Esta foi a segunda componente tradutiva mais vezes

seleccionada, apenas superada por memórias de tradução, componente seleccionada por 35%

dos inquiridos. A opção terminologia foi ainda seleccionada por 10% dos inquiridos que nunca

trabalham nesta área. Nenhuma das restantes áreas registou um número tão baixo de

escolhas para a opção “nunca”. Isto revela o elevado grau de relevância que a terminologia

ocupa em projectos de tradução, e por ser uma área de trabalho frequente e/ou constante

para 60% dos inquiridos, os dados obtidos nas restantes questões podem conferir um elevado

grau de fiabilidade a todo o estudo.

Um factor relevante é o conhecimento sobre as plataformas já existentes (ver anexo B6a).

28,2% dos inquiridos já conhecia pelo menos uma plataforma de gestão de terminologia (ver

anexo B6b). A tabela 2 descreve as plataformas mencionadas, bem como o número de

referências de que cada uma foi alvo:

Tabela 2 ‐ Plataformas mencionadas no inquérito e respectivo número de referências

Plataforma N.º de referências

Globs 1

IATE 3

Linguateca – Corpógrafo 1

MultiTerm 1

NedTerm http://taalunieversum.org/taal/terminologie 1

Proz http://www.proz.com 4

Translator's Café 1

Wikis 1

Wiktionary 1

Wordreference 1

Segundo a análise dos resultados, 71,8% dos inquiridos afirmam não conhecer qualquer

plataforma de gestão de terminologia, o que representa uma fasquia superior a dois terços do

número de inquiridos.


Um dos principais propósitos do inquérito é dar resposta à questão “Qual o grau de relevância

de uma plataforma multimédia de gestão colaborativa de terminologia na Web?”. Esta questão

encontra resposta na sexta pergunta do inquérito.

Quando questionados sobre a relevância da existência de uma plataforma multimédia para

criação e gestão colaborativa de terminologia na Web (ver anexo B7), 67,5% dos inquiridos

consideram que esta é relevante, e 22,5% afirmam mesmo que esta é imprescindível. No total,

90% dos inquiridos atribuem um determinado grau de relevância à existência de uma

plataforma com as características mencionadas.

A finalidade da plataforma é um ponto fulcral para o seu desenvolvimento. Apesar de se

concentrar no desenvolvimento de uma plataforma que se insira no contexto educativo da

tradução, este projecto não descarta a sua aplicação a nível profissional ou de investigação e

desenvolvimento. Questionados sobre que finalidade dariam a uma plataforma multimédia

para criação e gestão colaborativa de terminologia na Web (ver anexo B8), 42,5% afirmam que

a utilizariam no contexto educativo/formativo, e 40% consideram provável a hipótese de o

fazer. Podemos então considerar que 82,5% aceitam a existência de uma plataforma com as

características referidas no âmbito do ensino da tradução ou de línguas, o que confere um

impulso e um suporte consideráveis ao seu desenvolvimento. O resultado mais surpreendente

está relacionado com a utilização da plataforma para fins profissionais: 55% dos inquiridos

afirmaram que utilizariam a plataforma com esta finalidade, 32,5% consideram provável a

hipótese de o fazer e 12,5% afirmam que dificilmente o fariam mas não rejeitam totalmente a

hipótese. Na verdade, nenhum dos inquiridos rejeitou totalmente a hipótese de utilizar a

plataforma para fins profissionais. De igual modo, nenhum dos inquiridos rejeita totalmente a

hipótese de utilizar a plataforma para consulta: 85% afirmam que o fariam e 15% consideram

provável a hipótese de o fazer, ou seja, 100% dos inquiridos aceitam a existência da plataforma

para este fim. Um resultado bastante animador que não aborda, no entanto, a questão da

partilha colaborativa de conhecimento ou de criação de um saber‐saber. Mas também aqui os

resultados são favoráveis e estimulantes:

• 92,5% aceitam a existência da plataforma para a criação de glossários;

• 80% aceitam a existência da plataforma para a colaboração na gestão linguística da

língua materna;

• 90% aceitam a existência da plataforma para a partilha de conhecimento;


• 87,5% aceitam a existência da plataforma para a colaboração na gestão linguística

multilingue.

No entanto, o trabalho colaborativo na Web acarreta alguns constrangimentos e algumas

fragilidades. Por muito que exista uma vontade de que a colaboração e a partilha de

conhecimento sejam parte integrante do futuro, há ainda demasiadas pontas soltas que

necessitam de remate.

A oitava questão do inquérito aborda este ponto (ver anexo B9) e é uma questão de escolha

múltipla com caixas de selecção. Os 40 inquiridos efectuaram, no total, 229 selecções entre as

13 opções possíveis sem lhes acrescentarem qualquer outra.

A principal preocupação dos inquiridos recai na certificação da qualidade do trabalho

produzido em ambiente colaborativo: 14,4% (num total de 33 selecções) consideram um

constrangimento de uma plataforma de trabalho colaborativo na Web a dificuldade no

controlo de qualidade; a mesma percentagem considera um constrangimento a utilização de

fontes não indicadas ou não fiáveis; 11,4% aponta o dedo à falta de fiabilidade no conhecimento

produzido devido à possível falta de competência especializada na área pelo autor. Um dado

surpreendente é o facto de 7,9% considerar um constrangimento a dependência do acesso à

Internet. Este factor previa menor valor indicativo uma vez que actualmente prolifera o uso de

computadores portáteis e o acesso sem fios à Internet cobre já uma área considerável do

território [109.]. Também a banda larga veio trazer alguma estabilidade no acesso à Internet,

bem como a possibilidade de acesso constante sem acréscimo de custo. Este é,

definitivamente, um ponto relevante a ter em consideração e que requererá uma solução.

As questões finais abordam as características consideradas relevantes para a plataforma e o

conteúdo multimédia da mesma.

Relativamente às características relevantes na criação e gestão de terminologia (ver anexo

B10), 30% consideram relevante conseguir distinguir sublínguas e 65% consideram mesmo que é

imprescindível. Dos 40 inquiridos, 95% atribuem um determinado grau de relevância (relevante

e/ou imprescindível) à navegação intuitiva na plataforma, 87,5% à exportação da base de dados

terminológica para outro ficheiro, 85% à importação de bases de dados provenientes de outros

ficheiros e 82,5% à atribuição de várias línguas ao mesmo glossário. Em relação à inclusão de

conteúdo multimédia na base de dados, 35% dos inquiridos considera que esta é relevante e

25% considera‐o imprescindível. Nenhum dos inquiridos considera irrelevante.


Quando questionados sobre a tipologia de conteúdo multimédia a inserir numa plataforma

deste tipo (ver anexo B11), hipertexto e imagem são considerados pelos inquiridos como os

mais relevantes: 40% consideram relevante a inserção de hipertexto e 30% consideram‐no

imprescindível; 47,5% considera a inserção de imagem relevante e 35% considera‐o

imprescindível. Nenhum dos inquiridos considera irrelevante a inclusão quer de hipertexto,

quer de imagem. Os conteúdos áudio, transcrição fonética e pronunciação do termo

totalizaram valores idênticos entre si: 45% consideram relevante e/ou imprescindível a inclusão

de conteúdo áudio e a transcrição fonética e 47,5% consideram relevante e/ou imprescindível a

pronunciação do termo.

Esta análise permite concluir que grande parte dos inquiridos tem o espírito aberto em relação

ao trabalho colaborativo na Web. A maioria afirma mesmo que utilizaria a plataforma para os

mais diversos fins e considera a sua existência relevante ou até mesmo imprescindível.

Esta conclusão permite fundamentar alguns dos pressupostos para a criação de uma

plataforma multimédia para criação e gestão colaborativa de terminologia na Web e permitiu

retirar novas premissas a considerar durante o seu desenvolvimento.

3.3.3 Análise de Documentos

A análise de documentos é uma técnica de recolha de dados num projecto de investigação

bastante utilizada numa abordagem de Pesquisa – Acção.

Também a análise do estado da arte constitui um ponto de referência para a realização deste

projecto na medida em que permitiu avaliar as diferentes plataformas já existentes, como

foram concebidas, que princípios foram seguidos, o que ainda permanece por fazer, o que

funciona e o que falha. As metodologias já utilizadas em outros casos podem ainda permitir

estabelecer novos padrões de actuação ou desenvolver mais aprofundadamente o que já está

enraizado. Esta análise está desenvolvida de forma aprofundada no capítulo II – Estado da

arte.

Durante a fase de pré‐produção do desenvolvimento da plataforma (temática abordada no

Capítulo IV), esta será apresentada a utilizadores que poderão ser seus potenciais futuros

utilizadores assíduos em diversos contextos. Após uma breve utilização informal da

plataforma será pedido aos utilizadores que a avaliem tendo em consideração que a mesma


está ainda em fase de testes e desenvolvimento e que as suas considerações seriam

seriamente consideradas e utilizadas como um contributo para a continuação deste projecto.

De novo, a utilização de um inquérito como instrumento permitirá não só a recolha de

informação, sugestões e opiniões para consolidar ou reconsiderar futuras metodologias e

novos procedimentos de investigação, como também a avaliação das características,

funcionalidades e usabilidade da própria plataforma.

Resumidamente, o procedimento adoptado é o seguinte:

• Antes do desenvolvimento da plataforma:

Inquérito: PollDaddy

Aferição do grau de relevância do projecto

Análise de documentos

Estado da arte

• Durante a fase de pré‐produção do desenvolvimento da plataforma:

Inquérito: PollDaddy;

Recolha de informação, sugestões e opiniões.

Em última análise pretende avaliar‐se se a plataforma poderá ou não contribuir como

instrumento de apoio nos processos de ensino‐aprendizagem, construção de um saber‐saber e

partilha de informação na actual sociedade de informação.

Capítulo IV – Desenvolvimento e implementação da plataforma | 37

4 Capítulo IV – Desenvolvimento e implementação da plataforma

Web 2.0 is the business revolution in the computer industry caused by the move to the internet as

platform, and an attempt to understand the rules for success on that new platform. Chief among

those rules is this: Build applications that harness network effects to get better the more people use

them.

Tim O’Reilley

Conforme já foi referido anteriormente, aquilo que se pretende com este projecto é criar uma

plataforma multimédia para a e gestão colaborativa de bases de dados terminológicas e torná‐

la acessível ao maior número de utilizadores possível. Para atingir este objectivo, optou‐se por

utilizar a Web para a disponibilização da plataforma.

O desenvolvimento para a Web é uma das actividades que mais tem sofrido alterações ao

longo da sua “breve” existência. Na verdade, desde o seu aparecimento não cessou de evoluir

e cedo se percebeu que as possibilidades com este novo meio eram virtualmente ilimitadas.

O’Reilley [99.]considera que o rumo certo a tomar é compreender a fundo o funcionamento

da Internet e construir sistemas e aplicações que façam uso dela de forma mais rica e liberta

das amarras do pensamento da era do computador pessoal.

Na sua origem, as páginas Web eram criadas em meros editores de texto e a linguagem

utilizada era HTML, Hypertext Markup Language. Inicialmente estáticas (em que o conteúdo é

idêntico independentemente do utilizador que a requisite) as páginas Web depressa evoluíram

para a interactividade (situação em que a página possui elementos que interagem com o

utilizador com ou sem necessidade de comunicação com o servidor) e, consequentemente,

para a dinamização de conteúdos (neste caso, apesar de alojadas num servidor, as páginas

devolvidas ao utilizador são geradas consoante o pedido efectuado). Algumas páginas

interligam mesmo o conceito de interactividade e de dinamização, ou seja, determinadas áreas

possuem comportamentos interactivos mas estabelecem contacto com o servidor Web,

conceito este que será o adoptado para o desenvolvimento da plataforma.

38 | Capítulo IV – Desenvolvimento e implementação da plataforma

Hoje, as páginas Web podem mesmo ser editadas por utilizadores sem conhecimentos

profundos de edição Web e suportadas por acessos a bases de dados.

A figura 9 demonstra a evolução da Web entre os meados dos anos 90 do século XX, passando

pela actualidade e fazendo uma breve alusão ao que poderá ser o futuro próximo.

A Internet suporta vários tipos de aplicação, desde aplicações de comunicação interpessoal

(como correio electrónico e videoconferência) a uma variedade de aplicações interactivas.

Destas aplicações interactivas, as mais utilizadas têm como finalidade a interacção com um

servidor World Wide Web (WWW) ou, simplesmente, servidor Web.

A totalidade da informação armazenada num servidor é o equivalente a uma vasta biblioteca

de documentos (Halsall 2001) [28.].

Figura 9 ‐ Evolução da Web


A figura 10 ilustra este princípio:

Figura 10 ‐ Interacção simples com um servidor Web


4.1 Metodologia utilizada

4.1.1 Metodologia ágil de desenvolvimento

As metodologias de desenvolvimento tradicionais são preditivas, isto é, focam‐se no

planeamento de actividades futuras e todas as tarefas estão exactamente planeadas para

todas as fases do processo de desenvolvimento. Neste caso, e como se trata de um processo

de desenvolvimento que decorreu em camadas, optou‐se por se adoptar uma metodologia

adaptativa, ou seja, uma metodologia que se concentra na adaptação das e às variáveis que

surgem ao longo de um processo de desenvolvimento e em encontrar uma solução para essas

variáveis. Numa metodologia deste tipo, não é possível prever todas as tarefas a completar a

médio ou longo prazo, mas apenas o seu objectivo.

Caracteristicamente, as metodologias tradicionais de desenvolvimento são adoptadas em

situações em que os requisitos do projecto são seguros e têm uma evolução previsível, já uma

metodologia adaptativa não traz muito de novo mas concentra‐se em alguns princípios

distintos [100.]:

• Pessoas e interacções em detrimento de processos e ferramentas

Numa metodologia ágil de desenvolvimento, é dada maior relevância à equipa do que

ao ambiente: a equipa deverá ser criada em primeiro lugar e apenas depois poderá

configurar o ambiente com base nas suas necessidades.

• Desenvolvimento de software em detrimento de documentação

Demasiada documentação poderá consumir demasiado tempo e é difícil de manter a

par com a evolução do software, tempo e energia que poderão ser dispendidos em

desenvolvimento e implementação. Neste caso a regra é não produzir qualquer

documentação a não ser que a mesma seja imediatamente necessária e significativa.

• Colaboração com o cliente em detrimento de uma negociação contratual

Projectos de sucesso implicam interacção regular e frequente com o cliente e não

dependem exclusivamente de um contrato ou uma lista de especificações. Pelo

contrário, o cliente trabalha em parceria com a equipa de desenvolvimento, e entra

frequentemente em debate com ela sobre os progressos e problemas ocorridos.

• Adaptação à mudança em detrimento de seguir um plano

Esta será provavelmente a mais importante questão relativamente à adopção de uma

metodologia ágil de desenvolvimento. No decurso de um projecto de software é

virtualmente impossível prever o que irá acontecer a longo prazo, pois as variáveis a


ter em conta são demasiadas. Não só é difícil estabelecer requisitos fiáveis, como

também é difícil mantê‐los no tempo. A probabilidade de alteração dos requisitos por

parte do cliente quando vê o sistema em funcionamento é bastante elevada, como

também é elevada a probabilidade de eliminar da lista de especificações algumas

tarefas pré‐estabelecidas que se vão revelando desnecessárias à medida que o

projecto se vai desenvolvendo, dando eventualmente lugar a novas tarefas não tidas

em consideração no início da planificação. Resumindo, o plano requererá alterações

na sua forma e no seu tempo. Estrategicamente é mais eficiente optar por não

planear a longo prazo, mas antes a (muito) curto prazo tendo em conta o futuro de

forma muito abrangente, investindo num planeamento detalhado apenas para as

tarefas que são imediatas, momento este repleto de impulso e empenho. Ainda que

seja necessário alterar o rumo nesta fase, isso apenas implicará um pequeno

contratempo numa escala que englobe todo o processo.

Estes princípios e valores permitem uma concentração em técnicas simples para atingir os

objectivos. Equipas de trabalho que operem sob esta metodologia tendem a ser bastante

céleres na criação de pequenos pedaços de código, pois assim que um componente está

terminado, são adicionadas novas funcionalidades e assim sucessivamente. É possível, ainda,

atingir elevados níveis de pontualidade na entrega do produto e dentro do orçamento pré‐

estabelecido. Por estes motivos, esta é, logicamente, uma metodologia adoptada por várias

empresas de renome como, por exemplo, a Google [64.].

Da mesma forma, o ponto forte da adopção de uma metodologia ágil de desenvolvimento

assenta na sua capacidade de adaptação a novas conjunturas em que não há uma segurança

no que é pretendido ou uma mudança frequente de opinião.

Consequentemente, o software desenvolvido em pequenas fracções é concluído mais

rapidamente, permitindo a sua aplicação o quanto antes.

Por fim, a implementação e a fase de testes são constantes, contribuindo para um aumento da

qualidade do produto final.


Friedman (2009) [90.] defende que entre preço, qualidade e tempo, apenas será possível

obter duas das três variáveis. Será sempre necessário sacrificar um dos vértices daquilo a que

se chama triângulo do projecto, esquematizado na figura 11 [77.]:

O desenvolvimento desta plataforma rege‐se pela escolha de qualidade e tempo, sendo este

último o critério mais inflexível, ou seja, é uma constante e não uma variável. O nível de

qualidade do produto a apresentar pretende‐se que seja o mais elevado possível, no entanto o

factor tempo é determinante e terão que ser feitas opções ao longo do desenvolvimento da

plataforma que permitam atingir um nível razoável na relação qualidade/tempo. Conforme se

esclarecerá adiante, optou‐se pela utilização de tecnologia open source e gratuita, pelo que o

custo da plataforma não estará em causa. A adopção de uma metodologia ágil de

desenvolvimento é fundamental pois permitirá, assim, sujeitar o projecto a alterações

consoante os progressos/problemas verificados ao longo do tempo.

4.2 O processo de desenvolvimento

O desenvolvimento da plataforma decorreu em 6 fases e por camadas, tendo como base o

esquema da figura 12.

Figura 11 ‐ Triângulo de projecto


4.2.1 Análise de requisitos

Numa primeira fase, foi efectuada uma análise de requisitos e foram estudadas as

características e funcionalidades que a plataforma deveria possuir. Este ponto foi já abordado,

ainda que de forma superficial, aquando da definição de objectivos determinada

anteriormente.

4.2.2 Tecnologia

O requisito essencial que a plataforma deve cumprir é poder ser disponibilizada ao maior

número de utilizadores possível, independentemente do computador que possuam ou do

sistema operativo instalado. Desta forma, apenas fará sentido disponibilizar a plataforma via

Web o que implicará que o utilizador apenas tenha instalado um sistema operativo e um

explorador Web. Implicará também que o utilizador esteja dependente de uma ligação à

Internet, no entanto a cobertura da Internet com [56.] e/ou sem [83.] fios está, hoje, bastante

implementada, quer em Portugal quer no resto do mundo. De qualquer forma, esta questão

voltará a ser abordada mais adiante.

Figura 12 ‐ Metodologia de desenvolvimento adoptada


4.2.3 Funcionalidades

Numa fase de idealização da plataforma, foram apontados alguns requisitos funcionais

considerados necessários para disponibilizar um ambiente de trabalho eficiente, eficaz e útil

no âmbito da criação e gestão colaborativas de terminologia. Para validar estas opções e

inquirir sobre eventuais funcionalidades não tidas em conta ou consideradas secundárias, foi

colocada a questão “Que características considera relevantes na criação e gestão de

terminologia?” num inquérito dirigido à comunidade docente, discente e profissional na área

da tradução (ver anexo B10). Inicialmente, considerou‐se que seria fundamental numa

plataforma de criação e gestão colaborativas de terminologia:




• fácil usabilidade da plataforma (interface intuitiva);






Esta ordem não traduz a prioridade que cada uma das funcionalidades deve ocupar.

A tabela 3 ilustra, por ordem de relevância, as funcionalidades apontadas pelos inquiridos (o

valor percentual reflecte a somas das opções “Relevante” e “Imprescindível”).

Tabela 3 ‐ Funcionalidades apontadas pelos inquiridos por ordem de relevância

Funcionalidades Percentagem

Distinguir sublínguas, por exemplo: Português (Portugal) ou Português (Brasil). 95%

Interface intuitiva (fácil usabilidade). 95%

Exportar a base de dados terminológica (para um ficheiro *.csv, *.xlsx, *.xml ou outro).

87,5%

Importar a base de dados terminológica (de um ficheiro *.csv, *.xlsx, *.xml ou outro).

85%


Contactar criadores e gestores para colocar dúvidas ou sugerir alterações. 85%

Adicionar várias línguas ao mesmo glossário. 82,5%

Criar vários níveis hierárquicos na estrutura da árvore da base de dados terminológica.

80%

Consultar o registo de alterações efectuadas num determinado termo. 77,5%

Integrar a plataforma com outras ferramentas existentes no computador (editor de texto, editor de apresentações, folha de cálculo, ect.).

77,5%

Existência de vários níveis de permissão. 75%

Inserção automática da classe gramatical do termo 75%

Registo de alterações efectuadas por utilizadores. 67,5%

Incluir conteúdo multimédia. 60%

Definir obrigatoriedade de preenchimento de um determinado campo. 60%

Disponibilizar o glossário criado a um utilizador visitante (não registado). 42,5%

Registo de tempo dispendido por utilizador. 30%

Ouvir transcrição sonora (pronunciação) do termo. 25%

No espectro temporal disponível seria extremamente difícil por em prática todas as

funcionalidades consideradas relevantes, assim foi necessário fazer uma escolha bastante

selectiva das funcionalidades a disponibilizar num primeiro protótipo de uma plataforma de

criação e gestão colaborativas de terminologia. Contrapondo os requisitos funcionais iniciais e

as funcionalidades apontadas pelos inquiridos, optou‐se por trabalhar e disponibilizar as

seguintes características:


• fácil usabilidade da plataforma (interface intuitiva);




• existência de diversos domínios de conhecimento;

• atribuir o termo a um glossário e permitir atribuir esse glossário a um determinado

domínio de conhecimento;




• definição da nacionalidade dos utilizadores;


• possibilidade de associação de um glossário a um determinado domínio de conhecimento;


4.2.4 Actores e níveis de permissão

Conforme foi já mencionado anteriormente, um dos conceitos fundamentais da plataforma é

possibilitar a sua utilização de forma colaborativa entre vários tipos de utilizadores.

Num ambiente de colaboração, caberá a cada um dos diferentes tipos de utilizadores um papel

distinto. Esta colaboração entre utilizadores infere uma complexidade acrescida à gestão do

conteúdo terminológica da plataforma, tendo sido criado, para o efeito, um sistema de

permissões adaptado aos requisitos descritos anteriormente.

Resumidamente, os vários tipos de utilizadores e os seus papéis:

• Administrador

Caberá ao administrador da plataforma gerir o seu funcionamento e aceitar/declinar

novos utilizadores. O administrador terá total liberdade de acção.

• Gestor terminológico (Professor)

O gestor terminológico será o professor e caber‐lhe‐á gerir a informação introduzida

pelos colaboradores, bem como avaliá‐la. O gestor terminológico poderá:

visualizar, adicionar, editar e eliminar: entradas/termos inseridos por alunos

(públicos ou privados);

visualizar, adicionar, editar e eliminar: glossários;

adicionar, editar e eliminar: colaboradores e especialistas;

visualizar informação pública sobre todos os utilizadores e informação privada

sobre colaboradores e especialistas.

• Colaborador/Tradutor (Aluno)

O colaborador/tradutor será o aluno e caber‐lhe‐á inserir informação terminológica e

complementar as entradas com a informação necessária. Deverá seguir as indicações

do gestor terminológico e do especialista e terá permissões limitadas:


registar‐se: pendente de aceitação do gestor terminológico ou, em último caso,

do administrador;

visualizar, adicionar, editar e eliminar: entradas/termos inseridos pelo próprio

(públicos ou privados);

visualizar: entradas/termos inseridos por outros (públicos);

visualizar, e adicionar: glossários;


sobre si mesmo.

• Especialista

O especialista terá um papel bastante importante e muito específico na criação e

gestão terminológicas. Pretende‐se que o especialista seja capaz de identificar o

conceito associado ao termo/entrada, que identifique as suas características e valide

a informação contida numa entrada. Quanto maior o grupo de especialistas mais

representativa será a informação disponibilizada num determinado domínio (Costa &

Silva) [66.]. As suas permissões permitir‐lhe‐ão:

registar‐se: pendente de aceitação do gestor terminológico ou, em último caso,

do administrador;

visualizar e editar: entradas/termos inseridos por outros (públicos ou privados)

(a edição dos termos será efectuada sobre a inclusão de informação no campo

“notas”);

visualizar, e adicionar: glossários;


sobre si mesmo.

• Visitante (Utilizador não registado ou sem sessão iniciada)

O visitante será qualquer utilizador não registado que pretenda consultar o conteúdo

público disponível na plataforma. As suas permissões serão muito limitadas e apenas

permitirão:

registar‐se: pendente de aceitação do administrador ou do professor;

visualizar dados públicos;

O propósito desta plataforma é ser aplicada no ensino da tradução e, eventualmente, a nível

profissional. As categorias de utilizadores prevêem cada um dos papéis que estes possam

desempenhar em cada um desses ambientes, conforme ilustra a seguinte tabela:


Tabela 4 ‐ Paralelismo entre utilizadores em ambiente educativo e ambiente profissional

Ambiente educativo Ambiente profissional

Administrador Administrador

Professor Gestor terminológico

Aluno Colaborador/tradutor

Especialista Especialista

Utilizador não registado/sem sessão iniciada Visitante

4.3 Estudo e proposta de sistema

A proposta de sistema apresentada assenta nos requisitos pré‐estabelecidos. Após a análise

das tecnologias existentes procedeu‐se à averiguação das mais adequadas para dar forma à

ideia. Foram analisados vários sistemas, utilizando tecnologias diferentes, mas todos carecem

de pelo menos um factor para serem considerados totalmente eficientes. Foram ponderadas

algumas vias possíveis para o desenvolvimento da plataforma em causa.

4.3.1 CMS

Uma das hipóteses consideradas consistia em tentar identificar um CMS que pudesse já dar

resposta a alguns dos requisitos. Uma das plataformas abordadas durante a análise do estado

da arte, o GLOBS, utiliza um CMS como base do seu desenvolvimento: o GLOBS assenta no

CMS Drupal 5.

4.3.1.1 Vantagens de um CMS

• Geralmente, os CMS disponíveis são gratuitos, um factor relevante quando se pretende

manter os custos no mínimo. A maioria disponibiliza mesmo o seu código abertamente, o

que permite que haja um trabalho contínuo no seu desenvolvimento e no

desenvolvimento de funcionalidades mais específicas como a segurança, elevando o nível

de qualidade e fiabilidade. Código aberto é sinónimo de comunidade, o que significa que


existe um amplo apoio caso nos deparemos com problemas pontuais, ou que poderemos

expor algum problema a essa comunidade que provavelmente trabalhará para o resolver.

OS CMS são ainda facilmente personalizáveis, sendo disponibilizados com uma base já

bastante sólida e passíveis de serem adaptados ao gosto de cada utilizador (Mehta 2009)

[39.].

4.3.1.2 Desvantagens de um CMS

• Apesar de ajudarem na gestão de diversos tipos de conteúdo, desde weblogs a comércio

electrónico, a escolha é demasiado extensa e difícil. Escolher um CMS que se destine aos

objectivos propostos, tornou‐se uma tarefa ingrata, pois se alguns são excelentes na

disponibilização de elementos que podem ser caracterizados como funcionais, outros são

bastante melhores na arquitectura dos elementos (Ruby, 2006) [112.]. Não existe uma

fórmula para escolher um CMS e mesmo que este passo seja ultrapassado, a instalação,

personalização e gestão do CMS pode tornar‐se demasiado técnica e por vezes

ininteligível para alguns utilizadores (Mehta 2009) [39.].

• Adicionalmente, é necessário considerar a curva de aprendizagem longa e acentuada que

poderá ser impeditiva num projecto de término a curto prazo, como é o caso desta

dissertação.

A utilização de um CMS implica ainda a instalação de componentes que poderão ser

desnecessários às finalidades de cada utilizador. Neste ponto será contraproducente

desinstalar componentes desnecessários pois obrigará à perda de tempo, mas por outro lado

ocupar espaço com informação inutilizada poderá tornar a sua utilização menos eficiente. A

desinstalação dos componentes que à partida não serão utilizados poderá também pôr em

risco a funcionalidade de outros que sejam necessários.

4.3.2 Wiki

Numa análise detalhada sobre CMS, foi necessário comparar as potencialidades e

funcionalidades de sistemas mais generalistas com outros mais específicos como as Wiki de

forma a avaliar se algum destes sistemas poderia servir os propósitos da plataforma.


O termo “wiki” é uma abreviatura da expressão havaiana “wiki wiki” que significa “rápido”.

Actualmente esta expressão refere‐se a uma ferramenta que permite a qualquer pessoa criar e

editar páginas de um sítio Web. Funciona como um CMS em que os utilizadores não

necessitam de ter conhecimentos de HTML ou de outras linguagens e dispensa, na maioria das

vezes, o registo por parte do utilizador.

Uma característica fundamental das ferramentas/plataformas Wiki é a facilidade de edição e a

possibilidade de criação de conteúdo de forma colectiva e livre. Um sistema Wiki é, no fundo,

uma aplicação utilizada para trabalho colaborativo onde os utilizadores do sistema são os

contribuintes primários, e o que produzem é publicado para todos (Rahman 2007) [45.]. Este

sistema permite que qualquer utilizador possa editar conteúdo, possibilitando o crescimento e

correcção da plataforma com base na contribuição de todos. Sendo sistemas colaborativos por

natureza, pequenas contribuições de visitantes num sistema Wiki podem levar a um manancial

de conhecimento colectivo, e a qualidade será tanto maior quanto maior for o contributo dos

utilizadores (Mehta 2009) [39.].

No entanto, o facto de estar regularmente disponível para edição a qualquer pessoa que a

consulte, independentemente da nacionalidade, dos objectivos ou do grau de conhecimento

do utilizador, acaba por se transformar no maior constrangimento que uma plataforma deste

tipo apresenta. Se o objectivo for então o trabalho colaborativo num contexto educativo, será

necessário que a colaboração não seja totalmente livre, mas sim uma colaboração controlada

entre elementos de uma determinada unidade curricular. Um outro objectivo da plataforma,

ainda que numa fase posterior, será a avaliação do conteúdo criado pelo formando. Tal será

impraticável se houver uma abertura total à edição do conteúdo.

Duas plataformas foram fortemente consideradas para a base da plataforma: Mediawiki [93.] e

Dokuwiki [70.]. Estes sistemas são escritos em PHP e utilizam uma base de dados MySQL,

tecnologias bastante acessíveis e adequadas ao pretendido, no entanto, e na sua globalidade,

o processo de aprendizagem de utilização, a instalação, e a adequação de um CMS para

funcionar como base para a plataforma implicaria sacrificar a única variável que não o é: o

tempo.


4.3.3 RIA (Rich Internet Application)

Em resposta a uma crescente complexidade, as palavras‐chave nesta nova era de

desenvolvimento são “simplicidade”, “integração”, “abertura”, “geração”, e “agilidade”.

Neste sentido surge um novo conceito de desenvolvimento: as Rich Internet Applications, ou

como são vulgarmente mencionadas, as RIA (Surveyer 2004) [118.]. As RIA são utilizadas para

criar aplicações Web que combinem as capacidades de uma aplicação local para desenvolver

uma interface de utilizador enriquecido com as funcionalidades universalmente acessíveis e

sem recurso a download e instalação de uma aplicação.

A diferença fundamental entre as RIA e outras aplicações da Internet (como os CMS) é a

quantidade de interacção permitida na interface. Numa aplicação tradicional com base em

páginas da Internet, a interacção é limitada a um pequeno conjunto de controlos

normalizados, tais como caixas de selecção, botões rádio, campos de formulários e botões em

geral, o que limita seriamente a possibilidade de criar aplicações intuitivas e a grande maioria

das aplicações Web mostra‐se mais confusa e de mais difícil utilização do que as suas

correspondentes aplicações locais.

As RIA podem utilizar uma mais vasta (e eventualmente melhor) gama de controlos para

melhorar a interacção entre o utilizador e a interface, permitindo interacções eficientes,

melhor gestão do erro, retorno de informação e experiência geral de utilização (Mauer 2006)

[92.].

São exemplos de RIA: Backpack [58.], Basecamp [59.], Flickr [76.], Google Maps [79.] e Odeo

[101.].

Há, hoje, vários sistemas de desenvolvimento de RIA e alguns deles foram tidos em

consideração para o desenvolvimento da plataforma.

São exemplo desses sistemas: OpenLaszlo [86.] e Flex [55.].

4.3.3.1 Flex

O Flex é uma tecnologia lançada pela Adobe Systems para desenvolvimento, implementação e

manutenção de RIAs multi‐plataforma com base no Adobe Flash.


As aplicações Flex podem ser desenvolvidas com recurso a uma framework de código aberto

ou ao Adobe Flex Builder, um ambiente de desenvolvimento integrado concebido com base na

plataforma de código aberto Eclipse que permanece uma aplicação proprietária.

Se por um lado o Flex permite a criação de aplicações ricas num curto espaço de tempo, por

outro lado apresenta como desvantagens a curva de aprendizagem da tecnologia em si,

acentuada e demorada, e o facto de produzir um resultado em Flash®, o que pressupõe a

instalação da aplicação Adobe Flash Player e a existência dos plug‐ins necessários para a

visualização do conteúdo.

4.3.3.2 OpenLaszlo

O OpenLaszlo é uma plataforma de código aberto, patrocinada pela Laszlo Systems,

responsável original pelo seu desenvolvimento. Distribuída gratuitamente, a plataforma é

utilizada para criar aplicações Web enriquecidas que igualem as características de aplicações

locais e é a única plataforma RIA que suporta o desenvolvimento simultâneo de aplicações em

DHTML e Flash® a partir de uma mesma base.

O Laszlo Webtop tem o OpenLaszlo como base e permite a integração de múltiplas aplicações

OpenLaszlo num ambiente de trabalho unificado via explorador Web. O Webtop permite,

também, a gestão avançada de dados em aplicações mais complexas e de maior envergadura,

e do ponto de vista do desenvolvimento, permite a integração de aplicações OpenLaszlo

recorrendo a XML para aplicações já existentes. As aplicações em Java precisam apenas de

implementar uma interface simples para a troca de dados XML.

Foi neste sentido que foram efectuadas algumas tentativas de implementação deste sistema

com base na linguagem XML. No entanto, a plataforma disponibilizada encontra‐se ainda com

alguns problemas e a documentação disponível não corresponde à versão disponibilizada.

Também os problemas que surgiram não encontraram resposta em fóruns ou sítios Web com

alguma (ainda que pouca) informação sobre a implementação da plataforma.

Sobre a curva de aprendizagem do OpenLaszlo, apesar de ser de curta duração para aplicações

tipificadas, revelou‐se acentuada para o tipo de funcionalidade pretendida.

Mais uma vez optou‐se por não se sacrificar o pouco tempo disponível na aprendizagem,

detecção e correcção de erros de um novo sistema.


4.3.4 Bibliotecas de JavaScript

Embora não sejam consideradas plataformas de desenvolvimento de RIAs, as bibliotecas de

JavaScript constituem uma alternativa à forma como se desenvolve uma aplicação nesta

linguagem e uma solução eficaz para um mais rápido desenvolvimento de aplicações para a

Web. Existe um vasto número de bibliotecas JavaScript [84.].

São exemplos de bibliotecas de JavaScript: jQuery, Prototype ou Ext JS.

Por ser a mais familiar, a única biblioteca considerada para utilização no desenvolvimento da

plataforma foi a biblioteca jQuery.

4.3.4.1 jQuery [85.]

O jQuery é uma biblioteca de JavaScript rápida e concisa que simplifica a substituição de

elementos, manipulação de eventos, animação e interacções AJAX (Asynchronous JavaScript

And XML) em documentos HTML para um mais rápido desenvolvimento Web.

DELL, Drupal, WordPress, NBC ou Mozilla.org são exemplos de empresas que usam este

sistema.

Apesar de ser uma ferramenta interessante para apostar na apresentação da plataforma, a sua

utilização implicaria, mais uma vez, sacrificar tempo e engrenar na aprendizagem de novos

conceitos.

4.4 Decisão

Após esta análise, concluiu‐se que a metodologia mais acertada seria o desenvolvimento da

plataforma de raiz, incluindo o desenvolvimento da base de dados, de scripts e da interface.

O passo seguinte será o desenho da plataforma e das suas especificações. Será especificada a

tecnologia e toda a lógica utilizadas quer do lado do cliente quer do lado do servidor, bem

como a estruturação da base de dados e a modulação da plataforma.


4.5 Arquitectura

As aplicações Web são o presente e o futuro (Bulger et al. 2004) [11.].

No seu nível mais básico, a Web funciona numa arquitectura de cliente/servidor, ou seja, tanto

o servidor central como a aplicação cliente são responsáveis por uma determinado

processamento da informação.

4.5.1 Tecnologia do lado do cliente

As tecnologias disponíveis para a construção de aplicações Web são as mais variadas.

No caso de páginas estáticas, as opções recaem em tecnologias como HTML e/ou CSS (Cascade

Style Sheet) [123.].

A tecnologia utilizada para conferir alguma interactividade às páginas Web não é, regra geral,

suportada pelos exploradores. Apesar de a grande maioria dos exploradores de Internet,

como o Mozilla Firefox, o Internet Explorer ou o Google Chrome suportarem plug‐ins como o

RealPlayer, o Adobe Flash Player ou Shockwave, a sua utilização na construção de uma página

Web pode acarretar alguns problemas pois dependendo do nível de permissão do utilizador

final, a possibilidade de instalação desses plug‐ins poderá não estar disponível.

Uma outra possibilidade para conferir interactividade às páginas Web é a utilização de

JavaScript, uma linguagem de scripting, isto é, tem que ser utilizada em conjunto com outra

linguagem ou aplicação e não necessita de um plug‐in para ser executada. Esta linguagem é

disponibilizada gratuitamente nos exploradores e é passível de ser integrada com HTML e com

CSS. Mas mais uma vez, a sua utilização poderá estar limitada caso a execução de scripts no

explorador esteja desactivada.

Não existe uma tendência absoluta sobre a utilização do JavaScript, mas na realidade alguns

utilizadores não activam esta funcionalidade. A tabela seguinte (adaptada de [128.]) demonstra

a percentagem de utilizadores que tem esta funcionalidade activada em comparação com a

percentagem que a tem desactivada e a sua evolução ao longo dos últimos anos:


Tabela 5 ‐ Dados sobre a activação de JavaScript nos exploradores Web

Data JavaScript activado JavaScript desactivado

Janeiro 2008 95% 5%

Janeiro 2007 94% 6%

Janeiro 2006 90% 10%

Janeiro 2005 89% 11%

Janeiro 2004 92% 8%

Janeiro 2003 89% 11%

Janeiro 2002 88% 12%

Janeiro 2001 81% 19%

Janeiro 2000 80% 20%

No caso concreto a escolha foi a mais simples possível pois o objectivo será possibilitar a

utilização da plataforma por qualquer utilizador e a componente de JavaScript utilizada não

implica a inutilização da plataforma, pois apenas está disponível em situações muito

específicas e que não interferem com o funcionamento geral da plataforma.

O desenvolvimento Web deve recorrer a técnicas eficientes, de fácil manutenção, e

universalmente acessíveis. A solução passará por adoptar uma metodologia de

desenvolvimento com base na normalização da Web e manter a estrutura, a apresentação e o

comportamento separados. Isto significa que a marcação semântica e hierárquica do HTML

deverá estar separada da atribuição de estilos com CSS, e da introdução de interactividade e

dinamismo com a utilização de JavaScript. Esta abordagem optimizará o desempenho,

reduzirá o tempo de desenvolvimento e permitirá a disponibilização do conteúdo a um público

mais vasto [131.].


A esta abordagem dá‐se o nome de Progressive Enhancement e a sua estrutura está definida na

figura 13.

4.5.1.1 Estrutura: HTML

O código HTML é utilizado para conferir às páginas Web a sua estrutura bem como para

permitir a inserção de conteúdo (como texto e imagens). Estruturalmente, um documento

HTML é delimitado pelos elementos <HTML> e </HTML> e possui duas secções: o cabeçalho

(delimitado pelos elementos <HEAD> e </HEAD>) e o corpo (delimitado pelos elementos

<BODY> e </BODY>) (Ribeiro 2007). O código HTML é igualmente utilizado para descrever o

significado e o conteúdo da página e não a forma como esse conteúdo é visualizado

(Remoaldo 2008). Apesar de ser possível alterar a apresentação do conteúdo de uma página

com elementos tais como <b>, <i> ou <u>, a sua utilização é desaconselhada pois pode

influenciar a compreensão do seu conteúdo a utilizadores que, devido às suas necessidades

especiais, recorram a aplicações próprias para aceder à informação. Uma excepção é o

elemento <strong> … </strong> que permite aos exploradores colocar o conteúdo a

negrito enquanto a aplicação de ajuda poderá enfatizar a pronunciação do texto [130.].

Adicionalmente, a marcação semântica do código HTML permitirá a aplicação de estilos e

comportamentos sem lhe efectuar grandes alterações.

Figura 13 ‐ Progressive enhancement


O código HTML utilizado na plataforma permitiu não só conferir estrutura às páginas como

também gerar todo o conteúdo estático da plataforma, como as tabelas ou os formulários. No

cabeçalho foi incluída informação sobre a codificação de caracteres ou mesmo sobre o

atributo do conteúdo dentro de um elemento <META>[129.]. A inserção deste conteúdo

tornou‐se necessária pois sem indicação contrária, o reconhecimento dos caracteres não era

processado correctamente e a apresentação de caracteres especiais, como em palavras

acentuadas, surgiriam como símbolos. O atributo http-equiv="Content-Type" especifica

que o conteúdo está vinculado a um cabeçalho de resposta http. A figura 14 exemplifica uma

parte do código HTML utilizado na plataforma.

4.5.1.2 Apresentação: CSS

A utilização de folhas de estilo em cascata, ou CSS, consiste numa funcionalidade introduzida

com o HTML4 em 1997 e permite definir características visuais e alterar a apresentação de

elementos HTML ou XML (eXtensible Markup Language) atribuindo estilos a tipos de

elementos, classes de elementos ou instâncias individuais (Remoaldo 2008) à medida que

permite o estabelecimento de regras, rapidamente alteráveis, na formatação de elementos

para manter a consistência de estilo em todas as páginas de um mesmo sítio (Ribeiro 2007).

Após a sua introdução, o Consórcio W3C [126.], entidade reguladora das normas que gerem a

Internet, promoveu amplamente a sua implementação [123.] e [125.] por oposição às

funcionalidades de apresentação específicas do código HTML.

4.5.1.3 Comportamento: JavaScript

Como já foi referido, o objectivo é conferir à plataforma um certo grau de interactividade ainda

que em pequenas doses. Se por um lado a utilização de HTML e de CSS pode conferir alguma

interactividade à plataforma, esta é demasiado limitada pois o objectivo com que estas

Figura 14 ‐ Exemplo de código HTML utilizado na plataforma


linguagens foram desenvolvidas não é esse. De todas as tecnologias disponíveis, optou‐se por

utilizar a linguagem JavaScript pois é suportada pela grande maioria dos exploradores sem que

haja o recurso à instalação de plug‐ins. A sua utilização foi, no entanto, muito conservadora

devido às possíveis restrições do explorador Web. Aquilo que se pretende, em última análise, é

que a utilização de JavaScript não implique que um utilizador, cujo computador possua

determinadas restrições (nomeadamente em relação a conteúdo JavaScript), veja impedida a

sua participação enquanto criador de conteúdo na plataforma.

4.5.2 Tecnologia do lado do servidor

Mais do que interactividade, o objectivo é imbuir a plataforma em causa de dinamismo, isto é,

as páginas devolvidas ao utilizador deverão conter informação gerada dinamicamente,

dependendo do pedido efectuado. Como esta operação não é possível recorrendo apenas a

HTML, uma parte do código (HTML) terá, então, que ser substituída por uma série de

instruções que devolvam uma determinada informação quando a página em causa for

solicitada. Este processo é transparente do ponto de vista do explorador pois este recebe uma

página HTML em tudo idêntica a uma página HTML estática, permitindo incluir no código

HTML gerado, quer o conteúdo dinâmico obtido por manipulação de parâmetros enviados ao

servidor, quer o conteúdo estático (inalterável) e respectivos elementos. A distinção

fundamental é que o código HTML que constitui a página dinâmica devolvida apenas é gerado

após o pedido.

O mecanismo de criação de páginas dinâmicas pressupõe o recurso a determinadas linguagens

como ASP (Active Server Pages) [94.], JSP (JavaServer Pages) [116.] ou PHP (PHP: Hypertext

Preprocessor) [103.]que são inseridas no interior dos elementos HTML e que recorrem a

marcas específicas que as diferenciem do conteúdo estático.

O recurso a este tipo de tecnologia permite a visualização de um conjunto de características,

tais como as preferências do utilizador, informação enviada em conjunto com o pedido ou

informação existente em bases de dados ou ficheiros externos, tendo‐se optado pela

utilização de PHP.


4.5.2.1 Desenvolvimento em três camadas

O desenvolvimento de aplicações Web que perspectivem um volume significativo de tráfego e

a manipulação de um elevado volume de dados pressupõe uma metodologia de

desenvolvimento em três camadas (three‐tier application development) [110.], uma

arquitectura cliente‐servidor em que a interface e/ou utilizador, o processamento da

informação e o acesso e armazenamento de dados têm lugar em módulos distintos.

Como mostra a figura 15, as três camadas neste tipo de arquitectura são a camada de

apresentação (presentation tier), a camada de processamento (logic tier) e a camada de dados

(data tier).

O que o utilizador visualiza no seu explorador Web é a camada de apresentação e o seu

conteúdo é disponibilizado por um servidor Web. A camada intermédia processa a informação

lógica que ocorre, por exemplo, quando um utilizador envia um formulário preenchido. A

Figura 15 ‐ Desenvolvimento em três camadas


terceira e última camada está encarregue do processamento da(s) base(s) de dados e do

acesso a esses dados. Mais detalhadamente:

• Camada de apresentação (presentation tier)

Esta camada é o que o utilizador visualiza quando abre uma página Web no seu

explorador. A interface transpõe ao utilizador um resultado que ele possa interpretar.

Ao visualizar o código‐fonte de uma página apenas é possível ver código HTML,

JavaScript e CSS, não sendo possível ver as interrogações efectuadas à(s) base(s) de

dados ou processamento de variáveis. A este nível, as linguagens tipicamente

utilizadas são HTML, DHTML, CSS e JavaScript.

• Camada de processamento (logic tier)

Esta é a camada de coordenação da aplicação e de processamento de comandos.

Aqui são tomadas as decisões lógicas, efectuados os cálculos e processada

informação entre as outras duas camadas. É nesta camada que ocorre a maior parte

do trabalho de processamento e é possível que vários utilizadores acedam a ela

simultaneamente, daí que ela tenha que gerir as suas próprias transacções. A este

nível não é utilizado HTML ou JavaScript, mas sim uma linguagem de servidor, como

o PHP.

• Camada de dados (data tier)

Nesta camada é armazenada informação, a qual é extraída de uma base de dados ou

sistema de ficheiros. Os serviços estão protegidos de um acesso directo pelo

utilizador numa rede segura e a interacção ocorre através da segunda camada onde é

reenviada e processada a informação que, eventualmente, será enviada para o

utilizador.

4.5.2.2 Camada de processamento

As aplicações Web, como é o caso concreto desta plataforma, vêem grande parte do seu

trabalho a decorrer num servidor Web que é responsável pela comunicação entre o explorador

e a camada aplicacional de processamento.

A camada de processamento é implementada com recurso a uma linguagem de servidor, a

qual vai permitir o processamento dos pedidos efectuados e a interacção com a base de

dados.


A figura 16 ilustra esta arquitectura para uma aplicação Web.

4.5.3 Servidor Web

O Servidor Web corre sob o sistema operativo, recebe pedidos provenientes da Web e

processa esses pedidos, devolvendo as páginas com a informação solicitada. Dos vários

servidores existentes, há dois que dominam o mercado: o Internet Information Server (IIS) da

Microsoft, e o popular Apache.

O IIS está demasiado ligado ao ambiente Windows e é um componente chave da linguagem

ASP, também da Microsoft.

A opção para servidor Web recaiu, neste caso, sobre o Apache. Localmente foi instalada a

aplicação XAMPP [57.], uma distribuição integrada que contém as mais comuns tecnologias de

desenvolvimento Web: XML, Apache, MySQL, PHP e Perl.

Figura 16 ‐ Arquitectura de uma aplicação Web


4.5.3.1 Apache

O servidor de HTTP Apache é um projecto de código aberto, bastante estável, sendo o mais

popular servidor Web, conforme mostra a figura 17 (adaptada de [98.]).

O Apache, como é informalmente chamado, é mais eficiente em ambientes Unix, apesar de

também funcionar bem em ambiente Windows. A maioria dos servidores Web que utilizam o

Apache é Linux. É possível instalar o Apache numa máquina som o sistema operativo Windows

e, depois, transferir as aplicações para Linux sem alterações nos scripts. Esta abordagem é a

mais simples quando se produz localmente em Windows e se passa para um servidor

Unix/Apache, tendo sido a abordagem adoptada durante o desenvolvimento da plataforma.

O Apache oferece ainda a vantagem de ser gratuito e faz uso de uma licença sem restrições;

por ser um projecto de código aberto, disponibiliza todo o seu código e utiliza módulos para

carregar extensões nas suas funcionalidades, o que permite um mais rápido processamento do

código PHP. Uma outra vantagem é o facto de correr em sistemas operativos que não o

Windows (Davis & Phillips 2007) [20.].

66,65%

18,68%

8,20%

3,06%1,56% 0,99% 0,59%

0,26%

Apache

Microsoft

Other

nginx

Google

Lighttpd

SunONE

Zeus

Figura 17 ‐ Índice de utilização de servidores Web


4.5.4 Middleware

Middleware é comummente definido como o que une os componentes de software ou o que

une o software e a rede; é a camada de software que está entre o cliente e o servidor [97.].

O middleware trabalha de perto com o servidor Web para interpretar os pedidos efectuados a

partir da Web, processá‐los, interagir com outros programas no servidor para dar resposta aos

pedidos e, depois, indicar ao servidor exactamente o que devolver ao explorador Web. É a esta

classe que pertencem linguagens como o PHP (Bulger et al. 2004) [11.].

4.5.4.1 PHP

No que à programação Web diz respeito, e de uma forma bastante generalizada, todas as

linguagens acabam por fazer a mesma coisa. Escolher a mais adequada é, muitas vezes, uma

questão de ponderar o que é necessário fazer. Todas elas interagem com bases de dados

relacionais, todas lidam com sistemas de ficheiros, e todas contactam com servidores Web

(Bulger et al. 2004) [11.].

O PHP surge exactamente da necessidade de desenvolvimento e manutenção de aplicações

Web que possuam funcionalidades dinâmicas de Cliente/Servidor, sendo uma linguagem

interpretada e não compilada, isto é, funciona directamente com o código‐fonte ao ser

executado, por oposição a criar um ficheiro binário isolado, como um *.exe.

O código PHP está essencialmente direccionado para o desenvolvimento interactivo de

aplicações Web, passível de ser embebido em código HTML, originando código com instruções

específicas, e passível de efectuar determinadas operações que permitam a devolução

automática e dinâmica de páginas que correspondam ao pedido do utilizador final.

Tal como várias outras linguagens, o PHP possui variáveis para armazenar valores, operadores

para as manipular instruções de fluxo para controlar o decurso da aplicação, entre outros.

Vantagens do PHP

• Rapidez e facilidade

O processamento do código PHP permite bastante rapidez, sendo a combinação

perfeita entre o poder, a estrutura e a facilidade de utilização. A sua sintaxe é mais


poderosa do que ASP, JSP ou mesmo ColdFusion, não tendo uma curva de

aprendizagem tão acentuada como Perl, por exemplo. Em última análise, esta

linguagem permite o desenvolvimento de muito boas aplicações Web num curto

espaço de tempo.

• Multi‐plataforma

A linguagem PHP corre em várias versões do Windows e em Unix, tanto com o

Internet Information Service como com Apache.

• Acessibilidade

No decurso do desenvolvimento de uma aplicação Web pode ser necessário aceder a

vários serviços, tais como LDAP, Oracle, um servidor de correio electrónico IMAP ou

até a um parser de XML. Seja o que for utilizado, existe uma elevada probabilidade de

o PHP ter funções apropriadas a essa aplicação.

• Melhoramentos constantes

Num projecto de código aberto e com uma comunidade aplicada ao seu

desenvolvimento tão extensa como tem esta linguagem, a quantidade e variedade de

pessoas envolvidas contribui para uma melhoria quase diária do que é

disponibilizado.

• Suporte e apoio

É possível encontrar para o PHP, como para tantas outras linguagens, listas de

distribuição e contacto por correio electrónico (mailing lists), bem como sítios e

fóruns de desenvolvimento. A sua natureza de projecto de código aberto em muito

contribui para um sentimento de pertença a uma comunidade.

• Preço

PHP e Apache são completamente gratuitos.

Arquitectura e funcionamento do PHP

Ao ser detectada a existência de código PHP, o servidor Web processa‐o antes de ser enviada

qualquer informação ao explorador Web. Este último recebe apenas o HTML devidamente

processado e formatado. As figuras 18, 19 e 20 ilustram a diferença entre o código original, o

respectivo código fonte e o resultado no visualizado no explorador Web.


Figura 19 ‐ Código fonte (ficheiro: checklogin.php)

Figura 18 ‐ Exemplo de código PHP embebido em código HTML (ficheiro: checklogin.php)


No código PHP é ainda possível enviar cabeçalhos http, permitindo quer o redireccionamento

do explorador, quer a criação/manutenção de sessões, conforme se pode verificar nas figuras

anteriores.

O processamento do PHP ocorre do lado do servidor e ao ser pedida uma página, é

despoletada uma cadeia de acções. De uma forma geral o que acontece é:

• É solicitada uma página Web a partir de um computador local ao servidor Web;

• O servidor Web recebe o pedido de um ficheiro *.php (ou de outra extensão, desde que

devidamente configurado no ficheiro php.ini);

• O servidor Web identifica pelo tipo de extensão que se trata de um ficheiro PHP e

submete‐o ao pré‐processador de PHP;

• O pré‐processador de PHP executa o código encontrado no ficheiro *.php (é possível que

existam pedidos à base de dados MySQL);

O PHP pede à bases de dados MySQL para processar os pedidos efectuados à base de

dados;

O processamento efectuado na base de dados MySQL devolve os resultados do

pedido;

• O pré‐processador de PHP completa a execução do código encontrado no ficheiro *.php

(com os dados obtidos da base de dados) e devolve os resultados ao servidor Web;

Figura 20 ‐ Visualização no explorador Web (ficheiro: checklogin.php)


• O servidor Web envia ao explorador Web os dados em texto HTML;

• O explorador Web utiliza o código HTML devolvido para construir a página Web a ser

visualizada.

Apesar da complexidade dos passos executados, a informação é processada automaticamente

de cada vez que é pedida uma página com código PHP e pode ser executada várias vezes para

a mesma página, pois esta pode conter imagens e ficheiros CSS associados.

A figura 21 ilustra os passos descritos, ou seja, a interacção entre o computador do utilizador e

o servidor Web.

Figura 21 ‐ Interacção entre computador local e servidor Web (com e sem ficheiros PHP)


4.5.5 Bases de dados relacionais

Os sistemas de gestão de bases de dados relacionais (SGBDR) providenciam uma óptima

forma de armazenar e aceder a informação complexa e existem numa grande a variedade. A

maioria das bases de dados relacionais utiliza a linguagem SQL, Structured Query Language, a

mais popular linguagem utilizada para criar, aceder ou eliminar informação dos SGBDR.

Dos mais populares SGBDRs comerciais, destacam‐se alguns como por exemplo o DB2 (IBM)

[81.], Informix (IBM) [82.], Oracle [102.], SQL Server (Microsoft) [95.] ou Sybase [119.].

De uma forma simplista, uma base de dados relacional é um motor de bases de dados e o

conjunto de dados organizados em tabelas relacionadas entre si, mas vários outros elementos

são geralmente considerados como parte integrante da base de dados pois ajudam à

organização e estruturação dos dados e permitem que essa mesma base de dados esteja em

conformidade com um conjunto de requisitos.

4.5.5.1 MySQL

MySQL é uma base de dados relacional gratuita, mas bastante completa, e surge da

necessidade crescente de gerir informação de forma inteligente, estando particularmente bem

adequada ao desenvolvimento de aplicações Web (Bulger et al. 2004) e apresenta algumas

vantagens:

• Facilidade de obtenção

MySQL é um sistema de gestão de bases de dados facilmente acessível para transferir

e instalar [117.].

• Relação qualidade/preço

Apesar das imensas potencialidades de bases de dados como Oracle ou Sybase, estas

são proprietárias e o seu preço pode ser incomportável para muitos utilizadores.

Apesar de ser gratuita para desenvolvimento, a base de dados MySQL está disponível

para utilização e disponibiliza, também, excelentes funcionalidades que permitem a

sua utilização em vários tipos de projectos. Para utilização comercial, este sistema de

gestão de bases de dados já terá um custo anual associado.


• Rapidez e vigor

Para bases de dados de pequena ou média dimensão, MySQL consegue ser bastante

rápido e, em alguns casos, é mesmo possível que nenhuma outra base de dados

actue tão rapidamente.

• Melhoramentos constantes

A sua taxa de desenvolvimento é assombrosa. A disponibilização de novas e

impressionantes funcionalidades é actualizada quase diariamente por todos aqueles

que se dedicam a empenhar esforços no seu progresso.

Esta base de dados suporta uma grande variedade de motores que determinam de que forma

o MySQL manipula a informação armazenada e os pedidos efectuados aos dados. Por esse

motivo, cada um dos motores de armazenamento tem as suas próprias funções e vantagens, e

a sua evolução ao longo dos últimos anos tem tornado as bases de dados mais avançadas e

céleres. A figura 22 ilustra os vários tipos de motores e tabelas disponíveis numa base de dados

MySQL.

As tabelas do tipo MyISAM são as predefinidas e, inicialmente, eram as únicas disponíveis.

Neste momento, MySQL já suporta transacções e estas só são possíveis com a utilização de

tabelas tipo InnoDB. Uma vez que a plataforma desenvolvida no âmbito deste projecto tem

como um dos requisitos a transacção entre as várias tabelas de uma mesma base de dados,

optou‐se por se criar toda a base de dados com tabelas do tipo InnoDB. Este tipo de tabelas

suporta ainda chaves estrangeiras, ou foreign keys, que permitem que as relações entre as

tabelas sejam explicitamente designadas na base de dados.

Figura 22 ‐ Tipos de motores de armazenamento disponíveis numa base de dados MySQL


4.5.6 Utilização simultânea de PHP e MySQL

Vários factores tornam adequada a decisão de trabalhar com PHP e MySQL simultaneamente.

Vantagens da utilização simultânea de PHP e MySQL (Davis & Phillips 2007) [20.]:

• PHP e MySQL trabalham bem em conjunto

Ambos foram desenvolvidos com o outro em mente para que a sua utilização

conjunta seja facilitada e adequada; as interfaces de programação de ambos estão

lógica e intencionalmente emparelhadas.

• PHP e MySQL são projectos de código aberto

Não só são ambos projectos de código aberto como também são de utilização

gratuita; utilizadores com conhecimentos avançados têm a capacidade de alterar o

código fonte e, assim, o modo de funcionamento da linguagem.

• PHP e MySQL têm apoio de uma comunidade

Ambos possuem comunidades activas na Web em que qualquer utilizador pode

participar, colocar questões e expor problemas, e onde será dada uma resposta e/ou

uma solução. É ainda possível pagar por este apoio.

• PHP e MySQL são rápidos

O seu design simples e eficiente permite um desempenho mais rápido.

• PHP e MySQL não causam entraves com detalhes desnecessários

Não é necessário que o utilizador conheça todos os detalhes da interacção da

interface entre ambos pois há uma interface normalizada para chamar

procedimentos MySQL a partir do PHP. Algumas interfaces de programação de

aplicações, ou API (Application Programming Interfaces), oferecem recursos ilimitados

[103.].


No entanto, para ser possível efectuar ligações à base de dados e, posteriormente, conseguir

manipular os dados aí armazenados, é necessário utilizar algumas funções disponíveis na

interface MySQL do PHP. Um desses exemplos é a utilização da função mysql_connect() em

PHP para estabelecer uma ligação à base de dados conforme ilustra a figura 23.

4.6 Arquitectura e modelo de dados

A utilização de bases de dados pressupõe a modelação da informação nelas contida. O modelo de dados ilustra os dados que servem de base aos processos de um sistema de informação, sendo um conjunto de regras (ou ferramentas conceptuais) utilizadas para definir os dados, as relações entre esses dados bem como a sua semântica e restrições.

A modelação dos dados assume um papel preponderante na compreensão do sistema de informação na medida em que ilustra o significado da informação. Num ambiente de partilha de informação, esta modelação pode permitir mais facilmente a detecção de eventuais conflitos ou a visualização mais eficiente da relevância da informação, permitindo visualizá‐la e conservá‐la, contribuindo para uma melhor especificação da sua estrutura.

O modelo de dados em si é desenhado recorrendo a um processo iterativo e onde se torna progressivamente mais detalhado e menos conceptual, passando por três fases distintas, cada uma delas com as suas características:

4.6.1 Modelo Conceptual de Dados (MCD)

• Fase durante a qual são representados os objectos, suas características e relacionamentos, independentemente de qualquer implementação física ou limitação

Figura 23 ‐ Utilização da função mysql_connect() em PHP para ligação à base de dados MySQL


tecnológica ou técnica de implementação, sendo utilizado ao nível da conversação ou transmissão e validação de conceitos.

• Para a construção de um MCD são frequentemente utilizados diagramas de entidades e relacionamentos.

• Um mesmo MCD pode implicar implementações estruturais distintas, simplificando, no entanto, a tarefa de modelação. A aplicabilidade da modelação de dados poderá estender‐se a várias finalidades, como a definição de especificações e regras.

4.6.2 Modelo Lógico de Dados (MLD)

• Durante esta fase os objectos já estão condicionados pelas limitações tecnológicas e é durante ela que ocorre a transformação do MCD em estruturas de dados implementáveis do SGBDR escolhido.

• O modelo relacional mais utilizado na construção de um MLD é, por norma, o Relacional, embora existam outros (como, por exemplo, o Modelo Orientado a Objectos).

• Esta fase envolve a representação de objectos e conceitos essenciais para a sua implementação, independentemente dos dispositivos ou meios de armazenamento físico das estruturas de dados.

4.6.3 Modelo Físico de Dados (MFD)

• Durante esta fase definem‐se os pormenores físicos (específicos do SGBDR escolhido) a ter em consideração durante a implementação do MLD.

• Este modelo reflecte o modo como será, efectivamente, armazenada a informação em bases de dados e ficheiros; os objectos são representados de acordo com o enfoque no nível físico da implementação de eventos das entidades e respectivas relações.

• O MFD pode variar de acordo com o modo de implementação física e dos recursos para armazenamento e manipulação dos dados.

O modelo relacional utiliza conceitos de relações entre os dados e possui um esquema. Os dados estão inseridos em tabelas e interligados através de relações. A relação entre estas tabelas e os seus dados é estabelecida através de atributos comuns, designados por chaves. Estas chaves podem ser:

• Chaves candidatas: atributo ou conjunto de atributos que identificam cada linha da tabela de forma única;


• Chaves primárias: escolhidas entre as chaves candidatas e irrepetíveis ao longo da tabela;

• Chaves estrangeiras: atributo de uma tabela que corresponde à chave primária de outra.

4.6.4 Regras de Edgar Frank Codd

Codd (1970) [14.] afirmou que os utilizadores de bases de dados de grandes dimensões teriam que estar protegidos da organização da informação na máquina e propõe 12 regras (1985) [15.] e [16.]que deverão ser seguidas por um sistema de gestão de bases de dados relacionais:

• Regra da Informação:

Toda a informação de uma base de dados deve ser representada, ao nível lógico, apenas de uma forma: através de valores em tabelas.

• Regra do acesso garantido:

Deverá ser garantido o acesso lógico a cada um dos valores atómicos da base de dados relacional através do recurso ao nome da tabela, ao valor da chave primária e ao nome da coluna.

• Regra do tratamento sistemático de valores nulos:

Valores nulos (que não devem ser confundidos com cadeias de caracteres vazias ou de valores em branco, nem com valores zero ou outro número), são suportados em SGBDR para representação de informação em falta de forma sistemática, independentemente do tipo de dados.

• Regra do catálogo dinâmico em linha com base no modelo relacional:

A descrição da base de dados está representada, ao nível lógico, da mesma forma que os dados para que os utilizadores autorizados possam aplicar a mesma linguagem relacional quando a interrogam (a base de dados) que aplicam aos dados.

• Regra da sublinguagem dos dados compreensivos:

Um SGBDR pode suportar várias linguagens e diversas formas de utilização terminal. No entanto, tem que haver pelo menos uma linguagem cujas declarações possam ser expressas, através de uma qualquer sintaxe bem definida, por cadeias de caracteres e que consiga suportar o seguinte: definição dos dados, definição de vistas, manipulação de dados (de forma interactiva e por programa), restrições de integridade e procedimentos de segurança.

• Regra de actualização de vistas:

Todas as vistas que sejam teoricamente actualizáveis, também o serão pelo sistema.

• Regra da inserção, actualização e eliminação de alto nível:


A capacidade de lidar com uma relação de base ou derivada aplica‐se não só ao acesso aos dados, como também à inserção, actualização e eliminação de dados.

• Regra da independência física de dados:

Programas de aplicação e actividades terminais devem permanecer logicamente inalterados aquando de qualquer alteração na representação de armazenamento ou métodos de acesso.

• Regra da independência lógica de dados:

Programas de aplicação e actividades terminais devem permanecer logicamente inalterados aquando da ocorrência de alterações de preservação de informação de qualquer tipo às tabelas da base de dados que teoricamente permitam a sua não danificação.

• Regra da independência da integridade:

Restrições de integridade específicas de uma base de dados relacional em particular devem ser definíveis na sublinguagem de dados relacionais e armazenáveis no catálogo, e não nos programas de aplicação. Das duas restrições de integridade que se seguem, um mínimo tem que ser suportado:

Integridade da entidade: nenhum dos componentes de uma chave primária poderá conter valores nulos;

Integridade referencial: para cada valor distinto de uma chave estrangeira não nula numa base de dados relacional, tem que existir um valor equivalente na chave primária do mesmo domínio.

• Regra da independência da distribuição:

Um SGBDR tem independência da distribuição, o que implica que os utilizadores não têm que se preocupar se a base de dados é distribuída.

• Regra da não‐subversão:

Se um sistema tem uma linguagem de baixo nível (registo único de cada vez), a mesma não pode ser utilizada para subverter ou desviar a integridade das regras ou das restrições expressas numa linguagem relacional de alto nível (registos múltiplos de cada vez).

À altura da publicação destas regras por Edgar Codd, nenhum SGBDR estava em conformidade com elas, pressuposto que ainda hoje se mantém. No entanto, as bases de dados têm vindo a tornar‐se maiores e mais complexas, aumentando, assim, os níveis de exigência que as tecnologias actuais têm que acompanhar.


O sistema relacional pressupõe independência física e lógica de dados, implica uma facilidade em interrogar a base de dados através de SQL e o desenvolvimento de aplicações.

A modulação dos dados e da estrutura da plataforma revelou‐se essencial para o desenrolar do projecto, pois um mau entendimento acerca de qualquer conceito poderia levar a erros que condicionariam a concepção da base de dados e, provavelmente, a uma remodelação da camada aplicacional na qual esta assenta. No entanto, a eficiente modulação levou à concepção de uma base de dados adaptada aos requisitos mencionados, embora a mesma se encontrasse em permanente actualização com a inserção de novas tabelas e novos campos nas tabelas já existentes.

Tendo como um dos pontos de partida um melhor desempenho e uma carga de tráfego considerável, foi necessário construir a base de dados com base no processo de normalização até à forma normal de Boyce‐Codd [68.].

Este processo sistemático é definido por um conjunto de regras que promovem a eficiência, a previsibilidade de resultados e eliminação de ambiguidade e redundância nos dados.

Formas Normais nas bases de dados relacionais [19.]

• Primeira Forma Normal (1FN):

Uma relação ‘R’ encontra‐se na 1FN se e apenas se possuir valores atómicos.

• Segunda Forma Normal (2FN):

Uma relação ‘R’ encontra‐se na 2FN se e apenas se estiver na 1FN e se cada atributo não‐chave estiver inteiramente dependente de uma chave‐primária.

• Terceira Forma Normal (3FN):

Uma relação ‘R’ encontra‐se na 3FN se e apenas se estiver na 2FN e se cada atributo não‐chave estiver transitivamente dependente de uma chave‐primária.

• Forma Normal de Boyce/Codd (BCNF):

Uma relação ‘R’ encontra‐se na BCNF se e apenas se cada determinante for uma chave‐candidata.

Numa fase inicial irá permitir‐se que alguns valores não‐chave possam ser nulos, como o atributo “assessment” da tabela “entry”, pois esse valor apenas será preenchido quando houver dados suficientes para o professor atribuir uma nota àquele conjunto de informação. No entanto, este foi um princípio seguido de forma sistemática implicando uma integridade da entidade, tão necessária à consolidação da base de dados.


Outro princípio fundamental foi manter as restrições de integridade referencial através da definição de chaves‐estrangeiras, ou seja, se esta não tiver um valor nulo terá que existir uma relação onde essa chave é primária. Assim, todas as entradas terão que corresponder a um determinado glossário que, por sua vez, terá que corresponder a um determinado domínio (ou área de conhecimento), nem que este seja denominado “None”.

A base de dados desenvolvida apresenta um mapa de relações (ver figura 25) onde é possível ver que estas são, essencialmente, relações do tipo um‐para‐muitos. Isto acontece quando um valor de uma coluna é referenciado por diversas linhas noutra coluna.

A figura 24 representa um pormenor do mapa de relações da base de dados que ilustra este tipo de relação:

4.6.5 Estruturação da base de dados

A base de dados é, assim, constituída por uma série de tabelas, tendo‐se optado pela inclusão

de um identificador (id) em todas as elas, identificador este que constitui a sua chave primária.

Figura 24 ‐ Pormenor do mapa de relações com relações do tipo um‐para‐muitos


Além de um identificador, cada uma das tabelas contém atributos e valores associados, mais

especificamente:

beta.acess_level: além do identificador (‘id’), esta tabela contém um descritor (‘description’) e

um campo com o nível de acesso de cada um dos utilizadores (‘level’).

Figura 25 ‐ Mapa de relações da base de dados


beta.assessment: esta tabela tem como objectivo manter o registo das avaliações globais dos

discentes; contém um campo onde são registados os utilizadores avaliados (‘users’) e que está

relacionado ao identificador (‘id’) da tabela ‘beta.users’; contém ainda um campo ‘assessment’

onde será mantido o registo da classificação global do discente, a data em que a mesma foi

atribuída e o identificador do utilizador (‘users.id’) que o classificou.

beta.country: esta tabela contém um descritor (‘description’) de todos os países do Mundo,

estando o seu identificador relacionado com o campo ‘country’ da tabela ‘users’.

beta.docs: esta tabela tem como objectivo manter um registo de todos os documentos

multimédia transferidos para o servidor; contém um campo para registo do caminho relativo

do directório onde fica armazenado o documento (‘relative_path’), um descritor (‘description’)

cujo valor é inserido pelo utilizador que transfere o ficheiro, um campo ‘file_size’ onde é

registado o tamanho do ficheiro, e um campo denominado ‘file_extension’ onde está indicada

a extensão do ficheiro transferido. O identificador desta tabela está relacionado com o campo

‘docs’ da tabela ‘beta.docs2entry’.

beta.docs2entry: esta tabela tem como objectivo manter um registo das relações entre os

documentos transferidos e os termos existentes na base de dados. Contém um campo ‘entry’

relacionado com o identificador da tabela ‘beta.entry’, um campo denominado ‘docs’

relacionado com o identificador da tabela ‘beta.docs’, um campo descritor, onde fica registada

a descrição do ficheiro em relação ao termo e, finalmente, um campo denominado ‘mmtype’

que está relacionado com o identificador da tabela ‘beta.mmtype’.

beta.domain: esta tabela contém um descritor (‘description’) de todos os domínios existentes

na plataforma; o identificador desta tabela está associado ao campo ‘domain’ da tabela

‘beta.gloss’.

beta.entry: esta tabela guarda o registo de todos os termos inseridos (‘term’), associando‐os a

uma língua, a um glossário e a uma classe gramatical (valores obrigatórios); pode ser atribuído

ao termo uma classificação por parte de um docente, a data em que a mesma foi atribuída e o

identificador do utilizador (‘users.id’) que o classificou; é, obrigatoriamente atribuído a cada

‘id’ o identificador do criador do termo, bem como a data da sua criação; pode, ainda, ser

definido o estado do termo, a sua privacidade (termo público vs. termo privado) e a sua

editabilidade.

beta.field_description: esta tabela contém um descritor (‘description’) de todos os campos

existentes no formulário de submissão de uma nova entrada; contém também um campo


denominado ‘field_type’ que está relacionado ao identificador da tabela ‘field_type’; esta

tabela permite ainda que o utilizador defina a privacidade de cada campo.

beta.field_type: esta tabela contém um descritor (‘description’) dos tipos de campos

existentes no formulário de submissão de uma nova entrada; o seu identificador está

relacionado com os campos ‘field_type’ existentes nas tabelas ‘field_description’, ‘field_value’,

e ‘part_of_speech’.

beta.field_value: esta tabela contém um campo denominado ‘field_description’ que está

relacionado com o identificador da tabela homónima; será nesta tabela que ficarão registados

todos os valores inseridos no formulário que não sejam provenientes de caixas de selecção,

eventuais botões de rádio ou de caminhos relativos de ficheiros e estes registos serão

inseridos no campo ‘input_value’; o campo ‘entry’ (‘field_value.entry’) desta tabela está

relacionado com o identificador da tabela ‘entry’ (‘entry.id’); existe ainda uma relação desta

tabela à tabela ‘field_type’ através de um campo homónimo.

beta.gloss: esta tabela contém um descritor (‘description’) de todos os glossários existentes

na plataforma; a cada glossário pode ser associado um de vários domínios existentes na tabela

‘beta.domain’; pode ser atribuído ao glossário uma classificação por parte de um docente, a

data em que a mesma foi atribuída e o identificador do utilizador (‘users.id’) que o classificou;

é, obrigatoriamente atribuído a cada ‘id’ o identificador do criador do glossário, bem como a

data da sua criação; pode, ainda, ser definido o estado do glossário, a sua privacidade

(glossário público vs. glossário privado) e editabilidade.

beta.groups: com esta tabela pretende criar‐se um registo de todos os grupos criados no

âmbito do trabalho colaborativo; ela contém um descritor (‘description’) dos grupos criados;

existe ainda um registo do nível de acesso de cada um dos grupos, a sua data de criação e o

utilizador que o criou.

beta.groups_users: com esta tabela pretende criar‐se um registo da relação entre os

utilizadores e os respectivos grupos a que estes pertencem através dos campos ‘groups_id’

(relacionado com o identificador da tabela ‘groups’) e ‘users_id’ (relacionado com o

identificador da tabela ‘users’); esta tabela mantém, ainda, o registo da data de criação de

cada uma das relações anteriores.

beta.history: com esta tabela pretende criar‐se um registo o histórico do eventos ocorridos na

plataforma; a tabela contém um campo onde será inserido o tipo de conteúdo alterado


(‘content_type’) o registo alterado (‘record’), a acção efectuada (‘action_type’), o utilizador

que efectuou a alteração (‘user’) e a data da alteração (‘action_date’).

beta.language: esta tabela contém um descritor (‘description’) de todas as línguas faladas no

Mundo, bem como o código da língua associado, de acordo com a norma ISO de forma a

normalizar a plataforma e a adaptá‐la, eventualmente, à Web semântica.

beta.mmtype: esta tabela contém um descritor (‘description’) dos tipos de ficheiros

multimédia passíveis de serem transferidos; existe ainda uma relação entre o identificador

desta tabela e o campo ‘mmtype’ da tabela ‘beta.docs2entry’.

beta.part_of_speech: esta tabela contém um descritor (‘description’) das classes gramaticais a

que um termo pode ser associado e existe ainda uma relação com a tabela ‘field_type’ através

de um campo homónimo (‘part_of_speech.field_type’).

beta.translation: esta tabela contém dois campos (‘source’ e ‘target’), sendo que cada um

deles está associado ao identificador da tabela ‘beta.entry’; o objectivo desta tabela será o de

armazenar as correspondências dos termos entre as várias línguas, ou seja, a sua tradução.

beta.users: esta tabela contém um campo onde fica registado o nome de cada utilizador

(‘name’); existe a possibilidade de atribuir um determinado nível de acesso através da relação

entre o campo ‘access_level’ desta tabela com o identificador da tabela homónima

(‘access_level.id’); cada utilizador pode ser associado a um grupo de trabalho colaborativo

através da relação do seu identificador com o campo ‘groups_users.users_id’ da tabela

homónima (‘beta.groups_users’); a cada utilizador é associado um criador (campo relacionado

com o identificador da própria tabela), uma data de criação, um endereço electrónico que

servirá de ‘login’ na plataforma, um endereço electrónico alternativo, uma afiliação à

Instituição a que está veiculado e que representa enquanto utilizador da plataforma, bem

como a sua nacionalidade, estando este último campo relacionado com o identificador da

tabela ‘beta.country’; um campo fundamental desta tabela é o campo ‘active’ que, por defeito,

tem o valor 0 (zero) e que indica a possibilidade de actividade por parte do utilizador, mais

especificamente: um novo registo na tabela de utilizadores significa um novo utilizador com o

valor “active = 0” e apenas a validação por parte de um docente ou administrador poderá

actualizá‐lo para “active = 1” e só estes últimos terão privilégios de utilização da plataforma.


Após a fase de análise conceptual, passou‐se à fase de programação e codificação que, por sua

vez, permitirá as primeiras implementações da plataforma.

4.7 Modulação da plataforma

Conforme já foi referido, a plataforma assenta na utilização de linguagem PHP que gera

conteúdo dinâmico e disponibiliza formulários para inserir informação na plataforma. Segue‐se

uma pormenorização dos ficheiros que constituem a plataforma, bem como da sua função.

4.7.1 Codificação da plataforma

4.7.1.1 Configuração e ligação à base de dados:

connect.php – O desenvolvimento de plataforma decorreu tendo em conta que a grande

maioria dos ficheiros teria que ter em conta uma ligação à base de dados, pelo que se optou

por englobar a configuração e a ligação à base de dados num ficheiro único e independente

dos restantes, pois no caso de ser necessária qualquer alteração de algum dos dados da

configuração da base de dados esta seria efectuada apenas uma vez. Os restantes ficheiros

fazem referência a este através da expressão include (“connect.php”);. Este script começa por

definir a configuração da base de dados com o devido nome ($dbname), local de

armazenamento ($dbhost), utilizador ($dbuser), e palavra‐chave ($dbpass). Após a

configuração da base de dados é estabelecida uma ligação à mesma através da função

mysql_connect(). Além da ligação à base de dados, existe, neste ficheiro, uma função que

informa o MySQL que toda a informação recebida da base de dados está codificada em UTF‐8

e convertê‐la‐á em codificação tabela/coluna e o mesmo acontecerá quando o MySQL enviar a

informação de volta. A função é a seguinte: mysql_query("SET NAMES 'utf8'");

4.7.1.2 Entrada na plataforma

index.php – A primeira página visualizada pelo utilizador quando este acede à plataforma não

contém muita informação, apenas a necessária para obter uma visão global do projecto e as

hiperligações para iniciar sessão, dar início ao pedido de registo e um breve formulário de

pesquisa.


4.7.1.3 Gestão de utilizadores:

register.php – Este script devolve um formulário a ser preenchido por um futuro utilizador.

Este formulário tem 7 campos de preenchimento: “e‐mail” e “Password” serão os campos

utilizados para a entrada na plataforma, sendo que o primeiro deverá, num futuro próximo,

estar restrito a um domínio específico no caso dos docentes e dos alunos

(“[email protected]”) e o segundo estará configurado para que a senha utilizada por cada

um dos utilizadores seja encriptada na própria base de dados; o campo “Full name” terá como

objectivo a identificação completa do utilizador para efeitos de validação de registo e

manutenção da plataforma; o campo “Alternative e‐mail” serve para indicar uma segunda

conta de correio electrónico para que a comunicação com o utilizador seja assegurada caso

haja uma falha no servidor de correio electrónico da primeira conta; o campo “Affiliation” tem

utilidade, essencialmente, para identificar a instituição que os especialistas representam, para

que lhes possa ser atribuído um determinado grau de fiabilidade; a caixa de selecção

“Nationality” é gerada automaticamente a partir da tabela “language” da base de dados e

indica a nacionalidade de cada utilizador de forma a validar a informação inserida por cada um

deles; por fim, o campo “I want to register as” permite a selecção do tipo de utilizador

pretendido; este script auto‐evoca‐se, isto é, dependendo das condições, o formulário

devolvido terá características diferentes. Na figura 26 é possível ver o fluxograma do processo

de pedido de um novo registo. Após a submissão do formulário, os dados são inseridos na

base de dados mas o campo “active” da tabela “users” terá, por defeito, com o valor 0 (zero)

o que implica que o utilizador não pode aceder imediatamente à plataforma. O seu acesso terá

que ser validado por um professor ou pelo administrador da plataforma. Desta forma é

assegurada a validade dos utilizadores que efectuam um registo.


access_requests_list.php – Este script devolve, aos professores e administradores uma lista de

utilizadores que tenham pedido acesso à plataforma; os administradores têm permissão para

validar qualquer utilizador que tenha pedido acesso, enquanto os professores apenas têm

permissão para validar os pedidos de utilizadores que pretendam utilizar a plataforma

enquanto alunos ou enquanto especialistas; a lista será gerada conforme o tipo de utilizador

com sessão iniciada e a tabela será composta pelo nome do utilizador que efectuou o pedido,

o seu endereço electrónico e uma hiperligação para outro script

(validate_access_requests.php) responsável pela actualização do estado do utilizador. Na

figura 27 é possível ver o fluxograma do processo de listagem de pedidos de novos registos.

Figura 26 ‐ Fluxograma de pedido de um novo registo


validate_access_requests.php – Este script é evocado sempre que é validado um pedido de

acesso e é responsável pela actualização do estado do utilizador ao actualizar o campo ‘active’

da tabela ‘users’ através da execução de uma variável:

$query = "UPDATE users SET active=1 WHERE id='$_REQUEST[id]'";

$result = mysql_query($query);

No final é enviado um “header” que permite que o utilizador volte à página que evocou este

script:

header("Location: $_SERVER[HTTP_REFERER]");

Figura 27 ‐ Fluxograma do processo de pedidos de acesso


checklogin.php – Este script devolve o formulário de entrada na plataforma caso ainda não

tenha sido iniciada uma sessão; caso já tenha sido iniciada uma sessão, é impresso o nome do

utilizador que tem sessão iniciada.

A utilização da variável super global $_SESSION permite a manutenção de um estado durante

o acesso às diversas páginas através do envio via cookie, por parte do PHP, de um identificador

de sessão único. O PHP cria um ficheiro correspondente no servidor cujo nome corresponde ao

número do identificador da sessão.

Após a submissão do formulário, é evocado um outro script (login.php) para que sejam

verificados os dados inseridos no formulário. As restantes páginas da plataforma evocam este

ficheiro através da expressão include (“checklogin.php”); para verificar se o utilizador

está ou não registado e/ou com sessão iniciada.

login.php – Através da estrutura de controlo “if… else” é executado um bloco de código de

forma condicional. Caso (if) a expressão ($_REQUEST['email'] AND

$_REQUEST['password']) seja validada como verdadeira, então a instrução seguinte é

executada. Esta instrução interroga a base de dados à qual é feito um “SELECT” que devolve o

número de resultados obtido. Dentro desta estrutura de controlo existe uma outra: caso (if)

não seja devolvida qualquer linha, o utilizador recebe uma mensagem que o informa que os

seus dados são inválidos; caso contrário (else) recebe os seus dados pessoais. Se a expressão

inicial não for validada como verdadeira (else), o utilizador recebe a indicação que um ou

ambos os dados pedidos estão em falta.

Figura 28 ‐ Estrutura de controlo if… else


4.7.1.4 Gestão de glossários

list_gloss_list: Este script começa por interrogar a base de dados e pede, através de uma query

“SELECT”, o registo de todos os nomes e domínios de glossários editáveis. A função

mysql_fetch_array() selecciona uma linha do resultado da interrogação efectuada à base

de dados e o registo é armazenado sob a forma de um array em que cada campo corresponde

ao nome do campo no seu índice associativo. Esta função obedece aos parâmetros $row =

mysql_fetch_array($result, MYSQL_ASSOC); em que a variável $result corresponde

ao resultado da query efectuada e MYSQL_ASSOC corresponde ao tipo de resultado obtido.

Após a consulta à base de dados, é gerada uma tabela dinâmica (através de um ciclo

while();, cuja sintaxe está demonstrada na figura 29) com a indicação de todos os glossários

existentes na base de dados e respectivos domínios a que estão associados. São também

disponibilizadas ao utilizador algumas opções para cada glossário encontrado na base de

dados: editar o glossário, ver os termos que fazem parte dele e adicionar um novo. Cada uma

das opções apresentadas possui um elemento <a> (anchor) com um atributo href que

redirecciona o utilizador para a opção seleccionada tendo em conta o glossário consultado:

<a href="update_gloss.php?id=<?php echo $glossID ?>">Edit glossary</a>

<a href="terms2gloss.php?id=<?php echo $glossID ?>">View glossary's terms</a>

<a href="new_gloss.php">Add new glossary</a>

Figura 29 ‐ Sintaxe de um ciclo while();


new_gloss.php: Este script começa por interrogar a base de dados e pede, através de uma

query “SELECT”, o registo de todos os nomes e domínios de glossários existentes

correspondentes às variáveis $glossID=$_REQUEST["glossary"]; e

$domainID=$_REQUEST["domain"];. Após a interrogação à base de dados, é gerado um

formulário de inserção de um novo glossário com apenas duas linhas em que a primeira

contém um campo com o nome do novo glossário e a segunda contém a lista de domínio

gerada automaticamente a partir da base de dados em que o utilizador selecciona aquele a

que quer associar o glossário. Ambos os campos são de preenchimento obrigatório. Após a

submissão do formulário, é evocado o script update_gloss.php através de uma “action” no

formulário.

update_gloss.php: Este script é evocado pelo formulário existente no ficheiro new_gloss.php

ou através de um atributo href existente no ficheiro list_gloss_list.php para edição do

glossário listado. Através de uma estrutura de controlo “if… else”, este script é responsável

por uma de duas acções na base de dados: é inserido um novo registo na tabela “beta.gloss”

da base de dados através de uma query “INSERT INTO” caso (if) os valores indicados pelo

utilizador não existam ainda ou (else), caso o nome do glossário e o domínio já existam, é

feita uma actualização à base de dados através de uma query “UPDATE”. No caso de estar

algum valor em falta no formulário é devolvida uma mensagem ao utilizador que o informa

sobre a obrigatoriedade dos campos a preencher no formulário. Utilizadores não registados

não estão autorizados a inserir novos glossários na base de dados:

//verificação de utilizador com sessão iniciada

if($_SESSION[access_level]<5){

(…)

}else{

echo "Guest users are not allowed to insert new glossaries.";

};

terms2gloss.php: Este script gera uma lista de todos os termos existentes na base de dados

que correspondam a um determinado glossário, bem como as línguas em que cada um está e o

respectivo criador. Ele é invocado a partir da lista dinâmica de glossários (list_gloss_list.php) e,

após interrogar a base de dados, gera uma tabela com 4 (quatro) colunas: a primeira coluna


contém o valor do termo encontrado na base de dados após esta ser interrogada, a segunda

coluna contém a língua em que o termo se encontra, a terceira coluna contém o nome do

criador do termo e a quarta e última coluna contém uma hiperligação para a visualização

detalhada do termo.

<td width="300" height="20"><?php echo $row[term]?></td>

<td width="300" height="20"><?php echo $row[language]?></td>

<td width="300" height="20"><?php echo $row[creator]?></td>

<td width="100" height="20"><a href="view_term.php?id=<?php echo $id; ?>">View term</a></td>

4.7.1.5 Gestão terminológica

term.php: Este script devolve um formulário para edição de um termo. O formulário é

construído através de várias queries à base de dados. Após ser definida a variável

$termID=$_REQUEST["term"]; a base de dados é interrogada e caso a condição if

($termID) seja validade como verdadeira a query “SELECT entry.term AS term,

entry.language AS lang, entry.gloss AS gloss, entry.part_of_speech AS

pos, entry.multimedia AS mm FROM entry WHERE entry.id='$termID' AND

entry.editable=1;” é executada. A expressão “SELECT * AS” permite criar um nome

alternativo para o nome da coluna. Este nome alternativo é utilizado nas variáveis seguintes

para que sejam devolvidas linhas em tabela relativas às opções seleccionadas. Por exemplo:

Query:

SELECT entry.term AS term, entry.language AS lang, entry.gloss AS gloss, entry.part_of_speech AS pos, entry.multimedia AS mm FROM entry WHERE entry.id='$termID' AND entry.editable=1;

Variável:

$pos = $row[pos];

Instrução:

//iniciar menu Part of Speech

?>

<tr>

<td width="100" height="20">Part of Speech:</td>


<td width="500" height="20">

<select name='part_of_speech'>

<option value="0"></option>

<?php

while($row = mysql_fetch_array($result, MYSQL_ASSOC)){

$option=$row[id];

$value=$row[description];

echo "<option value=\"$option\" ";

if ($option==$pos) echo "selected=\"selected\"";

echo ">$value</option>\n";

};

?>

</select>

</td>

</tr>

Entretanto é criada a primeira parte da tabela que constitui o formulário. A primeira linha do

formulário contém duas colunas: a primeira contém o título “Term:” e a segunda contém o

termo a inserir/editar através da expressão <input name="term" size="106"

value="<?php echo $term;?>"/> incluída na célula (<td>) , em que é impresso o valor da

variável $term, isto é, o valor da respectiva coluna “term” na tabela “entry” da base de dados.

Seguem‐se os campos que constam da tabela “beta.field_description”. Uma vez que o

objectivo é que o utilizador também tome parte da criação da própria estrutura do formulário,

optou‐se por que este fosse criado dinamicamente. Assim, no futuro, se o utilizador assim o

entender, poderá acrescentar um campo à tabela “beta.field_description” e o mesmo surgirá

no formulário dinamicamente. A base de dados é, então, interrogada através de uma query

que devolve várias linhas com duas colunas cada, em que a primeira contém o nome do campo

existente na tabela e a segunda contém o valor dos campos a serem preenchidos, caso o

mesmo já exista na base de dados caso contrário o campo permanecerá vazio:

//query field_description

$query = "SELECT * FROM field_description ORDER BY field_description.id ASC";


$result = mysql_query($query);

(…)

<?php

while($row = mysql_fetch_array($result, MYSQL_ASSOC)){

$descriptionID=$row[id];

if ($termID){

$query=" SELECT input_value FROM field_value WHERE entry=$termID AND field_description='$descriptionID'";

$values = mysql_fetch_array(mysql_query($query), MYSQL_ASSOC);

$value=$values[input_value];

}else{

$value='';

};

?>

<tr>

<td width="100" height="20"><?php echo $row[description]?>:</td>

<td width="500" height="20"><textarea name="description_<?php echo $row[id]?>" rows="1" cols="80"><?php echo "$value"; ?></textarea></td>

</tr>

<?php

};

?>

As caixas de selecção “Language” e “Glossary” são geradas da forma idêntica à caixa de

selecção “Part of Speech”, já descrita, sendo que cada uma delas é gerada individualmente no

código do ficheiro.

O botão “Insert term” irá permitir a submissão de todos os valores do formulário para a base

de dados e chamará o ficheiro “update_term.php”.


update_term.php: Este script será responsável pela inserção da nova informação na tabela.

Através da estrutura de controlo “if… else” é executado um bloco de código de forma

condicional. Se (if) a expressão (!$termID) for validada como verdadeira, então a query

INSERT INTO é executada para a inserção de nova informação na base de dados:

INSERT INTO entry (term, language, gloss, part_of_speech, editable) VALUES ('$term', '$lang', '$gloss', '$pos', 1)

Caso contrário (else) as tabelas não receberam um novo registo, mas antes será actualizada a

informação nas linhas existentes correspondentes à variável $termID através de uma query

UPDATE:

UPDATE entry SET term='$term', language='$lang', gloss='$gloss', part_of_speech='$pos' WHERE id='$termID'

Na falha de preenchimento de campos obrigatórios (“Term”, “Glossary”, “Language” e “Part

of speech”), o utilizador recebe a indicação que os dados pedidos estão em falta e o script não

será executado sem que todos eles estejam preenchidos.

Utilizadores não registados não estão autorizados a inserir termos na base de dados:

//verificação de utilizador com sessão iniciada

if($_SESSION[access_level]<5){

(…)

}else{

echo "Guest users are not allowed to insert new terms.";

};

No final do bloco de código existe um elemento <meta>, responsável por reencaminhar o

utilizador para a anexação de conteúdo multimédia ao termo em questão:

<meta http-equiv="refresh" content="3;URL=ask4multimedia.php? entry=<?php echo $termID ?>" />


O atributo http-equiv="refresh" é utilizado como substituto de name="refresh" e

identifica o nome de uma propriedade. O atributo content="..." especifica o valor da

propriedade "refresh". Em termos práticos é invocada a propriedade "refresh" com o URL

“ask4multimedia.php” de acordo com os parâmetros que se seguem ao operador “?”. No caso

concreto, o parâmetro passado indica que na base de dados, o campo “entry” terá que

corresponder à variável impressa pelo código PHP ($termID).

view_term.php: É ainda possível apenas visualizar o conteúdo de um termo sem que os seus

campos estejam abertos para edição. Este script pode ser invocado através de um atributo

href presente no ficheiro list_terms.php e é responsável por imprimir todo o conteúdo

relacionado com o termo em causa, desde a sua definição até à lista de documentos

multimédia que o acompanham. Os documentos anexos ao termo poderão ser reproduzidos

através de uma hiperligação gerada para cada um dos documentos existentes. Esta

hiperligação executa o documento multimédia em causa e o leitor/reprodutor por defeito

existente no computador do utilizador para o tipo de ficheiro em causa é aberto. Existem

ainda três hiperligações: uma para editar o termo (update_term.php), outra para o remover

(delete_term.php) e ainda outra para fazer uma pesquisa.

delete_term.php: Este script é dos mais complexos pois efectua alterações simultâneas em

várias tabelas da base de dados e é responsável pela eliminação de todos os registos

referentes a um determinado termo: ao ser eliminado um termo da tabela beta.entry da base

de dados, são eliminadas, em simultâneo, outras entradas na base de dados cujo identificador

seja igual ao da linha eliminada na tabela beta.entry, nomeadamente: beta.filed_value,

beta.docs2entry, beta.translation e beta.entry. A base de dados é interrogada para eliminar

cada um dos registos em cada uma das tabelas com um campo “entry” cujo valor seja idêntico

ao identificador do campo “term” da tabela entry. Caso cada uma das ocorrências seja de

facto eliminada, o utilizador recebe uma mensagem com a confirmação da eliminação do

termo, caso contrário, a mensagem recebida indicará que ocorreu um erro:

$query = "DELETE FROM table WHERE entry=$termID";

if(mysql_query($query)){


echo "Term deleted from table.<br>";

}else{

echo "Problems when deleting entry $termID from table";

};

Em todo o caso, só será possível a eliminação de um termo por parte do seu criador, por

parte de um professor ou por parte de um administrador.

if($row[creator] == $_SESSION[id] and $row[editable] == 1){

(…)

}else{

echo "You have no permissions to delete this term.";

};

list_terms.php: Nesta fase, este script gera um rol de todos os termos existentes na base de

dados, no entanto, e numa fase futura, ele gerará uma lista dos termos que correspondam a

uma pesquisa efectuada. A tabela gerada contém 5 (cinco) colunas: a primeira coluna contém

o valor do termo encontrado na base de dados após esta ser interrogada, a segunda coluna

contém o nome do criador do termo em causa e a terceira coluna contém uma hiperligação

para a visualização detalhada do termo:

<td width="200" height="20"><?php echo $row[term]?></td>

<td width="200" height="20"><?php echo $row[creator]?></td>

<td width="200" height="20"><a href="view_term.php?id=<?php echo $id; ?>">View term</a></td>

No entanto duas das colunas apenas serão geradas caso o utilizador com sessão iniciada

seja o criador do termo:

<?php

if($row[creator] == $_SESSION[id] and $row[editable] == 1){

?>


<td width="200" height="20"><a href="term.php?id=<?php echo $id; ?>">Edit term</a></td>

<td width="200" height="20"><a href="delete_term.php?id= <?php echo $id; ?>">Remove term</a></td>

<?php

}else{

?>

<td width="200" height="20"></td>

<td width="200" height="20"></td>

<?php

};

?>

4.7.1.6 Gestão de conteúdo multimédia

ask4multimedia.php: Após o preenchimento do formulário de inserção de um termo, é dada a

opção ao utilizador de anexar conteúdo multimédia ao termo em questão. Este script é

invocado através de um elemento <meta> no final do bloco de código do ficheiro

update_term.php, já explicado anteriormente, e contém apenas uma pergunta (“Attach

multimedia file to term?”) com duas possibilidades de resposta. Caso o utilizador opte por não

adicionar conteúdo multimédia ao termo, voltará ao formulário do termo; no entanto, caso o

utilizador opte por anexar conteúdo multimédia, uma hiperligação redireccioná‐lo‐á para um

ficheiro responsável pela transferência de ficheiros para o servidor: add_mm.php de acordo

com os parâmetros que se seguem ao operador “?”:

<a href="add_mm.php?entry=<?php echo $_REQUEST[entry]?>">

Yes

</a>

Os parâmetros passados indicam que será adicionado conteúdo multimédia ao termo cujo

identificador na base de dados corresponda à variável $_REQUEST impressa pelo código PHP.


add_mm.php: Este script é invocado quando o utilizador opta por anexar conteúdo multimédia

a um termo e de todos os scripts concebidos é o que possui uma maior componente de

JavaScript. O elemento <HEAD> … </HEAD> deste documento contém um elemento

<SCRIPT> </SCRIPT> cujo atributo “type” tem o valor “text/javascript”. Este bloco de

código JavaScript no cabeçalho do documento é responsável pelas múltiplas transferências de

ficheiros, limitando o número de transferências a 6 (seis) de cada vez e define a função

attachmore() que é invocada cada vez que o utilizador opta por enviar mais um ficheiro. Esta

função é também responsável por definir e incrementar o valor da variável “attachmentid” e

quando o valor desta for igual ao valor da variável “attachmentlimit” a opção “Add another

file” deixa de ser visualizada, ou seja, o utilizador deixa de poder anexar mais documentos.

Através de um formulário, o utilizador tem a possibilidade de seleccionar o tipo de ficheiro

multimédia a transferir através de uma caixa de selecção que é gerada a da mesma forma que

são geradas as caixas de selecção “Glossary” e “Part of speech” no formulário de

inserção/actualização de um termo. Em seguida é possível seleccionar o caminho do directório

onde se encontra o ficheiro a anexar e, caso opte por adicionar um outro ficheiro, é invocada a

função attachmore(), gerando um novo campo para selecção do directório onde se encontra

o ficheiro a anexar e um outro para descrição do ficheiro. Após a anexação dos ficheiros, o

utilizador pode submeter o formulário que, por sua vez, invocará um outro script, upload.php,

responsável pelo processamento da transferência, tratamento e armazenamento do ficheiro,

bem como da inserção da informação nas respectivas tabelas da base de dados.

upload.php: Este script é responsável pelo processo de transferência de ficheiros para o

servidor. O directório alvo para a transferência dos ficheiros é estabelecido pela variável

$targetpath = "multimediadocs/"; e dependendo do tipo de ficheiro seleccionado pelo

utilizador, este será transferido para uma pasta concreta no servidor:

<?php

// configuração do directório alvo para o upload de ficheiros multimédia

$targetpath = "multimediadocs/";

for($i=1;$i<=6;$i++){

$mmtypes = 'mmtype_'.$i;

(…)


//verificar se o nome do ficheiro está vazio

if($FileName != ""){

//verificar tipo de ficheiro seleccionado

$FileType = $_FILES[$attachments]['type'];

if ($_REQUEST[$mmtypes] == 1){

$targetpath = $targetpath."image/";

}elseif ($_REQUEST[$mmtypes] == 2){

$targetpath = $targetpath."movie/";

}elseif ($_REQUEST[$mmtypes] == 3){

$targetpath = $targetpath."sound/";

}else ($_REQUEST[$mmtypes] == 4){

$targetpath = $targetpath."text/";

};

(…)

As seguintes extensões são definidas como suportadas na transferência dos ficheiros: *.gif,

*.jpg, *.png, *.swf, *.flv, *.avi, *.wmv, *.mpeg, *.mp3, *.wav e *.wma. Numa fase futura,

restringir‐se‐á os tipos de ficheiros às pastas adequadas.

O tamanho máximo de cada um dos ficheiros a anexar é definido através da variável

$FileSize à qual é atribuída a função round(), responsável por arredondar um número ao

próximo inteiro:

$FileSize = round($_FILES[$attachments]['size']/1024);

Uma vez que o tamanho do ficheiro é calculado em bytes, o arredondamento será efectuado

tendo em conta o princípio básico que 1 Megabyte equivale a 1024 Kilobytes e 1Kilobyte

equivale a 1024 bytes. Assim, o número de bytes do ficheiro será dividido por 1024 e o

resultado ficará registado em Kilobytes. Optou‐se por esta estratégia e não por dividir

novamente o valor por 1024, para que a variável responsável pelo resultado pudesse imprimir

um valor inteiro na respectiva tabela da base de dados, caso contrário, sempre que um ficheiro

tenha apenas poucas dezenas de kilobytes, o valor inserido na base de dados seria 0 (zero). Se


o número inteiro resultante for superior a 10 vezes 1024 (o tamanho máximo em Megabytes

permitido para a transferência de um ficheiro), o utilizador recebe uma mensagem de erro,

mas caso contrário, o ficheiro é movido para o servidor e são inseridos os valores necessários

na base de dados através de uma variável $query:

INSERT INTO docs (relative_path, description, multimedia, file_size, file_extension) VALUES ('$FileLocation', '$description', '$FileSize', '$FileExtension')

Após uma nova interrogação à base de dados para inquirir sobre o máximo valor do

identificador na tabela beta.docs, e no caso de uma transferência com sucesso do ficheiro, é

adicionalmente registada a relação do ficheiro transferido com o termo em causa na tabela

beta.docs2entry através de uma outra variável $query:

INSERT INTO docs2entry (entry, docs, description, mmtype) VALUES ('$entry', '$docs', '$description', '$_REQUEST[$mmtypes]')

Para cada valor registado na tabela e para cada erro ocorrido, é enviada uma mensagem

gerada através de código JavaScript e da utilização de métodos como

document.getElementById(’elementID’) ou getElementsByTagName('tagName'). O

método document.getElementById() pertence ao objecto do documento, o que implica

que o escopo do método abarca o documento por inteiro, incluindo o cabeçalho (<HEAD>) e o

corpo (<BODY>) de um documento HTML. Por outro lado, o método

getElementsByTagName() pode ser invocado em qualquer nó elemento, restringindo a área

do DOM a partir da qual se pretende que os nós sejam seleccionados. Por exemplo:

add_mm.php:

document.getElementById('attachmentdiv').appendChild(newnode);

(…)

<div id="attachmentdiv" style="margin-left:30px">

(…)

</div>


upload.php:

if (mysql_query($query)){

echo "<script type='text/javascript'>parent.document.getElementById ('".$attachmentdiv."').innerHTML = 'File $FileName of type $FileType with size $FileSize Kb, stored in $FileLocation' </script>";

echo "<script type='text/javascript'>parent.document.getElementById ('".$attachmentdiv."').innerHTML += '<br>The relation docs/entry was successful.' </script>";

}(…)

4.7.1.7 Folha de estilo

style.css: O objectivo primário deste script é estabelecer a separação entre a apresentação e o

conteúdo. Ele está associado a todos os outros scripts através do elemento <link> dentro da

marca <HEAD>…</HEAD>. Este elemento contém os atributos “type", “rel" e “href" e a sua

sintaxe completa é a seguinte: <link type="text/css" rel="stylesheet"

href="style.css">. Aos vários selectores são atribuídas propriedades e respectivos valores,

e o seu conjunto traduz‐se na apresentação da plataforma.

4.8 A plataforma

Após o desenvolvimento dos blocos de código que constituem o esqueleto da plataforma,

esta vai começando a ganhar corpo, forma e cor. A personalização da plataforma teve início

pela escolha da sua designação.

4.8.1 O nome

Desde a fase de conceptualização da plataforma que houve uma preocupação com o nome

que esta teria. Após algumas tentativas através da utilização de anagramas e algumas

palavras‐chave, optou‐se por utilizar uma palavra que não tem um significado directo com o

objectivo da plataforma, mas com um dos conceitos em que esta assenta.

Optou‐se, então, pelo nome “Beta”. Este nome representa o conceito muito associado à

produção de software e aplica‐se, essencialmente, ao conteúdo lógico que já passou uma fase


prévia de testes no seu desenvolvimento e é, então, disponibilizado a uma comunidade de

utilizadores enquanto protótipo. A fase beta de testes permite que o software seja sujeito a

uma série de variáveis não calculadas e permite que haja um retorno de informação sobre a

detecção de erros e problemas que os utilizadores tenham eventualmente efectuado e,

consequentemente, a resolução dos mesmos por parte da equipa de desenvolvimento. No

entanto, o conceito de “versão beta” de um produto tem ganho outros contornos no decorrer

dos últimos anos.

Na Web 2.0, em que os sítios e as aplicações são de natureza dinâmica e estão em constante

evolução e adaptação, dificilmente se atinge uma versão final. O facto de as aplicações

estarem em rede implica que o retorno de informação por parte dos utilizadores é constante,

assim como a resolução de erros e problemas ou implementação de novas funcionalidades.

Este procedimento deu origem ao conceito de “beta permanente”, o que implica que os

conteúdos e as aplicações estão sujeitos a uma evolução e adequação ad eternum. Algumas

marcas adoptaram este conceito durante um longo período de tempo, como foi o caso do

Gmail ou do Flickr e algumas marcas ainda hoje o utilizam, como é o caso da rede social Orkut.

4.8.2 O logótipo

De uma forma muito generalista, um logótipo é um símbolo que identifica um produto, bem,

serviço, marca, empresa, instituição, etc. e consiste na estilização de uma ou mais letras com

um aspecto característico, fixo e peculiar [104.]. Como se trata de uma plataforma para gestão

terminológica, optou‐se apenas por construi um logótipo tipográfico em que as letras que o

compõem se encontram contornadas por um traço espesso de cor.

A escolha da cor, no entanto, foi alvo de maior indecisão, mas temporariamente optou‐se por

um logótipo de cor azul, por se tratar de uma cor neutra e sóbria. Tanto a cor sólida como os

Figura 30 ‐ Logótipo da plataforma


tons mais claros que constituem o logótipo fazem parte uma paleta de cores seguras para a

Web (ver anexo C):

Tabela 6 ‐ Tabela de cores utilizadas no logótipo e respectivas referências por sistema de cor

Valores

Sist

ema

Hexadecimal #003366 #99ccff

RGB 0 / 51 / 102 153 / 204 / 255

CMYK 100% / 87% / 33% / 23% 35% / 10% / 0% / 0%

HSB 210º / 100% / 40% 210º / 40% / 100%

Lab 21 / 2 / ‐35 80 / ‐8 / ‐31

As figuras seguintes ilustram mais duas opções de cor.

Figura 31 ‐ Logótipo de cor bordeaux

Figura 32 ‐ Logótipo de cor verde


4.8.3 Navegação

Uma grande preocupação advinda do inquérito inicial foi a usabilidade da plataforma e a

facilidade de navegação na mesma. Um ambiente sóbrio, claro e com pequenos laivos de cor

para destaque de pormenores importantes foi o pretendido com a criação da folha de estilo

associada a toda a aplicação (style.css).

Optou‐se, também, por um menu superior horizontal e pela ausência de menus verticais,

sendo que no futuro poderá ser possível adoptar uma das áreas laterais para pequenos

patrocínios, protocolos, parcerias ou outros destaques académicos.

Outros pormenores foram tidos em consideração na concepção da plataforma, tais como a

resolução escolhida para as dimensões da plataforma e por que explorador optar para

optimização geral.

4.8.4 Resolução

Sobre a resolução a escolher, as variáveis apresentadas cingiam‐se à resolução de monitores

mais utilizada pelos utilizadores.

Até há pouco tempo imperava a teoria que a concepção para a Web devia abranger todos os

utilizadores que utilizassem monitores com pelo menos 800 por 600 pixéis de resolução. No

entanto, estatísticas recentes indicam que o número de utilizadores que utiliza monitores com

esta resolução ou menor atinge apenas 4%, um valor que sofreu uma grande redução nos

últimos anos já que em 2004 era de 37% (mais de um terço), numa altura em que ainda eram

detectados monitores com resolução de 640 por 480 pixéis.

Actualmente, os utilizadores que possuem monitores com resolução de 1024 por 768 pixéis é

inferior à que em 2004 utilizava monitores com resolução de 800 por 600 e a tendência é para

a utilização de monitores de resolução já superior, conforme mostra a tabela seguinte

(adaptada de [127.]):


Tabela 7 ‐ Índice de resoluções de monitores mais utilizadas

Data Maior 1024 x 768 800 x 600 640 x 480 Desconhecida

Janeiro 2009 57% 36% 4% 0% 3%

Janeiro 2008 38% 48% 8% 0% 6%

Janeiro 2007 26% 54% 14% 0% 6%

Janeiro 2006 17% 57% 20% 0% 6%

Janeiro 2005 12% 53% 30% 0% 5%

Janeiro 2004 10% 47% 37% 1% 5%

Janeiro 2003 6% 40% 47% 2% 5%

Janeiro 2002 6% 34% 52% 3% 5%

Janeiro 2001 5% 29% 55% 6% 5%

Janeiro 2000 4% 25% 56% 11% 4%

Além da resolução do monitor, uma outra variável a considerar é a área útil disponível

quando excluímos as áreas de comando do sistema operativo (como a barra de

ferramentas) ou a barra de deslocação do explorador Web.

A tabela seguinte (adaptada de [48.]) estabelece a comparação entre a área total e a área

útil de monitores com diferentes resoluções (área útil tendo em conta o Internet Explorer

6 e o sistema operativo Windows):


Tabela 8 ‐ Comparação entre área total e área útil de um monitor de acordo com a resolução

Resolução do monitor Área útil

800 x 600 780 x 429

1024 x 768 1004 x 597

1152 x 864 1132 x 793

1280 x 1024 1260 x 853

1600 x 1200 1580 x 1129

A figura seguinte ilustra a comparação entre a área total e a área útil de um monitor de 1024

por 768 pixéis, confirmando que há, de facto, uma área considerável que não pode ser tida em

conta quando excluímos estes factores.

Figura 33 ‐ Comparação entre área total e área útil de um monitor com resolução de 1024 x 768 pixéis


Uma das convenções na concepção de conteúdo para a Web estabelece que esta concepção

deverá ter em conta a menor resolução de monitores em uso que tenha uma percentagem

significativa de utilizadores. Se até há pouco tempo fazia sentido produzir conteúdo para

monitores com resolução de 800 por 600 pixéis, hoje tal seria contraproducente pois a

percentagem de utilizadores é bastante pequena (4%) e tem vindo a diminuir

significativamente. Conceber uma aplicação Web para esta resolução implicaria que 93% dos

utilizadores, uma esmagadora maioria, veria grande parte da sua área de trabalho

desperdiçada.

A figura seguinte ilustra o contraste entre as proporções em várias resoluções, sendo que a

menor é a mínima resolução a considerar (800 x 600) e a maior (1680 x 1050) é a resolução em

que a plataforma foi maioritariamente desenvolvida.

Após a ponderação de todos os dados, e com a consciência que a resolução 1650 x 1050 será

excepcional, optou‐se por conceber uma plataforma com 1000 pixéis de largura para que seja

possível uma correcta visualização pelos utilizadores que têm uma resolução estabelecida nos

1024 por 768. Isto permitirá que não seja desperdiçada área de trabalho útil.

Figura 34 ‐ Contraste entre proporções de monitores de diferentes resoluções


4.8.5 Exploradores

Uma variável igualmente importante a considerar na optimização da plataforma é o

explorador Web em que a mesma vai ser visualizada. Uma vez que nenhum dos exploradores

interpreta o HTML da mesma forma, foi necessário optar por um explorador para a

optimização, não obstante a tentativa de harmonização para todos os exploradores.

A tabela seguinte (adaptada de [128.]) estabelece uma comparação percentual (em média) da

utilização dos vários exploradores ao longo dos últimos 42 meses (quatro anos e meio),

incluindo o ano corrente. A tabela completa, com dados desde 2002, pode ser consultada no

Anexo D.

Tabela 9 ‐ Índice de utilização dos vários exploradores nos últimos anos

IE7 IE6 IE8 Firefox Chrome Safari Opera

2009

Junho 18.7% 14.9% 7.1% 47.3% 6.0% 3.1% 2.1%

Maio 21.3% 14.5% 5.2% 47.7% 5.5% 3.0% 2.2%

Abril 23.2% 15.4% 3.5% 47.1% 4.9% 3.0% 2.2%

Março 24.9% 17.0% 1.4% 46.5% 4.2% 3.1% 2.3%

Fevereiro 25.4% 17.4% 0.8% 46.4% 4.0% 3.0% 2.2%

Janeiro 25.7% 18.5% 0.6% 45.5% 3.9% 3.0% 2.3%


2008 25,33% 25,57% 1,02% 40,94% 3,2% 2,43% 1,81%

IE7 IE6 IE5 Firefox Mozilla Safari Opera

2007 18,7% 37,42% 1,87% 33,83% 1,32% 1,62% 1,63%


IE7 IE6 IE5 Firefox Mozilla N7/8 Opera

2006 2,23% 56,38% 4,52% 26,32% 2,48% 0,38% 1,52%

Legenda: Abreviatura / Nome do explorador Web

Chrome – Google Chrome / Firefox – Firefox (identificado como Mozilla antes de 2005) / IE – Internet

Explorer / Mozilla – Mozilla Suite (Gecko, Netscape) / N – Netscape (identificado como Mozilla depois

de 2006) / Opera / O – Opera / Safari – Safari (e Konqueror. Ambos identificados como Mozilla antes de

2007)

Os dados mais recentes indicam que no seu conjunto, as três versões do Internet Explorer

ainda em utilização não atingem o valor alcançado pelo Firefox: 40,7% contra 47,3%. O terceiro

explorador mais utilizado é o Google Chrome que atinge 6% das utilizações. Os exploradores

Safari e Opera atingem 3,1% e 2,1% respectivamente e, no seu conjunto, não atingem o valor do

Google Chrome, ficando‐se pelos 5,2%.

Desta forma, optou‐se por uma optimização da plataforma para o explorador Firefox, embora

se tentasse uma harmonização sempre que possível.

4.9 Testes/detecção de erros

A detecção primária de erros e problemas foi efectuada através de breves testes

experimentais de utilização à medida que a plataforma ia ganhando dimensão e os resultados

serão futuramente analisados e darão lugar à correcção dos mesmos.

Um dos problemas verificados está relacionado com a visualização do código pelos diferentes

exploradores Web. Numa tentativa de conceber uma forma de leitura de ficheiros de vídeo,

verificou‐se que Internet Explorer e Mozilla Firefox interpretam o elemento

<object>…</object> de forma distinta. Aliás, o Internet Explorer não interpreta o elemento

em causa pois trata‐o como um elemento ActiveX. Neste caso, e como uma solução a curto

prazo, optou‐se pela implementação de um método que resolve o problema para qualquer

explorador: para cada documento na plataforma é gerada uma hiperligação que permite que o


utilizador ao pressioná‐la abra o documento com o leitor do ficheiro accionado por defeito

para o computador em que se encontra a trabalhar.

Assim que a plataforma for disponibilizada para trabalho contínuo, certamente que outros

problemas e erros surgirão, incluindo aqueles que já existem mas que ainda não foram

detectados e que não o serão mesmo numa sessão de experimentação.

4.10 Pré‐produção

A fase de pré‐produção da plataforma (ou release candidate) está prevista para o início do

próximo ano lectivo, altura em que esta será inserida num contexto educativo para que seja

efectivamente testada e em que a maior parte dos seus erros ou problemas estejam

detectados e corrigidos. Esta fase pressupõe que a plataforma tenha já sido testada e esteja já

apta para uma utilização eficiente, apenas constrangida ou mesmo impossibilitada pela

ocorrência de erros crassos.

Por se atravessar, neste momento, uma época de férias lectivas, tal ainda não foi possível mas

espera‐se que a muito curto prazo seja possível haver um retorno de informação sobre as

funcionalidades já disponibilizadas. Prevê‐se ainda a implementação, na própria plataforma, de

um formulário/inquérito de satisfação ou de uma área em que seja possível que os utilizadores

relatem os problemas que encontram.

Este processo é relevante pois permite manter a integridade da plataforma, o seu correcto

funcionamento e promover a sua melhoria.

A utilização da plataforma por alunos e docentes num contexto educativo prático permitirá

também detectar eventuais necessidades que, de outra forma, permaneceriam ocultas e que

permitirão assim um aumento da sua eficiência.

Capítulo V – Perspectivas de trabalho futuro | 109

5 Capítulo V – Perspectivas de trabalho futuro

Há um tempo em que é preciso abandonar as roupas usadas, que já tem a forma do nosso corpo, e

esquecer os nossos caminhos, que nos levam sempre aos mesmos lugares. É o tempo da travessia: e, se

não ousarmos fazê‐la, teremos ficado, para sempre, à margem de nós mesmos.

Fernando Pessoa

5.1 Objectivos propostos

O desenvolvimento desta plataforma teve, como objectivo primordial, a sua aplicação ao

contexto educativo da tradução. Dado o estrito escopo temporal para o seu desenvolvimento

e aplicação, este objectivo não foi alcançado de forma concreta. No entanto, foi já elaborado

um inquérito (ver anexo E) que será apresentado aos utilizadores que testem a plataforma

antes da devida implementação, para que possam apresentar as suas opiniões e apreciações

que serão, por sua vez, utilizadas para que o desenvolvimento da plataforma num futuro

próximo adquira contornos mais bem definidos e necessidades mais concretas.

5.2 Implementação

Apesar de não estar ainda concretizada, a implementação da plataforma está já prevista para o

próximo ano lectivo para que possa ser dada a devida aplicação e, até, para detecção de

eventuais erros ou problemas. Também a prática tradutiva com recurso a uma ferramenta

Web de trabalho colaborativo será alvo de análise por parte dos docentes responsáveis.

Apenas após um estudo e uma análise aprofundados será possível inferir que rumo dar ao

desenvolvimento da plataforma, característica própria de uma metodologia ágil de trabalho e

desenvolvimento. No entanto, este rumo poderá ser invariavelmente alterado dependendo do

próprio futuro tecnológico e educativo.

O desenvolvimento da plataforma, espera‐se, será constante e com o seu desenvolvimento

pretende‐se a sua implementação em diferentes contextos educativos, isto é, quer a nível

secundário, quer a nível superior, e em diversas instituições de ensino. Para que tal seja

110 | Capítulo V – Perspectivas de trabalho futuro

possível, a própria plataforma terá que disponibilizar dados sobre a sua utilização e sobre os

resultados obtidos em estudos efectuados ao longo do tempo.

Para a implementação inicial da plataforma, e contando com a colaboração do seu Centro de

Informática, foi já criado um espaço na rede interna do ISCAP (onde a plataforma será testada,

a curto prazo, em contexto educativo) com a instalação de PHP e MySQL.

Sobre a própria utilização da plataforma há vários aspectos ainda a trabalhar que poderão

contribuir para a sua optimização. Em primeiro lugar, terá que ser desenvolvida uma área na

própria plataforma que inclua breves tutoriais multimédia com indicações básicas de utilização.

Deverão ser efectuados, periodicamente, estudos sobre a utilização da plataforma enquanto

ambiente Web de trabalho colaborativo na sala de aula ou, mais especificamente, na

construção e partilha de terminologia e, conforme já foi também referido, terá que ser

desenvolvida uma área que disponibilize dados resultantes destes estudos para que seja

possível a sua divulgação e espicaçado o interesse na mesma. Uma área igualmente

importante e que já foi também referida é aquela destinada à recepção de informação por

parte dos utilizadores da plataforma em forma de um inquérito de satisfação ou de uma área

em que seja possível que os utilizadores deixarem os seus comentários e relatem os problemas

que encontram durante uma utilização prática da plataforma num contexto específico. Este

processo permitirá manter a integridade da plataforma, o seu correcto funcionamento e

desenvolvimento e adequação, bem como a promoção da melhoria das funcionalidades

disponibilizadas.

5.3 Integração

No âmbito da análise do estado da arte foi estudado um projecto que, apesar de não se

enquadrar directamente nas ferramentas de construção colaborativa terminológica (motivo

pelo qual não está descrita no Capítulo II) se enquadra no tratamento terminológico de

corpora, extracção de terminologia e na possibilidade de codificar relações semânticas e

ontológicas: o Corpógrafo [87.].

Este projecto é, essencialmente, uma plataforma de pesquisa baseada em corpora

especializados e surge da necessidade de integrar num ambiente único todo um conjunto de

processos e procedimentos, anteriormente realizados com recurso a várias ferramentas ou

sistemas e é, invariavelmente, restrito ou difícil. Também com base na Web, o Corpógrafo


oferece a possibilidade ao próprio utilizador de compilar e pesquisar nos seus corpora (a partir

de documentos em formato PDF, Microsoft Word, Postscript, RTF ou HTML).

Neste âmbito, foi já estabelecido contacto com o criador original da plataforma, o Eng.º Luís

Sarmento, para especular sobre uma possível integração de ambas as plataformas. Na

sequência deste contacto tomou‐se conhecimento que apesar de já não estar ligado ao

projecto, o Eng.º Luís Sarmento se mostrou disponível para servir de elo de ligação num

primeiro contacto com os actuais responsáveis da plataforma.

5.4 Adequação

A Internet alterou radicalmente o conceito de acesso à informação e o próprio conceito do que

é a Internet foi mudando ao longo dos anos. No início, esta consistia na disponibilização de

informação em páginas estáticas (HTML) tendo evoluído rapidamente para a publicação

dinâmica de conteúdos (com recurso a tecnologias e linguagens, tais como XHTML, SQL,

MySQL e PHP), objectivo também pretendido com o desenvolvimento desta plataforma.

Actualmente caminhamos para um novo nível em que se pretende que os computadores

entendam o significado e as inter‐relações da própria informação. Esta terceira geração da

Web caracteriza‐se por Web Semântica cujo objectivo, perspectivado por Tim Berners‐Lee

(2001) [6.], é o desenvolvimento de normas e tecnologias facilitadoras concebidas para ajudar

as máquinas a melhor compreenderem a informação disponível na Web. Estas ferramentas

contribuirão também para promover uma mais rica descoberta, integração de dados,

navegação e automatização da informação ao utilizador.

Cada vez mais a Internet se assume como uma ferramenta predominante na educação,

contribuindo amplamente não só para a implementação de sistemas de gestão de

aprendizagem, como também para a partilha de conteúdo e colaboração na construção de

conhecimento e de saberes. Todo este processo decorre com recurso a metadados, isto é,

informação sobre dados ou dados‐sobre‐dados. No entanto, os metadados apenas permitem

uma descrição do conteúdo do recurso e não estabelecer relações entre os vários recursos

existentes. Estas relações são necessárias para que, de acordo com um perfil de utilizador

específico, ou de acordo com um pedido em particular seja devolvido o conteúdo procurado.

Uma das soluções passa pela estruturação desses mesmos metadados e aplicação de

ontologias ao conteúdo desenvolvido.


A Web Semântica perspectiva uma melhor qualidade na disponibilização de informação do que

a actual Web 2.0 e, neste contexto, o papel das ontologias é indispensável para a partilha de

conhecimento. É certo que a Web Semântica está ainda a dar os primeiros passos e as

problematizações inerentes ao seu desenvolvimento estão apenas agora a ganhar resposta.

Questiona‐se ainda a qualidade e validade das ontologias públicas e reforça‐se, por outro lado,

a promoção da reutilização das mesmas (Tartir, 2005) [120.].

Para a comunidade, docente e não‐docente, que apenas agora começa a acordar para uma

nova realidade tecnológica, parte integrante do futuro não só do ensino como de várias outras

áreas, e que se lança voluntariamente na produção ontológica de recursos educativos, a

primeira impressão poderá ser a de um mundo gigantesco e confuso que poderá levar ao

baixar de braços e à desmotivação. Interfaces de editores de ontologias confusos e pouco

intuitivos e a (ainda) inserção manual de informação consomem demasiado tempo.

No entanto, tais entraves não poderão permitir, pelo menos, a conceptualização de adaptação

de novas ferramentas à Web Semântica, pois esta é inevitável e para o seu desenvolvimento é

indispensável a normalização de linguagens e a validação da integridade de ontologias, os

próximos passos no desenvolvimento semântico da Web.

Num futuro relativamente próximo, a automatização da informação será um passo lógico. Da

mesma forma que existem já ferramentas para extracção terminológica através da análise de

corpora (como é o caso do Corpógrafo, atrás mencionado, e outras aplicações locais como o

MultiTerm Extract), a mesma tecnologia poderá e deverá ser aplicada a um nível bem mais

auspicioso: a extracção de relações ontológicas através da análise de corpora. Adequar a

plataforma desenvolvida a este conceito parece apropriado e propositado. Um objectivo

possível é a criação de mapas conceptuais através da informação introduzida na plataforma e

na criação de relações entre os vários termos que dela (da base de dados) fazem parte. Para

tal é fundamental a integração de ferramentas tecnologicamente desenvolvidas para

disponibilizarem eficientemente a informação solicitada.

5.5 Conclusões

São vários os desígnios possíveis para o futuro desenvolvimento da plataforma.

Essencialmente, pretende começar‐se por alterar hábitos de trabalho e aprendizagem, bem

como melhorar os resultados do trabalho e conteúdo produzidos de forma colaborativa na


Web. O trabalho colaborativo, dentro e fora da plataforma, será crucial para o seu

desenvolvimento. A opção por tecnologias de código aberto, normalizadas e gratuitas em

muito poderá contribuir para que haja pro‐actividade no que à evolução conceptual e

tecnológica diz respeito.

A sociedade de informação está em constante evolução, adaptação e metamorfose.

A adopção de tecnologias da informação e comunicação por parte de instituições de ensino

terá que acompanhar as constantes transformações, no entanto ambas não poderão dissociar‐

se no futuro.

Capítulo VI – Considerações finais | 115

6 Capítulo VI – Considerações finais

This is not the end. It is not even the beginning of the end. But it is, perhaps, the end of the beginning.

Winston Churchill

No final deste projecto detém‐se uma sensação antagónica que espelha, por um lado, a

consciência de que o trabalho realizado em muito foi condicionado pela divergência nas

apetências adquiridas ao longo de uma vida académica ligada às Línguas e à Tradução face às

necessárias para o desenvolvimento deste projecto, mas por outro, a realização pessoal e

académica de alguém que se propôs a trabalhar fora do seu âmbito e das suas competências e

adquiriu novas apetências tecnológicas, características de uma especialização tão desejada.

Os objectivos propostos e os objectivos alcançados não são díspares e os resultados

alcançados não ficaram aquém das expectativas desenvolvidas no início deste projecto.

Os objectivos propostos para uma fase inicial de desenvolvimento da plataforma foram

alcançados na sua totalidade, tendo já sido dado início ao trabalho proposto para uma fase

posterior com a disponibilização de glossários criados a utilizadores visitantes (não registados)

apenas para consulta. Outros objectivos, apesar de estarem ainda em fase de planeamento,

estão já previstos na própria estruturação da plataforma, como a criação de vários níveis

hierárquicos na estrutura da árvore da base de dados terminológica (através da criação

dinâmica do formulário de inserção do termo) bem como o registo de alterações efectuadas

por utilizadores (com uma tabela de registo do histórico das acções realizadas na plataforma

“beta.history”).

O objectivo primordial deste projecto consistia na disponibilização de uma ferramenta

colaborativa de trabalho que permita a aprendizagem e a construção de um saber‐saber na

área da gestão terminológica aliada ao contexto da tradução na actual sociedade de

informação. Este objectivo, apesar de não estar implementado por força de se atravessar uma

época não lectiva, está já estruturada com a elaboração de um inquérito a apresentar aos

utilizadores após a experimentação da plataforma. A sua avaliação global sobre a plataforma

contribuirá como incentivo para o seu desenvolvimento futuro.

116 | Capítulo VI – Considerações finais

A versatilidade e usabilidade da plataforma eram factores fulcrais a ter em conta, bem como a

sua disponibilização ao maior número de pessoas possível. O primeiro destes objectivos foi

amplamente alcançado ao serem utilizadas tecnologias simples e bastante desenvolvidas e

implementadas, em conjunto com a adopção de folhas de estilo em cascata (CSS) que em

muito contribuiu para uma plataforma mais agradável, mais leve e de mais fácil leitura pelos

exploradores.

Certamente que os objectivos alcançados seriam bem mais alargados caso o escopo temporal

fosse mais alargado. Foi referido, frequentemente, ao longo desta dissertação que a única

constante que não foi sacrificada foi de facto o tempo.

O ponto de partida para este projecto, no entanto, concentrou‐se no conceito de Web 2.0 e

adoptou com fio condutor a noção de trabalho colaborativo e partilha de conhecimento sem

esquecer a sua adequação à evolução tecnológica não só da Web como de todo o espectro

que a envolve. Projectos como o Wordnet [122.] servem de referência e de inspiração para que

a Web semântica seja construída por todos e para todos; um lugar onde não só há partilha de

informação como colaboração na construção de um saber‐saber e em que a perspectiva é a de

uma evolução em prol do saber e do conhecimento verdadeiro e fiável. Também esta

plataforma tem a ambição de contribuir para e de se imiscuir na fase que se segue deste

mundo global de informação e de tecnologia que constitui a Web da Sociedade de Informação

do séc. XXI.

Capítulo VII – Bibliografia | 117

7 Capítulo VII – Bibliografia

7.1 Bibliografia

[1.] Ali, Ismail, & Ganuza, José Luis. 1997. Internet en la educación. Temas Generales: Vía@Internet. Madrid: Ediciones Anaya Multimedia, S. A.

[2.] Almeida, Gladis Maria de Barcellos & Oliveira, Leandro Henrique Mendonça de, & Aluísio, Sandra Maria. Junho de 2006. A terminoogia na era da informática. Ciência e Cultura, Vol. 58, n.º 2. São Paulo: Sociedade Brasileira para o Progresso da Ciência.

[3.] Bach, Santiago Olmedo. 2001. A gestão dos sistemas de informação. Colecção: Sociedade da Informação. Lisboa: Centro Atlântico, Lda.

[4.] Barrett, Edward (ed). 1995. Sociomedia ‐ Multimedia, Hypermedia and the Social Construction of Knowledge. Cambridge, Massachusetts: MIT Press.

[5.] Bell, Judith. 2002. Como realizar um projecto de investigação. 2.ª Ed. Vol. 38. Lisboa: Gradiva ‐ Publicações L.da.

[6.] Berners‐Lee, Tim & Hendler, James & Lassila, Ora. 2001. The Semantic Web. Scientific American.

[7.] Bogdan, Robert & Biklen, Sari. 1994. Investigação qualitativa em educação: Uma introdução à teoria e aos métodos. Colecção: Ciências da Educação. Traduzido por Maria João Alvarez, Sara Bahia dos Santos e Telmo Mourinho Baptista. Porto: Porto Editora, Lda.

[8.] Brampton, Martin. 2008. PHP5 CMS Framework Development. Birmingham: Packt Publishing, Ltd.

[9.] Brauner, Josef & Bickman, Roland. 1996. La Sociedad multimedia: Las futuras aplicationes del audio‐video, la informatica y las telecomunicaciones. Colec.: Ciencia para todos. Traduzido por Nélida Machain. Vol. 12. Barcelona: Editorial Gedisa, S. A.

[10.] Brown, S. & McIntyre, D. 1981. An action‐research approach to innovation in centralized educational systems. European Journal of Science Education 3(3): 243–258.

[11.] Bulger, Brad & Greenspan, Jay & Wall, David. 2004.MySQL/PHP Database Applications. 2nd Ed. Indianapolis, Indiana: Wiley Publishing, Inc.

[12.] Carriço, José António & António, José & Carriço, António João. 1998. Multimédia e Internet. Colecção: Nova Informática. Vol. II. Lisboa: CTI.

[13.] Castagnetto, Jesus & Rawat, Harish & Schumann, Sascha & Scollo, Chris & Veliath, Deepak. 2000. Professional PHP Programming. Collection: Programmer to Programmer. UK: Wrox Press Ltd.

118 | Capítulo VII – Bibliografia

[14.] Codd, Edgar Frank. 1970. A Relational Model of Data for Large Shared Data Banks. San Jose, California: IBM Research Laboratory,

[15.] Codd, Edgar Frank. 1985a. Does your DBMS run by the rules? ComputerWorld, 21st of October.

[16.] Codd, Edgar Frank. 1985b. Is Your DBMS Really Relational? ComputerWorld, 14th of October,

[17.] Coelho, Pedro. 2003. JavaScript ‐ Animação e Programação em Páginas Web. 5.ª Ed. Lisboa: FCA ‐ Editora de Informática, Lda.

[18.] Cohen, L. & Manion, L. 1989. Research Methods in Education. 3rd Ed. London: Routledge,

[19.] Date, Chris J. 1996. An Introduction to Database Systems. 4th ed. Vol. 1. Reading, Massachusetts: Addison‐Wesley Publishing Co.

[20.] Davis, Michele E. & Phillips, Jon A. 2007. Learning PHP & MySQL. 2nd Ed. Sebastopol, CA: O'Reilly Media, Inc.,

[21.] Deacon, David & Pickering, Michael & Golding, Peter & Murdock, Graham. 1999. Researching Communications: A Practical Guide to Methods in Media and Cultural Analysis. London: Arnold.

[22.] Fawcett, Neil. 1995. Multimédia: as suas múltiplas funções na gestão, na educação e no lazer. Traduzido por Eduardi Nogueira. Lisboa: Editorial Presença.

[23.] Figueiredo, Bruno. 2004. Web Design ‐ Estrutura, concepção e produção de sites Web. 2.ª Ed. actualizada e aumentada. Lisboa: FCA ‐ Editora de Informática.

[24.] Flick, Uwe. 2005. Métodos Qualitativos na investigação Científica. Traduzido por Artur M. Parreira. Lisboa: Monitor ‐ Projectos e Edições, Lda.

[25.] Gibaldi, Joseph. 2009. MLA Handbook for Writers of Research Papers. 7th Ed. New York, Broadway: Modern Language Association of America.

[26.] Gooden, Andrea R. 1996. Computers in the classroom: How teachers and students are using technology to transform learning. Montagem por Fred Silverman. United States of America: Apple Computer, Inc.

[27.] Goodman, Danny. 2007. JavaScript & DHTML Cookbook. 2nd Ed. Sebastopol, CA: O'Reilly Media, Inc.

[28.] Halsall, Fred. 2001. Multimedia Communications: Applications, Networks, Protocols and Standards. England: Addison‐Wesley. Pearson Education Limited.

[29.] International, SDL. 2007. SDL MultiTerm Desktop 2007 User Guide. SDL, plc.

[30.] Lloyd, Les, ed. 1997. Technology and Teaching. Medford, NJ: Information Today, Inc.


[31.] Lopes, Carlos Jorge & Ramalho, José Carlos. 2005. Web Services ‐ Aplicações distribuídas sobre protocolos Internet. Colecção: Web Pro. Lisboa: FCA ‐ Editora de Informática, Lda.

[32.] Lopes, Filomena Castro & Morais, Maria Paula & Carvalho, Armando Jorge. 2005. Desenvolvimento de sistemas de informação. Lisboa: FCA ‐ Editora de Informática, Lda.

[33.] Loureiro, Joaquim Luís. 2003. Gestão do conhecimento. Colecção: Sociedade da Informação. Lisboa: Centro Atlântico, Lda.

[34.] Lynch, Patrick J. & Horton, Sarah. 2004. Guia de estilo da Web: Princípios básicos de design para a criação de Web sites. Traduzido por Oscar Hernández Quiles. Barcelona: Editorial Gustavo Gil, S.A.

[35.] Macedo, Patrícia & Zacarias, Marielba & Tribolet, José. s. d. Técnicas e Métodos de Investigação em Engenharia Organizacional: Projecto de Investigação em Modelação de Processos de Produção. 6ª Conferência da Associação Portuguesa de Sistemas e Informação (disponível em http://www.inesc‐id.pt/ficheiros/publicacoes/2650.pdf).

[36.] Maedche, Alexander D. 2003. Ontology Learning for the Semantic Web. 2nd Ed. Massachusetts: Kluwer Academic Publishers.

[37.] Mason, Jennifer. 2006. Qualitative Researching. 2nd Ed. London: SAGE Publications Ltd.

[38.] Mayer, E. Richard (ed.). 2005.The Cambridge Handbook of Multimedia Learning. Cambridge: Cambridge University Press.

[39.] Mehta, Nirav. 2009. Choosing an Open Source CMS. Birmingham: Packt Publishing.

[40.] Miguel, António. 2006. Gestão de Projectos de Software. Colecção: Engenharia de Software. 2.ª Ed. actualizada. Lisboa: FCA – Editora de Informática,

[41.] Miguel, António. 2002. Gestão do risco e da qualidade no desenvolvimento de software. Colecção: Engenharia de Software. Lisboa: FCA ‐ Editora de Informática, Lda.

[42.] Myers, Michael D. 1997. Qualitative Research in Information Systems. MIS Quarterly 21 (2) (disponível em http://www.qual.auckland.ac.nz).

[43.] Pereira, Duarte da Costa, e João Paiva. 2009. Algumas notas sobre Metodologias de Investigações no âmbito de Mestrados Multimédia na FCUP. Faculdade de Ciências da Universidade do Porto.

[44.] Punch, Keith F. 2005. Developing effective research proposals. 2nd Ed. London: SAGE Publications Ltd.

[45.] Rahman, Mizanur. 2007. MediaWiki Administrator's Tutorial Guide. Birmingham: Packt Publishing, Ltd.

[46.] Remoaldo, Pedro. 2008. O guia prático do DreamWeaver CS3 com PHP, JavaScript e Ajax. V. N. Famalicão: Centro Atlântico, Ld.ª.


[47.] Ribeiro, Nuno. 2007. Multimédia e Tecnologias Interactivas. Colecção: Tecnologias da Informação. 2.ª Ed. actualizada. Lisboa: FCA – Editora de Informática.

[48.] Robbins, Jennifer Niederst. 2007. Learning Web Design. A beginner's guide to (x)html, style sheets and Web graphics. 3rd Ed. Sebastopol, CA: O'Reilly Media, Inc.

[49.] Serrão, Carlos & Marques, Joaquim. 2007. Programação com PHP 5. Colecção: Biblioteca Software Livre. Lisboa: FCA – Editora de Informática.

[50.] Sousa, Artur Afonso. 2002. Bases de Dados Web e XML. Lisboa: FCA – Editora de Informática.

[51.] Sousa, Gonçalo de Vasconcelos. 2005. Metodologia da investigação, redacção e apresentação de trabalhos científicos. Porto: Livraria Civilização Editora.

[52.] Ughetto, Vico. 2006. CSS – Criação Inovadora de Sites. Colecção: Web Pro. Lisboa: FCA – Editora de Informática.

[53.] Vandyk, John, e Matt Westgate. 2007. Pro Drupal Development. New York: Apress.

[54.] Vaswani, Vikram. 2007. PHP Programming Solutions. USA: Mc Graw Hill.

7.2 Fontes electrónicas

[55.] Adobe Flex 3. 2009. Create engaging, cross‐platform rich Internet applications. http://www.adobe.com/products/flex

[56.] ANaCom. 2008. Disponibilidade geográfica da banda larga em Portugal. http://www.anacom.pt/template12.jsp?categoryId=176882

[57.] Apache Friends. 2009. XAMPP. http://www.apachefriends.org/en/xampp.html

[58.] BackPack. s.d. Intranet, Group Calender, Small Business Organizer. http://backpackit.com/

[59.] Basecamp. s.d. Project management, collaboration and task software. http://basecamphq.com

[60.] Caldeira , Carlos P. s.d. Introdução ao Modelo de Dados Relacional. Portal Webmarketing. http://www.portalwebmarketing.com/Tecnologia/mdr_introducao_modelo_dados_relacional_indice/mdr_introducao_modelo_dados_relacional/tabid/658/Default.aspx.

[61.] Carvalho P. 2009. Criação e Gestão Colaborativa de Terminologia – Inquérito. http://surveys.polldaddy.com/s/A1418758C74CDD71

[62.] Chakraborty, Angsuman. 2006. Estrutura da base de dados de Java (recolocação de ORM) em 80 linhas de código. Simple Thoughts. http://blog.taragana.com/index.php/archive/java‐database‐framework‐orm‐replacement‐in‐80‐lines‐of‐code/pt.


[63.] CInAMil & ISCAP. 2009. DicMil – Dicionário de Termos Militares do Exército. http://dicmil.iscap.pt

[64.] CNNMoney. s.d. Agile Software Development. http://money.cnn.com/galleries/2007/biz2/0706/gallery.50whomatter.biz2/33.html

[65.] Costa, Francisco. Janeiro de 2009. O que é, para que serve e quais as características da WEB 2.0. blog.franciscocosta.com. http://blog.franciscocosta.com/web‐20.html

[66.] Costa, Rute & Silva, Raquel. Dezembro de 2006. Metodologia para a investigação aplicada em Terminologia. http://www.clunl.edu.pt/resources/docs/grupos/lexicologia/projecto_fct/guiao_ine.pdf

[67.] Dal'Alba, Adriano . s.d. Modelo de dados. http://www.geocities.com/SiliconValley/Port/5072/Modelo.htm

[68.] DataModel.org. s. d. Rules of Data Normalization. http://www.datamodel.org/NormalizationRules.html

[69.] Di Iorio, Angela. s.d. Um modelo de dados para metadados de preservação. Digital Preservation Europe. http://www.digitalpreservationeurope.eu/publications/briefs/PORTODIIORIO.pdf.

[70.] DokuWiki. 2009. DokuWiki. http://www.dokuwiki.org/dokuwiki

[71.] Drupal. 2009. Drupal: Community Plumbing. http://drupal.org

[72.] Embrapa Informática Agropecuária & NILC – Núcleo Interinstitucional de Linguística Computacional. 2009. e‐Termos ‐ Ambiente Colaborativo Web de Gestão Terminológica. http://www.etermos.ufscar.br/index.php

[73.] Escola Superior de Tecnologia de Viseu. s. d. Técnicas de modelação de dados. http://www.estv.ipv.pt/paginaspessoais/ajas/AS/Apontamentos%20Te%C3%B3ricos/as_2_1.pdf.

[74.] Faculdade de Ciências da Universidade de Lisboa. s.d. Caracterização da Investigação‐Acção. http://www.educ.fc.ul.pt/docentes/ichagas/mi1/Anexo%20i.pdf

[75.] Ferreira, Karine Reis & Queiroz, Gilberto Ribeiro & Paiva, João Argemiro & Souza, Ricardo Cartaxo Modesto de & Câmara, Gilberto. 2002. Arquitetura de Software para Construção de Bancos de Dados Geográficos com SGBD Objeto‐Relacionais. XVII Simpósio Brasileiro de Banco de Dados. http://www.lbd.dcc.ufmg.br:8080/colecoes/sbbd/2002/004.pdf.

[76.] Flickr. s. d. Photo Sharing. http://www.flickr.com

[77.] Friedman, Eric. 2009. Price, Quality, Time – Choose Two. http://www.marketing.fm/2009/06/16/price‐quality‐time‐choose‐two/


[78.] Gonçalves, João Henrique & Rosa, José Wilson Corrêa & Abram, Maísa Bastos & Neto, Reginaldo Leão & Ramos, Maria Angélica Barreto & Jesus, José Domingos Alves de & Matos, Gerson Manoel Muniz de & Baars, Franciscus Jacobus. 2003. Estruturação de Bases de Dados e Metodologia de Integração de Dados em SIG: Data Base Structuring and Data Integration in GIS. CPRM. http://www.cprm.gov.br/publique/media/capXII.pdf.

[79.] Google Maps. 2009. Google Maps. http://maps.google.com

[80.] IATE – Inter‐Active Terminology for Europe. 2009. About IATE. http://iate.europa.eu/iatediff/about_IATE.html

[81.] IBM. s. d. DB2: IBM. DB2 software. http://www‐01.ibm.com/software/data/db2

[82.] IBM. s. d. Informix: Online Transaction Processing. http://www‐01.ibm.com/software/data/informix

[83.] IOL Portugal Diário. 2008. Portugal tem mais de 1600 postos de Internet sem fios. http://diario.iol.pt/tecnologia/internet‐sem‐fios‐postos‐publicos‐wireless‐portugal‐hotspots/971489‐4069.html

[84.] JavaScript Libraries. s. d. A directory of tools shaping the new web. http://javascriptlibraries.com

[85.] jQuery. 2009. jQuery: the write less, do more JavaScript Library. http://jquery.com

[86.] Laszlo Systems. 2008. OpenLaszlo: the premier platform for rich internet applications. http://www.openlaszlo.org

[87.] Linguateca. s. d. Corpógrafo V4. http://www.linguateca.pt/Corpografo

[88.] Lopes, Secundino Domingos Marques. 2009. EstruturaBasesDados.pdf. Index of ftp://www.global.estgp.pt/. ftp://www.global.estgp.pt/ionline/Engenharia.Informatica.9119/AnoLectivo.2008‐2009/Semestre1/Bases.De.Dados.I/Modulo2/1.1.EstruturaBasesDados.pdf

[89.] Marinho, Carlos. s. d. Modelos de Dados em Sistemas de Informação. Sapientia, Repositório Institucional da Universidade do Algarve. http://sapientia.ualg.pt/bitstream/10400.1/65/1/13_15.pdf.

[90.] Marketing.fm. 2009. Eric Friedman: Marketing.fm Author Archive. http://www.marketing.fm/author/admin

[91.] Martins, Célia Talma. 2003/2004. Modelos de Bases de Dados. Informática II. http://www.iscap.ipp.pt/~celia/Modelos%20de%20Bases%20de%20Dados.pdf

[92.] Maurer, Donna. 2006. Usability for Rich Internet Applications. http://www.digital‐web.com/articles/usability_for_rich_internet_applications

[93.] MediaWiki. s.d. MediaWiki. http://www.mediawiki.org/wiki/MediaWiki


[94.] Microsoft Corporation ASP.net. 2009. The official Microsoft ASP.net site. http://www.asp.net

[95.] Microsoft Corporation SQL Server 2008. 2009. SQL Server 2008 overview, data platform, store data. http://www.microsoft.com/sqlserver/2008/en/us/default.aspx

[96.] Microsoft Office Online. s. d. Princípios básicos da estrutura de bases de dados – Access. http://office.microsoft.com/pt‐pt/access/HA012242472070.aspx

[97.] Middleware Resource Center. 2008. What is Middleware? http://www.middleware.org/

[98.] Netcraft. March 2009. March 2009 Web Server Survey. http://news.netcraft.com/archives/2009/03/15/march_2009_web_server_survey.html

[99.] O’Reilly, Tim. 2006. Web 2.0 Compact Definition: Trying Again. http://radar.oreilly.com/2006/12/web‐20‐compact‐definition‐tryi.html

[100.] Object Mentor. s. d. Agile Processes. http://www.objectmentor.com/resources/articles/agileProcess.pdf

[101.] Odeo. s. d. Search, discover and share Digital Media from Millions of Audio and Video Clips. http://odeo.com

[102.] Oracle. s. d. Product Lifecycle Management. http://www.oracle.com/index.html

[103.] PHP Group. 2009. PHP: Hypertext Processor. http://www.php.net

[104.] Pias, Maria Filipa. s. d. Como se constrói um logótipo. http://portaldasartesgraficas.com/down/home.htm

[105.] Pires, Ivan. 2009. Universidade do Estado de Mato Grosso, no Departamento de Computação do Campus de Colíder. Bancos de Dados. http://www2.unemat.br/~ivanpires/files/dwl/bd/correcoes_artigos_bd2009.txt

[106.] PollDaddy. Create Stunning Polls and Surveys!. Automatic. http://polldaddy.com

[107.] Portugal a programar. 2008. Comparar estrutura de base de dados. http://www.portugal‐a‐programar.org/forum/index.php?topic=31956.0.

[108.] Proença, H. & Muranho, J. & Prata, P. 2005/2006. Bases de Dados I – Modelos de Dados. Universidade da Beira Interior – Engenharia Informática, Ensino da Informática, Matemática Aplicada e Matemática /Informática. http://www.di.ubi.pt/~pprata/bd/BD_05_06_T2.pdf

[109.] Público, Jornal O. 2008. Internet: pontos públicos de ligação sem fios duplicam nos últimos três anos. http://ultimahora.publico.clix.pt/noticia.aspx?id=1335337

[110.] Ramirez, Ariel Ortiz. 2000. Three‐Tier Architecture. http://www.linuxjournal.com/article/3508


[111.] Rational Software Corporation. 2003. Diretrizes: Modelo de Dados. WThreex. http://www.wthreex.com/rup/process/modguide/md_datmd.htm.

[112.] Ruby, Bryan. 2006. Drupal and Joomla comparison. http://cmsreport.com/content/2006/12/drupal‐and‐joomla‐comparison

[113.] SAPO. s.d. Entrevista Globs – SAPO Software Livre. http://softwarelivre.sapo.pt/projects/geral/wiki/EntrevistaGLOBS

[114.] SDL. 2009. SDL MultiTerm Desktop 2009. http://www.sdl.com/en/sites/sdl‐trados‐solutions/desktop‐products/sdl‐multiterm‐2009‐desktop.asp

[115.] Silva, Everton da. s.d. Estruturaçãode Base de Dados e Aspectos Organizacionais. Lincoln Institute of Land Policy. http://www.lincolninst.edu/subcenters/capacity‐building‐for‐property‐tax/news/oficina‐iii/oficina‐iii‐estruturacao‐base‐dados.pdf.

[116.] Sun Microsystems. 2009. JavaServer Pages Technology. http://java.sun.com/products/jsp

[117.] Sun Microsystems. 2009. MySQL Downloads. http://dev.mysql.com/downloads

[118.] Surveyer, Jacques. s.d. Overview ‐ Rich Internet Applications / Featuring: RIAs are designed to deliver 8A's Software Simply. http://theopensourcery.com/xmlria.htm

[119.] Sybase. s. d. Business intelligence and database management software systems including data warehousing. http://www.sybase.com

[120.] Tartir, Samir (22nd of July, 2005). Ontologies Re‐use in the Semantic Web. http://www.cs.uga.edu/~tartir/classes/8990/reuse.ppt

[121.] Universidade do Minho. 2008. Globs – Global Glossary for everybody. http://eremita.di.uminho.pt/terminologia

[122.] W3C. 2006 . RDF/OWL Representation of WordNet. http://www.w3.org/TR/wordnet‐rdf

[123.] W3C. 2009 . Cascading Style Sheets home page. http://www.w3.org/Style/CSS

[124.] W3C. 2009 . W3C Semantic Web Activity. http://www.w3.org/2001/sw

[125.] W3C. 2009 . Web Style Sheets home page. http://www.w3.org/Style

[126.] W3C. 2009 . World Wide Web Consortium. http://www.w3.org

[127.] W3schools. s. d. Browser Display Statistics. http://www.w3schools.com/browsers/browsers_display.asp

[128.] W3schools. s. d. Browser Statistics. http://www.w3schools.com/browsers/browsers_stats.asp

[129.] W3schools. s. d. HTML <meta> Tag. http://www.w3schools.com/tags/tag_meta.asp

[130.] Web Standards Project. s. d. The Web Standards Project. http://www.webstandards.org


[131.] Welterlin, Frederic. October 2006. Presentation Layer: Why web standards and accessibility matter. http://www.welterlin.com/whitepapers/PresentationLayerBestPractices.pdf

[132.] Wikipedia. s. d. Wikipedia. http://www.wikipedia.org

[133.] Wikipédia. s.d. Wikipédia, a enciclopédia livre. http://pt.wikipedia.org/wiki/P%C3%A1gina_principal

[134.] Wiktionary. s.d. Wiktionary. http://www.wiktionary.org

Capítulo VIII – Anexos | 127

8 Capítulo VIII – Anexos

128 | Capítulo VIII – Anexos


8.1 Anexo A – Questões colocadas no inquérito efectuado


8.2 Anexo B1a – Relatório geral

8.2.1 Número de respostas completas vs. número de respostas

incompletas

8.2.2 Localização geográfica dos inquiridos


8.3 Anexo B2 – Relatório de respostas à Questão n.º 1

Q.1 Seleccione a opção que corresponde à sua faixa etária.


8.4 Anexo B3 – Relatório de respostas à Questão n.º 2

Q.2 Indique o grau académico na área de tradução que...


8.5 Anexo B4 – Inquérito: Relatório de respostas à Questão n.º 3

Q.3 Quantos anos de experiência tem como...



Q.4 Em projectos de tradução, indique com que frequência trabalha em...


8.7 Anexo B6a – Inquérito: Relatório de respostas à Questão n.º 5

8.7.1 Valores Sim/Não

Q.5 Conhece alguma plataforma de criação e gestão colaborativa de terminologia na Web?

8.8 Anexo B6b – Inquérito: Relatório de respostas à Questão n.º 5

8.8.1 Outra opção: Discriminação.



Q.6 A existência de uma plataforma com esse fim é...



Q.7 Utilizaria uma plataforma de criação e gestão colaborativa de terminologia na Web para...



Q.8 Que constrangimentos pode apresentar uma plataforma de trabalho colaborativo na Web?



Q.9 Que características considera relevantes na criação e gestão de terminologia?



Q.10 Que grau de relevância atribui à possibilidade de inserção dos seguintes conteúdos multimédia numa plataforma de criação e gestão colaborativa de terminologia na Web:


8.14 Anexo C – Paleta de cores seguras para a Web


8.15 Anexo D – Índice de utilização dos vários exploradores nos

últimos anos (tabela completa)


2009

Junho 18.7% 14.9% 7.1% 47.3% 6.0% 3.1% 2.1%

Maio 21.3% 14.5% 5.2% 47.7% 5.5% 3.0% 2.2%

Abril 23.2% 15.4% 3.5% 47.1% 4.9% 3.0% 2.2%

Março 24.9% 17.0% 1.4% 46.5% 4.2% 3.1% 2.3%

Fevereiro 25.4% 17.4% 0.8% 46.4% 4.0% 3.0% 2.2%

Janeiro 25.7% 18.5% 0.6% 45.5% 3.9% 3.0% 2.3%


2008 25,33% 25,57% 1,02% 40,94% 3,2% 2,43% 1,81%

IE7 IE6 IE5 Firefox Mozilla Safari Opera

2007 18,7% 37,42% 1,87% 33,83% 1,32% 1,62% 1,63%

IE7 IE6 IE5 Firefox Mozilla N7/8 Opera

2006 2,23% 56,38% 4,52% 26,32% 2,48% 0,38% 1,52%

IE6 IE5 Firefox Mozilla N7 O8 O7

2005 65,6% 7,2% 19,65% 2,95% 0,68% 0,68% 0,82%


IE6 IE5 Mozilla N3 N7 N4 O7

2004 6,7% 13,13% 10,95% 0,45% 1,38% 0,42% 1,57%

IE6 IE5 Mozilla N3 N7 N4 O7

2003 65,25% 21,25% 5,32% 0,8% 1,42% 0,9% 1,6%

IE6 IE5 AOL N3 N5 N4 IE4

2002 42,42% 42,58% 3,63% 1,22% 3,37% 3,12% 0,73%

Legenda:

Abreviatura – Nome do explorador Web

AOL – America Online (com base no Internet Explorer e no Mozilla)

Chrome – Google Chrome

Firefox – Firefox (identificado como Mozilla antes de 2005)

IE – Internet Explorer

Mozilla – Mozilla Suite (Gecko, Netscape)

N – Netscape (identificado como Mozilla depois de 2006)

Opera / O – Opera

Safari – Safari (e Konqueror. Ambos identificados como Mozilla antes de 2007)


8.16 Anexo E – Inquérito a apresentar aos utilizadores após uma

sessão experimental da plataforma

Faculdade de Engenharia de Universidade do Porto · Faculdade de Engenharia de Universidade do...

Documents

Transcript of Faculdade de Engenharia de Universidade do Porto · Faculdade de Engenharia de Universidade do...