faculdade de engenharia de universidade do porto · faculdade de engenharia de universidade do...
TRANSCRIPT
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
ii |
| iii
À minha família, aos meus amigos e ao Jorge
iv |
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
8.6 Anexo B5 – Inquérito: Relatório de respostas à Questão n.º 4 ............................... 138
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.10 Anexo B8 – Inquérito: Relatório de respostas à Questão n.º 7 ............................... 141
8.11 Anexo B9 – Inquérito: Relatório de respostas à Questão n.º 8 ............................... 142
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
xvi |
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.
Capítulo I ‐ Introdução | 3
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.
4 | Capítulo I ‐ Introdução
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
Capítulo I ‐ Introdução | 5
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
6 | Capítulo I ‐ Introdução
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
Capítulo I ‐ Introdução | 7
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.
8 | Capítulo I ‐ Introdução
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
Capítulo I ‐ Introdução | 9
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:
10 | Capítulo I ‐ Introdução
• 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.
Capítulo I ‐ Introdução | 11
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.].
12 | Capítulo I ‐ Introdução
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
Capítulo II – Estado da arte | 15
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).
16 | Capítulo II – Estado da arte
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
Capítulo II – Estado da arte | 17
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
18 | Capítulo II – Estado da arte
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
Capítulo II – Estado da arte | 19
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
20 | Capítulo II – Estado da arte
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
Capítulo II – Estado da arte | 21
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
22 | Capítulo II – Estado da arte
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
Capítulo II – Estado da arte | 23
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:
24 | Capítulo II – Estado da arte
• 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.
Capítulo III – Metodologias de Investigação | 27
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.].
28 | Capítulo III – Metodologias de Investigação
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
Capítulo III – Metodologias de Investigação | 29
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
30 | Capítulo III – Metodologias de Investigação
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).
Capítulo III – Metodologias de Investigação | 31
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.
32 | Capítulo III – Metodologias de Investigação
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;
Capítulo III – Metodologias de Investigação | 33
• 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.
34 | Capítulo III – Metodologias de Investigação
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
Capítulo III – Metodologias de Investigação | 35
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.
36 | Capítulo III – Metodologias de Investigaçã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
Capítulo IV – Desenvolvimento e implementação da plataforma | 39
A figura 10 ilustra este princípio:
Figura 10 ‐ Interacção simples com um servidor Web
40 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 41
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.
42 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 43
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
44 | Capítulo IV – Desenvolvimento e implementação da plataforma
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:
• 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 intuitiva);
• 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.
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%
Capítulo IV – Desenvolvimento e implementação da plataforma | 45
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:
• distinção entre sublínguas, por exemplo: Português (Portugal) ou Português (Brasil);
• fácil usabilidade da plataforma (interface intuitiva);
• criação de glossários;
• possibilidade adicionar várias línguas ao mesmo glossário;
• inserção de conteúdo multimédia;
• 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;
• inserção automática da classe gramatical do termo;
46 | Capítulo IV – Desenvolvimento e implementação da plataforma
• possibilidade de contactar criadores e gestores para colocar dúvidas ou sugerir alterações;
• definição da nacionalidade dos utilizadores;
• definição de obrigatoriedade de preenchimento de um determinado campo;
• possibilidade de associação de um glossário a um determinado domínio de conhecimento;
• registo e gestão de utilizadores com vários níveis de permissão.
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:
Capítulo IV – Desenvolvimento e implementação da plataforma | 47
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;
visualizar informação pública sobre todos os utilizadores e informação privada
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;
visualizar informação pública sobre todos os utilizadores e informação privada
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:
48 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 49
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.
50 | Capítulo IV – Desenvolvimento e implementação 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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 51
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.
52 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 53
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.
54 | Capítulo IV – Desenvolvimento e implementaçã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:
Capítulo IV – Desenvolvimento e implementação da plataforma | 55
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.].
56 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 57
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
58 | Capítulo IV – Desenvolvimento e implementação da 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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 59
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
60 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 61
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
62 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Lighttpd
SunONE
Zeus
Figura 17 ‐ Índice de utilização de servidores Web
Capítulo IV – Desenvolvimento e implementação da plataforma | 63
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
64 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 65
Figura 19 ‐ Código fonte (ficheiro: checklogin.php)
Figura 18 ‐ Exemplo de código PHP embebido em código HTML (ficheiro: checklogin.php)
66 | Capítulo IV – Desenvolvimento e implementação da plataforma
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)
Capítulo IV – Desenvolvimento e implementação da plataforma | 67
• 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)
68 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 69
• 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
70 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.].
Capítulo IV – Desenvolvimento e implementação da plataforma | 71
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
72 | Capítulo IV – Desenvolvimento e implementação da plataforma
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;
Capítulo IV – Desenvolvimento e implementação da plataforma | 73
• 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:
74 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 75
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.
76 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 77
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
78 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 79
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
80 | Capítulo IV – Desenvolvimento e implementação da plataforma
(‘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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 81
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.
82 | Capítulo IV – Desenvolvimento e implementação da plataforma
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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 83
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
84 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 85
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
86 | Capítulo IV – Desenvolvimento e implementação da plataforma
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();
Capítulo IV – Desenvolvimento e implementação da plataforma | 87
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
88 | Capítulo IV – Desenvolvimento e implementação da plataforma
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>
Capítulo IV – Desenvolvimento e implementação da plataforma | 89
<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";
90 | Capítulo IV – Desenvolvimento e implementação da plataforma
$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”.
Capítulo IV – Desenvolvimento e implementação da plataforma | 91
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 ?>" />
92 | Capítulo IV – Desenvolvimento e implementação da plataforma
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)){
Capítulo IV – Desenvolvimento e implementação da plataforma | 93
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){
?>
94 | Capítulo IV – Desenvolvimento e implementação da plataforma
<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.
Capítulo IV – Desenvolvimento e implementação da plataforma | 95
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;
(…)
96 | Capítulo IV – Desenvolvimento e implementação da plataforma
//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
Capítulo IV – Desenvolvimento e implementação da plataforma | 97
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>
98 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 99
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
100 | Capítulo IV – Desenvolvimento e implementação 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
Capítulo IV – Desenvolvimento e implementação da plataforma | 101
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.]):
102 | Capítulo IV – Desenvolvimento e implementação da plataforma
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):
Capítulo IV – Desenvolvimento e implementação da plataforma | 103
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
104 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 105
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%
IE7 IE6 IE5 Firefox Chrome Safari Opera
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%
106 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo IV – Desenvolvimento e implementação da plataforma | 107
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.
108 | Capítulo IV – Desenvolvimento e implementação da plataforma
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
Capítulo V – Perspectivas de trabalho futuro | 111
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.
112 | Capítulo V – Perspectivas de trabalho futuro
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
Capítulo V – Perspectivas de trabalho futuro | 113
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.
114 | Capítulo V – Perspectivas de trabalho 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.
Capítulo VII – Bibliografia | 119
[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.ª.
120 | Capítulo VII – Bibliografia
[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.
Capítulo VII – Bibliografia | 121
[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/
122 | Capítulo VII – Bibliografia
[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
Capítulo VII – Bibliografia | 123
[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
124 | Capítulo VII – Bibliografia
[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
Capítulo VII – Bibliografia | 125
[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
126 | Capítulo VII – Bibliografia
Capítulo VIII – Anexos | 127
8 Capítulo VIII – Anexos
128 | Capítulo VIII – Anexos
Capítulo VIII – Anexos | 129
8.1 Anexo A – Questões colocadas no inquérito efectuado
130 | Capítulo VIII – Anexos
Capítulo VIII – Anexos | 131
132 | Capítulo VIII – Anexos
Capítulo VIII – Anexos | 133
134 | Capítulo VIII – Anexos
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
Capítulo VIII – Anexos | 135
8.3 Anexo B2 – Relatório de respostas à Questão n.º 1
Q.1 Seleccione a opção que corresponde à sua faixa etária.
136 | Capítulo VIII – Anexos
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...
Capítulo VIII – Anexos | 137
8.5 Anexo B4 – Inquérito: Relatório de respostas à Questão n.º 3
Q.3 Quantos anos de experiência tem como...
138 | Capítulo VIII – Anexos
8.6 Anexo B5 – Inquérito: Relatório de respostas à Questão n.º 4
Q.4 Em projectos de tradução, indique com que frequência trabalha em...
Capítulo VIII – Anexos | 139
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.
140 | Capítulo VIII – Anexos
8.9 Anexo B7 – Inquérito: Relatório de respostas à Questão n.º 6
Q.6 A existência de uma plataforma com esse fim é...
Capítulo VIII – Anexos | 141
8.10 Anexo B8 – Inquérito: Relatório de respostas à Questão n.º 7
Q.7 Utilizaria uma plataforma de criação e gestão colaborativa de terminologia na Web para...
142 | Capítulo VIII – Anexos
8.11 Anexo B9 – Inquérito: Relatório de respostas à Questão n.º 8
Q.8 Que constrangimentos pode apresentar uma plataforma de trabalho colaborativo na Web?
Capítulo VIII – Anexos | 143
8.12 Anexo B10 – Inquérito: Relatório de respostas à Questão n.º 9
Q.9 Que características considera relevantes na criação e gestão de terminologia?
144 | Capítulo VIII – Anexos
8.13 Anexo B11 – Inquérito: Relatório de respostas à Questão n.º 10
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:
Capítulo VIII – Anexos | 145
8.14 Anexo C – Paleta de cores seguras para a Web
146 | Capítulo VIII – Anexos
8.15 Anexo D – Índice de utilização dos vários exploradores nos
últimos anos (tabela completa)
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%
IE7 IE6 IE5 Firefox Chrome Safari Opera
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%
Capítulo VIII – Anexos | 147
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)
148 | Capítulo VIII – Anexos
8.16 Anexo E – Inquérito a apresentar aos utilizadores após uma
sessão experimental da plataforma
Capítulo VIII – Anexos | 149
150 | Capítulo VIII – Anexos
Capítulo VIII – Anexos | 151
152 | Capítulo VIII – Anexos