Embed Size (px)
Citation preview
Intelligent e-Job Marketplace
Nuno Filipe Grilo Nobre Marques
Dissertação para obtenção do Grau de Mestre em
Engenharia Electrotécnica e Computadores
Júri
Presidente: Professor Nuno Cavaco Gomes Horta
Orientador: Professor João Paulo Baptista de Carvalho
Vogal: Professor Luís Manuel Antunes Veiga
Outubro de 2010
AGRADECIMENTOS
O presente estudo não poderia ter sido concretizado sem o contributo e auxílio de diversas pessoas a
quem presto os meus agradecimentos
Gostaria em primeiro lugar de agradecer ao orientador, Professor João Paulo Carvalho por toda a
disponibilidade com que sempre me presenteou, auxiliando-me na definição das linhas de desenvolvimento
e na organização do estudo ora apresentado, bem como por todo o apoio prestado na concretização do
presente trabalho.
Os meus mais sinceros agradecimentos.
Em segundo lugar gostaria de agradecer à minha namorada Rita, porque sempre acreditou em mim
e me proporcionou todo o apoio que necessitava sem excepção, sobretudo para a realização do presente
trabalho, bem como minha à minha mãe Maria Benedita que foi incansável no seu apoio, fazendo o possível
e o impossível para que eu beneficiasse de uma disponibilidade permanente para a concretização do
presente estudo.
Gostaria de agradecer ainda à minha irmã Margarida, sempre disponível para o que foi necessário,
bem como ao meu irmão João que auxiliou em tudo o que precisei no decurso do desenvolvimento este
trabalho.
Não poderia deixar de apresentar um profundo agradecimento ao Eng. Rui Alexandre por me ter
concedido a oportunidade de estágio e posteriormente integrado nos quadros da empresa, por toda a
disponibilidade, oportunidade e confiança em mim depositadas.
Um agradecimento ao Eng. Luís Reis por me ter integrado na sua equipe de trabalho, bem como
por me ter proporcionado flexibilidade de horário sempre que necessário.
Aos colegas, amigos e familiares que, embora não tenham contribuído directamente para o trabalho,
estimularam a sua realização com incentivos e compreensão. Para eles o meu Muito Obrigado.
ii
RESUMO
O presente trabalho tem como objectivo o desenvolvimento de um protótipo de um site de emprego
que utilize computação inteligente de modo a permitir obter uma ordem de classificação de perfis e ofertas
relativamente a um modelo de perfil ou oferta definido.
O trabalho inicia-se com uma análise do estado da arte existente, seguido do conteúdo teórico no
qual é baseado. Em seguida, procede-se a uma análise da arquitectura que permite garantir a tolerância a
falhas e a escalabilidade do protótipo desenvolvido. E depois detalhado qual o modelo de dados que
persiste toda a informação, quer a introduzida pelos utilizadores, quer a necessária ao funcionamento do
protótipo.
São apresentadas as várias funcionalidades implementadas, por forma a que candidatos possam
gerir os seus perfis e visualizar ofertas e que empregadores possam gerir as suas ofertas e visualizar perfis
de candidatos.
Por fim é detalhado o algoritmo desenvolvido e são apresentados resultados que confirmam a sua
validade. O algoritmo utiliza a maior parte da informação introduzida pelos utilizadores, de modo a
estabelecer um critério de semelhança entre um determinado perfil de candidato modelo ou oferta de
empregador modelo relativamente aos existentes, apresentando uma lista ordenada contendo aqueles que
mais se aproximam do modelo desejado e o grau de aproximação.
Este protótipo pretende ser o ponto de partida de um projecto ao qual, acrescentadas algumas
funcionalidades adicionais, poderá ser utilizado como site de emprego em produção.
PALAVAS-CHAVE
emprego, site, classificação, candidato, empregador
iii
ABSTRACT
The purpose of this work concerns the development of a prototype of a job web site that relies on
intelligent computing to obtain the matching degree of candidate profiles and job offers compared to a model.
The explanation starts with the state of the art analysis on the area followed by its theoretical basis.
Then, the architectural structure of the application is analyzed to ensure that the prototype is fault tolerant
and scalable. After this, we detail the data model that supports all of the data inserted by the users and the
required for the prototype to work properly.
We follow on to detail all of the implemented features, allowing candidates to manage their profiles
and view offers, and employers to manage their job offers and view candidate profiles.
By the end of the document, we explain the developed algorithm and obtain some processed results
to assure its correctness. The developed algorithm uses almost all information provided by the site users to
establish a resemblance criteria between the candidate model profile and existing ones, or company model
offer and existing offers, allowing users to see an ordered list featuring the nearest, as well as their degree of
resemblance.
The prototype intends to be the first step to a more complex web site that can be used in real life,
requiring some other, yet undeveloped, features to be added.
KEY WORDS
job, site, matching, candidate, employer
iv
ÍNDICEAgradecimentos........................................................................................................................................... ii
Resumo ...................................................................................................................................................... iii
Abstract ...................................................................................................................................................... iv
Lista de Figuras......................................................................................................................................... viii
Lista de Tabelas.......................................................................................................................................... ix
Lista de Palavras não traduzidas................................................................................................................ xi
Lista de Acrónimos.................................................................................................................................... xiii
1 - Introdução.............................................................................................................................................. 1
1.1 - Motivação....................................................................................................................................... 1
1.2 - Objectivos...................................................................................................................................... 1
2 - Breve Abordagem sobre sites existentes...............................................................................................3
3 - Conteúdo Teórico................................................................................................................................. 10
3.1 - Django.......................................................................................................................................... 10
3.1.1 - Introdução ao Django...........................................................................................................10
3.1.2 - Estrutura de um Projecto Django.........................................................................................12
3.1.3 - Linguagem de Programação Python....................................................................................17
3.2 - Desenvolvimento orientado por testes.........................................................................................18
3.2.1 - Descrição e objectivos.........................................................................................................18
3.2.2 - Programação em TDD.........................................................................................................18
3.2.3 - TDD comparado ao Método Tradicional...............................................................................19
3.2.4 - Processo de codificação de testes.......................................................................................20
3.2.5 - Testes como documentação.................................................................................................21
3.2.6 - Testes no Django.................................................................................................................. 21
3.3 - Interacção Cliente – Servidor.......................................................................................................21
3.3.1 - Request - Response.............................................................................................................21
3.3.2 - O protocolo HTTP................................................................................................................22
3.3.3 - O protocolo HTTPS..............................................................................................................25
3.3.4 - REST – Representational State Transfer.............................................................................26
3.3.4.1 - Restrições da arquitectura REST.................................................................................26
3.3.4.2 - Elementos da arquitectura REST.................................................................................27
3.3.4.3 - A interface REST aplicada ao protocolo HTTP.............................................................29
3.3.4.4 - Vantagens do uso de uma interface REST..................................................................30
3.3.5 - Interpretação da Resposta...................................................................................................30
3.3.5.1 - Browser........................................................................................................................ 30
3.3.5.2 - HTML - HyperText Markup Language..........................................................................31
3.3.5.3 - CSS – Cascade Style Sheet........................................................................................31
3.3.5.4 - JavaScript.................................................................................................................... 32
3.3.5.5 - JQuery..........................................................................................................................32
v
3.3.5.6 - Formulários..................................................................................................................33
3.3.6 - Linguagem de Templating...................................................................................................34
3.3.6.1 - Geração de páginas dinâmicas....................................................................................34
3.3.6.2 - Vantagens do uso de Templating.................................................................................34
3.3.6.3 - Sistema de Templating do Django................................................................................35
3.3.6.4 - Funcionalidades...........................................................................................................35
3.3.6.5 - O Sistema de Herança.................................................................................................36
3.3.6.6 - Notas sobre o uso de templating..................................................................................36
3.4 - Acesso ao SGBD..........................................................................................................................37
3.4.1 - Definição de SGBD..............................................................................................................37
3.4.2 - Modelos de Dados...............................................................................................................37
3.4.3 - Linguagem de Base de Dados Relacional...........................................................................40
3.4.4 - Django – camada de acesso ao SGBD................................................................................40
3.4.5 - Escolha de SGBD................................................................................................................41
4 - Trabalho Desenvolvido.........................................................................................................................42
4.1 - Infra-estrutura............................................................................................................................... 42
4.1.1 - Arquitectura.......................................................................................................................... 42
4.1.2 - Servidor HTTP..................................................................................................................... 44
4.1.3 - Servidor Aplicacional............................................................................................................44
4.1.4 - SGBD................................................................................................................................... 45
4.1.5 - Memcached.......................................................................................................................... 45
4.1.6 - Sistema Operativo................................................................................................................46
4.2 - A Aplicação................................................................................................................................... 46
4.2.1 - Entidades e Relações..........................................................................................................46
4.2.2 - Descrição dos Recursos da Aplicação.................................................................................48
4.2.3 - Registo de utilizadores.........................................................................................................52
4.2.4 - Sessões e Autenticação.......................................................................................................53
4.2.5 - Estrutura dos Documentos HTML Gerados..........................................................................54
4.2.6 - Logging................................................................................................................................ 54
4.2.7 - Internacionalização..............................................................................................................55
4.2.8 - Modelo de Dados Desenvolvido...........................................................................................55
4.2.9 - Visibilidade dos atributos......................................................................................................57
4.2.10 - Opções de campos dependentes de escolhas...................................................................58
4.2.11 - Validação dos Atributos introduzidos..................................................................................59
4.3 - Estrutura de Directorias e ficheiros..............................................................................................60
4.4 - Algoritmo de Classificação de Perfis e Ofertas............................................................................62
4.4.1 - Conceito de Agregação........................................................................................................62
4.4.2 - Critério de Medida................................................................................................................63
4.4.3 - Comparação entre os Critérios de Medida...........................................................................65
4.4.4 - Pesquisas............................................................................................................................. 68
vi
4.4.5 - Implementação da Operação de Agregação........................................................................69
4.4.6 - Testes Efectuados e Resultados..........................................................................................70
5 - Conclusão............................................................................................................................................ 75
Bibliografia................................................................................................................................................. 80
Anexo A – Operações básicas sobre o SGBD...........................................................................................83
Anexo B – Métodos para obtenção de semelhanças................................................................................84
Anexo C – Modelo Relacional de Dados (Entidades)................................................................................88
Anexo D – Modelo Relacional de Dados (Relações).................................................................................98
vii
LISTA DE FIGURAS
Figura 1: Página inicial www.netemprego.gov.pt.........................................................................................3
Figura 2: Página inicial www.net-empregos.com.........................................................................................4
Figura 3: Página inicial www.empregos.org.................................................................................................5
Figura 4: Página inicial aeiou.expressoemprego.pt.....................................................................................6
Figura 5: Página inicial www.stepstone.pt...................................................................................................6
Figura 6: Página inicial www.infoemprego.pt...............................................................................................7
Figura 7: Página inicial www.monster.com..................................................................................................8
Figura 8: Página inicial www.totaljobs.com..................................................................................................9
Figura 9: Página inicial www.eurojobs.com.................................................................................................9
Figura 10: Etapas do processo TDD.........................................................................................................19
Figura 11: Arquitectura Cliente-Servidor....................................................................................................22
Figura 12: Componentes REST e interacções..........................................................................................28
Figura 13: Arquitectura de produção da aplicação....................................................................................43
Figura 14: Modelo Relacional de Dados parcial........................................................................................56
viii
LISTA DE TABELAS
Tabela 1: Exemplo de User.......................................................................................................................10
Tabela 2: Comparação de resultados obtidos com alguns critérios de medida.........................................67
Tabela 3: Perfis Modelo usados em testes................................................................................................71
Tabela 4: Ofertas Modelo usadas em testes.............................................................................................71
Tabela 5: Perfis usados em testes.............................................................................................................72
Tabela 6: Ofertas usadas em testes..........................................................................................................72
Tabela 7: Semelhança de Graus Académicos...........................................................................................73
Tabela 8: Semelhança de Universidades..................................................................................................73
Tabela 9: Semelhança de Cursos Superiores...........................................................................................73
Tabela 10: Semelhança de Áreas Profissionais........................................................................................73
Tabela 11: Semelhança de Empregos.......................................................................................................73
Tabela 12: Resultados da pesquisa pelo Algoritmo de Classificação (Perfis)............................................73
Tabela 13: Resultados da pesquisa pelo Algoritmo de Classificação (Ofertas).........................................73
Tabela 14: Entidade User..........................................................................................................................88
Tabela 15: Entidade Candidate................................................................................................................. 88
Tabela 16: Entidade CandidateBookmarkedOffer......................................................................................88
Tabela 17: Entidade Company..................................................................................................................89
Tabela 18: Entidade AuthenticationTicket..................................................................................................89
Tabela 19: Entidade CandidateAreaMainTechnology................................................................................89
Tabela 20: Entidade CandidateProfile.......................................................................................................90
Tabela 21: Entidade CandidateAppliedOffer..............................................................................................90
Tabela 22: Entidade CompanyOffer...........................................................................................................91
Tabela 23: Entidade Country.....................................................................................................................91
Tabela 24: Entidade CandidateAreaMainFunction....................................................................................92
Tabela 25: Entidade CandidateProfessionalCourse..................................................................................92
Tabela 26: Entidade CandidateOldJob......................................................................................................92
Tabela 27: Entidade CompanyBookmarkedProfile....................................................................................92
Tabela 28: Entidade City............................................................................................................................ 92
Tabela 29: Entidade CandidateModelOffer................................................................................................94
Tabela 30: Entidade CompanyAppliedProfile............................................................................................94
Tabela 31: Entidade University..................................................................................................................94
Tabela 32: Entidade JobSimilarity..............................................................................................................94
Tabela 33: Entidade CompanyModelProfile...............................................................................................96
Tabela 34: Entidade UniversityCourse.......................................................................................................96
Tabela 35: Entidade AcademicDegree.......................................................................................................96
Tabela 36: Entidade JobArea....................................................................................................................97
Tabela 37: Entidade Job............................................................................................................................ 97
Tabela 38: Entidade UniversitySimilarity....................................................................................................97
ix
Tabela 39: Entidade UniversityCourseSimilarity........................................................................................97
Tabela 40: Entidade AcademicDegreeSimilarity........................................................................................97
Tabela 41: Entidade JobAreaSimilarity......................................................................................................97
x
LISTA DE PALAVRAS NÃO TRADUZIDAS
backoffice
branding
browser
bugs
built-in
cache
checkbox
code-on-demand
company
cookie
create
data-mining
delete
design
dictionary
digest
firewall
fixtures
framework
gateway
host-to-host
hypermedia
interface
ip
java
lazy
load-balancing
log
logging
mailbox
manager
markup
metadata
middleware
network
newsletter
open-source
overhead
xi
password
provider
proxy
python
query
rails
read
reporting
representation
request
resource
resource identifier
response
release
round-trip
ruby
script
site
snooping
software
stateless
store
template tag
templates
templating
transaction
update
user
user-agent
user-friendly
user-interface
web
widgets
loose-coupled
xii
LISTA DE ACRÓNIMOS
API – Application Programming Interface
ASP.NET – Active Server Pages
CA – Certificate Authority
CRUD – Create, Read, Update, Delete
DAO – Data Access Object
DDL – Data Definition Language
DML – Data Manipulation Language
DNS – Domain Name System
DRY – Don't Repeat Yourself
DTD – Document Type Definition
DTO – Data Tranfer Object
ERB – Embedded Ruby
HTML – Hyper Text Markup Language
HTTP – Hyper Text Transfer Protocol
HTTPS – Hyper Text Transfer Protocol Secure
IETF – Internet Engineering Task Force
IP – Internet Protocol
JSON – JavaScript Object Notation
JSP – Java Server Pages
MIME – Multipurpose Internet Mail Extensions
MVC – Model, View, Controller
ORB – Object Request Broker
OSI – Open Systems Interconnection
PKI – Public Key Infrastructure
REST – Representational State Transfer
RFC – Request For Comments
S-HTTP – Secure HTTP
SOCKS – Sock-Et-S
SGBD – Sistema de Gestão de Base de Dados
SSL – Secure Socket Layer
SQL – Structured Query Language
TDD – Test Driven Development
TFD – Test First Design
TCP – Transmission Control Protocol
TLS – Transport Layer Security
UDP – User Datagram Protocol
URI – Uniform Resource Identifier
URL – Uniform Resource Locator
xiii
WAIS – Wide Area Information Server
XML – eXtensible Markup Language
XP – Extreme Programming
YAML – YAML Ain't Markup Language ou Yet Another Markup Language
xiv
1 - INTRODUÇÃO
1.1 - MOTIVAÇÃO
Actualmente, o recrutamento de pessoas com características profissionais específicas é
objecto de cada vez maior atenção por parte das empresas. É usual existirem nas empresas de uma
certa dimensão departamentos especializados na gestão dos seus recursos humanos, de modo a
agilizarem a prospecção e contratação de novas pessoas para a ocupação de todo o tipo de tarefas
necessárias ao funcionamento da empresa.
A massificação da utilização da internet possibilitou um aumento na rapidez de acesso à
informação de uma forma geral, com um grande impacto nos processos de recrutamento, dado que
passaram a utilizar essa maior quantidade de informação disponível, quer ao nível da informação
disponibilizada pelos empregadores, quer ao nível da informação disponibilizada pelos candidatos.
Assim, surgiram aplicações designadas por sites de emprego que permitem centralizar essa
informação, de modo a disponibilizá-la, quer aos candidatos, quer aos empregadores, usando a
internet como canal preferencial dada a sua facilidade de acesso e ao uso de ferramentas comuns
para as trocas de informação, nomeadamente a utilização da linguagem HTML e a sua interpretação
através de aplicações desenvolvidas para o efeito – browsers.
À medida que os sites de emprego foram sendo desenvolvidos, foi sendo disponibilizado aos
utilizadores cada vez maior detalhe na informação e cada vez mais funcionalidades.
Porém, não só os sites de emprego mas os sites de uma maneira geral permitem apenas
critérios de pesquisa muito básicos, o que implica muito trabalho dos utilizadores, sejam eles
candidatos ou empregadores, na análise dos resultados apresentados. No caso de um empregador
precisar de contratar um empregado para uma determinada função, por exemplo um advogado, é
provável que num determinado site de emprego, o conjunto de resultados possíveis seja de algumas
centenas, tornando o processo de recrutamento, ou num processo moroso e incomportável de
visualização individual de cada um dos resultados, ou aleatório, não estando bem definido o critério
pelo qual foi escolhido um sub-conjunto dos resultados da pesquisa para o prosseguimento do
processo.
1.2 - OBJECTIVOS
Com o presente trabalho pretende-se desenvolver uma aplicação que disponibilize as
funcionalidades habitualmente encontradas noutros sites de emprego, mas que integre uma nova
forma de pesquisa que permita aos utilizadores basearem as suas pesquisas não apenas em critérios
específicos, como por exemplo a lista de todos os candidatos de uma profissão, mas em critérios
mais abstractos que permitam uma melhor tomada de decisão sobre os resultados a apresentar,
como por exemplo a ordenação de perfis de candidatos que melhor correspondem a um determinado
1
perfil modelo definido pelo empregador.
Para esse efeito será necessário iniciar este trabalho por uma breve análise às
funcionalidades disponibilizadas neste momento por outros sites de emprego. De seguida escolher
ferramentas e metodologias que possibilitem o desenvolvimento da aplicação de uma forma rápida e
eficaz, permitindo a prevenção de erros e a fácil alteração de funcionalidades, bem como a não
repetição do código desenvolvido, por forma a reduzir o tempo de desenvolvimento e a aumentar
centralização de lógica da aplicação.
É necessário também abordar os protocolos de transmissão de dados actualmente utilizados
para este tipo de aplicações, bem como o modo como esses dados são recebidos pelo browser e
apresentados ao utilizador.
Uma vez que a aplicação irá disponibilizar determinada informação de utilizadores para outros
utilizadores, é necessário que os dados sejam persistidos de forma correcta e coerente e que o seu
acesso seja rápido, de modo a que a aplicação seja rápida na apresentação de dados aos
utilizadores. É apresentado o mecanismo disponibilizado pela ferramenta utilizada para a
implementação da lógica de funcionamento da aplicação, por forma a minimizar a repetição do código
da aplicação, permitindo a sua reutilização, sobretudo na geração da linguagem de comunicação
entre o browser e a aplicação.
É discutido o modo de persistência dos dados e a forma de garantir a sua coerência. Dado
que o site vai potencialmente ser acedido por muitos utilizadores, é necessário que exista uma
infraestrutura para garantir robustez e rapidez de execução da aplicação desenvolvida, passando
para as funcionalidades disponibilizadas aos utilizadores, assim como o seu registo como utilizadores
e a sua autenticação e autorização.
Pretende-se ainda que a aplicação seja facilmente transposta para outras linguagens de
modo a poder ser utilizada em vários países e que essa adaptação seja simples de realizar. Como já
foi referido, a aplicação irá potencialmente ser acedida por muitos utilizadores, o que pode levar à
introdução de dados não válidos ou não relevantes. Assim, é necessário que todas as introduções de
dados dos utilizadores sejam correctamente validadas. É natural também que os utilizadores não
queiram disponibilizar toda a informação introduzida de uma forma totalmente aberta. Por isso deve
ser o utilizador a escolher que informação estará visível para outros, podendo ao longo do tempo
modificar as suas preferências.
Finalmente, é necessário que as pesquisas possam funcionar de uma forma eficaz, usando o
máximo de informação possível, quer através da pesquisa por escolha de critérios, quer através da
definição de modelos de perfis (por parte dos empregadores) e de ofertas (por parte dos candidatos),
por forma a permitir que sejam encontrados de entre os perfis e ofertas introduzidos pelos candidatos
e empregadores, aqueles que mais se assemelham aos modelos definidos, por forma a que estes
sejam apresentados por ordem de semelhança.
Os assuntos acima referidos irão ser alvos de abordagem e justificação detalhada ao longo
dos próximos capítulos.
2
2 - BREVE ABORDAGEM SOBRE SITES EXISTENTES
Com o intuito de obter uma noção do estado da arte no que diz respeito a sites de emprego
existentes, foram consultados alguns dos sites de maior utilização, quer nacionais, quer estrangeiros.
Durante a pesquisa, foi constatado que existem uma série de características comuns a todos
os sites de emprego e outras características apenas apresentadas por um ou alguns. Entre as
características comuns contam-se a introdução de currículos, que designaremos futuramente por
perfis, por parte dos candidatos, bem como a introdução de ofertas de emprego por parte dos
empregadores.
Apresentaremos de seguida as principais características de alguns dos sites de emprego
visitados, quer nacionais, quer internacionais, sendo estes dos mais utilizados por empregadores e
candidatos.
www.netemprego.gov.pt
O site www.netemprego.gov.pt é um site lançado e apoiado pelo IEFP – Instituto de Emprego
e Formação Profissional. Na área de candidatos, é possível a introdução de perfil, a consulta de
ofertas de emprego nacionais, a consulta de ofertas de emprego no espaço económico europeu, a
consulta de concursos de acesso à administração pública, a gestão do perfil e a gestão de uma pasta
pessoal de ofertas de emprego. As pesquisas possíveis por candidato são a pesquisa simples e a
pesquisa avançada. Na pesquisa simples, o candidato pode efectuar pesquisas de ofertas através de
alguns critérios, nomeadamente ofertas inseridas no próprio dia, ofertas inseridas durante a semana,
por área profissional, por emprego, região e concelho. Na pesquisa avançada, além dos critérios
anteriormente enunciados, são acrescentadas as pesquisas por habilitações literárias, tipo de
3
Figura 1: Página inicial www.netemprego.gov.pt
contrato, idioma, regime de trabalho e número de oferta.
Na área de empregadores, as funcionalidades são a pesquisa de perfis, a gestão das ofertas
inseridas e a gestão de uma pasta pessoal de perfis. Existem também nesta área dois tipos de
pesquisa. Na pesquisa simples, o empregador pode efectuar pesquisas de perfis inseridos no próprio
dia ou durante a semana, por área profissional, por profissão, por região e por concelho. A pesquisa
avançada permite a utilização dos critérios da pesquisa simples, assim como a pesquisa por
habilitações literárias, idiomas e número de perfil.
É ainda possível efectuar a pesquisa por centros de emprego existentes no país.
www.net-empregos.com
O site www.net-empregos.com é um dos sites mais usados no mercado de emprego em
Portugal. As funcionalidades disponíveis para o candidato são a introdução de perfil de candidato, a
pesquisa de ofertas, gestão de pasta de ofertas favoritas, agentes automáticos para envio de email na
introdução de uma oferta de uma determinada categoria profissional pelo empregador, caixa de
correio, sistema de mensagens e visualização de estatísticas.
Os empregadores têm à sua disposição a introdução de ofertas, a pesquisa de perfis, a
gestão de uma pasta de perfis favoritos, agentes automáticos para envio de email na introdução de
um perfil de uma determinada categoria profissional pelo candidato, caixa de correio, sistema de
mensagens, visualização de estatísticas e a introdução de uma página de apresentação da empresa.
As pesquisas, quer para candidatos, quer para empregadores poderão ser efectuadas por
categoria profissional – pesquisa simples – assim como por zona geográfica, área profissional e
palavra chave – pesquisa avançada.
4
Figura 2: Página inicial www.net-empregos.com
www.empregos.org
O site www.empregos.org é um site bastante simples na sua construção embora possua
totais de candidatos, empregadores, perfis e ofertas da ordem das dezenas de milhares. As
funcionalidades principais são a introdução de perfis e ofertas, bem como pesquisas, quer para
candidatos, quer para empregadores por palavra-chave, área profissional, localização e nível de
experiência.
aeiou.expressoemprego.pt
O site aeiou.expressoemprego.pt é um dos mais visitados em Portugal para a procura de
emprego. Embora seja bastante limitado nas funcionalidades apresenta como vantagem o facto de
estar ligado a um dos semanários de maior tiragem que contém um caderno exclusivo dedicado ao
tema emprego. É possível o registo para candidatos e empregadores bem como a subscrição de uma
newsletter. As pesquisas poderão ser efectuadas utilizando os seguintes critérios: emprego,
referência, formação, empresa, artigo, ofertas mais visitadas, ofertas menos visitadas e ofertas a
expirar. Possui ainda a pesquisa avançada que inclui os critérios entidade, localização, função e
5
Figura 3: Página inicial www.empregos.org
sector.
www.stepstone.pt
O site www.stepstone.pt é um site derivado do site principal internacional www.stepstone.com,
partilhando algumas das suas funcionalidades. Tem uma apresentação simples e apresenta apenas a
possibilidade de pesquisa de ofertas, podendo empregadores e candidatos efectuar o seu registo. Os
critérios de pesquisa são: categoria, localização, área profissional, estatuto, sector, palavras-chave,
empresa e últimas ofertas.
Possui ainda a possibilidade de visualização de apresentações de empresas, ofertas para
primeiro emprego e ofertas para executivos de vários sectores de actividade.
6
Figura 4: Página inicial aeiou.expressoemprego.pt
Figura 5: Página inicial www.stepstone.pt
www.infoemprego.pt
O site www.infoemprego.pt é também um dos mais comummente utilizados em Portugal,
embora seja bastante reduzido em termos de funcionalidades. É possível o registo para candidatos e
empregadores assim como a criação de alertas para envio de email se for introduzido um perfil ou
uma oferta que sejam da área profissional pretendida. As pesquisas são por emprego e área
profissional para as pesquisas simples e por área profissional, distrito, salário, tipo de contrato,
experiência, período, data de publicação e palavras chave para as pesquisas avançadas.
www.monster.com
O site www.monster.com é um dos sites de emprego internacionais mais utilizados em todo o
mundo e dos mais completos em termos de funcionalidades apresentadas. As funcionalidades mais
relevantes são a inserção de perfis e ofertas, o envio de newsletters, a existência de gestão de pasta
pessoal de perfis e ofertas, o aviso de oportunidade de emprego por email, a introdução de antigos
empregos assim como um conjunto de ajudas como por exemplo cursos superiores aconselhados e
templates de escrita de perfis.
As pesquisas são bastante completas ao nível dos critérios apresentados. A pesquisa simples
inclui pesquisa por emprego, palavra-chave e localização. A pesquisa avançada permite ainda a
7
Figura 6: Página inicial www.infoemprego.pt
utilização dos critérios experiência, empresa, área profissional, distância, categoria, grau académico,
tipo de emprego e data da oferta.
As empresas poderão fazer a gestão de perfis de candidatos e efectuar pesquisas por
emprego, experiência, localização, distância e palavra-chave.
A destacar o facto de existir uma aplicação para a utilização em telemóveis.
www.totaljobs.com
O site www.totaljobs.com é um site de emprego do Reino Unido apresentando
funcionalidades bastante interessantes. As principais são o registo de empregadores e candidatos, o
envio de email a candidatos e empregadores se alguma oferta ou perfil são inseridos cumprindo
alguns critérios como área profissional (jobs by email). Tem também à disposição templates de perfis
e ofertas. As pesquisas poderão ser simples ou avançadas.
A pesquisa simples de perfis inclui salário, sector, tipo, categoria, localização e palavras-
chave e a avançada inclui ainda o actual emprego do candidato e o emprego desejado. Para
candidatos, a pesquisa simples de ofertas inclui palavras-chave, localização e distância, enquanto
que a avançada inclui ainda salário, sector de actividade, tipo de emprego, referência e palavras-
chave a excluir da pesquisa.
Outras funcionalidades adicionais são o nível do perfil uma zona para licenciados, uma zona
de aconselhamento em entrevistas e uma zona de vídeos.
8
Figura 7: Página inicial www.monster.com
www.eurojobs.com
O site www.eurojobs.com é um dos sites de emprego mais utilizados a nível europeu. As suas
funcionalidades mais interessantes são o registo de candidato e empregador, a possibilidade de
visualização de carta de apresentação, a submissão de candidaturas, o contacto por email e a
introdução de fotografia e currículo. As pesquisas podem ser efectuadas por emprego, data, sector,
país e actividade.
Como conclusão, podemos referir que não foi encontrado nenhum site que dispusesse das
características que motivaram o desenvolvimento deste trabalho. Alguns dos sites consultados
possuem funcionalidades interessantes, mas aquém do objectivo pretendido com o resultado final do
protótipo a desenvolver, especialmente no que respeita às pesquisas de perfis e ofertas.
9
Figura 8: Página inicial www.totaljobs.com
Figura 9: Página inicial www.eurojobs.com
3 - CONTEÚDO TEÓRICO
3.1 - DJANGO
Este capítulo tem como objectivo introduzir a framework sobre a qual foi desenvolvido o
protótipo, apresentando as suas principais potencialidades, detalhando os seus vários componentes e
a forma como um projecto em Django deve ser estruturado. É também analisada a linguagem de
programação Python utilizada.
3.1.1 - INTRODUÇÃO AO DJANGO
O Django é uma framework escrita inteiramente em Python, destinada ao desenvolvimento de
aplicações web que têm por base um Sistema de Gestão de Base de Dados (SGBD).
Esta framework foi estruturada de modo a permitir que a codificação da aplicação siga um
princípio fundamental: o DRY (Don't Repeat Yourself) [35] cap. 2, ou seja o princípio da não repetição
de código. A framework baseia-se no padrão de arquitectura de software MVC [53] cap. 2, consistindo
na separação das várias camadas da aplicação. O 'M' corresponde ao Modelo, o 'V' à Vista e o 'C' ao
Controlador.
MODELO
O Modelo permite obter uma representação de dados de uma tabela na Base de Dados,
embora não seja somente um DTO. Os DTOs são objectos que mapeiam dados persistidos e
permitem algumas operações simples, como por exemplo a representação em String do objecto, sem
expor os detalhes da persistência. Consideremos o seguinte exemplo de uma tabela num SGBD:
Userpk id int(11)
username varchar(30)
name varchar(100)
Tabela 1: Exemplo de User
Para a Tabela “User”, o Modelo correspondente seria um objecto que iria conter os três
campos correspondentes às colunas da Tabela, assim como a lógica de persistência e a lógica de
relação com outros Modelos.
Particularizando a definição de Modelos em Django, tomemos o seguinte exemplo onde são
definidas a classe “Reporter” e a classe “Article”:
10
class Reporter(models.Model):
full_name = models.CharField(max_length=70)
def __unicode__(self):
return self.full_name
class Article(models.Model):
pub_date = models.DateTimeField()
headline = models.CharField(max_length=200)
content = models.TextField()
reporter = models.ForeignKey(Reporter)
def __unicode__(self):
return self.headline
No exemplo apresentado, são definidos dois Modelos em Django. De salientar o facto de
ambos serem extensões da classe abstracta “models.Model”.
Os atributos correspondentes às colunas das Tabelas do SGBD são os atributos das
instâncias e correspondem a tipos de dados coerentes com as colunas das Tabelas. A lógica de
relação entre as Tabelas é também descrita no Modelo: neste caso “um para muitos” (capítulo 3.4.2).
A lógica de persistência é definida na classe abstracta “models.Model”, a qual é herdada.
A lógica de persistência consiste no acesso e manipulação de dados num SGBD pela
aplicação. O Django disponibiliza uma API criada em run-time para o acesso e manipulação dos
dados, exclusivamente através das definições de Modelos acima exemplificados, assunto que será
detalhado mais à frente.
VISTA
A Vista consiste na camada destinada à manipulação da apresentação, e contém elementos
informativos e de tomada de decisão, ou seja a user-interface. A Vista, numa aplicação web, consiste
na grande maioria das situações, na geração dinâmica de um documento de HTML, baseado em
dados de um Modelo parcial, total ou em vários Modelos. Tomando os exemplos acima indicados,
uma Vista possível para a classe “Reporter” seria a apresentação do atributo “full_name” e uma lista
de “Article” relacionados.
Uma Vista possível para o exemplo referido seria:
My full name is {{ reporter.full_name }}
{% for article in reporter.articles %}
<p>Headline - {{ article.headline }}</p>
<p>PubDate - {{ article.pub_date }}</p>
{% endfor %}
CONTROLADOR
O Controlador recebe pedidos (request) e envia respostas (response), ou seja é nos
Controladores que se encontra toda a lógica da aplicação. Os pedidos e as respostas são detalhadas
11
no capítulo 3.3.1. O Controlador poderá receber ou não dados e processa as respostas, fazendo
invocações a Modelos e populando os objectos necessários para as Vistas apresentarem.
Por exemplo, para um Controlador que tem como função preparar a apresentação de um
“Reporter”, a sequência de tarefas deste poderia ser a seguinte:
• Receber pedido
• Interpretar dados do pedido (“full_name” do “Reporter”)
• Invocar o Modelo “Reporter” para que retorne o objecto correspondente aos dados
recebidos (“full_name”) e “Article” relacionados, se existir no SGBD
• Se existir popular, a Vista com o objecto “Reporter”
• Retornar o documento HTML gerado pela Vista
• Se não existir, exibir Vista de erro.
Pela descrição de funções de cada um dos componentes, podemos verificar que cada um
tem a sua função específica, o que permite que a aplicação tenha uma estrutura mais clara e bem
definida.
3.1.2 - ESTRUTURA DE UM PROJECTO DJANGO
Uma aplicação web em Django, é pois um conjunto de Modelos, Vistas e Controladores que
constituem a base da aplicação desenvolvida pelo programador.
Quando inicia uma nova aplicação em Django, o programador deve usar o script de criação
de um novo projecto, que cria os ficheiros iniciais do mesmo, nomeadamente “manage.py”,
“settings.py”, “urls.py”, e uma pasta com o nome do projecto. Esta pasta contém o ficheiro de
definição de Modelos: “models.py”, o ficheiro “views.py”, o ficheiro “forms.py”, e o ficheiro “tests.py”, e
tipicamente uma pasta contendo as templates, que são ficheiro contendo a linguagem de templating
do Django de modo a criar páginas dinâmicas em HTML.
Iremos agora abordar o que devem ser os conteúdos de cada um destes ficheiros.
SETTINGS
O ficheiro “settings.py” é o ficheiro onde são definidas todas as configurações necessárias ao
funcionamento da aplicação em Django, devendo ser adaptado pelo programador. Entre as várias
configurações possíveis de definir, temos a definição do SGBD usado (capítulo 3.4.5), a linguagem a
utilizar, as definições horárias, a localização da pasta que contém as templates, a localização dos
vários ficheiros de fixtures e as definições de cache. Por omissão, são colocadas algumas definições
necessárias quando a aplicação é criada, podendo-se posteriormente adicionar outras definições se
assim se justificar, como as definições de cache, ou as definições de logging.
12
URLS
O ficheiro “urls.py” é onde está definido o mapeamento de URLs. Este consiste na definição
de um tuplo contendo os vários padrões de URLs necessários à interacção do browser com a
aplicação.
VIEWS
O ficheiro “views.py” contém os Controladores do MVC. Estes são definidos através de
métodos e contém a lógica da aplicação.
MODELS
O ficheiro “models.py” é onde deve constar a definição dos modelos. Como já antes referido,
é através deste ficheiro que são definidos em objectos Python as entidades correspondentes às
tabelas no SGBD. Uma das grandes vantagens da utilização de uma framework é a existência de
middleware para gestão dos acessos ao SGBD. Desta forma, definindo um modelo, são
disponibilizados métodos para efectuar acções CRUD (Create, Read, Update, Delete) sobre a Base
de Dados.
O package “models” no Django contém ainda classes que nos permitem definir qual o tipo de
dados de cada campo de um modelo. Por exemplo, se se definir um atributo de um modelo como
“CharField” significa que o tipo de dados corresponde a uma String e se se definir como IntegerField
siginifica que o tipo de dados é inteiro.
Os modelos do Django proporcionam também a manutenção da integridade referencial entre
as várias tabelas do SGBD. Se uma tabela contiver uma chave-estrangeira (capítulo 3.4.2) para outra
tabela, é possível o acesso ao modelo que mapeia a segunda tabela através do modelo que mapeia a
primeira tabela.
O Django é considerado loose-coupled ao SGBD. Isto significa que qualquer alteração aos
modelos não se repercute imediatamente no SGBD. Se for apenas acrescentado um novo atributo a
um objecto Model, essa alteração não se irá repercutir na tabela correspondente. Neste caso é
necessário aceder directamente ao SGBD e acrescentar a coluna à tabela.
O mesmo acontece caso algum modelo seja considerado desnecessário em determinada
altura. É necessário efectuar a remoção da tabela correspondente. Estas alterações aos modelos são
acontecimentos regulares durante o período de vida de uma aplicação, devido à sua própria
evolução, de forma a que esta cumpra mais requisitos e permita mais funcionalidades.
Todavia é disponibilizado pelo Django a possibilidade de se efectuar uma sincronização com
o SGBD, embora esta seja bastante limitada, consistindo em criar no SGBD todas as tabelas com os
correspondentes campos definidos no modelo que ainda não tenham sido criadas.
O objectivo da existência do ficheiro “models.py” contendo todos os modelos definidos pelo
13
programador é disponibilizar à camada “C”- Controlador do MVC objectos Python que representem os
dados de uma base de dados de um SGBD, bem como funções que permitam a pesquisa e
manipulação desses mesmos dados.
De realçar ainda que são sempre criados pelo Django alguns campos que não são
explicitamente definidos no modelo. Se o objecto não contiver referências a outros objectos (chaves-
estrangeiras), é criado um campo do tipo inteiro de nome “ID” que é uma chave-primária. Caso haja
referências a outros objectos são criadas as chaves-estrangeiras correspondentes, sendo que o
nome da coluna criado é o nome da tabela relacionada seguido de “_id”.
No Anexo A – Operações básicas sobre o SGBD, apresentam-se alguns exemplos de como
realizar algumas operações sobre o SGBD, usando os modelos “Library” e “Book”.
FORMS
O ficheiro “forms.py” é o ficheiro onde estão as definições dos vários formulários, ou seja
objectos que irão conter dados introduzidos pelo utilizador. Estas definições têm um papel
fundamental na arquitectura do Django. Como verificámos anteriormente, podemos facilmente criar
um objecto para introdução de dados no SGBD. Porém os dados introduzidos pelos utilizadores
muitas vezes não estão preparados para essa finalidade. As definições colocadas no ficheiro
“forms.py” vão permitir transformar esses dados “em bruto” em dados prontos a inserir.
Regularmente os campos apresentados numa Vista para a edição ou criação de uma
entidade correspondem aos campos definidos no modelo dessa entidade. Por vezes pode tornar-se
um pouco repetitivo apresentar numa Vista os campos correspondentes a um modelo. Supondo que o
modelo e o formulário correspondente continham muitos campos, poderia tornar-se uma tarefa
morosa construir o formulário na Vista.
Nesse sentido o Django disponibiliza algumas funções que permitem transformar formulários
directamente em HTML. Estas são:− as_p()
− as_ul()
− as_table()
Deste modo, os formulários são transformados em HTML directamente, sem ser necessário
na template a escrita do HTML para a construção do formulário, dado que é gerado através das
funções apresentadas.
Outra das vantagens do uso de formulários no Django prende-se com as validações. É
possível utilizar as validações do Django ou efectuar validações definidas pelo programador.
As validações do Django são baseadas no modelo de dados criado, ou seja são validados o
comprimento máximo dos campos e a sua obrigatoriedade de preenchimento, embora variem com o
tipo de dados. Para um campo inteiro, o Django apenas permite valores que contenham algarismos,
apresentando uma mensagem de erro caso sejam introduzidos outros caracteres.
É possível também fazer transformação de dados de campos. Pense-se porventura em
14
transformar todas as primeiras letras de campos que correspondam a introdução de nomes próprios
para letra maiúscula seguido de letras minúsculas, ou seja para uma introdução do utilizador de
“mARIa” ou de “maria”, o que seria introduzido no SGBD seria “Maria”.
Os formulários em Django são usados em controladores de uma forma bastante directa. É
passado um parâmetro para o formulário que é um objecto do Django – será analisado
posteriormente – que recolhe todos os parâmetros de submissão de um pedido ao servidor, ou seja
de um request. Caso o formulário seja válido ou não, é efectuada a acção correspondente.
Se o formulário não é válido e se for colocado novamente como parâmetro para a Vista, o
utilizador irá ver os campos com os dados inseridos anteriormente, assim como a lista de erros onde
falharam as validações. Existe ainda a possibilidade de se definirem formulários directamente através
dos modelos, podendo as validações serem redefinidas sobrepondo-se às do modelo. É também
possível redefinir as transformações dos dados dos utilizadores. Podem-se ainda definir quais os
campos a excluir ou a incluir quando se pretende que o formulário contenha apenas alguns dos
campos do modelo. A vantagem da utilização de formulários definidos através de modelos é a
utilização por estes da a informação que já existente no modelo.
TEST
O ficheiro “test.py” é onde devem ser colocados os testes à aplicação. Os testes têm dois
objectivos: validar que, quando se está a realizar o desenvolvimento de uma nova funcionalidade, se
obtém o comportamento esperado, e permitir que, quando se está a reformular uma funcionalidade já
existente, se garanta que não houve alterações de comportamento inesperadas.
Ao conjunto de testes de uma aplicação dá-se o nome de test suite. Justificar-se-á então, que
se testem dois tipos de componentes: os modelos e os controladores, ou seja as classes que
compõem o ficheiro “models.py” e os métodos que compõem o ficheiro “views.py”.
O Django permite que os testes sejam escritos de duas formas distintas: como Doc test ou
como Unit test. Os “Doc test” usam o atributo especial “__doc__” do objecto em causa, ou seja uma
docstring. Dentro desta temos a codificação do teste com alguma semelhança a uma sessão
interactiva de Python. Quando é executado o teste, é verificada a existência do atributo “__doc__” e
se existir é avaliado o código existente dentro da docstring.
A grande vantagem oferecida por este tipo de teste, é permitir que o próprio teste fique dentro
do objecto, podendo este objecto ser um módulo, uma função, uma classe ou um método. Permitem
ainda documentar, quer o objecto, quer o teste, e assim evitar o overhead de escrever classes e
métodos. Apresentam, porém, a desvantagem de aumentar o código presente dentro dos objectos,
bem como a utilização de uma sintaxe menos clara que os Unit test. Quando a test suite é executada
pelo Django é verificada a existência de docstring dentro dos vários objectos que constam nos
ficheiros “models.py” e “test.py”.
Os Unit test são codificados como métodos de uma classe que é sub-classe de
“unittest.TestCase”. São derivados de uma framework de testes unitários existente em Java
15
denominada JUnit. As vantagem da utilização deste tipo de testes são a clareza do código, já que não
são utilizadas as docstring, bem como a centralização no ficheiro “test.py” de todo o conjunto de
testes de uma aplicação, embora possam também ser declarados no ficheiro “models.py”.
Estas duas formas de realizar testes a uma aplicação em Django poderão ser usadas em
conjunto, não havendo por isso qualquer necessidade de escolha prévia de qual o tipo de testes a
realizar durante o desenvolvimento da aplicação. Todavia, por uma questão de organização, optou-se
por colocar os testes apenas no ficheiro “test.py”, usando apenas Unit test.
Para a realização a testes aos controladores, o Django disponibiliza uma ferramenta muito
útil: o “Test Client”.
Esta ferramenta tem as seguintes funções:
• Simular pedidos GET e POST aos URLs definidos no ficheiro “urls.py” que são mapeados
em métodos definidos no ficheiro “views.py”, e deste modo efectuar testes aos
controladores, observando a resposta recebida, podendo ser testados os códigos de
resposta do protocolo HTTP (capítulo 3.3.2), os cabeçalhos da resposta e o próprio corpo
da resposta, ou seja o conteúdo resultante da renderização do template (capítulo 3.3.6).
• Testar que a template correcta é renderizada e que são colocados no seu contexto os
atributos necessários ao seu processamento.
• Testar que o controlador (método do ficheiro “views.py”) executado é o correcto.
Por último, o Django apresenta ainda a possibilidade de utilização de fixtures. As fixtures são
ficheiros que contêm dados para popular o SGBD antes da realização de testes. Por exemplo, se se
está a efectuar um teste a um modelo que retorna informação de uma tabela no SGBD, é possível
popular essa tabela com dados de teste de modo a verificar se esses valores são retornados. No
início de cada teste são inseridos no SGBD os dados e são novamente retirados no fim do teste.
MANAGE
O ficheiro “manage.py” é um ficheiro que permite realizar uma série de tarefas utilitárias e de
administração através da linha de comando.
As principais funções realizadas são:
• O lançamento de uma shell1 para o SGBD.
• A apresentação de diferenças entre as configurações da aplicação e as configurações
iniciais (no ficheiro “settings.py”).
• O retorno de todos os dados relacionados com a aplicação persistidos no SGBD.
• A criação de um ficheiro “models.py” através de tabelas de uma base de dados do SGBD.
• Popular um SGBD com fixtures.
1 Cliente de uma aplicação por linha de comando
16
• Executar o servidor aplicacional de desenvolvimento do Django.
• Executar uma “shell” interactiva de Python.
• Iniciar um novo projecto em Django, criando a estrutura de directorias.
• Criar as tabelas no SGBD correspondentes a novos modelos definidos no ficheiro
“models.py”.
• Executar testes.
• Validar os modelos do ficheiro “models.py” com as tabelas no SGBD correspondentes.
Foi apresentada uma breve descrição dos componentes de um projecto em Django, bem
como alguns exemplos muito simples da sua utilização, de modo a que sejam mais claras as funções
de cada um desses componentes e o dinamismo e funcionalidades oferecidos pelo Django na criação
de aplicações, permitindo tornar o desenvolvimento mais organizado e eficiente.
3.1.3 - LINGUAGEM DE PROGRAMAÇÃO PYTHON
A linguagem de programação Python foi a linguagem usada para o desenvolvimento deste
projecto. O Python [45] cap. 1, é uma linguagem de programação open-source usada quer para o
desenvolvimento de aplicações quer para scripting. É portável entre sistemas operativos, a sua
sintaxe é simples, o que torna o código perceptível e fácil de manter, e é orientada à produtividade do
programador dado que o código necessário para desenvolver uma aplicação é menos extenso do que
noutras linguagens, como Java e C, e pelo facto de ser uma linguagem interpretada, ou seja não há a
necessidade de o programador compilar o código sempre que pretende executar a aplicação.
O Python é uma linguagem orientada a objectos [66] cap. 1, ou seja, permite a estruturação
da programação em classes com atributos e comportamentos (métodos) próprios, gozando das
propriedades de herança1 e polimorfismo2, embora possa ser também utilizada como linguagem
procedimental, não usando objectos. Fica ao critério do programador a metodologia de programação
utilizada. No caso deste projecto, foi utilizada programação por objectos, dado que o Django foi
desenvolvido para ser utilizado segundo esse paradigma.
É também uma linguagem dinâmica, não sendo por isso necessário tipificar explicitamente as
variáveis, o que se por um lado requer maior atenção da parte do programador, por outro permite que
o código implementado seja muito menos verboso em comparação com outras linguagens estáticas
como o Java e o C, em que é necessário definir explicitamente os tipos de todas as variáveis.
O Python é distribuído com uma variada colecção de bibliotecas o que permite uma grande
flexibilidade de utilização em domínios tão variados como, por exemplo, aplicações web, sistemas de
integração contínua, sistemas de controlo de versões e media players.
Foi escolhida a utilização de Python versão 2.7 devido a ser a última versão estável e mais
1 Uma classe pode herdar o comportamento de outra.2 Uma classe pode redefinir parte do seu comportamento relativamente a outra classe de onde herda esse comportamento.
17
completa a nível de bibliotecas. Não foi usada uma nova evolução da linguagem, o Python versão 3.x,
devido a não existir ainda compatibilidade com o Django e com a interface WSGI. A versão 3.x não é
um upgrade à versão 2.x, mas uma evolução diferente da linguagem, não havendo compatibilidade
entre o código desenvolvido para a versão 2.x e 3.x.
Uma solução também possível para este projecto seria o uso da linguagem Ruby e a
framework web Rails desenvolvida em Ruby, concorrente e em muitos aspectos similar ao Django.
Não foi escolhida esta solução devido à maior experiência do autor com Python e Django por
comparação com Ruby e Rails.
3.2 - DESENVOLVIMENTO ORIENTADO POR TESTES
O objectivo deste capítulo é analisar uma metodologia de desenvolvimento de software que
permite, através de uso de regras muito simples mas por vezes difíceis de seguir, que o
desenvolvimento do código de uma aplicação seja sistemático e eficaz.
Dadas as suas características, esta metodologia permite uma grande poupança de tempo na
codificação, dado que é orientada à funcionalidade e foi o método usado no desenvolvimento deste
protótipo.
3.2.1 - DESCRIÇÃO E OBJECTIVOS
O desenvolvimento orientado por testes (Test Driven Development) é uma forma de
desenvolvimento de software que consiste em executar testes antes da escrita do próprio código,
durante o processo de desenvolvimento de uma aplicação.
O objectivo do TDD não é validar o código desenvolvido, mas garantir que as especificações
são cumpridas. Deste modo podemos considerar que o TDD é uma técnica de programação e não
uma forma de efectuar testes funcionais à aplicação. Desta forma, o TDD permite, por um lado, que o
programador reflicta sobre o design do código a desenvolver, e por outro que o código seja limpo,
funcione e cumpra o que é especificado pelos testes.
O TDD foi introduzido em [1], como parte integrante dos conceitos de programação de
Extreme Programming (XP), que define um conjunto de regras simples tendo como objectivo o
melhoramento do desenvolvimento de software. Entre estas contam-se, além do TDD, programação
em pares de programadores, revisão de código desenvolvido, código claro e alterações de requisitos
ao longo do tempo, objectivos de desenvolvimento realistas, planeamento de releases e integração
contínua.
3.2.2 - PROGRAMAÇÃO EM TDD
O TDD é um processo iterativo constituído por três fases:
• Na primeira fase o programador escreve um teste. Como não existe a funcionalidade
18
desenvolvida na aplicação, o teste irá falhar.
• De seguida efectua-se o desenvolvimento do código necessário até que o teste passe.
Estas duas primeiras fases correspondem ao TFD (Test First Design).
• Na terceira fase é avaliado o código desenvolvido para passar o teste, de forma a que
não haja repetições na aplicação e para que fique o mais “limpo” possível.
A Figura 10 ilustra os vários passos do TDD.
Findo este processo, voltamos novamente à primeira fase, escrevendo um novo teste para
uma nova funcionalidade até que seja terminada a aplicação.
Desta forma o código funcional é sempre escrito depois de um teste sendo, por isso,
completamente distinto do método tradicional em que se escreve código funcional e depois testes a
esse código.
3.2.3 - TDD COMPARADO AO MÉTODO TRADICIONAL
Em comparação com o método tradicional, o TDD apresenta consideráveis vantagens,
embora à primeira vista não pareça. A questão que se coloca é a seguinte: porque é necessário
“perder tempo” a escrever testes? Com o desenrolar do desenvolvimento, a aplicação vai ficando
cada vez mais complexa. Nem sempre existe tempo por parte dos programadores para,
posteriormente à implementação de uma funcionalidade, efectuarem os testes necessários.
Por seu turno, é muito frequente também que um programador não teste todas as
funcionalidades que foram adicionadas, especialmente se desenvolvidas por outro programador. Com
o passar do tempo de desenvolvimento, e sem os testes adequados, o dinamismo com que se
consegue fazer uma alteração na aplicação diminui, porque uma pequena alteração pode provocar
um colapso em várias funcionalidades.
É para suprir estas dificuldades que se torna vantajoso o uso do TDD. Uma das
características é ser o programador a escrever os seus próprios testes. Isto, conjugado com o facto
19
Figura 10: Etapas do processo TDD
de não se desenvolver código funcional, tem como consequência que todas as funcionalidades estão
antecipadamente testadas, bem como todas as linhas de código desenvolvidas. Caso seja necessário
alguma alteração na aplicação em termos funcionais, depois de efectuada essa alteração, é possível
aferir imediatamente qual o impacto que a alteração vai ter no resto da aplicação, dado que alguns
testes passam a falhar.
Outra das vantagens é o facto de se ter incrementalmente construído um conjunto de testes à
aplicação desenvolvida, que garantem que esta cumpre todas as funcionalidades para a qual foi
planeada, o que traduz um aumento da qualidade do produto final.
Embora inicialmente o tempo despendido em desenvolvimento tenha um acréscimo devido à
codificação dos testes, rapidamente esse tempo é recuperado à medida que a aplicação vai ficando
mais extensa, dado o facto de haver um grande ênfase na qualidade do código produzido, o que
permite que, em comparação com o método tradicional, se consiga reduzir consideravelmente o
tempo de manutenção da aplicação e correcção de bugs, que surgirão com maior frequência usando
o método tradicional.
3.2.4 - PROCESSO DE CODIFICAÇÃO DE TESTES
A correcta codificação de testes é fundamental para que a programação TDD seja eficaz. Se
os testes não corresponderem às funcionalidades desenvolvidas, todo o princípio do TDD não é
respeitado e a qualidade da implementação começa a diminuir.
Assim, enumera-se de seguida alguns princípios a que a codificação de testes deve obedecer
[2] cap. 25:
• Os testes devem ter uma execução rápida.
• Os testes devem ser executados de forma isolada.
• Devem ser usados dados claros.
• Devem ser usados dados o mais próximos dos reais caso seja necessário.
• Cada teste deve contribuir para a conclusão das funcionalidades a desenvolver.
No caso do primeiro ponto, se os testes tiverem uma grande duração a serem executados, a
implicação decorrente será que o conjunto dos testes vai ser executado menos vezes do que o
necessário dado ser uma tarefa morosa, o que impõe grandes tempos de paragem entre a
codificação e o resultado dos testes, tornando todo o processo ineficiente.
Se os testes não puderem ser executados de forma isolada, cada vez que se testa uma
funcionalidade que está a ser desenvolvida, é necessário executar os testes correspondentes,
acrescidos dos testes necessários para que todos possam ter sucesso. Ora, aqui encontramos dois
problemas. Primeiro a falta de eficiência já referida anteriormente. Segundo, executando um teste
dependente de outro de forma isolada, não é claro se a falha no teste é devida ao não cumprimento
das especificações pelo código desenvolvido.
20
No caso do uso de dados não claros, a maior dificuldade será no diagnóstico ao teste caso
este falhe. Com dados não claros é necessário despender mais tempo para se perceber porque e
como falhou o teste.
A utilização de dados reais é conveniente, dado que quanto mais aproximado do ambiente de
produção se estiver, maior a garantia que os dados de produção são compatíveis com a
funcionalidade desenvolvida.
O último ponto traduz a eficácia que os testes deverão possuir. É contraproducente escrever
um teste e desenvolver código para uma funcionalidade não necessária. Se acontecer de forma
regular, a aplicação poderá tornar-se muito maior do que seria necessário, o que, com o acréscimo de
complexidade correspondente, irá implicar maiores tempos para que os testes sejam executados e
para que a aplicação seja compilada.
3.2.5 - TESTES COMO DOCUMENTAÇÃO
Se os testes seguirem os princípios anteriormente apresentados, podem tornar-se numa parte
importante da documentação técnica de um projecto, dado que induzem a especificação funcional do
código. Estes permitem descrever as características das várias APIs constituintes do projecto,
indicando o seu uso correcto e incorrecto.
3.2.6 - TESTES NO DJANGO
A maior parte das linguagens de programação actuais já têm desenvolvido frameworks para
testes, como por exemplo o PyUnit para Python, os xUnit para Java, ou Test::Unit para Ruby. As web
frameworks, como o Django para Python ou o Rails para Ruby, já têm suporte para frameworks de
testes, possibilitando a programação em TDD sem a instalação de módulos adicionais e fornecendo
um conjunto de funcionalidades de modo a que a integração dos testes no projecto seja de forma fácil
e estruturada.
3.3 - INTERACÇÃO CLIENTE – SERVIDOR
O objectivo deste capítulo é apresentar as bases teóricas sobre as quais irá assentar a troca
de dados entre a aplicação desenvolvida e o utilizador, desde o momento em que este efectua um
pedido até à visualização da resposta obtida. São descritos os protocolos utilizados, é introduzido o
conceito REST e analisada a resposta obtida pelo cliente (browser) e a forma como esta é
processada e visualizada pelo utilizador.
3.3.1 - REQUEST - RESPONSE
O ciclo Request-Response é um padrão de troca de informação habitualmente utilizado por
21
arquitecturas Cliente-Servidor1. Embora possa ser implementado de forma assíncrona2, em que a
resposta pode ser retornada mais tarde no tempo, a implementação comum é síncrona3. A
arquitectura usada neste projecto é Cliente-Servidor sem estado, com comunicação síncrona.
Desta forma, obtemos melhorias nas seguintes propriedades: Visibilidade, Fiabilidade e
Escalabilidade. Visibilidade melhorada porque é apenas necessário olhar para um request para
determinar a sua essência, Fiabilidade melhorada porque torna mais simples o processo de
recuperação de uma falha parcial e Escalabilidade melhorada porque, sem ter de guardar estado
entre requests, o servidor rapidamente liberta os recursos alocados [21] cap. 5.
Sendo este projecto web, um cliente (tipicamente um browser) efectua pedidos (requests) ao
servidor onde está alojada a aplicação, de modo a obter informação (response) para apresentar ao
utilizador, tipicamente documentos HTML - capítulo 3.3.5.
A Figura 11 mostra a arquitectura Cliente-Servidor:
3.3.2 - O PROTOCOLO HTTP
O protocolo sobre o qual é feita a interacção entre cliente e servidor é o protocolo HTTP –
Hypertext Transfer Protocol, que constitui a base da maioria de transferência de informação neste
projecto entre estas duas entidades. O protocolo HTTP é considerado um protocolo de camada de
aplicação (segundo o modelo OSI4), requerendo uma ligação fiável host-to-host providenciada pelo
protocolo de camada de transporte TCP – Transmission Control Protocol [40] cap. 3.5, embora já
tenha sido usado sobre protocolos não fiáveis como o UDP – User Datagram Protocol [40] cap. 3.3.
Inicialmente o protocolo HTTP foi desenvolvido com o objectivo de transferir documentos
(Hypertext documents) que contém referências a outros documentos, a que o utilizador pode aceder 1 O modelo cliente-servidor em computação é uma estrutura distribuída onde existe uma clara definição entre o requester ou cliente e o provider ou servidor. Neste modelo os clientes iniciam a comunicação e solicitam ao servidor recursos.2 O emissor inicia a comunicação, mas não aguarda pela resposta, que será entregue mais tarde no tempo.3 O emissor inicia a comunicação e aguarda pela resposta o tempo necessário ou até ser atingido o tempo máximo de ligação.4 Open Systems Interconnection [68]
22
Figura 11: Arquitectura Cliente-Servidor
de imediato, habitualmente por um clique de rato ou por uma sequência de teclas. Estes documentos
ou recursos são identificados por URI – Uniform Resource Identifier, ou mais especificamente por
URL – Uniform Resource Locator. URIs e HTML – Hyper Text Markup Language, formam um sistema
de recursos interligados, que induziram o aparecimento da World Wide Web em 1990 por Tim
Berners-Lee.
A primeira versão do protocolo, posteriormente designada por HTTP/0.9, utilizava apenas um
método (GET), mesmo para o envio de informação para o servidor, e tinha a característica de fechar a
ligação entre cliente e servidor assim que o pedido era satisfeito. O protocolo era muito simples mas
apresentava algumas limitações, como a necessidade de abertura de uma ligação por documento, o
que congestionava os servidores porque a abertura de ligação é um processo pesado [40] cap. 3.7, a
restrição do envio de dados apenas no URI, o envio desses dados em claro e o não tratamento de
erros.
Devido às limitações desta versão, o protocolo foi melhorado e foi introduzida a versão
HTTP/1.0, tendo nesta altura sido nomeada a versão anterior como HTTP/0.9. Esta versão já incluía a
possibilidade de interagir com sistemas de cache, request e response com muito mais informação
como a tipificação de códigos de resposta, o uso de novos métodos (POST e HEAD) e ainda uma
forma de autenticação muito simples (Basic Authentication [24]).
Embora esta versão tenha solucionado alguns dos problemas detectados, mantinha-se com
algumas restrições, nomeadamente a necessidade de continuar a efectuar múltiplas ligações, e
possuir um método de autenticação demasiado simples e pressupondo uma ligação segura entre
cliente e servidor, dado que os dados da autenticação são passados em claro.
A versão HTTP/1.1 vem suprir o que ainda não tinha sido melhorado na versão HTTP/1.0. A
principal característica é a reutilização da ligação, por exemplo para a transmissão de várias imagens
constituintes de um documento. Desta forma a latência diminui, dado que o estabelecimento de uma
comunicação TCP apresenta um significativo overhead. Como a ligação é reutilizada, em comparação
com a versão HTTP/1.0, o overhead de novas ligações é suprimido.
Outra das características é a melhoria da eficiência no tratamento de recursos. O mecanismo
de cache [22] cap. 13, foi significativamente melhorado e a comunicação entre cliente e servidor
tornou-se mais eficiente, sendo apenas transmitido o que é estritamente necessário. O objectivo é
eliminar em alguns casos request supérfluos, bem como noutros casos, response completas. Assim,
são reduzidos os números de network round-trip necessários para muitas operações. Para isso é
usado um mecanismo de expiração e validação.
De modo a melhorar a performance e disponibilidade, o protocolo permite um relaxamento à
transparência semântica quando necessário. As situações em que acontece esse relaxamento são as
seguintes: por um pedido explícito pelo cliente ou pelo servidor de origem ou, existindo um aviso para
o utilizador final quando houve relaxamento pela cache ou pelo cliente.
Uma cache comporta-se de uma forma “semanticamente transparente” relativamente a uma
resposta se o seu uso não afecta o pedido do cliente ou o servidor de origem, ou seja o cliente recebe
exactamente a mesma resposta como se fosse enviada pelo servidor de origem.
23
Assim, o protocolo, a nível de cache, contém os seguintes elementos: permite a transparência
semântica completa quando é requerido por todas as partes, permite que um servidor de origem ou
um cliente explicitamente controlem operações não transparentes e permite que uma cache adicione
avisos às respostas que não preservam transparência semântica.
A autenticação foi também revista, passando a ser usado o método digest [24] cap. 3, que ao
contrário do método basic não envia o segredo comum (password) em claro, o que corresponde à sua
maior fraqueza.
Os dois métodos de autenticação não são os mais seguros, mas uma comparação entre eles
revela a necessidade de se utilizar sempre que possível o digest. A maior ameaça a este tipo de
comunicação é o network snooping. Se, por exemplo, a comunicação envolver o acesso a uma base
de dados restrita a alguns utilizadores, com a autenticação basic é possível que se obtenha a
password do utilizador e, consequentemente, se tenha acesso quer à base de dados, quer a tudo o
que o utilizador tenha protegido com essa mesma password. Com o método digest é apenas possível
o acesso à transacção e não à password do utilizador. Por isso é possível efectuar a repetição do
pedido - replay attack [9], mas apenas do mesmo documento, embora esta situação também possa
ser minorada pela escolha de nonce (number chosen once) do servidor. O método é também
vulnerável ao ataque man-in-the-middle [9] que pode, por exemplo, em vez do uso de digest,
interceptar o pedido e alterá-lo de modo a solicitar a autenticação basic.
São introduzidos também novos estados para o manuseamento de cache e controlo de
tráfego – os estados 1xx, passando os estados 2xx a ser usados para o manuseamento de canais de
transmissão.
São também adicionados novos métodos aos anteriores (GET, HEAD e POST),
nomeadamente OPTIONS, PUT, DELETE, TRACE e CONNECT [22] cap. 9. O método OPTIONS
permite que um cliente saiba quais as opções de comunicação disponíveis, as capacidades do
servidor, ou as opções/requisitos associados a um recurso sem implicar a devolução do recurso ou
qualquer acção. O método PUT solicita que um determinado recurso seja alterado para o URI
indicado. Se não existir, o servidor de origem deve informar o cliente através do estado 201 –
Created. Caso contrário, deve ser enviada uma de duas respostas de sucesso: 200 - OK ou 204 – No
Content. O método DELETE solicita que o servidor de origem apague o recuso identificado pelo URI.
Neste caso as respostas de sucesso são: 200 – OK, 202 – Accepted ou 204 – No Content. O método
TRACE é usado por um cliente para enviar de volta o pedido ao servidor de origem. Este deve
constar na resposta com o estado 200 – OK. O método CONNECT é reservado na especificação para
uso com um proxy [40] cap. 2.2.6, que possa dinamicamente transformar-se num túnel [44].
Outro aspecto importante do protocolo HTTP é o mecanismo de gestão de estado através de
cookies. As cookies são cabeçalhos HTTP cuja sintaxe é definida por [38] cap. 3.2.2 e que permitem
que o cliente mantenha alguma informação de estado entre pedidos HTTP.
Todavia o seu uso viola uma das restrições da arquitectura REST (stateless) [21] cap. 6.3.4.2.
O uso de cookies neste projecto permite uma melhoria significativa de performance dado que reduz
significativamente a quantidade de informação transmitida em alguns request e response, bem como
24
a carga no SGBD.
As cookies são neste momento usadas por quase todas as aplicações web, e são a única não
conformidade com a arquitectura REST usada em larga escala. A discussão sobre o uso ou não de
cookies e a sua interferência com a arquitectura REST não é aqui aprofundada.
3.3.3 - O PROTOCOLO HTTPS
O protocolo HTTP opera na camada de aplicação do modelo OSI. Já foram anteriormente
referidos os problemas de segurança existentes no protocolo e alguns mecanismos descritos na
especificação que tentam aumentar a sua segurança. O protocolo HTTPS1, difere do protocolo HTTP
essencialmente por usar uma comunicação cifrada. O protocolo de camada de transporte usado pelo
HTTP, como já foi explicitado anteriormente é o TCP que, embora garanta a fiabilidade na
transmissão, permite que os dados sejam transmitidos em claro. Assim, os dados são cifrados e só
depois transportados pelo protocolo TCP, sendo revertidos apenas no receptor.
Deste modo é criada uma camada intermédia destinada à cifra dos dados a transmitir entre a
camada de aplicação e a camada de transporte.
Inicialmente foi usado o standard SSL, criado pela Netscape de modo a garantir a segurança
em transacções comerciais na Internet, nomeadamente pagamentos. Posteriormente a patente foi
comprada pelo IETF (Internet Engineering Task Force) e renomeada de TLS (Transport Layer Security),
tendo o TLS 1.0 descrito por [17], sido desenvolvido com base no SSL 3.0. A versão de TLS 1.1 é
descrita por [18] e a versão mais recente TLS 1.2 é descrita por [19].
A breve descrição aqui apresentada baseia-se em [37], [55] e [19].
O protocolo TLS permite que aplicações cliente-servidor possam comunicar de uma forma
segura, com autenticação e confidencialidade usando criptografia. Em comunicação típica entre
browser e servidor a autenticação é unilateral, ou seja, o servidor está autenticado (o cliente conhece
a sua identidade) mas para o servidor o cliente permanece anónimo. O protocolo TLS permite
também uma comunicação mais segura, usando autenticação bilateral, em que quer cliente quer
servidor se autenticam entre si e onde seriam necessários dois certificados digitais.
O início de ligação compreende um procedimento de hand-shake, ou seja, uma fase de
negociação entre o cliente e servidor onde são definidos vários parâmetros de modo a ser
estabelecida a segurança da ligação. O cliente efectua um pedido de ligação segura, informando o
servidor qual a lista de cypher-suites suportadas [10]. Desta lista o servidor escolhe a mais forte e
notifica o cliente da sua decisão enviando a sua identificação sob a forma de um certificado digital. O
certificado digital contém o nome do servidor, a Certificate Authority2 (CA), e a sua chave pública. O
cliente usualmente contacta o servidor que emitiu o certificado digital de modo a assegurar-se da sua
validade.
Para gerar as chaves da sessão o cliente gera um número aleatório, cifra-o com a chave
1 HTTPS – Hyper Text Transfer Protocol over SSL – Secure Socket Layer2 Entidade que emite certificados digitais, na qual cliente e servidor confiam.
25
pública do servidor e envia-o cifrado para o servidor. Apenas este com a sua chave privada irá
conseguir decifrar o número. Assim, o cliente conhece o número aleatório gerado e a chave pública
do servidor, e o servidor conhece o número aleatório e a sua chave privada.
A menos que a chave privada do servidor tenha sido descoberta, qualquer outra entidade
nesta comunicação não sabe qual o número aleatório gerado e não conseguirá decifrar as
mensagens transmitidas.
Desta forma, quer cliente quer servidor geram os conteúdos necessários à comunicação
tendo como base o número aleatório e é iniciada a ligação segura. No caso da ligação ser encerrada,
e para o estabelecimento de nova ligação, são necessários novamente cumprir as etapas
enumeradas desde o início e por esta ordem. Caso alguma das etapas falhe, não é iniciada qualquer
ligação.
A menos que negociado de outra forma entre cliente e servidor, o certificado digital deverá ser
do tipo X.509v3. Este standard assume um sistema de CA hierárquicos para a emissão de
certificados – Public Key Infrastructure (PKI) [14].
O tipo X.509v3 é definido em [13].
Existem outros protocolos para comunicações seguras como o S-HTTP, mas nunca foram
largamente adoptados e desta forma o HTTPS tornou-se o mecanismo De facto1 para comunicações
seguras na World Wide Web.
3.3.4 - REST – REPRESENTATIONAL STATE TRANSFER
O conceito REST, introduzido em [21] cap. 5, é um conceito de arquitectura de sistemas
hypermedia2 distribuídos. A arquitectura da web pode ser descrita por um conjunto de restrições
aplicada aos seus elementos, e através da análise do impacto de cada uma destas restrições
conseguimos identificar as suas propriedades.
O REST foi desenvolvido paralelamente ao protocolo HTTP/1.1 e muitas das especificações
existentes nesse protocolo foram introduzidas para que a arquitectura existente na web tivesse em
conta este novo conceito, dado que o autor do REST contribuiu também para o desenvolvimento
desta versão do protocolo HTTP/1.1.
3.3.4.1 - RESTRIÇÕES DA ARQUITECTURA REST
A primeira restrição é a utilização de uma arquitectura Cliente-Servidor em que existe uma
separação de funções. Enquanto que o cliente dará mais relevância à user-interface, o servidor dará
mais importância ao armazenamento de dados. Desta forma é melhorada a portabilidade da user-
interface e é melhorada a escalabilidade pela simplificação dos componentes do servidor, permitindo
1 De facto - expressão latina que significa na prática, mas sem ter sido regulamentado por lei.2 Elementos de texto, dados, gráficos, áudio e vídeo ligados de forma a que o utilizador possa navegar entre eles.
26
que a evolução destes dois componentes seja independente.
A segunda restrição define que a interacção entre cliente e servidor seja stateless1, o que
implica que cada request do cliente enviado para o servidor contenha toda a informação necessária
para ser entendido e processado, não tirando partido de qualquer informação de contexto existente
no servidor, o que implica que toda a informação de sessão é mantida exclusivamente no cliente. Esta
restrição introduz as propriedades já referidas no capítulo 3.3.5, que são visibilidade, robustez e
escalabilidade.
A terceira restrição é o uso de cache. O uso de cache implica que, implicitamente ou
explicitamente, uma response tem de ser marcada como podendo ser ou não reutilizada para futuros
requests semelhantes. Esta restrição, embora possa diminuir a robustez devido às possíveis
diferenças entre o conteúdo da cache e a response obtida directamente do servidor, melhora a
eficiência, a escalabilidade e o tempo de resposta do ponto de vista do utilizador.
A quarta restrição é o uso de uma interface uniforme entre componentes. Assim a arquitectura
do sistema, bem como a sua visibilidade é melhorada, embora a eficiência seja menor devido à
normalização da transferência de informação, em comparação com a transferência de informação
específica por aplicação. Uma interface REST é definida pelas seguintes propriedades: identificação
de recursos, manipulação de recursos por representações, mensagens auto-descritivas e hypermedia
definindo estado.
A quinta restrição implica um sistema por camadas. Uma hierarquia de camadas impõe que
cada componente só possa aceder a uma determinada camada, diminuindo a complexidade e
permitindo a simplificação de componentes, ao mesmo tempo que aumenta a escalabilidade devido à
distribuição de carga (load-balancing) pela rede e por múltiplos processadores. Esta restrição
aumenta o overhead e latência, com consequências no tempo de resposta do ponto de vista do
utilizador, minimizado pelo uso de caches. O uso de camadas melhora também a segurança dos
dados transmitidos, possibilitando o uso de firewalls2.
A sexta e última restrição é o code-on-demand. Desta forma, é possível que as
funcionalidades do cliente sejam expandidas à medida que se torna necessário. Assim, é aumentada
a extensibilidade do sistema e a simplicidade do cliente, embora a visibilidade diminua e por isso é
uma restrição opcional.
3.3.4.2 - ELEMENTOS DA ARQUITECTURA REST
A arquitectura REST é constituída três tipos de elementos: Elementos de informação,
conectores e componentes.
Os elementos de informação são os seguintes: o recurso (resource), que indica qualquer
informação que possa ter um nome, imagem, documentos, um conjunto de outros recursos, um
serviço temporal. Alguns recursos são estáticos, como por exemplo um documento HTML, que não
1 Sem estado2 Dispositivos desenhados para controlar e monitorizar o acesso a uma rede restrita. [40] cap. 8.1.
27
varia ao longo do tempo e outros são dinâmicos, como por exemplo a indicação da hora actual. O
único requisito necessário para um recurso existir é a semântica do seu mapeamento. O segundo é o
identificador para o recurso (resource identifier). Tipicamente é utilizado um URL ou um URN [61] e
[46]. O terceiro é a representação do recurso (representation), por exemplo, um documento HTML ou
uma imagem JPEG. O quarto é a metadata da representação do recurso (representation metadata),
que inclui informação como data da última modificação ou MIME type1. O quinto elemento é a
metadata do recurso (resource metadata), ou seja informação sobre o recurso que não é específica,
como, por exemplo, o autor, ou a data da última alteração ao recurso, e o sexto elemento é
informação de controlo (control data), como por exemplo, informação para o manuseamento de
cache.
Os conectores são os elementos que podem estabelecer ligações, nomeadamente o cliente,
o servidor, a cache, o resolver, por exemplo, um DNS [47] e [48], e o túnel (SOCKS [42], SSL após
HTTP CONNECT).
Os componentes são o servidor de origem, a gateway [40] cap. 4.3, a proxy, e o user-agent,
ou seja no nosso caso o browser.
A Figura 12 mostra-nos as interacções que existem entre os vários componentes, os
conectores existentes, com ou sem cache e o fluxo de dados.
O user-agent efectua três pedidos, respectivamente a, b, c. Qualquer dos pedidos não é
satisfeito pela cache do user-agent, e é direccionado pelo identificador de recurso respectivo.
O primeiro pedido é efectuado a uma proxy local que por sua vez o encaminha para uma
gateway descoberta por um pedido de resolução de nomes a um DNS. De seguida, o pedido é
encaminhado para um servidor de origem, cujos recursos encapsulam uma arquitectura ORB [50].
O segundo pedido é enviado directamente para um servidor de origem, que o consegue
satisfazer através da sua cache.
O terceiro pedido é efectuado a uma proxy que consegue aceder directamente a um serviço
WAIS [51] e [32], que é um sistema separado da arquitectura web.
1 Ver [27], [25], [49], [28], [26]
28
Figura 12: Componentes REST e interacções [21] cap. 5
3.3.4.3 - A INTERFACE REST APLICADA AO PROTOCOLO HTTP
O protocolo HTTP desempenha um papel especial na arquitectura web actual, sendo o
protocolo da camada de aplicação do modelo OSI maioritariamente utilizado para comunicação entre
aplicações, tendo sido desenhado especificamente para a representação de recursos [21] cap. 6.3.
Como já foi apresentado, um dos elementos de informação da arquitectura REST é o recurso.
Este é exposto através do seu identificador de recurso como um objecto. Supondo que é necessário
expor o recurso através do seu URL, e que este recurso é um catálogo de produtos. Em vez de
invocar o recurso através de métodos como getAllProducts ou createNewProduct, este irá ser
invocado através dos métodos HTTP já anteriormente apresentados. São estes o GET, POST, HEAD,
PUT, DELETE e OPTIONS [56].
No exemplo apresentado, catálogo de produtos, o recurso catálogo é constituído por um
conjunto de categorias. Cada categoria é identificada por um nome, por um conjunto de outras
categorias (sub-categorias) e por uma lista de produtos. Cada produto é constituído por um nome e
por uma cor. Tomemos por exemplo uma aplicação que está no seguinte URL: http://myapp.com .
Todos os recurso expõem a mesma interface e têm um funcionamento semelhante. Para
solicitar um determinado recurso, é efectuado um pedido GET para o seu URL.
Para definir uma interface REST que nos permita mapear os nossos recursos, comecemos
pela identificação da estrutura hierárquica. Na base temos um catálogo de produtos que é constituído
por um conjunto de categorias. Se se pretender listar os valores constantes do catálogo de produtos,
ir-se-á obter a lista de categorias. Dessa forma o URL que identifica o recurso catálogo irá retornar a
lista de categorias. Logo invocando o URL http://myapp.com/catalog iremos receber essa lista.
Para aceder aos valores de uma determinada categoria basta, da mesma forma, invocar o
URL http://myapp.com/catalog/paint para ser retornada a lista de sub-categorias, bem como a lista de
produtos para essa categoria. Para se aceder a uma sub-categoria e serem listadas as suas sub-
categorias poder-se-ia, eventualmente, aceder ao URL http://myapp.com/catalog/paint/outside ou
http://myapp.com/catalog/paint/inside. Para, por exemplo, aceder à lista de produtos da categoria “inside”
aceder-se-ia ao URL http://myapp.com/catalog/paint/inside/products e a um produto específico ao URL
http://myapp.com/catalog/paint/inside/products/waterpaint.
Da mesma forma, são utilizados os outros métodos além do GET, exclusivamente usado até
aqui, mas para realizar as outras funcionalidades que não apenas receber informação. Por exemplo,
se for necessário acrescentar mais um produto à categoria “inside”, basta para isso que se efectue
um POST com a informação do objecto no corpo do pedido para o URL
http://myapp.com/catalog/paint/inside/products. Está-se assim a fornecer a informação ao servidor de que é
pretendido adicionar outro produto à categoria “inside”. Da mesma forma, pode-se usar o método
PUT para efectuar alterações a qualquer produto existente, enviando no corpo do pedido os dados a
alterar (por exemplo a cor). O mesmo acontecerá com o método DELETE, que apagará um
determinado produto, podendo apenas retirá-lo da categoria ou retirá-lo de todas as categorias,
removendo-o completamente do sistema (dependendo da implementação). Pode-se ainda usar o
método HEAD para receber a metadata de um recurso e o método OPTIONS para receber quais as
29
operações disponíveis para um determinado recurso. Não será com certeza razoável eliminar todo o
catálogo disponibilizando o método DELETE para o URL http://myapp.com/ e, dessa forma, é possível
utilizar o método OPTIONS para obter informação sobre os métodos disponíveis para este recurso,
que neste caso seria apenas o método GET.
Os métodos usados anteriormente para a manipulação de produtos poderão também ser
usados para a manipulação das categorias, se a interface assim for implementada.
Claro que também se pode verificar que, se for pedido o URL http://myapp.com/catalog/paint/inside/x
e se não existir o produto “x”, não é obtida a mesma resposta. Dessa forma, deve-se avaliar o código
de resposta do protocolo HTTP. Se for recebido o código de resposta 200 (OK), o cliente é informado
que o pedido foi um sucesso e que deverá apresentar a informação. Para o produto “x”, como não
existe, o servidor deverá indicar um outro código de resposta, na gama 3xx, 4xx ou 5xx. Dessa forma,
é transmitido ao cliente que o recurso por ele solicitado não permite a utilização de um determinado
método ou simplesmente não existe.
3.3.4.4 - VANTAGENS DO USO DE UMA INTERFACE REST
A interface REST do exemplo anterior permite que uma aplicação cliente-servidor apresente
algumas características interessantes. Esta, usa eficazmente o protocolo HTTP, utilizando os seus
vários métodos e os vários códigos de resposta apresentados pelo mesmo. Permite também que os
recursos estejam mapeados de forma hierárquica, sendo por isso mais perceptíveis as suas
dependências. Permite ainda que os clientes da aplicação possam utilizar URLs mais claros e mais
indicativos do recurso, e que o acesso e manipulação dos recursos seja de uma forma sistemática
para os diversos recursos. Neste projecto, o mapeamento de URLs, (capítulo 3.1.2 - mapping.py) foi
feito usando a arquitectura REST.
3.3.5 - INTERPRETAÇÃO DA RESPOSTA
3.3.5.1 - BROWSER
Um browser é uma aplicação que tem como objectivo interpretar e apresentar recursos
disponíveis na World Wide Web (web) ao utilizador, recursos estes tão variados como imagens,
vídeos e páginas HTML. Estes recursos são identificados por um URI (capítulo 3.3.4), cujo prefixo
indica como o recurso irá ser interpretado e que protocolo está a ser utilizado para o pedido de dados.
Alguns dos prefixos mais utilizados são “http:” (capítulo 3.3.2), “https:” (capítulo 3.3.3), “ftp:” -
indicativo de FTP (File Transfer Protocol) [52] - e “file:” para ficheiros locais.
Uma vez recebida a informação correspondente ao pedido (response), o browser utiliza um
motor ou renderer, de modo a transformar a informação recebida num documento que será mostrado
ao utilizador. Actualmente os renderers dos browsers são tão evoluídos que conseguem mostrar
muitos dos tipo de conteúdos que sejam constituintes de páginas web.
30
Entre os browsers mais populares enumeramos o Mozilla Firefox, o Internet Explorer, o
Google Chrome, o Safari e o Opera.
3.3.5.2 - HTML - HYPERTEXT MARKUP LANGUAGE
No início deste capítulo foi dito que um cliente, tipicamente um browser, efectua pedidos
(requests) ao servidor onde está alojada a aplicação, de modo a obter informação ( response) para
apresentar ao utilizador, tipicamente páginas HTML – HyperText Markup Language [64].
Os documentos HTML ou XHTML [65], usualmente designados por páginas web, são
definidos por uma linguagem própria de modo a poderem ser interpretados pelos browsers. O XHTML
é uma restrição do HTML baseada nas regras aplicáveis para a linguagem XML.
O HTML, como o nome indica é uma linguagem de markup [12]. Existem três tipos de
linguagens de markup: de apresentação, procedimental e descritiva. O markup de apresentação é o
usado pelos processadores de texto e consiste em códigos binários inseridos no texto do documento,
de modo a alterar a sua apresentação. O markup procedimental difere do markup de apresentação
pelo facto de consistir em instruções dadas pelo próprio autor do texto, podendo estas ser editadas,
mas com o fim de alterar também a apresentação. É, por exemplo, a linguagem usada por LaTeX [41]
e PostScript [54]. O markup descritivo é usado para assinalar partes do documento, mas sem o
objectivo de serem instruções sobre a forma como deve ser processado. É o tipo do HTML.
A linguagem HTML consiste no uso de vários componentes: elementos e os seus atributos,
tipos de dados, referências de caracteres e entidades e declaração de tipo de documento (document
type declaration), de modo a que formem documentos.
Os elementos são definidos por uma etiqueta (tag) de início e uma etiqueta de fim e podem
conter atributos. O conteúdo do elemento é definido como: tudo o que está entre a etiqueta de início e
a etiqueta de fim. Uma etiqueta é definida por uma palavra reservada constante da gramática da
linguagem [15], rodeada por um sinal de menor “<” e um sinal de maior “>”.
Exemplo de um elemento com atributos: <tag attribute1=”atr1”>text to be rendered</tag>
A linguagem é também recursiva, ou seja, podem existir elementos dentro doutros elementos.
As declarações de tipo de documento indicam qual o modo de rendering que o browser deve adoptar.
No caso de HTML 5.0, é suficiente a declaração <!doctype html>. Para versões anteriores era necessário
usar a declaração em que explicitamente era definido o DTD1 (Document Type Definition), onde era
designada a linguagem.
3.3.5.3 - CSS – CASCADE STYLE SHEET
Outra das componentes do HTML é a definição de tipo de dados. Esta componente é
bastante importante para esta aplicação, dado que permite definir, entre outros, folhas de estilo (CSS
– Cascade Style Sheets [62]) e Scripts que são pequenos blocos de código (habitualmente na
linguagem JavaScript) executados no cliente.
1 Contém as definições gramaticais da linguagem.
31
A definição de estilo do documento é feita entre as tags <style> e </style>, ou através da
indicação do URL para o ficheiro que contém as definições de estilo <link rel="stylesheet" href="/style.css"
type="text/css">, habitualmente definida dentro das tags <head> e </head>, de forma a que seja
processada inicialmente pelo browser.
O uso de folhas de estilo (CSS) em documentos que sejam em linguagem de markup tem o
objectivo de descrever a semântica de apresentação, por exemplo, definindo o aspecto, cores e
fontes. Desta forma é possível separar o conteúdo do documento do seu aspecto visual.
O CSS é uma linguagem cuja gramática define uma série de regras de estilo e prioridades de
aplicação aos vários elementos constituintes de um documento.
Cada regra consiste em duas partes: selectores e propriedades. Os selectores definem a que
elementos são aplicadas as propriedades [59] cap. 2, pp. 36. Se duas propriedades iguais estiverem
definidas em duas regras diferentes é aplicada a propriedade definida pelos selectores mais
específicos do elemento.
3.3.5.4 - JAVASCRIPT
Tal como a definição de estilo, o HTML permite utilizar outros tipos de dados usados neste
projecto, como scripts. Estes são definidos em tags próprias, tal como a os estilos e poderão ser
definidos explicitamente no documento ou através da referência a um ficheiro externo. A definição no
documento é feita através do código existente entre tags <script> e </script>. A definição por referência a
um ficheiro é feita através de <script type=”text/javascript” src=”/myscript.js”></script>, que referencia o ficheiro
“myscripts.js”.
Embora possam ser codificados em várias linguagens, abordaremos apenas a linguagem
JavaScript usada no projecto para a realização destes scripts.
Como os documentos HTML são estruturados, os browsers, depois de receberem o
documento, constroem em memória uma estrutura de objectos correspondente ao documento
recebido – DOM (Document Object Model) [23], [63]. Esta estrutura de objectos é construída com o
objectivo de poder ser acedida e manipulada através de scripts incluídos nas páginas HTML.
As funcionalidades apresentadas pela linguagem JavaScript são as seguintes [29], pp. 8:
• Permitir que que os documentos respondam rapidamente à interacção do utilizador,
nomeadamente elementos de formulários, não sendo necessário comunicação com o
servidor.
• Processar informação antes desta ser submetida ao servidor.
• Modificar conteúdos e estilos dinamicamente e rapidamente em resposta à interacção
com o utilizador.
3.3.5.5 - JQUERY
O JQuery é uma biblioteca open-source de JavaScript que define uma conjunto de funções de
32
modo a facilitar as interacções entre o DOM e a linguagem JavaScript [43] cap. 1.
Algumas das funcionalidades do JQuery permitem a manipulação do DOM, gerir eventos do
browser, facilitar animações e interacções AJAX (Asyncronous JavaScript and XML) [33]. Usando
AJAX é possível, assincronamente, efectuar um pedido ao servidor em background, sem interferir
com o comportamento actualmente a ser visualizado.
3.3.5.6 - FORMULÁRIOS
Os formulários permitem a interacção, sem o uso de scripts, entre cliente e servidor [64] cap.
4.10. Estes contêm a informação dada pelo utilizador, de modo a que esta informação seja submetida
ao servidor e seja processada. Por exemplo, quando um utilizador efectua um registo num site, é-lhe
apresentado um formulário contendo vários campos que tem de preencher de modo a efectivar esse
registo.
Os formulários são definidos entre as tags HTML <form> e </form> e contêm alguns elementos
não possíveis de utilização fora dos próprios formulários.
Estes são:
• input
◦ text
◦ password
◦ checkbox
◦ radio
◦ file
◦ reset
◦ submit
• textarea
• select
Os elementos que correspondem a tags HTML são o “input”, “select” e “textarea”. Os outros
são definidos usando atributo type na tag “input”.
Estes elementos são especialmente renderizados pelos browsers, de modo a serem
apresentados de uma forma clara ao utilizador, embora o seu aspecto, como foi anteriormente
referido, seja passível de alteração através do uso de CSS, e os seus valores sejam passíveis de
serem manipulados ou validados por JavaScript.
O elemento “submit” permite que o utilizador efectue a submissão da informação inserida nos
outros elementos, por forma a que estes sejam enviados para servidor. O elemento “reset” permite
que sejam repostos os valores de origem nos vários campos do formulário.
Todos os outros elementos são elementos de recolha de informação do utilizador. Quando um
formulário é submetido pelo utilizador, o browser constrói um pedido (request) com a informação
33
constante desse formulário (método, URI, parâmetros) e envia-o para o servidor, ficando a aguardar a
resposta, de modo a apresentar o novo documento ao utilizador e todo o ciclo se repetir.
3.3.6 - LINGUAGEM DE TEMPLATING
3.3.6.1 - GERAÇÃO DE PÁGINAS DINÂMICAS
As páginas web actualmente contém uma combinação de conteúdo específico e de conteúdo
partilhado ou template material [29] cap. 1, que se encontra presente em muitas das páginas de uma
aplicação web e cujos objectivos são a formatação, navegação e branding1. Como exemplo, podemos
apresentar barras de navegação contendo links, logótipos de empresa, cabeçalhos, rodapés, menus,
informação de contacto, e cores e estilos comuns.
Não existe um único mecanismo através do qual são gerados os conteúdos partilhados pelas
páginas de um site. Alguns dos mecanismos utilizados são, por exemplo, em sites pessoais a cópia
por todas as páginas de determinados fragmentos de HTML, servidores aplicacionais que
implementam templates no próprio código, gestores de conteúdos CMS (Content Management
System) que organizam templates, como por exemplo o OpenCMS e o LifeRay desenvolvidos para
Java, ou o Django-cms desenvolvido para o Django mas com o objectivo de serem utilizados em
projectos de grande dimensão, e páginas geradas dinamicamente que encapsulam conteúdo num
template, que é o mecanismo utilizado neste projecto.
Para diversas linguagens de programação foram desenvolvidos mecanismos destinados a
gerar páginas web dinâmicas, como por exemplo JSP (Java Server Pages) [4], para Java ou
ASP.NET (Active Server Pages) [7], para a plataforma .NET da Microsoft, assim como a linguagem de
templating do Rails – ERB (Embedded Ruby) [57].
No caso específico da linguagem utilizada – Python – existem algumas linguagens de
templating desenvolvidas como por exemplo Mako, Cheetah, Myghty e Genshi. Estas linguagens de
templating para Python podem ser enquadradas com o Django de uma forma extremamente simples.
Dado que o Django nos fornece uma linguagem de templating própria, foi da nossa preferência utilizá-
la devido às seguintes vantagens apresentadas: está documentada de uma forma mais criteriosa,
será sempre alvo de evolução, dado que o Django está a ter cada vez mais aceitação como
framework web ao contrário das outras que poderão ter a sua evolução estagnada, e a sua utilização
não implicaria qualquer melhoria, quer na performance, quer em termos de clareza do código
desenvolvido.
3.3.6.2 - VANTAGENS DO USO DE TEMPLATING
O uso de uma linguagem de templating apresenta vantagens significativas [34] cap. 4, pp. 59.
É muito mais simples, mais claro e passível de facilmente efectuar manutenções, a existência de uma 1 branding ou brand management – gestão de marcas
34
separação clara entre o design da página e o código Python da aplicação, separação essa
conseguida pela utilização da arquitectura MVC (capítulo 3.1.1).
O design de uma página tende a ser alterado de forma muito mais frequente do que o código
da aplicação e por isso não seria conveniente alterar o código sempre que é necessário uma
alteração à página.
Implementar código numa aplicação e desenhar páginas HTML são duas tarefas distintas e
atribuídas a pessoas ou departamentos com competências diferentes. Desta forma, os designers não
devem ter necessidade de editar código da aplicação.
É mais eficiente se os programadores e os designers puderem simultaneamente trabalhar em
partes distintas da aplicação, em vez de ser necessário esperar que uma das tarefas esteja concluída
para iniciar outra tarefa, quando estas deviam ser realizadas paralelamente.
3.3.6.3 - SISTEMA DE TEMPLATING DO DJANGO
Uma template é um documento de texto num determinado formato escolhido onde é possível
definir zonas que contenham pequenos fragmentos de lógica ou código [34] cap. 4, pp. 50. Os
formatos poderão ser variados, embora os mais comuns sejam HTML, XML (eXtensible Markup
Language) [58], JSON (JavaScript Object Notation) [16], ou YAML (YAML Ain't Markup Language) [3].
O sistema de templating do Django foi desenhado para o formato HTML e o seu uso é quase
exclusivamente para HTML, embora estejam disponíveis funções de modo a gerar respostas HTTP
que contenham informação nos outros formatos mencionados, usados tipicamente para serializar
modelos (Capítulo 3.1.1).
A invocação de templates é feita de uma forma muito simples e intuitiva, e segue três passos
que têm de ser codificados no controlador. Primeiro, é explicitamente referido qual a template a
utilizar; de seguida são colocadas no contexto da template variáveis (de um modo geral objectos), de
forma a estarem disponíveis na mesma; e é necessário “renderizar” a página. Entende-se por
“renderizar” o processamento da template de modo a gerar a página HTML final.
3.3.6.4 - FUNCIONALIDADES
O sistema de templating do Django permite três tipos de entidades [34] cap. 4, pp. 41:
variáveis ou métodos, template tags, filtros e comentários. Qualquer texto rodeado de duplas
chavetas é avaliado como uma variável ou método.
O sistema de templating consegue, de uma forma elegante, manusear estruturas de dados
complexas e não simplesmente variáveis. Na presença do ponto “.”, é inferido que se está na
presença de uma estrutura de dados complexa. Desta forma é transparente a invocação de métodos
de um objecto (não é possível a invocação de métodos que recebam parâmetros), o uso de um dos
seus atributos, a apresentação de um valor contido num mapa (dictionary em Python) ou numa lista.
O uso de template tags é também extremamente útil. Qualquer texto entre chaveta,
35
percentagem e percentagem, chaveta é uma template tag. Estas permitem que sejam executada
alguma lógica no template. As template tags mais comuns são: “if/else”, “for”, “ifequal” e a
complementar “ifnotequal”.
Com o uso de filtros, é possível executar a formatação de variáveis dentro do template. Os
casos mais usuais de aplicação são, por exemplo, a transformação em maiúsculas ou minúsculas,
truncar uma variável demasiado extensa, e a formatação de datas. Na presença da barra vertical “|” é
aplicada à variável o filtro indicado. Os filtros podem ser também usados de forma sequencial, ou seja
podem-se aplicar vários filtros consecutivos a uma variável.
É também possível colocar comentários nos templates. Esta funcionalidade permite que o
programador coloque informações no documento, sendo esta ignorada na “renderização”. Textos que
estejam contidos entre “{#” e “#}” são sempre ignorados.
3.3.6.5 - O SISTEMA DE HERANÇA
Uma das grandes vantagens de usar o sistema de templating do Django é a possibilidade de
herança. Desta forma, conseguimos que o sistema cumpra o princípio DRY.
A utilização de herança permite-nos definir apenas partes de conteúdos de uma página, sem
ter de a redefinir múltiplas vezes. Assim é possível construir um esqueleto de página com as partes
comuns a todas as outras e definir um bloco que será redefinido pelas páginas que herdam esse
esqueleto. É também possível, do mesmo modo, na página que redefiniu o bloco anterior, voltar a
definir um novo bloco para que ainda outras páginas possam redefinir este mesmo bloco, ou seja, é
possível existirem tantos níveis de herança quanto se queira.
As vantagens proporcionadas por esta característica são a centralização de partes comuns
apenas num template, e a reutilização dessas partes comuns sem haver duplicação.
Por outro lado o sistema de herança não afecta o contexto, ou seja as variáveis populadas no
controlador estão disponíveis para todos os templates a montante do template “renderizado”.
Este comportamento é conseguido através do uso de três template tags omitidas
anteriormente de forma propositada: “include”, “extends” e “block”.
3.3.6.6 - NOTAS SOBRE O USO DE TEMPLATING
Existem algumas considerações que é necessário ter em conta para o uso adequado de
templating no Django.
A lógica de apresentação deve estar separada da lógica de negócio (modelo MVC). Neste
sentido é propositadamente impossível executar código Python dentro das templates [34] cap. 4, pp.
58.
Por outro lado, as templates são maioritariamente criadas e editadas por designers e é um
princípio o facto de não ser necessário ser programador Python para implementar templates.
O objectivo da linguagem de templating é oferecer apenas estruturas de controlo necessárias
36
para a apresentação e não ser o desenvolvimento de outra linguagem de programação, e por isso os
tipos das estruturas de controlo e as suas funcionalidades como “for” e “if” são limitadas ao essencial.
3.4 - ACESSO AO SGBD
Neste capítulo é realizada uma abordagem sobre os Sistemas de Gestão de Base de Dados,
apresentando alguns conceitos teóricos sobre como a informação é persistida.
É também abordada a forma como o Django se integra com o SGBD e é apresentada uma
comparação entre os sistemas existentes e a justificação da escolha tomada para o protótipo.
3.4.1 - DEFINIÇÃO DE SGBD
Um SGBD – Sistema de Gestão de Base de Dados – é um conjunto de informação
relacionada e de mecanismos de gestão dessa informação permitindo o seu armazenamento e o
acesso a essa mesma informação de uma uma forma eficiente [60], pp. 1. Ao conjunto de informação
relacionada damos o nome de Base de Dados.
Os principais objectivos de um SGBD são o armazenamento de grandes quantidades de
informação, a garantia de segurança da informação armazenada, quer ao nível de controlo de
acessos, quer ao nível de tolerância a falhas, a garantia de consistência da informação para acessos
concorrenciais e providenciar aos utilizadores uma abstracção para que não seja explícita a forma
como a informação é armazenada e gerida.
Um SGBD é composto por três sistemas [60] cap. 1: o gestor de transacções (transaction
manager) que garante a consistência da informação armazenada; o processador de pedidos (query
processor) que compila e executa os pedidos para gestão da informação; o gestor de armazenamento
(store manager) que proporciona uma interface entre a camada de armazenamento de dados a baixo
nível e os pedidos efectuados ao sistema.
3.4.2 - MODELOS DE DADOS
A informação numa Base de Dados é armazenada segundo um modelo de dados. Um modelo
de dados é um conjunto de ferramentas conceptuais que representam dados, relações entre dados,
semântica dos dados e a sua coerência através de restrições.
Existem vários tipos de modelos de dados como sejam o Modelo Orientado a Objectos [60]
cap. 8, o Modelo Relacional de Objectos [60] cap. 9, o modelo Entidade-Relação [8] e o modelo
Relacional [11] sendo estes dois últimos os usados para o projecto.
No modelo Entidade-Relação os dados são representados por conjuntos de entidades e são
definidas relações entre os conjuntos de entidades. Todas as coisas sobre as quais os utilizadores
pretendam ter informação deverão ser representados por um conjunto de entidades sendo as
37
relações entre esses conjuntos de entidades relações explícitas [39].
No modelo Relacional os conjuntos de entidades e as relações têm de obedecer a regras
mais restritivas. Assim, é desenvolvido primeiro o modelo Entidade-Relação e posteriormente o
modelo Relacional (capítulo 4.2.8).
Comecemos por definir o modelo Entidade-Relação e alguns dos seus elementos.
Um determinado conjunto de entidades é caracterizado pelo facto de todas as entidades
desse conjunto partilharem os mesmos atributos. Um atributo é uma propriedade descritiva que
caracteriza cada membro de um conjunto de entidades. As relações são associações entre os
conjuntos de entidades.
Determinado atributo ou conjunto de atributos permitem identificar univocamente cada uma
das entidades de um conjunto. Neste caso, o atributo ou conjunto de atributos é nomeado de chave.
Existem vários tipos de chaves. Uma super-chave é um atributo ou conjunto de atributos que nos
permitem identificar univocamente uma entidade. As chaves-candidatas são o sub-conjunto das
super-chaves que têm a propriedade de não conterem nenhum sub-conjunto de atributos que seja
também chave-candidata. Uma chave-primária é a chave-candidata escolhida pelo designer da Base
de Dados como o meio principal de identificação de uma única entidade.
Outro aspecto a ter em conta é a cardinalidade das relações, ou seja, o número de conjuntos
de entidades ao qual um determinado conjunto poderá estar associado.
Definem-se quatro tipos de cardinalidade [60] cap. 2:
• Um para Um (uma entidade A está associada no máximo a uma entidade B)
• Um para Muitos (uma entidade A está associada a nenhuma, uma ou várias entidades B)
• Muitos para Um (uma entidade A está associada no máximo a uma entidade B; esta pode
estar associada por sua vez a nenhuma, uma ou várias entidades A)
• Muitos para Muitos (uma entidade A está associada a nenhuma, uma ou várias entidades
B e uma entidade B está associada a nenhuma uma ou várias entidades A)
Definidos os pressupostos, constrói-se o diagrama Entidade-Relação seguindo os pontos:
1. Definem-se os conjuntos de entidades e os atributos que os compõem.
2. Identificam-se as relações entre os conjuntos de entidades; se necessário poder-se-á
construir uma matriz com os conjuntos de entidades em linhas e colunas de modo a
explicitar os conjuntos relacionados nas intersecções.
3. Definem-se as chaves-primárias dos conjuntos de entidades.
4. Constrói-se um diagrama intermédio contendo os conjuntos de entidades e as relações.
5. Definem-se as cardinalidades das relações.
6. Constrói-se o diagrama final contendo toda a informação anteriormente definida.
Tendo o modelo Entidade-Relação definido, estão reunidas as condições para derivar deste, o
modelo Relacional. O modelo Relacional é o modelo mais utilizado pelas aplicações actuais. Ao
contrário do modelo Entidade-Relação, não é um modelo conceptual, mas um modelo de
38
implementação. Dadas as semelhanças entre estes modelos e a possibilidade de, para a grande
maioria dos casos, se poder derivar o modelo Relacional do modelo Entidade-Relação, optou-se por
construir primeiro o modelo Entidade-Relação e a partir deste o modelo Relacional, que é o utilizado
neste projecto.
O modelo Relacional permite representar informação de uma forma muito simples, mas muito
poderosa, assente em álgebra relacional [60] cap. 3. A álgebra relacional serve como base para o uso
de linguagens user-friendly como o SQL (Structured Query Language) [6], alvo de análise posterior.
Uma Base de Dados relacional consiste num conjunto de tabelas. Cada tabela representa um
conjunto de entidades, exactamente o mesmo conjunto de entidades definido no modelo Entidade-
Relação. Uma linha numa tabela representa uma relação entre um conjunto de valores. Como uma
tabela é um conjunto dessas relações, há uma correspondência entre o conceito de tabela e o
conceito matemático de relação, donde modelo Relacional herda o nome.
Eis algumas regras do modelo Relacional:
• Uma relação é definida por uma tabela bidimensional em que as linhas representam
entidades (instâncias) e as colunas representam os atributos.
• Não podem existir duas linhas numa tabela com exactamente os mesmos valores em
todas as colunas; porém, a ordem das linhas não é relevante.
• Cada coluna numa tabela deve ter um nome único; a ordem das colunas não é relevante.
• Cada tabela deve ter uma chave, dado que não podem existir duas linhas que contenham
exactamente os mesmos valores em todas as colunas, ou seja não podem existir linhas
repetidas numa tabela.
• Cada coluna da tabela deve apenas depender da sua chave e não de outras colunas da
tabela.
Deve-se ainda definir o que é uma chave-estrangeira. Quando uma tabela “t1” inclui um
atributo que é uma chave-primária de outra tabela “t2”, este atributo tem o nome de chave-estrangeira
de “t1” referenciando “t2”.
Assim, iremos apresentar os passos a seguir de modo a transformar o modelo Entidade-
Relação no modelo Relacional:
1. Identificar os atributos e a chave-primária para cada um dos conjuntos de entidades do
modelo Entidade-Relação, tendo em conta as regras do modelo Relacional anteriormente
apresentadas.
2. Agrupar as tabelas (conjuntos de entidades) e as suas relações, que tenham uma
cardinalidade de Um para Um ou Um para Muitos. A chave-primária da tabela para a qual
a cardinalidade é Um deve tornar-se chave-estrangeira da outra tabela.
3. Nas relações de cardinalidade Muitos para Muitos, é criada uma nova tabela que exprime
a relação. Assim, uma relação com cardinalidade Muitos para Muitos é transformada
numa nova tabela com uma cardinalidade de Um para Muitos de cada um dos lados das
novas relações entre as duas anteriores tabelas e a criada. As chaves-primárias das duas
39
tabelas da relação de Muitos para Muitos deverão formar a chave-primária composta da
nova tabela.
Desta forma obtemos o modelo Relacional que vai ser o modelo de dados que vai guardar a
informação a persistir na Base de Dados.
Os modelos Entidade-Relação e Relacional do projecto são discutidos no capítulo 4.2.8.
3.4.3 - LINGUAGEM DE BASE DE DADOS RELACIONAL
Para a interacção com o SGBD é necessário utilizar a linguagem SQL. Embora hajam muitas
linguagens de interacção com o SGBD, o SQL é a linguagem especialmente conceptualizada para o
acesso a Bases de Dados Relacionais.
A linguagem SQL pode ser dividida em dois tipos: o DDL (Data Definition Language) e o DML
(Data Manipulation Language).
O DDL define o esquema da Base de Dados. O esquema é o nome dado ao conjunto das
tabelas e restrições para manter a coerência dos dados que definem o modelo Relacional.
O DDL inclui comandos para a manipulação de várias valências da Base de Dados. Poder-se-
ão criar, modificar e apagar esquemas, adicionar, modificar ou apagar relações (através das
restrições de coerência), definir direitos de acesso, vistas e especificar o início e o fim de transacções.
As vistas são definidas por qualquer relação que não faz parte do modelo Relacional, sendo
apresentada ao utilizador como uma relação virtual. Um conjunto de atributos pertencentes a uma ou
várias tabelas é considerado uma vista, ficando o utilizador com a percepção de que se trata de uma
tabela no modelo. Poder-se-ão também definir vistas sobre outras vistas, caso seja necessário.
Uma transacção é uma colecção de operações na Base de Dados que formam uma unidade
lógica de trabalho e que partilham das seguinte propriedades: ou todas as operações são executadas,
ou nenhuma é executada, é sempre preservada a consistência da Base de Dados, cada transacção
não é afectada por outras transacções em execução, e depois de uma transacção ser executada com
sucesso, as alterações devem ser persistidas, mesmo que hajam falhas no sistema. Um SGBD deve
assegurar o correcto processamento de transacções, de forma concorrencial e tolerante a falhas.
O DML é o conjunto de todos os comandos que permitem a pesquisa e manipulação dos
dados numa Base de Dados, ou seja a manipulação de entidades. Entre as operações possíveis
temos a pesquisa, a adição de dados (novas entidades), a alteração de dados (alteração de um ou
mais atributos numa entidade) e a possibilidade de apagar entidades, recordando que cada entidade
corresponde a uma linha de uma tabela e o conjunto de entidades à própria tabela.
3.4.4 - DJANGO – CAMADA DE ACESSO AO SGBD
O Django apresenta um conjunto de ferramentas de acesso ao SGBD e está dotado de
middleware de acesso ao SGBD que permite a abstracção do uso de SQL para executar operações
40
sobre a Base de Dados. Também são geridos as acessos ao SGBD e é permitida a utilização de
qualquer um dos SGBD mais comummente utilizados para aplicações, como é o caso do Oracle,
MySQL e PostgeSQL, de uma forma transparente e uniforme.
No caso do MySQL (o SGBD escolhido para este projecto), o Django utiliza a biblioteca de
acesso “MySQLdb” para Python que disponibiliza uma interface para executar DDL e DML.
De modo a encapsular as operações necessárias à manipulação da Base de Dados, o
Django, na classe abstracta “model” define uma série de métodos que permitem realizar a quase
totalidade das operações, sendo convertidos para linguagem SQL e depois executados. Caso
porventura seja necessário efectuar alguma operação mais complexa é possível executar
directamente operações em SQL.
O Anexo A – Operações básicas sobre o SGBD contém alguns exemplos de operações sobre
o SGBD.
3.4.5 - ESCOLHA DE SGBD
O Django, como já foi referido está desenhado de modo a possibilitar a utilização de alguns
SGBD. Os SGBD suportados (built-in) são: Oracle, MySQL, PostgreSQL e SQLite. Assim a escolha
teria necessariamente de ser um de entre os apresentados.
O SGBD Oracle seria o SGBD de eleição, dadas as possibilidades de escalabilidade e
segurança dos dados, bem como a sua utilização pelas grandes empresas um pouco por todo o
mundo. Apresenta todavia uma grande desvantagem relativamente aos outros. Foram utilizados para
este projecto componentes gratuitos (freeware). O SGBD Oracle na sua versão limitada Oracle XE
(Express Edition), possui a maior parte das funcionalidades da Standard Edition, mas a sua Base de
Dados está limitada a quatro GigaBytes.
Por seu turno o SQLite não é aconselhado para ambientes de produção, tem um défice de
performance e escalabilidade e não possui gestão de utilizadores. Seria todavia uma alternativa
apropriada como SGBD de testes ou para etapas de desenvolvimento, dado que consome menos
recursos que o MySQL ou o PostgreSQL e o processo de instalação é mais simples.
A escolha entre os SGBD MySQL e PostgreSQL é uma escolha difícil, já que são os dois
SGBD open-source mais usados. O MySQL apresenta a estabilidade e a velocidade como qualidades
principais e o PostgreSQL apresenta o maior número de funcionalidades, sendo que os dois SGBD
convergem nestes parâmetros à medida que são disponibilizadas novas versões de cada um dos
produtos.
A escolha recaiu sobre o SGBD MySQL, apenas devida à maior experiência do autor com
este Sistema de Gestão de Base de Dados.
41
4 - TRABALHO DESENVOLVIDO
Este capítulo detalha todo o trabalho efectuado para a obtenção do protótipo do site de
emprego. É inicialmente apresentada a infra-estrutura utilizada, seguida da aplicação desenvolvida.
É também abordada a estrutura e localização dos ficheiros do protótipo, e é descrito em
detalhe o algoritmo utilizado para a classificação de perfis e ofertas.
4.1 - INFRA-ESTRUTURA
O objectivo deste capítulo é a apresentar em detalhe todos os componentes necessários para
o processamento dos pedidos e as camadas onde esse processamento é efectuado. No final do
capítulo é ainda abordado o sistema operativo utilizado.
4.1.1 - ARQUITECTURA
O projecto foi desenvolvido por forma a poder escalar com facilidade (scalability), ser
tolerante a falhas (fault-tolerance) e permitir balanceamento de carga (load-balancing). Deste modo,
foi desenvolvida uma arquitectura de componentes que garante os três pressupostos anteriores.
Uma vez em ambiente de produção, existem algumas considerações a ter em conta de modo
a maximizar o tempo de disponibilidade da aplicação, prever a falha de uma máquina e garantir
tempos de resposta aceitáveis para uma aplicação web.
Durante o desenvolvimento foi usado o servidor de desenvolvimento do Django, que é um
servidor web muito simples, disponibilizado com o objectivo único de optimizar o tempo de
desenvolvimento. Algumas das suas características são um tempo de arranque muito reduzido e a
detecção de alterações ao código da aplicação, não sendo por isso necessário parar e recomeçar o
servidor sempre que é efectuada uma alteração. Contudo, este servidor apresenta algumas
limitações, não sendo o seu uso aconselhado em produção. Estas são a fiabilidade, e o facto de
apenas poder servir um pedido de cada vez, ou seja, não suporta pedidos concorrenciais.
A arquitectura para uso da aplicação em produção foi equacionada de modo a haver várias
camadas de servidores, permitindo o uso de clustering [67] em cada camada, por forma a que os
pressupostos anteriormente enumerados fossem cumpridos. Todavia, devido a restrições de ordem
financeira, é natural que a complexidade inicial não seja a que aqui será apresentada, mas com o
aumento de carga decorrente do uso cada vez mais intensivo da aplicação ao longo do tempo, a
arquitectura tenderá a evoluir neste sentido. Todavia esta estrutura foi testada, embora apenas numa
máquina com várias instâncias de cada um dos componentes, por forma a garantir a sua validade.
A arquitectura consiste numa separação em três camadas de servidores, tendo cada camada
a sua função. A camada inicial destina-se a receber os pedidos vindos da internet, ou seja, pedidos
efectuados pelos browsers à aplicação. Haverá um servidor que receberá os pedidos (poderá ser
42
qualquer um nesta camada), balanceando a carga para si próprio e para os outros servidores da
mesma camada, não efectuando neste passo qualquer tipo de processamento.
Depois do balanceamento, o pedido será então processado. Se for conteúdo estático, como
por exemplo documentos HTML estáticos, imagens, ficheiros JavaScript, folhas de estilo e qualquer
outro tipo de ficheiro de texto ou binário não dinâmico, este deverá ser logo servido e não enviado à
camada seguinte. Será decidido nesta camada, que pedidos serão logo servidos e quais os que
deverão passa à camada seguinte.
Se for decidido que o pedido não é logo servido, este é enviado à camada contendo a
aplicação. Esta camada irá efectuar o processamento do pedido, se necessário usando informação
constante na sua própria instância de cache, e se necessário também, contactando a camada
seguinte, ou seja a camada que contém a Base de Dados. Depois de processado o pedido pela
camada que contém a aplicação, este é devolvido à camada anterior já processado, retornando ao
cliente (browser).
A Figura 13 apresenta o esquema do fluxo tal como explicado.
É apresentada na Figura 13 uma arquitectura com dois servidores em cada camada como
exemplo, mas é possível em qualquer altura acrescentar mais servidores em qualquer das camadas,
dependendo obviamente da carga a que essa camada possa a vir a estar sujeita. Poderá também
43
Figura 13: Arquitectura de produção da aplicação
acontecer que uma camada contenha apenas um servidor devido a razões de ordem financeira, mas
neste caso perde-se a tolerância a falhas e o balanceamento de carga nessa camada.
Os componentes de cada uma das camadas serão analisados com maior detalhe nos
próximos sub-capítulos.
4.1.2 - SERVIDOR HTTP
O servidor HTTP desempenha um papel fundamental na arquitectura apresentada. É este
servidor que como já foi referido recebe todos os pedidos feitos pelos clientes e os serve
directamente ou os direcciona para o servidor aplicacional.
O servidor escolhido para este efeito foi o servidor HTTP da Apache versão 2.2, por ser a
última versão estável disponível. Em comparação com outros servidores HTTP, como o Lighttp, ou o
Microsoft IIS, o servidor Apache apresenta como vantagens a sua modularidade, facilidade de
configuração e facilidade de integração com o Django, sendo também o servidor HTTP open-source
mais popular. Sendo um servidor vocacionado para ambientes de produção, dado que foi
desenvolvido com o intuito de proporcionar um elevado desempenho, foi a nossa escolha para o
projecto, aliado ao facto de ser o servidor HTTP com o qual o autor está mais familiarizado e ao facto
de haver maior documentação disponível para a integração com o Django.
Outras características importantes deste servidor são a possibilidade de implementação de
segurança, incluindo o uso de certificados digitais conforme discutido nos capítulos 3.3.2 e 3.3.3,
virtual hosting1 e a possibilidade de implementação, através de configuração, de load-balancing entre
várias instâncias do servidor.
4.1.3 - SERVIDOR APLICACIONAL
O servidor aplicacional usado foi também o servidor HTTP Apache 2.2, já anteriormente
referido mas complementado com um dos seus módulos, o “mod_wsgi”, sendo a sua função servir a
aplicação desenvolvida. Este módulo implementa a interface WSGI - Web Server Gateway Interface,
que é uma especificação para servidores web e servidores aplicacionais comunicarem com
aplicações web desenvolvidas em Python [20]. O objectivo do desenvolvimento da WSGI foi
proporcionar uma especificação standard passível de interpretar todas as interacções entre um
servidor e uma framework para aplicações web. Assim foi necessário usar o suporte dado pelo
Django de modo a transformar a aplicação numa aplicação WSGI [34] cap.12, pp. 222.
Poder-se-ia também usar o “mod_python” do servidor HTTP Apache 2.2, embora a
configuração necessária fosse mais complexa, e o uso de memória para a mesma aplicação não seja
tão optimizado.
Outra possibilidade seria o uso de um outro interpretador da linguagem Python, ou seja, o
1 Uso de vários domínios com um único endereço IP.
44
Jython. O Jython [36] é uma implementação de Python que é executada na plataforma Java1. Assim
poder-se-ia usar um servidor aplicacional que fosse um servlet container, como o Apache Tomcat [5].
Todavia não foi escolhida esta opção, devido ao facto do Jython não estar ainda num grau de
desenvolvimento equivalente ao interpretador de Python.
4.1.4 - SGBD
O SGBD, já analisado em detalhe no capítulo 3.4, pertence à camada com a qual o servidor
aplicacional interage e onde é persistida toda a informação do sistema. Assim, é de vital importância,
para uma aplicação a funcionar em ambiente de produção, o uso de um SGBD que permita
clustering, de modo a que também nesta camada sejam cumpridos os pressupostos enunciados no
capítulo 4.1.1. Esta solução é possível de implementar usando o software de clustering específico
para o SGBD MySQL (MySQL Cluster)2.
A escolha do SGBD já foi abordada anteriormente no capítulo 3.4.5.
4.1.5 - MEMCACHED
O Memcached é um software open-source que implementa um sistema de cache distribuída
usando a memória da máquina onde a instância de cache está a ser executada. Esta cache funciona
como um “saco” de pares chave/valor sendo por isso vocacionada para alojar pequenos fragmentos
de informação. Relativamente a outros sistemas de cache, apresenta as seguintes vantagens: o facto
de ser distribuída, permitindo várias instâncias (ver Figura 13) em várias máquinas diferentes sendo a
replicação gerida pela própria aplicação, é facilmente integrável com o Django, dado que este tem já
integrado middleware para gestão de Memcached, e o facto de o armazenamento ser feito em
memória, o que se traduz numa alta rapidez de gestão da informação guardada.
Neste projecto, o sistema de cache distribuída foi usado para partilhar as sessões de
utilizadores entre as várias instâncias dos servidores que alojam a aplicação. Estes servidores não
comunicam entre si, e deste modo não têm a informação de sessão (capítulo 4.2.4) de um utilizador
se uma série de pedidos foi servido por outro servidor que aloja a aplicação.
Dado que a informação de sessão é a única informação que é necessária partilhar no projecto
entre as várias instâncias de servidores que servem a aplicação, usou-se o Memcached para efectuar
essa partilha.
Caso a carga sobre os SGBD, em determinada altura, seja alta pode-se usar também o
Memcached como um sistema de apoio ao SGBD para alojar informação guardada na Base de
Dados que seja pouco alterada ao longo do tempo, mas solicitada em muitos pedidos, de forma a
aliviar o SGBD dessa carga e melhorar o tempo de resposta.
1 Java JVM (Java Virtual Machine)2 O sistema de clustering do MySQL não foi testado neste projecto.
45
4.1.6 - SISTEMA OPERATIVO
Este projecto foi desenvolvido no sistema operativo Microsoft Windows Vista. Devido à
grande portabilidade da linguagem de programação utilizada, da framework web utilizada (Django), e
dos vários componentes utilizados, anteriormente enumerados, é possível executar a aplicação e
todos os seus componentes em sistemas operativos que não o Windows, como por exemplo qualquer
distribuição recente de Linux, Mac OS ou Solaris, bastando para o efeito algumas alterações na
configuração quer da aplicação em si, quer de alguns dos seus componentes.
Durante o desenvolvimento deste projecto, houve sempre alguma atenção em permitir que
não fosse dependente do sistema operativo, quer no seu desenvolvimento, quer na sua utilização
num ambiente de produção.
4.2 - A APLICAÇÃO
Neste capítulo é abordado em concreto o protótipo desenvolvido, sendo inicialmente
explicada a motivação pela qual foram definidas as entidades do modelo de dados, seguida da
descrição de todas as funcionalidades disponíveis para os utilizadores e a sua implementação. São
também apresentadas algumas particularidades desenvolvidas e são ao longo do capítulo discutidas
as decisões tomadas.
4.2.1 - ENTIDADES E RELAÇÕES
Para que toda a informação necessária ao funcionamento da aplicação seja guardada e
utilizada de uma forma coerente é necessário definir um conjunto de entidades e também as relações
que existem entre essas mesmas entidades.
Sendo uma aplicação web, esta irá ser acedida por um conjunto de utilizadores. A primeira
entidade definida é o user (Tabela 14). Um user é qualquer utilizador que através de um cliente acede
a recursos da aplicação. Um user é definido de forma a que seja possível efectuar a autenticação e
autorização dos utilizadores para que acedam a determinados recursos da aplicação, contendo
também alguma informação sobre o registo, nomeadamente datas relevantes dos seus percursos
como utilizadores e ainda indicadores do seu tipo e estado.
Os vários utilizadores vão ser tipificados segundo o tipo de recursos que terão disponíveis.
Estes podem ser anónimos, candidatos ou empregadores. Um utilizador anónimo é o utilizador que
não é candidato nem empregador e tem apenas acesso a secções muito restritas da aplicação
(capítulo 4.2.2).
Para o utilizador ser candidato ou empregador, terá de efectuar um registo na aplicação
(capítulo 4.2.3), inserindo alguns dados, de modo a que seja tipificado. Assim, foi necessário definir
mais duas entidades que correspondem aos utilizadores tipificados: candidate e company. A entidade
candidate contém informação geral sobre o próprio candidato (Tabela 15), nomeadamente os seus
dados pessoais.
46
Um candidato pode ter perfis, ofertas modelo, ofertas marcadas, ofertas respondidas e
antigos empregos. Assim foram definidas as entidades candidateprofile (Tabela 20),
candidatemodeloffer (Tabela 29), candidatebookmarkedoffer e candidateappliedoffer. O perfil do
candidato contém a informação relevante do seu currículo que irá ser disponibilizada para consulta
pelos empregadores. O candidato pode também definir os seus antigos empregos, ao que
corresponde a entidade candidateoldjob (Tabela 26).
Ao perfil do candidato estão associados cursos profissionais, tecnologias e funções
desempenhadas (Tabela 25, Tabela 24, Tabela 19). Estes correspondem às entidades definidas
candidateprofessionalcourse, candidateareamaintechnology e candidateareamainfunction.
É ainda possível ao candidato, através da consulta de lista de ofertas ou da pesquisa de
ofertas, marcar ofertas existentes que considere relevantes ou responder a essas ou a outras ofertas.
Para esse efeito foram criadas as entidades candidatebookmarkedoffer (Tabela 16) e
candidateappliedoffer (Tabela 21).
O candidato pode ainda definir ofertas modelo para efectuar pesquisas através do algoritmo
de classificação. Para esse efeito foi definida a entidade candidatemodeloffer também associada ao
candidato. Esta entidade é constituída pelos atributos definidos na Tabela 29, semelhante à entidade
companyoffer, com excepção do nome, do endereço, e da descrição de emprego, que são atributos
não necessários para a utilização do algoritmo de classificação.
Um utilizador empregador é definido pela entidade company, que contém os atributos
definidos em Tabela 17. Tal como o candidato, esta entidade contém informação sobre o
empregador, nomeadamente os dados da empresa.
Um empregador pode inserir ofertas, marcar perfis de candidatos, responder a perfis de
candidatos e também definir perfis modelo, de modo a poder efectuar pesquisas através do algoritmo
de classificação de perfis. Nesse sentido foi necessário criar as entidades companyoffer (Tabela 22),
companybookmarkedprofile, companyappliedprofile e companymodelprofile.
A entidade companyoffer contém a informação relevante sobre ofertas de emprego inseridas
pelos empregadores, informação essa que irá ser disponibilizada para consulta dos candidatos. De
modo a que um empregador tenha a possibilidade de marcar perfis de candidatos que considere
relevantes, foi criada a entidade companybookmarkedprofile (Tabela 27), assim como a entidade
companyappliedprofile (Tabela 30), criada para que o empregador possa responder a perfis de
candidatos e consultar a informação de quais os perfis de candidatos respondidos.
A entidade companymodelprofile contém os atributos descritos na Tabela 29, muito
semelhantes aos da entidade candidateprofile, com excepção de nome do perfil e descrição do
emprego oferecido, que são atributos não necessários para procuras através da utilização do
algoritmo de classificação e permite definir perfis modelo, de modo a que sejam efectuadas procuras
através do algoritmo de classificação de perfis.
Foram ainda definidas outras entidades relevantes para a classificação de candidatos, perfis,
empregadores e ofertas. De modo a agilizar as procuras, e a segmentar os perfis e ofertas foi
necessário criar outras entidades, que embora não contenham informação muito relevante, permitem
47
classificar de uma forma mais eficaz, quer candidatos, quer empregadores, e ainda perfis e ofertas.
Assim foram criadas as entidades país (country) - Tabela 23, cidade (city) - Tabela 28,
emprego (job) - Tabela 37, área profissional (jobarea) - Tabela 36, universidade (university) - Tabela
31, curso superior (academiccourse) - Tabela 34 e grau académico (academicdegree) - Tabela 35.
Estas entidades foram criadas para uniformizar estes atributos, por forma a que não hajam
ambiguidades indesejáveis no preenchimento dos mesmos. Assim quando um candidato está a
efectuar o seu registo ou a alterar os seus dados, terá a hipótese de seleccionar, por exemplo, um de
entre os países definidos, bem como, dependendo do país, uma de entre as cidades apresentadas.
Por outro lado, quando, por exemplo, um empregador está a inserir uma nova oferta, terá a
possibilidade de escolher o grau académico de entre uma lista de graus académicos possíveis,
dependentes do país.
Desta forma, consegue-se, nestes campos muitas vezes ambíguos e, caso fosse dada a
opção aos utilizadores de inserirem textualmente estes elementos, que estes estejam concretamente
definidos, tornando fiável o resultado das procuras através destes elementos.
Dado que alguns dos elementos destas entidades podem ter uma relação de semelhança
entre si, foram criadas entidades que traduzem numericamente essa mesma semelhança, de modo a
que as pesquisas sejam mais aproximadas ao pretendido. Por exemplo, para um empregador que
defina uma oferta contendo um determinado emprego oferecido, seria interessante serem também
apresentados os resultados de empregos que, embora não sejam especificamente o pretendido,
apresentam um elevado grau de semelhança.
Assim, foram criados os seguintes modelos que quantificam graus de semelhança entre
algumas das entidades referidas anteriormente: universitysimilarity (Tabela 38),
academicdegreesimilarity (Tabela 40), universitycoursesimilarity (Tabela 39), jobareasimilarity (Tabela
41) e jobsimilarity (Tabela 32).
Estes contêm a informação da semelhança existente entre as várias instâncias dessas
entidades. Respectivamente, universitysimilarity traduz as semelhanças existentes entre
universidades, academicdegreesimilarity traduz a semelhança existente entre graus académicos,
universitycoursesimilarity traduz a semelhança existente entre dois cursos, jobareasimilarity traduz a
semelhança entre áreas profissionais e jobsimilarity traduz a semelhança entre empregos.
Se não estiver definida a semelhança entre duas das instâncias dessa entidade, é
considerado que não existe qualquer semelhança entre elas.
Por fim, foi também criada a entidade authenticationticket (Tabela 18), destinada a guardar
informação para o correcto desempenho do processo de registo dos vários utilizadores,
nomeadamente para guardar tokens, bem como o seu estado, datas de criação, uso e expiração, se
existirem (capítulo 4.2.3).
4.2.2 - DESCRIÇÃO DOS RECURSOS DA APLICAÇÃO
A aplicação disponibiliza uma página inicial que qualquer utilizador poderá visualizar e onde
48
são apresentadas as últimas ofertas colocadas pelos empregadores, assim como uma indicação do
total de candidatos, empregadores, perfis inseridos pelos candidatos e ofertas inseridas pelos
empregadores.
Nesta página inicial, os utilizadores poderão efectuar o seu registo, quer como candidatos,
quer como empregadores. Poderão também efectuar a sua autenticação, caso já tenham efectuado o
registo anteriormente.
Se o endereço da aplicação (URL) for http://myapp.com, e o endereço correspondente a um
determinado recurso for http://myapp.com/index, entende-se por caminho relativo do recurso a
componente /index. Assim a página inicial estará disponível no endereço relativo “/”, o que significa que
se um utilizador colocar no browser o endereço http://myapp.com/ ou http://myapp.com, acederá a esta
página inicial. De ora em diante serão apenas referidos os caminhos relativos dos recursos.
Caso o utilizador efectue a sua autenticação correctamente (indicando o seu username e
password), ou efectue um novo registo, será redireccionado para o caminho relativo /candidate ou
/company correspondente ao tipo de utilizador. Caso o utilizador não seja autenticado, permanecerá na
mesma página sendo indicada através de uma mensagem de erro a razão pela qual não foi possível
a autenticação.Se um utilizador pretender aceder a um recurso para o qual não tem autorização, será
também redireccionado para esta página. Como exemplo, podemos apresentar um candidato que
pretenda aceder a um recurso de um empregador.
Se o utilizador for um candidato, será apresentada uma lista resumida das últimas ofertas de
emprego inseridas por empregadores, sendo também apresentada uma lista de acções possíveis de
executar através de um menu com diversas opções.
Na lista resumida de ofertas, o candidato terá, em cada uma das ofertas, a possibilidade de
visualizar a oferta em detalhe, ou guardar a oferta como oferta marcada. As opções disponíveis são:
voltar para esta página, visualização de dados pessoais, editar dados pessoais, alterar password,
inserir novo perfil, listar os perfis já inseridos, listar os perfis respondidos por empregadores, ver as
últimas ofertas (em detalhe), listar as ofertas marcadas, listar as ofertas que respondeu, pesquisar
ofertas, inserir ofertas modelo, listar as ofertas modelo inseridas e listar sub-conjuntos de ofertas
pesquisadas. Cada uma destas acções irá ser abordada em detalhe.
Uma das acções possíveis é a visualização dos seus dados pessoais bem como a
visualização dos empregos exercidos. Se não estiverem especificados nenhuns empregos exercidos,
haverá a possibilidade de inserir novos empregos exercidos. Caso hajam empregos exercidos já
introduzidos, haverá a possibilidade de acrescentar novos empregos exercidos, bem como editar ou
apagar os existentes.
Outra das acções possíveis é a edição dos dados pessoais. Neste caso o candidato poderá
modificar os seus dados pessoais, introduzidos quando é efectuado o seu registo como candidato. O
candidato tem também a possibilidade de efectuar a alteração da sua password, caso assim o
pretenda.
Outra opção disponível é a inserção de um novo perfil. Neste caso é solicitado o
preenchimento de alguns dados necessários para a introdução de um novo perfil, de modo a que
49
fique disponível para a pesquisa e visualização pelos empregadores. Os dados necessários são os
que constam na Tabela 20. O candidato terá também a possibilidade de seleccionar, para alguns
destes campos, qual a visibilidade que estes terão para o empregador.
Para a visualização dos perfis inseridos, existe uma opção para listar os perfis do candidato.
São apresentados em detalhe os vários perfis inseridos havendo a possibilidade de editar ou apagar
cada um deles. O detalhe dos perfis inseridos inclui também opções para acrescentar a cada um dos
perfis cursos profissionais frequentados, tecnologias que o candidato domine e funções exercidas e,
se existirem alguns destes elementos já inseridos, a possibilidade de editá-los ou apagá-los.
Outra das opções disponíveis para o candidato é a possibilidade de listar quais dos seus
perfis foram respondidos por empregadores. Aqui, o candidato poderá ver por perfil quais os
empregadores que responderam a um determinado perfil, tendo acesso às ofertas inseridas por esse
empregador. Foi criada também uma opção para disponibilizar ao candidato uma listagem detalhada
das últimas ofertas inseridas, podendo o candidato ver o detalhe completo da oferta, marcar a oferta
ou responder à oferta. Neste caso, o empregador será informado através de email da resposta do
candidato a essa oferta.
Outra das opções apresentadas, possibilita ao candidato a visualização da lista de ofertas
marcadas. Aqui haverá a possibilidade de ver o detalhe completo da oferta, desmarcar a oferta ou
ainda responder à oferta, sendo o empregador notificado através de email. Da mesma forma, o
candidato tem a possibilidade de visualizar as ofertas por ele respondidas, podendo ver o detalhe
completo da oferta e remover a resposta dada.
Para efectuar pesquisas o candidato tem duas opções. Ou efectua uma pesquisa de ofertas
por critério, seleccionado a pesquisa de ofertas, ou efectua uma pesquisa usando o algoritmo de
classificação. Ao seleccionar pesquisa de ofertas, são apresentados os critérios de pesquisa através
dos quais é possível efectuar a pesquisa, bem como a possibilidade de seleccionar por que critérios
será efectuada essa pesquisa. Para efectuar a pesquisa basta pressionar o botão para pesquisar e
será apresentada uma lista de ofertas que correspondem aos critérios seleccionados.
Para a pesquisa utilizando o algoritmo de classificação, o candidato deverá através da opção
de inserção de ofertas modelo, definir uma ou mais ofertas que correspondam à oferta procurada. De
seguida, através da opção existente para a listagem das ofertas modelo, poderá, por cada uma,
efectuar uma pesquisa por ofertas de empregadores que tenham maior semelhança com as ofertas
modelo inseridas, sendo apresentada uma listagem com as ofertas existentes possuindo maior
semelhança relativamente à oferta modelo escolhida para efectuar a pesquisa, podendo esta lista ser
guardada para se efectuarem novas pesquisas apenas neste sub-conjunto de resultados. É também
nesta listagem de ofertas modelo que o candidato tem a possibilidade de editar ou apagar cada uma
das ofertas modelo inseridas. O candidato tem também a possibilidade de visualizar os sub-conjuntos
guardados de ofertas pesquisadas.
Se o candidato optar por sair da aplicação, deverá usar a opção logout de modo a invalidar a
sessão e ser redireccionado para a página inicial.
No caso de o utilizador ser um utilizador empregador, depois da devida autenticação é
50
apresentada uma página contendo uma lista resumida dos últimos perfis inseridos por candidatos,
assim como um menu com diversas opções. Serão apresentadas de seguida em detalhe as várias
opções disponíveis.
A lista resumida de perfis permite que, para cada um dos perfis apresentados, haja a
possibilidade de ver em detalhe cada um dos perfis, bem como marcar os que terão interesse para o
empregador. A primeira opção do menu permite que seja novamente apresentada esta lista de perfis
resumida. O empregador tem também a possibilidade de ver os seus dados, inseridos durante o
processo de registo. Ao visualizar os dados tem a possibilidade de efectuar a sua alteração. Existe
também no menu uma opção para realizar a alteração dos mesmos, assim como a alteração da
password.
O empregador, tal como o candidato tem a opção de inserir novos perfis, pode inserir novas
ofertas. Neste caso tem de preencher alguns campos necessários à introdução da oferta e poderá
seleccionar, em alguns campos, qual a visibilidade para os candidatos dos mesmos.
Para visualizar a lista de ofertas inseridas existe também uma opção no menu. Neste caso é
apresentada uma lista detalhada com essas ofertas e com a possibilidade de, em cada uma, editar ou
apagar. Outra das opções disponíveis é a lista de ofertas respondidas por candidatos. Neste caso são
apresentados, por oferta, quais os candidatos que responderam a cada uma, com a possibilidade de
ver em detalhe os perfis de cada candidato, bem como a possibilidade de efectuar um contacto com o
candidato por email.
O empregador pode também, através de outra opção do menu, listar com maior detalhe os
últimos perfis inseridos por candidatos, tendo, para cada um destes, a possibilidade de ver o detalhe
completo, marcar o perfil ou responder ao perfil.
Existe uma opção para listar todos os perfis marcados, com a possibilidade de, para cada um
dos perfis marcados, ver todos os perfis inseridos por esse candidato, ver o perfil em detalhe,
desmarcar o perfil ou responder ao perfil. Da mesma forma, é possível ver a lista de perfis
respondidos, tendo este as opções de visualização de detalhe completo do perfil e remoção da
resposta dada.
Para efectuar pesquisas, tal como o candidato, o empregador tem duas opções. A pesquisa
por critérios e a pesquisa usando o algoritmo de classificação. Se o empregador efectuar a pesquisa
por critérios, é apresentada uma lista dos critérios pelos quais é possível pesquisar e permitida a
selecção individual desses critérios. Escolhendo a opção de pesquisar, são apresentados os perfis
que correspondem a esses critérios de pesquisa, com a possibilidade de, tal como na lista dos últimos
perfis, efectuar a marcação e responder a cada um dos perfis.
Caso o empregador opte por pesquisar pelo algoritmo de classificação, deverá usar a opção
de inserir perfil modelo do menu de modo a designar um ou mais perfis que sejam muito aproximados
aos perfis procurados. Assim, acedendo à opção para listar os perfis modelo poderá, por cada um dos
perfis modelo inseridos, pesquisar perfis inseridos por candidatos, classificados por ordem de maior
semelhança com o perfil modelo inserido. Na lista resultante da pesquisa é possível marcar perfis,
responder a perfis e guardar o sub-conjunto de perfis apresentado, de modo a efectuar novas
51
pesquisas nesse sub-conjunto. Na lista apresentada existe também a possibilidade de editar ou
apagar cada um dos perfis modelo inseridos. É ainda apresentada uma opção para listar os
subconjuntos de perfis guardados decorrentes de pesquisas.
Tal como o candidato, o empregador deverá usar a opção logout para sair da aplicação.
4.2.3 - REGISTO DE UTILIZADORES
O registo de utilizadores é habitualmente uma área sensível de uma aplicação, porque exige
algumas regras de segurança de modo a garantir a segurança e confidencialidade dos dados
fornecidos pelo utilizador, isto porque, normalmente neste processo, são transmitidos dados sensíveis
como dados pessoais dos candidatos ou dados de empregadores, bem como a definição das
credenciais de acesso (username e password).
Deste modo, foi usado para esta transferência de dados o protocolo HTTPS (capítulo 3.3.3)
que garante a segurança e confidencialidade na transmissão de dados e foi usado um algoritmo de
transformação de passwords de forma a que estas não sejam guardadas na Base de Dados tal como
foram inseridas pelos utilizadores1.
O registo de utilizadores obedece a um processo de verificação, de modo a que seja
garantida a real intenção de um utilizador em efectuar o seu registo. Desta forma o processo de
registo segue alguns passos de forma a que essa verificação seja efectuada. Este processo é comum
quer a candidatos quer a empregadores.
Quando o utilizador, na página inicial, escolhe uma das opções para efectuar novo registo é
apresentado um formulário contendo informação de preenchimento obrigatório. Caso algum dos
campos não esteja correctamente preenchido, são apresentadas mensagens de erro indicando os
campos que contêm informação incorrecta.
Depois de todos os campos estarem correctamente preenchidos, é criado o utilizador do tipo
correspondente na Base de Dados, mas esse utilizador não é activado e desta forma não consegue
usar as suas credenciais para acesso à aplicação. É gerado um token2, que neste caso identifica o
possível registo, é persistido na Base de Dados (Tabela 18) e é enviado um email ao utilizador com o
recurso ao qual deve aceder, com o token gerado como parâmetro. Será enviado ao utilizador um
URL da forma http://myapp.com/validate/12ab34cd56ef(...).
O utilizador visualiza, entretanto, uma mensagem que indica que irá receber um email
contendo dados necessários à validação do seu registo. Desta forma, é validado que o email que o
utilizador introduziu é um email válido e activo e pode ser usado para notificações posteriores a esse
utilizador.
Uma vez usado o URL enviado ao utilizador, o registo é efectivo e o utilizador é autenticado
na aplicação directamente, para poupar o utilizador de inserir as suas credenciais, dado que o token
também o identifica univocamente, podendo a partir daí autenticar-se normalmente na aplicação.
1 É guardado o hashing da password misturado com uma string de sal, através do algoritmo SHA256 de 32 bits.2 Um token é uma combinação de letras e dígitos único.
52
O token é mantido na Base de Dados como garantia de que não é gerado outro token com
uma combinação igual, passando ao estado de “usado” e não podendo ser novamente utilizado, dado
que deixou de ser válido para a confirmação do registo ao qual está associado.
Se um utilizador, após ter efectuado um registo não o confirme num prazo que pode ser
definido na aplicação (por exemplo uma semana), terá novamente de efectuar o registo e cumprir os
passos aqui enumerados. Neste caso, o token gerado passará ao estado de “expirado”. Esta
validação é efectuada através do campo “expiration_date”.
O token é criado segundo o seguinte algoritmo: é gerado um número aleatório entre 0 e 1012,
é realizada a operação xor em bits com o tempo actual em micro-segundos desde 01 de Janeiro de
1970 e é feito o hashing desse valor misturado com uma string de sal, através do algoritmo SHA256
de 32 bits.
4.2.4 - SESSÕES E AUTENTICAÇÃO
O processo de autenticação seleccionado foi a autenticação por username e password,
designados por credenciais de autenticação e escolhidos pelo utilizador na altura do registo. Para
garantir a segurança neste envio de dados sensíveis para o utilizador, tal como no registo de
utilizadores, foi utilizado o protocolo HTTPS.
Depois de enviada esta informação, é verificada a validade destes dados. O username é uma
chave-candidata (capítulo 3.4.2) na base de dados e por isso não existe nenhum username repetido.
Desta forma, é garantido não haverem repetições do par username/password. Assim estas
credenciais permitem identificar univocamente o utilizador, seja este candidato ou empregador.
Caso seja identificado o utilizador na Base de Dados, é criada uma sessão. De modo a
melhorar a rapidez e reduzir o número de acessos ao SGBD, é gerado um objecto (“Distributed
Session”) que contém a informação do candidato ou empregador e é colocado na cache (a
serialização é gerida pelo Django). Esta cache de sessões tem a vantagem de estar acessível por
qualquer dos servidores aplicacionais e por isso os próprios servidores não guardam estado, mas sim
a cache distribuída, de forma que qualquer servidor possa receber um pedido de um cliente, verificar
se existe correspondência deste cliente na cache e prosseguir com o pedido, ou informar o utilizador
que este precisa de se autenticar.
Para a identificação da sessão na cache é enviada ao utilizador, na resposta, uma cookie
(capítulo 3.3.2), com um valor gerado da mesma forma que o token, mas sem ser persistido na Base
de Dados e com a validade de sessão do browser (se o utilizador deixar de executar o browser, esta
cookie é perdida). Assim depois de efectuada a autenticação, é sempre enviada a cookie pelo
browser enquanto existir, o que vai permitir identificar o utilizador na cache e possibilitar o acesso ao
resto dos recursos disponíveis para o seu tipo de utilizador.
Caso o utilizador opte pela acção de logout, a cache é invalidada, ou seja o objecto
correspondente é retirado da cache, e é enviado um pedido de invalidação da cookie. Se o utilizador
apenas deixar de executar o browser e não efectuar o logout, poder-se-ia correr o risco de acumular
53
objectos na cache que nunca mais eram acedidos. É, porém, possível definir nos parâmetros de
configuração qual o tempo de duração máximo de um objecto na cache sem ser acedido, de forma a
prevenir esta situação.
4.2.5 - ESTRUTURA DOS DOCUMENTOS HTML GERADOS
Como já foi abordado no capítulo 3.3.6.5, o Django através da herança de templates permite
definir apenas partes de conteúdos de uma página, que poderão ser utilizados múltiplas vezes, na
mesma, ou em várias páginas. Esta característica foi utilizada na aplicação, de modo a definir uma
estrutura que serve de base a todos os documentos gerados.
A estrutura de todos os documentos é definida por uma template base, “base.html”, da qual
todos os documentos gerados herdam o seu comportamento, redefinindo apenas as componentes
necessárias. Assim foi utilizada uma estrutura com cinco blocos distintos: cabeçalho, rodapé, bloco
esquerdo, bloco central e bloco direito.
O cabeçalho, rodapé e bloco direito, contêm habitualmente informação institucional, ou seja
estática, sendo por isto comuns a todas as paginas e podem facilmente ser alterados, permitindo que
se mude completamente o aspecto da aplicação apenas com alterações mínimas.
Os outros blocos contêm informação dinâmica. O menu com as várias opções que um
candidato ou empregador pode realizar é colocados no bloco esquerdo, enquanto que o resultado
dessas acções é apresentado no bloco do centro. Como os bloco esquerdo e o bloco do centro são
dinâmicos, vai ser necessário colocar no contexto do template os dados necessários ao seu
preenchimento.
É possível porém, que numa evolução futura possa existir conteúdo dinâmico em todos os
blocos, sendo este preenchido com dados do mesmo tipo mas variantes no tempo, como por exemplo
colocar no bloco direito uma lista dos cinco últimos perfis inseridos. Assim, foi desenvolvido um
mecanismo de forma a que, se os blocos não forem explicitamente populados em cada controlador,
estes dados sejam populados por omissão.
De modo a que a apresentação das várias listagens esteja centralizada, foram desenvolvidos
templates que definem exclusivamente essas listagens, de modo a poderem ser incluídos em várias
páginas. Por exemplo, quando um empregador consulta os últimos perfis inseridos ou visualiza os
resultados dos perfis pesquisados, não faria sentido desenvolver duas páginas exactamente com a
mesma aparência, mas apenas com diferentes dados populados.
Desta forma, foi usado o sistema de inclusão de templates do Django (capítulo 3.3.6.5), de
modo a reutilizar as vezes necessárias, mas com dados diferentes, templates parciais que nunca são
apresentadas directamente ao utilizador, mas incluídas noutras templates.
4.2.6 - LOGGING
Uma aplicação deve registar num ficheiro as acções mais importantes realizadas durante a
54
sua execução, por forma a que seja possível detectar falhas e determinar as razões dessas falhas.
Por outro lado, deve manter um registo das acções realizadas por cada utilizador, para se detectarem
os recursos a que esse utilizador acedeu.
Foi utilizada para este projecto a biblioteca de registo (logging) do Python, configurada de
modo a criar um ficheiro com os registos de cada um dos dias de uso da aplicação. Um dos
parâmetros de configuração é a hora a que é criado um novo ficheiro de log. Definiu-se às 00.00
horas. Quando todos os dias é atingida esta hora, é guardado o ficheiro de registo actual com a data
do dia correspondente e é criado um novo ficheiro de registo [31] cap. 10. Optou-se por esta solução
por uma questão de gestão de espaço, dado que os ficheiros de registo, dependendo do número de
utilizadores da aplicação, podem ter um tamanho bastante considerável.
Foi também incluída, caso o utilizador não seja anónimo, um identificador em cada linha de
registo gerado com o identificador de sessão do utilizador, de modo a que seja possível monitorizar
um utilizador específico.
4.2.7 - INTERNACIONALIZAÇÃO
De modo a ser possível a internacionalização do projecto, ou seja, para que facilmente se
coloque a aplicação noutra linguagem, todos os blocos de texto apresentadas aos utilizadores estão
centralizados num ficheiro, sendo este um dos parâmetros de configuração da aplicação.
Assim, se for necessário que a aplicação esteja inteiramente apresentada em qualquer outra
língua que não o português (que foi a língua escolhida para os textos dos documentos gerados), é
apenas necessário construir um outro ficheiro, com a mesma estrutura, mas com os blocos de texto
traduzidos para outra linguagem e configurar na aplicação qual o ficheiro a utilizar.
4.2.8 - MODELO DE DADOS DESENVOLVIDO
O modelo de dados indica como as várias entidades definidas para esta aplicação irão ser
persistidas na Base de Dados. Já foram referidas no capítulo 4.2.1 as várias entidades que formam o
modelo da aplicação, as relações existentes entre essas entidades e a justificação da sua existência.
Como foi apresentado no capítulo 3.4.2, são necessários definir o modelo Entidade-Relação e
depois, a partir deste, obter o modelo Relacional correspondente que é o modelo através do qual os
dados são persistidos na Base de Dados. São também enumerados os passos necessários de modo
a serem definidos estes modelos.
Seguindo os passos descritos, obtemos primeiro o modelo Entidade-Relação e, através
deste, derivamos o modelo Relacional. Devido ao facto de estes modelos serem um pouco complexos
de apresentar graficamente, são apresentadas todas as entidades e todos os atributos que
constituem essas entidades no Anexo C – Modelo Relacional de Dados (Entidades) e são explicitadas
todas as relações entre essas mesmas entidades no Anexo D – Modelo Relacional de Dados
(Relações), quer ao nível da cardinalidade da relação, quer ao nível da sua obrigatoriedade, definindo
55
assim o modelo Relacional. As entidades referidas correspondem às tabelas, e os seus atributos às
colunas constituintes das tabelas. Na Figura 14 é apresentado o modelo Relacional parcial, contendo
apenas as entidades que persistem os dados passíveis de serem criados e alterados pelos
candidatos e empregadores.
Todas as entidades referidas possuem uma chave-primária (o atributo id), o que lhes permite
serem univocamente identificadas na Base de Dados. São apresentadas do lado direito as entidades
que contêm as chaves-estrangeiras para as entidades apresentadas do lado esquerdo. São também
apresentadas as obrigatoriedades de participação das entidades nas relações, bem como a
cardinalidade da sua relação. Numa Base de Dados Relacional, como a que foi usada para a
aplicação, a obrigatoriedade de participação na relação, é obtida através da não permissão da chave-
estrangeira de assumir o valor nulo (null). O contrário também é verdade, ou seja, se se permitir que
uma chave-estrangeira possa assumir o valor nulo, deixa de haver obrigatoriedade de participação na
relação.
Como exemplo concreto podemos apresentar um perfil associado a um candidato, sendo que
um candidato pode ter vários perfis. Se a chave-estrangeira desse perfil que referencia o candidato
pudesse ser de valor nulo, poderiam existir perfis de candidato não associados ao candidato. Se por
56
Figura 14: Modelo Relacional de Dados parcial
outro lado essa chave-estrangeira não pudesse assumir o valor nulo, então não poderiam haver perfis
sem candidato associado.
Porém, tal não tem influência na obrigatoriedade de um candidato poder ou não ter perfis.
Esta obrigatoriedade não é possível de definir no modelo Relacional, e teria de ser validada pela
aplicação. Se, no entanto, a cardinalidade da relação fosse de 1, já seria possível definir a
obrigatoriedade dos dois lados da relação, através da existência de duas chaves-estrangeiras, uma
para cada entidade participante na relação, referenciando cada uma respectivamente a outra
entidade e podendo desta forma definir-se a possibilidade de cada uma das chaves, poderem ou não,
assumirem valores nulos.
4.2.9 - VISIBILIDADE DOS ATRIBUTOS
De forma a que os utilizadores não permitam que todos os dados por eles inseridos sejam
visíveis para outros utilizadores, foi desenvolvida a possibilidade de escolha das visibilidades de
alguns dos atributos.
De entre os vários atributos que constituem as várias entidades, nomeadamente candidatos,
perfis, empregadores e ofertas, existem alguns atributos, que por uma determinada razão, o
candidato ou o empregador não tenham interesse em que sejam visíveis.
A visibilidade dos atributos é classificada de três formas: não visível, visível apenas no
detalhe e visível.
Desta forma fica salvaguardado que o candidato ou o empregador não disponibiliza
informação que possa considerar sensível aos outros utilizadores. Todavia, esta fica persistida na
Base de Dados e pode ser ser usada para as pesquisas.
Tendo em conta os atributos dos modelos apresentados no Anexo C – Modelo Relacional de
Dados (Entidades), para as entidades utilizador, candidato, empregador, perfil e oferta, serão
referidos apenas os atributos que têm um valor pré-definido e não são configuráveis pelo utilizador.
Os atributos da entidade utilizador nunca são visíveis. Para a entidade candidato, os atributos
país e cidade são sempre visíveis. Na entidade empregador, a cidade e o país são sempre visíveis.
Na entidade perfil, os atributos cidade pretendida, país pretendido, grau académico, curso, área
profissional procurada e emprego procurado são sempre visíveis, ao invés de salário mínimo
pretendido que é sempre não visível. Para a entidade oferta, são sempre visíveis o país de trabalho, a
cidade de trabalho, o grau académico pretendido, a universidade pretendida, o curso pretendido, a
área de emprego pretendida e o emprego pretendido.
Todos os outros atributos destas entidades poderão ter as suas visibilidades definidas pelo
utilizador. O candidato pode ainda configurar a visibilidade de cada um dos seus antigos empregos e
dos modelos associados ao perfil, nomeadamente tecnologias, funções desempenhadas e cursos
profissionais desempenhados.
A configuração da visibilidade dos atributos pode ser definida no registo do candidato ou
empregador, para a configuração das visibilidades dos atributos destas mesmas entidades. Caso o
57
candidato ou o empregador decidam efectuar alguma alteração à visibilidades dos atributos, poderão
fazê-lo através da edição destes dados.
Da mesma forma, na inserção de perfis pelo candidato ou de ofertas pelo empregador, esta
configuração está também disponível para os atributos das entidades correspondentes. Poderão,
também neste caso, efectuar alterações às visibilidades dos atributos destas entidades através da
edição das mesmas.
Para o candidato, a configuração da visibilidade dos antigos empregos exercidos encontra-se
na visualização dos dados pessoais, quer através da criação de um novo emprego exercido, quer
através da sua edição, enquanto que a configuração das visibilidades das tecnologias, funções
desempenhadas e cursos profissionais frequentados poderá ser definida na página de listagem de
perfis, quer na introdução de alguma nova instância destas entidades, quer através da sua edição.
4.2.10 - OPÇÕES DE CAMPOS DEPENDENTES DE ESCOLHAS
Como já foi abordado no capítulo 4.2.1, foram criadas várias entidades de forma a que alguns
atributos, quer dos candidatos e empregadores, quer dos perfis e das ofertas, fossem explicitamente
escolhidos através da utilização de campos de escolha de opções, em vez de preenchidos através de
campos de texto.
Alguns destes campos são dependentes de outros campos. Não faz sentido que sejam
apresentadas ao utilizador todas as opções possíveis para determinados campos depois de um
utilizador ter efectuado uma selecção de um campo do qual estes dependem. Justificar-se-á que o
âmbito de selecção se restrinja apenas aos valores possíveis, dependendo da selecção anterior
realizada.
Concretizando, a escolha de cidades é dependente do país. Se um utilizador selecciona um
dos países, apenas deverão ser visualizadas as opções de cidades correspondentes àquele país.
Também são dependentes do país, as universidades, as áreas profissionais e os graus
académicos. Por sua vez, os cursos são dependentes da universidade e os empregos da área
profissional.
Porém, quando se está a popular uma determinada página onde são apresentados estes
atributos, nomeadamente no registo de candidatos, empregadores, na inserção de perfis e ofertas, ou
em atributos não obrigatórios na edição dos anteriores, ainda não se tem informação sobre as opções
escolhidas pelo utilizador. Apenas quando o utilizador efectua uma determinada escolha ou uma
alteração à escolha anterior se podem, então, restringir as opções de campos que sejam
dependentes dessa opção escolhida.
Assim, quando é efectuada uma selecção de um atributo, é realizado um pedido (request)
assíncrono ao servidor através de AJAX (capítulo 3.3.5.5), de modo a serem modificadas as opções
dos outros atributos dependentes, sendo alterado o DOM (capítulo 3.3.5.4).
Para este efeito foram criados controladores (para efectuar a pesquisa das opções
correspondentes na Base de Dados) e templates específicas, gerando apenas o sub-conjunto das
58
opções possíveis para a escolha do atributo dependente do anteriormente seleccionado, ou seja, é
apenas alterado esse atributo e não toda a página, que continua a ser visualizada pelo utilizador.
Para todos os atributos dependentes de outros, as escolhas são sempre modificadas em
função das opções seleccionadas nos atributos dos quais estes são dependentes.
4.2.11 - VALIDAÇÃO DOS ATRIBUTOS INTRODUZIDOS
Habitualmente numa aplicação web, é necessário que os utilizadores efectuem a introdução
de dados através de formulários. Qualquer inserção de dados por parte dos utilizadores pode levar a
que seja persistida informação contendo ambiguidades e erros.
Assim, esta aplicação foi desenvolvida de forma a minimizar as ambiguidades de dados
inseridos pelos utilizadores. O Django providencia mecanismos que permitem que os dados inseridos
pelos utilizadores sejam validados, ou seja, que correspondam ao formato pretendido e que, nalguns
casos, existam obrigatoriamente.
Por exemplo, quando um candidato pretende inserir um novo perfil, um dos atributos a
introduzir é o salário pretendido pelo candidato para aceitar um determinado emprego. Esta inserção
é feita através de um campo de texto.
Alguns dos valores possíveis de inserir nesse campo são conjuntos de caracteres,
nomeadamente caracteres não numéricos. Estes valores possíveis de serem inseridos pelos
utilizadores, a serem aceites, ou geravam um erro na introdução destes dados no SGBD, ou eram
inseridos e o seu valor não teria qualquer significado. Por esse motivo, todos os campos introduzidos
pelos utilizadores que correspondam a atributos das várias entidades definidas, são validados de
forma a terem o formato requerido.
No exemplo anteriormente referido, apenas são aceites valores numéricos. Caso sejam
introduzidos valores não aceites, é mostrada na própria página visualizada uma mensagem de erro
indicando os requisitos necessários para que esse campo seja válido.
Entre as várias validações efectuadas, contam-se a existência do preenchimento do campo,
para campos obrigatórios, o tipo de dados aceites (um campo numérico apenas aceita dígitos, um
campo para introdução de datas apenas aceita datas, um campo para introdução de email apenas
aceita emails válidos) e o comprimento máximo aceite para o campo.
Assim, consegue-se garantir alguma fiabilidade, embora não total, dado que não é feita uma
validação semântica na maioria dos campos, dos dados inseridos pelo utilizador.
Em concreto, um candidato tem liberdade para definir um endereço através de um conjunto
arbitrário de caracteres, ou definir um salário pretendido com um valor extremamente baixo, sendo
estes normalmente inseridos na Base de Dados e apresentado aos empregadores,
independentemente de serem valores absurdos.
59
4.3 - ESTRUTURA DE DIRECTORIAS E FICHEIROS
Como foi referido (capítulo 3.1.2), iniciando um novo projecto Django, são criados à partida
determinados ficheiros e directorias. Porém, embora estes constituam a base para o projecto, é
necessário definir uma estrutura coerente e modular onde são alojados os vários ficheiros
desenvolvidos, os ficheiros de configuração, bem como os ficheiros de monitorização do
funcionamento da aplicação e outros ficheiros informativos e auxiliares.
Assim o projecto apresenta a seguinte estrutura de directorias:
• raiz do projecto – directoria que contém os ficheiros “manage.py”, “urls.py”, “settings.py”,
“__init__.py” , “sandbox.bat” e “.hgignore”; contém também as directorias “docs”, “logs”,
“marketplace”, “misc”, “static” e “templates”.
• “.hg” – directoria criada pela aplicação “hg” que foi a aplicação escolhida para
versionamento do projecto.
• “docs” – directoria que contém alguns documentos informativos da aplicação, este
documento e alguma bibliografia.
• “logs” – directoria que contém os “logs” de funcionamento da aplicação.
• “marketplace” – directoria que contém os ficheiros principais da aplicação que foram
desenvolvidos pelo programador e que contém as directorias “language” e “fixtures”.
• “language” – directoria que contém os dicionários de blocos de texto apresentados, caso
se pretenda estender a aplicação para o uso de várias linguagens.
• “fixtures” – directoria que contém dados para pré-popular a Base de Dados, usados para
testes.
• “misc” – directoria que contém o software necessário para a configuração e execução da
aplicação (capítulo 4.1).
• “static” – directoria que contém os ficheiros estáticos usados pela aplicação, como
imagens, folha de estilos e ficheiros de JavaScript.
• “templates” – directoria que contém os templates desenvolvidos para a aplicação,
contendo esta várias sub-directorias estruturadas de acordo com a lógica hierárquica das
Vistas.
Os principais ficheiros desenvolvidos neste projecto podem ser tipificados em três categorias:
ficheiros de configuração, ficheiros auxiliares e ficheiros de desenvolvimento.
Os ficheiros de configuração do Django são ficheiros em Python que nos permitem efectuar a
configuração de parâmetros específicos da aplicação. São estes o “settings.py” e o “urls.py” e estão
colocados na raiz do projecto, tendo já sido alvo de abordagem detalhada (capítulo 3.1.2).
O ficheiro “manage.py” é um ficheiro copiado pelo Django para a raiz de qualquer novo
projecto e não é alvo de qualquer desenvolvimento; é um ficheiro que permite efectuar um conjunto
de tarefas auxiliares e por isso pertencente à categoria de ficheiros auxiliares. Na raiz do projecto,
60
encontramos ainda o ficheiro “__init__.py”, que é o primeiro ficheiro executado uma vez iniciada a
aplicação e onde foram colocadas algumas validações iniciais de funcionamento da infra-estrutura,
validando se todos os componentes da aplicação estão em execução, como por exemplo o sistema
de gestão de cache. Está também o ficheiro “sandbox.bat” que é destinado a definir algumas
variáveis de ambiente.
Os ficheiros desenvolvidos com o código da aplicação encontram-se na directoria
“marketplace” e incluem (juntamente com as templates) toda a lógica de execução da aplicação.
O ficheiro “portuguese.py” contém todas as palavras usadas nas interacções com o utilizador,
seja através em emails, seja através dos vários templates de forma a que, para o uso de outra
linguagem, seja apenas necessário efectuar a tradução dessas palavras e indicar no ficheiro de
configuração do Django (“settings.py”) qual o ficheiro que contém as novas palavras a usar.
O ficheiro “classes.py” define algumas classes necessárias à aplicação e, dada a arquitectura
modular do projecto, centraliza as definições de classes auxiliares. Da mesma forma foi incluído o
ficheiro “constants.py”, que define constantes não necessárias ao funcionamento do Django, mas
específicas da aplicação. Todas as constantes usadas foram centralizadas neste ficheiro. O ficheiro
“logconf.py” contém as configurações de logging da aplicação e a forma como os ficheiros de log são
criados e formatados. O ficheiro “utils.py” contém alguns métodos auxiliares, nomeadamente métodos
de conversão de dados e métodos usados de forma recorrente, mas sem interferência na lógica da
aplicação.
Os ficheiros “forms.py”, “views.py” e “models.py” contêm toda a lógica da aplicação e, por
isso, é analisado em detalhe o seu conteúdo no capítulo 3.1.2, e no capítulo 4.2.
O ficheiro “resemblances.py” contém a lógica de semelhanças, entre alguns campos,
necessária ao algoritmo de classificação. O ficheiro “search.py” contêm a implementação das
procuras por critério e através do algoritmo de classificação. O constante nestes ficheiros é detalhado
no capítulo 4.4.4.
O ficheiro “test.py” contém todos os testes efectuados durante o desenvolvimento da
aplicação, assunto que é abordado no capítulo 3.2. O ficheiro “widgets.py” contém algumas definições
de widgets que foram necessárias de implementar, de modo a que fosse possível a apresentação de
campos booleanos através de uma forma que não uma checkbox, que é apresentação normal do
Django para campos booleanos. O ficheiro “ejob.wsgi” contém o código necessário para converter a
aplicação numa aplicação WSGI, de modo a poder ser servida através do módulo “mod_wsgi” do
servidor Apache.
Ainda uma referência para os ficheiros “jquery.js” e “style.css”, ambos na directoria “static”. O
primeiro, é uma biblioteca de JavaScript desenhada para simplificar o client-side scripting e usada
neste projecto. O segundo, é o ficheiro é onde estão definidas as formatações das várias páginas
HTML geradas (capítulo 3.3.5.3).
61
4.4 - ALGORITMO DE CLASSIFICAÇÃO DE PERFIS E OFERTAS
O objectivo deste capítulo é apresentar o algoritmo de classificação desenvolvido para o
protótipo. É apresentada a sua formulação matemática seguida da sua implementação e integração
na aplicação. São ainda apresentados exemplos de como são efectuados os cálculos e são
discutidos os resultados obtidos.
4.4.1 - CONCEITO DE AGREGAÇÃO
Para esta aplicação, temos o objectivo encontrar uma forma de conseguir classificar perfis de
candidatos relativamente a um perfil ideal proposto pelo empregador, e ofertas de empregadores
relativamente a um ideal de oferta de um candidato.
Temos pois que conseguir quantificar distâncias entre perfis ou entre ofertas, de modo a
conseguir encontrar um sub-conjunto destes, que garanta um determinado grau de satisfação por
forma a que seja um conjunto válido. Este objectivo é atingido através da operação de agregação que
passaremos a detalhar.
Agregação é o conceito de combinação vários valores, numéricos ou não numéricos apenas
num único, de modo a que este se torne uma medida. Em tomadas de decisão, os valores a serem
agregados, usualmente correspondem a um grau de satisfação ou grau de preferência.
Um grau de preferência quantifica o quanto uma alternativa A é preferida relativamente a uma
alternativa B e, desse modo, é uma avaliação relativa. Um grau de satisfação expressa o quanto uma
alternativa é satisfatória relativamente a um determinado critério, ou seja, representa uma distância
relativamente à alternativa ideal para uma tomada de decisão e deste modo é uma avaliação
absoluta.
Os valores deverão pertencer a uma escala numérica ou a uma escala não numérica que
tenha alguma relação de ordem, mesmo que fraca, ou não é possível executar a agregação. Um
exemplo de uma escala não numérica é {muito pequeno, pequeno, médio, grande, muito grande}.
Este tipo de escala não numérica é muitas vezes usada na teoria dos conjuntos imprecisos ( fuzzy set
theory).
Uma vez definidos os valores, estes podem ser agregados e é obtido um novo valor na
mesma escala. Podemos definir três classes de operações de agregação distinguidas pelo seu
comportamento: as conjuntivas, as disjuntivas e normais. As conjuntivas implicam que o valor
agregado é alto caso todos os valores sejam altos e é correspondente ao “e” lógico. As disjuntivas
implicam que o valor agregado é alto se algum dos valores da agregação for alto e corresponde ao
“ou” lógico. As normais têm a propriedade de ser compensativas e o resultado vai corresponder a
uma média.
As propriedades da operação de agregação são impostas pela natureza dos valores a serem
agregados. Em alguns métodos de agregação com múltiplos critérios, o objectivo é encontrar uma
62
pontuação absoluta para um objecto, dado um conjunto de pontuações parciais que obedecem a
diferentes critérios.
4.4.2 - CRITÉRIO DE MEDIDA
O critério de medida vai permitir descrever como é efectuada a agregação. Para ser definido
o critério de medida utilizado, é necessário introduzir algumas notações.
Definimos um conjunto X de alternativas x1 , ... , xn e um conjunto de critérios
h1 , ... , hn . Um critério h i mapeia um conjunto de alternativas numa escala L . O valor
h ix1 é considerado o valor parcial do critério i para a alternativa x1 . É utilizada uma
escala de medida comum a todos os critérios e considerada a escala definida pelo conjunto [0,1] .
É considerado também, por uma questão de simplicidade, a i=hi x1 e assim, é possível
representar a alternativa x1 como um vector de pontuações parciais [a1…an] em [0,1]n .
Um operador de agregação é um mapeamento de Ln em L que permite calcular a
partir do vector de pontuações parciais a pontuação total da alternativa a .
As propriedades matemáticas podem ser consultadas em [30]. Existe ainda outro tipo de
propriedades que é útil enunciar, que são as propriedades de comportamento, algumas das quais
necessárias para a correcta definição da agregação que são: a possibilidade de definir pesos que
reflectem a importância de cada critério e a possibilidade de definir o comportamento do decisor.
A definição de pesos permite que alguns critérios tenham mais influência do que outros no
resultado da agregação. Por outro lado, o decisor pode pretender que um ou alguns critérios sejam
absolutamente necessários e deste modo pode definir um ou alguns critérios como imprescindíveis
(veto), ou se pretender que apenas um critério ou alguns critérios sejam suficientes, pode definir o
favorecimento.
A maioria das operações de agregação requerem o uso de pesos que reflectem a importância
de cada um dos critérios. A operação de agregação mais usada é a operação de média aritmética
ponderada.
É definido um vector de pesos normalizados [w1 ,... ,w n] tal que:
w i∈[0,1] (1)
∑iw i=1 (2)
e assim, operação média aritmética nas condições enumeradas é definida por:
WM w1 ,.. ,wna1 ,... , an=∑i=1
n
w i a i (3)
63
O efeito de veto pode ser formalizado da seguinte forma:
1. é a operação de agregação final
2. é a operação de agregação escolhida
3. a i é um veto de
4. ∧ é a operação de mínimo
então, a operação de veto existe se for possível a seguinte decomposição:
a1 , ... , an=a i∧a1 , ... , an (4)
De forma análoga podemos formalizar o efeito de favorecimento:
1. é a operação de agregação final
2. é a operação de agregação escolhida
3. a i é um favorecimento de
4. ∨ é a operação de máximo
então, a operação de favorecimento existe se for possível a seguinte decomposição:
a1 , ... , an=a i∨a1 , ... , an (5)
As operações mínimo e máximo gozam das propriedades comutativa,
a i∨a j=a j∨a i (6)
a i∧a j=a j∧a i (7)Idempotência,
a i∨ai=a i (8)
a i∧ai=a i (9) e associativa entre si:
a i∨a j∧ak =a i∨a j∧a i∨ak=a i∨ak∧a i∨a j (10)
a i∧a j∨ak =a i∧a j∨a i∧ak=a i∧ak∨a i∧a j (11)
Desta forma, a formalização do algoritmo para a agregação será o seguinte:
1. é a operação de agregação final
2. WM w1 ,.. ,wna1 ,... , an é a operação de agregação media aritmética ponderada
3. a x1 , ... , axn são vetos de
4. a y1 ,... , a yn são favorecimentos de
5. a xi≠ayi
64
6. ∨ é a operação de máximo
7. ∧ é a operação de mínimo
então:
a1 , ... , an=a x1∧...∧axn∧WM w1 ,.. ,wna1 ,... , an∨a y1∨...∨a yn (12)
Porém foram também experimentados outros critérios de medida, embora não tenham sido
utilizados por corresponderem a resultados não tão representativos.
Um dos critérios de medida experimentados foi a média aritmética ponderada mas com uma
ordenação decrescente dos pesos ou seja utilizando o operador OWA (Ordered Weighted Averaging).
Nas condições (1) e (2) é efectuada uma ordenação dos pesos por ordem decrescente dos valores
dos pesos. Assim esta operação é definida por:
OWAw1 , ... , wna1 ,... , an=∑i=1
n
w jb j (13)
em que:
b j≡a n−i1 (14)
Outro critério de medida estudado foi a média geométrica ponderada. Para o mesmo conjunto
de pontuações parciais [a1…an] em [0,1]n e para o mesmo vector de pesos normalizados
[w1 ,... ,w n] a operação média geométrica ponderada é definida da seguinte forma:
WGM w1 ,... ,wn a1 , ... , an=∏i=1
n
aiw i
∑i=1
n
w i
(15)
A operação de agregação utilizada foi a média aritmética ponderada, mas com a possibilidade
do efeito de veto ou favorecimento definida por (12), sendo que cada valor parcial a i não pode ser
simultaneamente veto e favorecimento e vai corresponder ao critério de medida.
4.4.3 - COMPARAÇÃO ENTRE OS CRITÉRIOS DE MEDIDA
Para a demonstração da aplicação dos critérios de medida foram escolhidos dados de
exemplo reduzidos, por uma questão de simplicidade de cálculos. No capítulo 4.4.5 é discutida a
forma de obtenção do critério de medida escolhido (média aritmética ponderada) com dados reais e
utilizando os efeitos de veto e preferência. Para a comparação entre os resultados obtidos pela
aplicação dos critérios de medida apresentados no capítulo 4.4.2 foram utilizados os dados a seguir
indicados.
65
Conjunto de alternativas:
X=[ x1] (16)
Vectores de critérios para um exemplo com 5 critérios:
a x1=[0.5,0.7,1,0.2, 0] (17)
a x2=[0.2,0.5,0.6,0.2,0.8] (18)
a x3=[0.1,0.1, 0.3, 0.3,0.1] (19)
a x4=[0.8,0.7,1,0.3,0.9] (20)
Vector de pesos normalizado:
w=[0.2,0.3,0.3 ,0.1,0.1] (21)
Com a aplicação do critério de medida utilizando a operação média aritmética ponderada (3)
são obtidos os seguintes resultados:
WAM 1=∑i=1
5
wia x1i=0.2×0.50.3×0.70.3×10.1×0.20.1×0=0.63 (22)
WAM 2=∑i=1
5
w iax2 i=0.2×0.20.3×0.50.3×0.60.1×0.20.1×0.8=0.47 (23)
WAM 3=∑i=1
5
wi ax3i=0.2×0.10.3×0.10.3×0.30.1×0.30.1×0.1=0.18 (24)
WAM 4=∑i=1
5
w i ax4 i=0.2×0.80.3×0.70.3×10.1×0.30.1×0.9=0.79 (25)
Na aplicação do critério de medida utilizando o operador OWA foram obtidos os seguintes
resultados:
OWA1=∑i=1
5
w i bx1i=0.3×0.50.3×0.70.2×10.2×0.20.1×0=0.58 (26)
OWA2=∑i=1
5
wi bx2i=0.3×0.20.3×0.50.2×10.2×0.60.1×0.8=0.45 (27)
OWA3=∑i=1
5
w ibx3i=0.3×0.10.3×0.10.2×0.30.2×0.30.1×0.1=0.19 (28)
OWA4=∑i=1
5
wi bx4i=0.3×0.80.3×0.70.2×10.2×0.30.1×0.9=0.80 (29)
Aplicando o critério de medida utilizando a operação média geométrica ponderada ao mesmo
conjunto de dados obtemos:
66
WGM 1=∏i=1
5
ax1iw i
∑i=1
5
w i
=0.50.2×0.70.3×10.3×0.20.1×00.1
1=0 (30)
WGM 2=∏i=1
5
ax2 iw i
∑i=1
5
wi
=0.20.2×0.50.3×0.60.3×0.20.1×0.80.1
1=0.42 (31)
WGM 3=∏i=1
5
ax3iw i
∑i=1
5
wi
=0.10.2×0.10.3×0.30.3×0.30.1×0.10.1
1=0.16 (32)
WGM 4=∏i=1
5
a x4iw i
∑i=1
5
w i
=0.80.2×0.70.3×10.3×0.30.1×0.90.1
1=0.75 (33)
Para uma melhor comparação entre os resultados obtidos utilizando os vários critérios de
medida construiu-se a Tabela 2 que resume os resultados obtidos.
a x1 a x2 a x3 a x4WAM 0.63 0.47 0.18 0.79
OWA 0.58 0.45 0.19 0.80
WGM 0 0.42 0.16 0.75
Tabela 2: Comparação de resultados obtidos com alguns critérios de medida
Pela análise dos resultados obtidos, constata-se que a utilização do critério de medida média
geométrica ponderada conduz a resultados semelhantes aos obtidos pelos outros critérios com
excepção da existência de um elemento que tenha o valor zero no vector de critérios. Neste caso o
resultado da agregação terá sempre o valor zero mesmo que os outros critérios tenham o valor 1.
Desta forma este critério de medida não poderia ser utilizado.
Na comparação entre o critério de medida média aritmética ponderada e a utilização de OWA,
constata-se que, se os primeiros valores do vector forem altos e se os primeiros pesos forem também
altos, este critério de medida apresenta também valores altos. No caso limite, se um vector de
critérios for [0,0,1 ,0 ,0] e o vector de pesos for [0,0,1 ,0 ,0] , o valor da operação de
agregação será de zero enquanto que o comportamento esperado seria de apresentar o valor 1 .
Porém, se estes vectores forem respectivamente [1,0 ,0 ,0 ,0] e [0,0,0 ,0 ,1] o valor da
67
operação de agregação será de 1 enquanto que o esperado seria zero. Para vectores de critérios
de medida que sejam semelhantes a estes como por exemplo [1,0.2 ,0.1 ,0.1,0.1] e
[0.1,0.1,0.1 ,0.1,0.6] , a discrepância de valores obtidos na agregação utilizando a média
aritmética ponderada e a utilização de OWA é acentuada e são obtidos valores para a operação
utilizando OWA muito distantes do comportamento esperado.
Assim, foi escolhida a operação de agregação média aritmética ponderada com os efeitos de
veto e preferência que corresponde ao critério de medida que apresenta valores mais coerentes com
os resultados esperados pela sua aplicação.
4.4.4 - PESQUISAS
Como já foi referido anteriormente no capítulo 4.2.2, foram implementados dois tipos de
pesquisas: a pesquisa por critério e a pesquisa através do algoritmo de classificação.
A pesquisa por critério permite ao utilizador, através do preenchimento de campos existentes
no formulário de pesquisa, obter uma lista de ofertas ou perfis, conforme o tipo de utilizador a efectuar
a pesquisa, que cumpram os critérios introduzidos. No caso de o utilizador ser um candidato, os
campos do formulário de pesquisa são os campos correspondentes às ofertas inseridas pelos
empregadores e, no caso de o utilizador ser empregador, os campos do formulário de pesquisa são
os campos correspondentes aos perfis inseridos pelos candidatos.
O utilizador tem a possibilidade de, entre os vários critérios de pesquisa, seleccionar por
quais pretende efectuar a procura. Se a procura retornar um conjunto de resultados demasiado
grande, são apresentados apenas alguns dos resultados e o total de resultados que correspondem
aos critérios de pesquisa, e é solicitado ao utilizador que refine a sua pesquisa.
De entre os vários critérios de pesquisa, existem critérios que implicam que os campos da
pesquisa correspondam exactamente a atributos existentes na Base de Dados como, por exemplo, a
área profissional, enquanto que outros critérios apenas requerem que o critério de pesquisa seja
cumprido como, por exemplo, a média de curso. Ou seja, se se escolher pesquisar por uma
determinada área profissional, apenas serão apresentados os resultados para essa área profissional,
enquanto que, pesquisando pela média de curso, são apresentados todos os perfis que apresentem
uma média de curso igual ou superior à indicada para a pesquisa. Os campos que necessitam
apenas que o critério seja cumprido estão assinalados no formulário de pesquisa.
A outra pesquisa desenvolvida foi a pesquisa através do algoritmo de classificação. Nesta
pesquisa, substancialmente diferente da anterior, o utilizador insere um ou mais modelos, a partir dos
quais pretende que seja efectuada a comparação com os perfis e ofertas existentes.
Se o utilizador for um candidato, tem de inserir uma ou mais ofertas modelo. Se o utilizador
for um empregador, tem de inserir um ou mais perfis modelo. Na inserção de perfis ou ofertas modelo,
os utilizadores têm a possibilidade de definir pesos para cada um dos atributos do perfil modelo, bem
como escolher se determinado atributo é um veto ou um favorecimento.
68
Assim estamos nas condições necessárias para a utilização do algoritmo de classificação
descrito no capítulo 4.2.2. Dependendo do tipo de utilizador, são retornados da Base de Dados todos
os perfis ou todas as ofertas. De seguida, estes são classificados, de modo a que sejam encontrados
os perfis ou ofertas que correspondem a um valor mais elevado do resultado obtido através da
operação de agregação entre o perfil ou oferta e o perfil modelo ou oferta modelo.
Os perfis ou ofertas que tenham obtido um valor mais elevado são apresentados ao utilizador,
ordenados por ordem decrescente do valor obtido, sendo este valor também apresentado. Será
depois possível persistir os resultados obtidos e efectuar nova pesquisa através da utilização de um
modelo diferente inserido, mas restringido apenas a estes resultados obtidos.
De realçar o facto de, em qualquer das pesquisas, serem usados todos os atributos
disponíveis quer nas ofertas quer nos perfis, e não apenas os visíveis, de modo a que as pesquisas
sejam o mais precisas possível.
Para a utilização do algoritmo de classificação, como foi referido, é necessário que sejam
retornados todos os perfis ou todas as ofertas existentes na Base de Dados. A agilização deste
processo é abordada no capítulo 5.
Se o total de perfis existentes ou o total de ofertas existentes for da ordem das dezenas de
milhares ou superior, este processo de cálculo poder-se-ia tornar moroso. Isto porque o maior
constrangimento não está em retornar estes valores da Base de Dados, mas em instanciar os
objectos correspondentes, de modo a mostrá-los ao utilizador.
Nesse sentido, foram usados alguns mecanismos de forma a minimizar este impacto na
aplicação. Todos os pedidos efectuados à Base de Dados que sejam para retornar resultados de
pesquisas, são feitos através da linguagem SQL (capítulo 3.4.3), não usando a camada de
abstracção providenciada pelo Django, minimizando assim os objectos instanciados. Por outro lado,
na pesquisa por critérios, apenas são instanciados os objectos apresentados como resultado ao
utilizador. Na construção das páginas HTML (renderização), são apenas mostrados ao utilizador um
conjunto limitado de resultados pré-definido (dez resultados, mas com a possibilidade deste valor ser
alterado na configuração da aplicação).
Assim, consegue-se tirar partido do facto de a instanciação de objectos do Django ser lazy, ou
seja, só são transformados em objectos os resultados de um pedido à Base de Dados quando
necessário, e não imediatamente quando os resultados são retornados.
A implementação das pesquisas, bem como a implementação da operação de agregação
está no ficheiro “search.py”, por forma a estar centralizada num único ficheiro criado para o efeito.
4.4.5 - IMPLEMENTAÇÃO DA OPERAÇÃO DE AGREGAÇÃO
A operação de agregação permite que se obtenha um resultado que traduz o grau de
semelhança entre várias ofertas ou vários perfis.
Para a aplicação da operação de agregação há que definir previamente os dados
necessários, nomeadamente um conjunto X de alternativas, um vector a de resultado de
69
aplicação de critérios, uma escala L , um vector de pesos w normalizado, um vector de vetos
v , e um vector de preferências p .
Por uma questão de implementação optou-se por restringir o conjunto X de alternativas
apenas a uma, que corresponde à diferença entre uma oferta e a oferta modelo ou um perfil e o perfil
modelo.
O cálculo do vector a implicou que se tivessem de calcular valores para a semelhança
entre cada um dos atributos do modelo e do perfil ou da oferta, com o qual se efectua a comparação.
Assim, foram definidos no ficheiro “resemblances.py” métodos que permitem obter valores
numéricos para estas semelhanças (Anexo B – Métodos para obtenção de semelhanças) baseados,
quando aplicável, nas entidades que traduzem graus de semelhança entre atributos (capítulo 4.2.1).
A escala L escolhida é o intervalo real [0,1] .
O vector de pesos w é obtido através do peso de cada um dos atributos introduzido pelo
utilizador numa escala inteira entre 0 e 10 , sendo depois normalizado.
O vector de vetos v é obtido a partir da introdução, pelo utilizador, dos atributos indicados
como vetos ( 0 se o atributo não corresponde a um veto e 1 se corresponde), multiplicado pelo
elemento do vector a correspondente.
O vector de preferências p é obtido da mesma forma que o vector de vetos, sendo obtido
através da introdução pelo utilizador dos atributos indicados como preferências.
Aplicando a operação de agregação a estes dados, obtemos o resultado na escala escolhida
para a semelhança entre um perfil ou oferta modelo e o perfil ou oferta alvo do cálculo. Para a
obtenção dos vários valores correspondentes a vários perfis ou ofertas, este processo é repetido
tantas vezes quanto o número de perfis ou ofertas existentes, sendo retidos apenas os perfis ou
ofertas que apresentem valores de semelhança mais elevados.
4.4.6 - TESTES EFECTUADOS E RESULTADOS
Para além dos testes unitários, já referidos em capítulos anteriores, que permitem garantir a
fiabilidade e a eficácia da aplicação, foram realizados testes, de modo a aferir os resultados da
pesquisa utilizando o algoritmo de classificação e testes de carga aos dois tipos de pesquisas, dado
que estas são as funcionalidades que requerem maior performance da infra-estrutura aplicacional.
Para garantir que o algoritmo de classificação retorna os resultados esperados, foram
testadas pesquisas utilizando os dados das tabelas apresentadas de seguida, respectivamente de
perfis (Tabela 5) e ofertas (Tabela 6), usando os perfis e ofertas modelo constantes na Tabela 3 e na
Tabela 4. Foram também inseridos na Base de Dados, dados que definem a semelhança entre as
várias instâncias de cada entidade constantes nas restantes Tabelas. Foram ainda inseridos alguns
dados necessários como países, cidades, graus académicos, universidades, cursos superiores, áreas
profissionais e empregos, de modo a que os identificadores usados nas tabelas anteriores existissem,
70
embora não seja relevante detalhá-los.
Perfil Modelo 1 Perfil Modelo 2 Perfil Modelo 3Nome do Atributo Valor Peso Veto Pref. Valor Peso Veto Pref. Valor Peso Veto Pref.
appliance_country 1 5 0 0 1 10 0 0 1 10 0 0appliance_city 1 5 0 0 1 10 0 0 1 10 0 0academic_degree 1 0 0 0 8 9 0 0 8 8 0 0academic_school 0 0 0 0 1 5 0 0 2 3 0 0academic_course 0 0 0 0 1 10 0 0 4 9 0 0is_complete 1 0 0 0 0 7 0 0 1 10 0 0course_start_date 01-02-90 0 0 0 01-01-03 3 0 0 01-02-80 8 0 0course_end_date 01-01-09 0 0 0 01-01-09 3 0 0 01-02-90 1 0 0course_average 10 0 0 0 12 6 0 0 16 8 0 0appliance_job_area 3 10 0 0 1 5 0 0 2 8 0 0appliance_job 6 10 0 0 1 5 0 0 2 7 0 0appliance_job_key_words Tinta 0 0 0 Linux 8 0 0 Redes 0 0 0prof_experience_time_months 12 10 0 0 12 2 0 0 96 1 0 0prof_experience_area_time_months 12 10 0 0 6 2 0 0 96 8 0 0available_start_time_days 10 3 0 0 30 0 0 0 15 2 0 0available_hours 8 10 0 0 8 4 0 0 8 7 0 0available_hours_from 7 5 0 0 8 4 0 0 9 2 0 0available_hours_to 19 5 0 0 19 4 0 0 19 2 0 0available_travel 1 3 0 0 0 0 0 0 0 0 0 0driver_license 1 3 1 0 0 3 0 0 1 0 0 0salary_euros 700 8 0 0 900 5 0 0 1300 3 0 0salary_euros_min 700 8 0 0 700 5 0 0 1200 3 0 0
Tabela 3: Perfis Modelo usados em testes
Oferta Modelo 1 Oferta Modelo 2 Oferta Modelo 3Nome do Atributo Valor Peso Veto Pref. Valor Peso Veto Pref. Valor Peso Veto Pref.
working_place_country 1 10 0 0 1 10 1 0 1 3 0 0working_place_city 1 10 0 0 1 2 0 0 1 1 0 0working_place_max_distance_km 50 3 0 0 10 1 0 0 80 7 0 0academic_degree 8 10 0 0 7 5 0 0 6 3 0 0academic_school 2 2 0 0 2 7 0 0 1 4 0 0academic_course 3 10 0 0 1 3 0 0 2 2 0 0is_complete 1 8 0 0 1 2 0 0 0 10 0 0course_average 13 3 0 0 16 8 0 0 12 4 0 0job_area 1 10 0 0 1 10 0 0 2 7 0 0job 1 10 0 0 3 5 0 0 2 7 0 1job_key_words Java 0 0 0 Linux 2 0 0 Java 5 0 0prof_experience_area_time_months 200 5 0 0 12 3 0 0 60 4 0 0available_start_time_days 15 5 0 0 20 0 0 0 5 6 0 0available_day_hours 8 10 0 0 8 3 0 0 4 3 0 0available_hours_from 8 2 0 0 10 2 0 0 9 3 0 0available_hours_to 20 2 0 0 20 8 0 0 21 3 0 0available_travel 1 0 0 0 1 5 0 0 0 1 0 0driver_license 1 0 0 0 1 5 0 0 0 1 0 0salary_euros 900 7 0 0 2000 10 0 0 500 5 0 0salary_euros_max 1000 7 0 0 2200 10 0 0 600 5 0 0
Tabela 4: Ofertas Modelo usadas em testes
71
Perfil 1 Perfil 2 Perfil 3Nome do Atributo Valor Valor Valor
appliance_country 1 1 1appliance_city 1 1 2academic_degree 3 8 9academic_school 0 1 2academic_course 0 1 2is_complete 1 1 0course_start_date 26-02-95 01-09-00 01-09-80course_end_date 02-07-98 05-08-05 01-07-90course_average 12 14 12appliance_job_area 3 1 1appliance_job 4 1 1appliance_job_key_words Estuque Java Energiaprof_experience_time_months 24 24 200prof_experience_area_time_months 12 24 190available_start_time_days 0 15 30available_hours 12 10 8available_hours_from 7 9 8available_hours_to 21 22 18available_travel 0 1 0driver_license 1 1 0salary_euros 800 1100 1900salary_euros_min 650 800 1850
Tabela 5: Perfis usados em testes
Oferta 1 Oferta 2 Oferta 3Nome do Atributo Valor Valor Valor
working_place_country 1 1 1working_place_city 1 1 1working_place_max_distance_km 20 50 100academic_degree 4 6 8academic_school 0 2 1academic_course 0 3 1is_complete 1 1 1course_average 12 15 13job_area 2 1 1job 2 1 7job_key_words Canalização Java J2EEprof_experience_area_time_months 15 120 24available_start_time_days 5 25 15available_day_hours 8 8 4available_hours_from 8 9 12available_hours_to 19 21 18available_travel 1 0 0driver_license 1 0 1salary_euros 900 1300 700salary_euros_max 950 1400 850
Tabela 6: Ofertas usadas em testes
72
Academic Degree Similarity
Degree 1 Degree 2 Similarity
6 7 0.95
7 6 0.8
7 8 0.7
8 7 0.7
6 8 0.2
8 6 0.2
8 9 0.92
9 8 0.98
Tabela 7: Semelhança de Graus Académicos
University Similarity
University 1 University 2 Similarity
1 2 0.9
2 1 0.7
Tabela 8: Semelhança de Universidades
University Course Similarity
Course 1 Course 2 Similarity
1 2 0.5
2 1 0.6
Tabela 9: Semelhança de Cursos Superiores
Job Area Similarity
Job Area 1 Job Area 2 Similarity
1 2 0.8
2 1 0.8
Tabela 10: Semelhança de Áreas Profissionais
Job Similarity
Job 1 Job 2 Similarity
1 2 0.2
2 1 0.2
Tabela 11: Semelhança de Empregos
O Anexo B – Métodos para obtenção de semelhanças, contém os métodos usados para o
cálculo de semelhanças entre cada um dos atributos.
Para este conjunto de dados, e efectuando os cálculos tal como demonstrado no capítulo
4.4.3, os resultados para a operação de agregação definida são os apresentados na Tabela 12 e na
Tabela 13.
Perfil Modelo 1 Perfil Modelo 2 Perfil Modelo 3Perfil 1 0.857 0.591 0.501
Perfil 2 0.581 0.813 0.695
Perfil 3 0.000 0.630 0.540
Tabela 12: Resultados da pesquisa pelo Algoritmo de Classificação (Perfis)
Oferta Modelo 1 Oferta Modelo 2 Oferta Modelo 3Oferta 1 0.638 0.547 1.000
Oferta 2 0.912 0.605 0.652
Oferta 3 0.872 0.712 0.648
Tabela 13: Resultados da pesquisa pelo Algoritmo de Classificação (Ofertas)
Destes resultados podemos extrair alguma informação relevante. No conjunto de resultados
73
encontrados para o Perfil Modelo 1, podemos constatar o efeito do veto existente no resultado do
Perfil 1, bem como o facto de terem sido adoptados apenas alguns critérios com peso diferente de
zero, mas desses, muitos têm o peso máximo, o que traduz diferenças abruptas nos valores das
classificações.
Os resultados obtidos para o Perfil Modelo 2 mostram um modelo com os pesos mais
distribuídos, mas com o Perfil 2 a cumprir quase todos os critérios mais relevantes, e por isso
destacado dos outros. No caso do Perfil Modelo 3, não existe nenhum perfil que cumpra muitos dos
critérios, embora se destaque o Perfil 2, dado que consegue obter valores parciais de semelhanças
em muitos dos critérios, o que o aproxima em termos de resultado do modelo.
No caso das ofertas, os resultados obtidos para a Oferta Modelo 1 indicam bastante
semelhança entre esta e as ofertas pesquisadas, o que é facilmente perceptível pela análise dos
dados usados para os testes. Porém a Oferta 1 é penalizada face às outras pelo facto de não cumprir
alguns dos critérios de peso elevado.
Já para a Oferta Modelo 2, embora exista um veto, este não é perceptível, dado que todas as
ofertas cumprem esse critério, embora, cada uma, não cumpra alguns dos critérios de peso relevante,
o que se traduz em resultados parecidos mas mais favoráveis à Oferta 3, devido ao cumprimento de
alguns critérios com bastante peso relativamente às outras ofertas. Para a Oferta Modelo 3, há uma
grande disparidade no resultado, motivada pela existência de uma preferência, cumprida apenas pela
Oferta 1, o que a torna igual à oferta modelo pela aplicação deste critério de medida, o que garante a
preponderância da preferência caso esse critério seja cumprido.
Os testes realizados à aplicação do critério de medida permitem verificar a correcta aplicação
deste e atestam o seu bom comportamento, bem como a real tradução em resultados esperados das
diferenças entre os vários modelos, quer de ofertas quer de perfis.
Foram também efectuados testes de carga, de modo a validar o seu funcionamento em
ambientes de maior solicitação de recursos e onde o tempo de resposta é crítico. Assim, foi testada a
aplicação com um pouco mais de 1000 instâncias das várias entidades definidas na Base de Dados e
não foram detectados aumentos significativos nos tempos de retorno dos dados da Base de Dados,
bem como do tempo de construção por parte do Django das páginas HTML apresentadas aos
utilizadores, tendo estes testes sido efectuados apenas numa máquina, com uma instância do
servidor aplicacional e com uma instância da base de dados em execução sem o clustering MySQL
activo.
Na pesquisa simples, os tempos cifraram-se em 1 segundo para o pior caso colocado, ou seja
uma pesquisa sem qualquer critério seleccionado, quer na pesquisa de perfis, quer na pesquisa de
ofertas. Porém, a pesquisa através do algoritmo de classificação, nas condições apresentadas,
demorou cerca de 20 segundos, quer na pesquisa de perfis, quer na pesquisa de ofertas, tendo-se
verificado um crescimento linear do tempo de pesquisa com o número total de perfis e ofertas, quer
na pesquisa por perfis, quer na pesquisa por ofertas. No capítulo seguinte são apresentadas soluções
de modo a reduzir o tempo das pesquisas, caso este se torne demasiado demorado.
74
5 - CONCLUSÃO
Esta dissertação teve como objectivo o planeamento e desenvolvimento de uma aplicação
que permitisse melhorar a forma de acesso à informação entre os vários intervenientes,
nomeadamente candidatos e empregadores, numa área tão importante como a procura e oferta de
emprego, utilizando para esse efeito um algoritmo de classificação dessa informação.
Iniciou-se o projecto com uma análise dos serviços actualmente disponíveis para os
utilizadores, quer a nível nacional, quer a nível internacional, assinalando quais as funcionalidades
existentes e identificando as características passíveis de serem melhoradas.
Foi desde muito cedo óbvio que uma das grandes lacunas existentes é a correcta
classificação dos perfis dos candidatos por parte dos empregadores, existindo por vezes apenas a
distinção por tipo de emprego ou eventualmente por área profissional. Por outro lado, o mesmo se
passa da parte dos candidatos. Segmentados apenas por estes critérios, torna-se moroso quer para
candidatos, quer para empregadores, a procura e análise das melhores ofertas de emprego
existentes ou dos melhores perfis de candidatos disponíveis, requerendo muitas vezes a análise
individual de cada perfil ou de cada oferta, de modo a obter os dados necessários para a sua correcta
avaliação.
De modo a tornar esta avaliação mais eficaz e mais eficiente, foi desenvolvido um método
que permite efectuar a classificação dos perfis de candidatos e das ofertas de emprego através do
uso de toda a informação disponibilizada, quer por candidatos, quer por empregadores, por forma a
obter uma medida de proximidade entre um perfil ou uma oferta ideal, definida respectivamente por
empregador e candidato, e os vários perfis e ofertas existentes.
A primeira questão colocada centrava-se no universo de utilizadores que teriam interesse em
usufruir desta aplicação. Qualquer pessoa, num ou em vários momentos, decide procurar emprego,
motivada pelas mais diversas razões. Ao nível das empresas é habitual existirem departamentos
específicos dedicados ao recrutamento.
Assim, a aplicação tem de ser acessível da forma mais simples e mais directa possível, sem
necessidade de instalação de software adicional, de modo a permitir que um grande número de
pessoas a utilizem. Por este motivo, optou-se por desenvolver uma aplicação web, acessível por
qualquer pessoa que “navegue” na internet com um browser sem, desta forma, necessitar de instalar
uma nova aplicação, o que para a maioria dos utilizadores seria um entrave à sua utilização.
A segunda questão colocada foi sobre as ferramentas a utilizar para o desenvolvimento da
aplicação. Dado que um site institucional ou informativo é constituído por um número limitado de
páginas HTML, apresentando sempre o mesmo conteúdo ou com pequenas variações deste ao longo
do tempo, uma abordagem simplista utilizando apenas páginas estáticas não nos permitiria aproximar
da solução para o problema identificado. Teria de se desenvolver uma aplicação que permitisse gerar
várias páginas, de forma dinâmica e dependentes das opções tomadas pelo utilizador, necessitando
por isso de ser implementada uma aplicação bastante mais complexa.
A aplicação teria de conseguir receber, guardar e apresentar informação fornecida pelos
75
utilizadores, de forma a disponibilizá-la aos outros utilizadores. Assim foi necessária a utilização de
um Sistema de Gestão de Base de Dados de modo a persistir essa informação.
Todavia, nem toda a informação pode ser disponibilizada a todos os utilizadores, assim como
nem todos os utilizadores têm iguais papéis na aplicação. Assim, foram criados mecanismos de
segurança, de forma a realizar a autenticação e autorização dos vários utilizadores, definindo o
âmbito da utilização da aplicação para os dois tipos de utilizadores (candidatos e empregadores).
Por outro lado, de forma a minimizar o tempo de desenvolvimento e permitir a adição de
novas funcionalidades e a alteração, se necessário, das existentes ao longo do tempo de vida da
aplicação, ou seja da sua manutenção, bem como providenciar um conjunto de ferramentas que
permitissem que o grande enfoque fosse a lógica de funcionamento da aplicação, de modo a cumprir
as funcionalidades necessárias, e não o desafio de resolver questões de implementação, optou-se
por uma linguagem de alto nível (Python) e pela utilização de uma framework (Django) nessa
linguagem, desenhada especificamente para dinamizar o desenvolvimento de aplicações web.
Dado que a aplicação necessita de permitir o uso intensivo por parte de uma quantidade
crescente de utilizadores, houve o cuidado de dotar a aplicação de uma arquitectura que a tornasse
robusta, de modo a maximizar o tempo de serviço, e que lhe permitisse manter a performance com o
aumento de carga.
A robustez é obtida através do uso de componentes redundantes, ou seja, se existir por
qualquer razão uma falha numa máquina, haverá sempre outra que irá preencher essas funções até
haver novamente disponibilidade da primeira para efectuar o serviço, sem a percepção do
acontecimento pelo utilizador, enquanto que a manutenção de performance está associada à
distribuição da carga não apenas para um dos componentes, mas por todos os existentes de forma
igualitária, bem como a possibilidade de em qualquer altura serem acrescentados novos
componentes para que a carga seja também distribuída entre eles.
De modo a que sejam prevenidos à partida alguns erros na aplicação, e a garantir que as
suas funcionalidades estão operacionais e retornam os resultados esperados, optou-se pelo
desenvolvimento orientado por testes, por forma a que cada funcionalidade tivesse um teste, que
falhava aquando da sua falta ou do retorno de um resultado não esperado, prevenindo assim
possíveis falhas futuras não aguardadas.
Conhecidos os requisitos e algumas decisões na realização da aplicação iremos abordar os
fundamentos teóricos que permitiram o seu desenvolvimento e uma descrição detalhada do trabalho
realizado.
Iniciou-se o trabalho, como anteriormente foi referido, por um levantamento das soluções
existentes actualmente. De seguida foi apresentada uma descrição detalhada da framework utilizada,
sendo explanadas as características e potencialidades que a tornaram a escolhida para a realização
da aplicação.
Foi abordado em detalhe o desenvolvimento orientado por testes, avaliado o seu
desempenho como metodologia de programação em comparação com o método tradicional de
desenvolvimento, e foram apresentados os vários passos do método e como proceder de modo a
76
usar esta metodologia em conjunto com o Django.
Foi também explicada como se processa a troca de dados entre o utilizador e a aplicação,
enumerados e detalhados os principais protocolos de comunicação utilizados, nomeadamente o
protocolo HTTP e HTTPS, e foi apresentado o conceito de arquitectura de sistemas REST, definidas
as suas restrições de modo a poder ser aplicado, definido o conceito de recursos, e apresentada a
utilização bem mais alargada do protocolo HTTP através do REST, bem como apresentadas as
vantagens da sua utilização.
Posteriormente foi apresentada a linguagem da resposta recebida e visualizada pelo cliente
(HTML) como resposta à solicitação no servidor dos recursos disponíveis, foram descritas as suas
várias componentes, como folhas de estilo (CSS) que permitem alterar completamente a visualização
do conteúdo enviado ao browser do utilizador, foi brevemente descrita a linguagem de scripting
(JavaScript) que permite a execução de código já depois da resposta ter sido enviada ao cliente, foi
referida a biblioteca de JavaScript utilizada de modo a serem usados alguns métodos para a
realização de pedidos assíncronos ao servidor e foi abordada a forma de envio de informação do
cliente para o servidor usando formulários.
O sistema de templating do Django foi também detalhado, tendo sido um componente
bastante útil na construção desta aplicação, dado que permite, ao máximo, a reutilização de HTML
implementado, não havendo necessidade de existirem várias páginas exactamente com o mesmo
código desenvolvido, com especial enfoque na herança e inclusão.
Foram apresentadas brevemente as principais funções e conceitos subjacentes aos SGBD, o
modelo de dados e a forma de estruturar toda a informação de modo a que esta esteja persistida de
forma coerente, foram introduzidos os modelos Entidade-Relação e Relacional, foi referida a
linguagem de comunicação com o SGBD e foi abordada a camada de abstracção do Django de modo
a permitir a interacção com o SGBD.
Numa vertente mais prática e de já da implementação da solução, foi apresentada a estrutura
de componentes da aplicação, detalhando cada um deles e referindo qual a estrutura ideal de modo a
que a aplicação seja robusta e mantenha um elevado desempenho, mesmo com uma carga
crescente.
Entrando na lógica da aplicação desenvolvida, foram enumeradas as várias entidades criadas
na aplicação, como o utilizador, o candidato e o empregador, a sua constituição em termos de
atributos e as suas relações, foram descritos todos os recursos disponíveis na aplicação, ou seja
todas as acções que os candidatos e empregadores podem realizar, como por exemplo inserir perfis e
ofertas e efectuar pesquisas, bem como os resultados obtidos pela execução de cada uma das
acções.
Foi descrito o processo de registo de utilizadores e foi apresentada a forma de garantir que o
registo é efectuado em total segurança, sem haver o risco de intercepção de informação privada, quer
de candidatos quer de empregadores, assim como foi detalhado o processo de autenticação dos
utilizadores e a gestão das sessões dos utilizadores autenticados a utilizarem a aplicação.
Foi explicado o formato das várias páginas constituintes da aplicação, os seus componentes
77
(cabeçalho, rodapé, bloco esquerdo, direito e central) e a forma de colocar informação acessível
pelos templates, de modo a que os conteúdos das páginas sejam dinâmicos, mas preenchidos de
forma centralizada.
Foi apresentada a possibilidade de internacionalização da aplicação, ou seja, de efectuar a
transposição da linguagem da aplicação para outra qualquer língua, bastando para isso traduzir as
palavras constantes de um ficheiro que contém todas as palavras numa determinada língua.
Foi explicado o modelo de dados definido para a aplicação, constituído pelo conjunto de todas
as tabelas criadas e todos os atributos dessas tabelas. Foi referida a possibilidade de definição, pelo
utilizador, da visibilidade para os outros utilizadores da maior parte dos atributos das entidades,
possibilitando que este omita aos outros determinada informação que não pretenda que seja
conhecida, como por exemplo o seu nome ou o seu número de telefone, ou qual o salário pretendido
num determinado perfil.
A questão das validações da informação introduzida pelo utilizador foi referida, assim como a
diminuição do leque de escolhas de determinadas opções mediante a escolha de outra, da qual as
primeiras são dependentes. Um utilizador ao escolher o país, não tem de escolher de entre todas as
cidades do mundo, mas apenas as correspondentes ao país seleccionado.
Foi ainda detalhada a organização da estrutura de ficheiros do projecto, quer dos ficheiros
usados pelo Django para a sua configuração, quer dos ficheiros que contêm toda a lógica de
funcionamento da aplicação.
Por fim foi abordado em detalhe o algoritmo desenvolvido para efectuar a classificação dos
perfis de candidatos e das ofertas de emprego, tendo sido apresentada a sua definição formal, foi
efectuada a comparação com outras operações de agregação passíveis de serem utilizadas, foram
explicadas as duas pesquisas possíveis, sendo uma a pesquisa por critérios, muito semelhante às já
encontradas noutras aplicações, mas enriquecida com uma grande variedade de possibilidades de
escolha de critérios, e a pesquisa pelo algoritmo de classificação, o que implica a introdução dos
pesos necessários ao algoritmo, bem como vetos e preferências.
Foi ainda apresentada a forma como foi programada a operação de agregação, ou seja o
algoritmo de classificação e foram apresentados resultados de testes com perfis e ofertas contendo
dados fictícios, mas que nos permitem validar o bom comportamento do algoritmo de classificação e a
sua assertividade em termos dos resultados obtidos. Foram também referidos alguns resultados de
testes de carga realizados.
A inovação introduzida por este trabalho centra-se na formalização e implementação de um
algoritmo, cujo objectivo é conseguir calcular distâncias entre informação abstracta e complexa tal
com perfis e ofertas, constituída por valores definidos mas difíceis de modelar. Houve um grande
ênfase na tentativa de minimizar as incoerências provocadas pelos utilizadores na introdução de
dados e por isso reduziu-se ao mínimo a possibilidade, para atributos relevantes, da introdução de
dados de texto, como o país e a cidade. Isto implicou um crescimento substancial do modelo de
dados em tamanho e complexidade, quer em termos de entidades, quer em termos de relações,
78
tendo sido criadas entidades para representar algumas das opções possíveis para o utilizador, e
entidades para representar os graus de semelhança entre instâncias de algumas dessas entidades.
Uma aplicação como a que foi desenvolvida é um projecto que ao longo da sua vida útil será
sempre melhorada, quer a nível de design, quer a nível de novas funcionalidades requeridas, quer a
nível do melhoramento da sua gestão como aplicação.
Alguns dos melhoramentos a introduzir futuramente na aplicação poderão ser a criação de
um Backoffice, de modo a existir uma interface de administração na aplicação, proporcionando que
determinados utilizadores possam, por exemplo, criar mais entradas em entidades como o país, as
cidades, as universidades e os empregos. A existência de um Backoffice poderia também permitir a
introdução de novas semelhanças entre entidades, quando essa relação de semelhança fizer sentido
existir, garantindo dessa forma que a aplicação se mantém com dados sempre actualizados.
Também poderá ser muito útil, o uso de ferramentas de data-mining que proporcionem a
criação de diversos tipos de estatísticas e tratamento da informação existente na Base de Dados da
aplicação. Por outro lado, para uma melhor monitorização da aplicação, seria interessante a criação
de algum reporting, de modo a que regularmente haja informação relevante a ser endereçada a
utilizadores que sejam gestores da aplicação (por exemplo com acesso ao Backoffice).
Em termos de implementação, e de modo a que a aplicação não aguarde que os emails de
aviso ou registo sejam enviados, poder-se-ia criar uma fila de espera assíncrona para o envio de
emails, com outra qualquer aplicação dedicada a tratar do seu envio.
Com o potencial aumento de candidatos, perfis, empregadores e ofertas, para que as
pesquisas se mantenham rápidas, poder-se-ia intensificar o uso de cache, ou integrar um mecanismo
de indexação de perfis o ofertas de modo a minimizar o número de acessos à Base de Dados para as
pesquisas, o que para ordens de grandeza do total de utilizadores superiores aos milhares poderá
constituir um melhoramento a realizar.
Poderia ainda ser também acrescentada uma funcionalidade na página inicial, de modo a
permitir que os utilizadores redefinam a sua password, caso não se recordem da actual, e poderia ser
enviado um aviso aos empregadores quando um determinado tipo de perfil especificado fosse
inserido por um candidato, e enviado um aviso aos candidatos quando um determinado tipo de oferta
fosse introduzida por um empregador. Para complementar os dados do candidato, poderia ser
acrescentada uma fotografia ao perfil e permitir que o candidato submeta um ficheiro contendo o seu
currículo, de modo a que seja acessível aos empregadores.
Embora tenha sido experimentado o algoritmo desenvolvido com sucesso, tal não é
impeditivo de se tentar melhorar o algoritmo utilizado na aplicação, por forma a obter ainda melhores
resultados nas pesquisas.
79
Bibliografia[1] Beck, Kent, Extreme Programming Explained: Embrace Change, Addison Wesley, 1999
[2] Beck, Kent, Test-Driven Development By Example, Addison Wesley, 2002
[3] Ben-Kiki, O., Evans, C., Net, I., YAML Ain’t Markup Language - Specification, YAML, 2009
[4] Bergsten, H., Java Server Pages, O'Reilly, 2000
[5] Brittain, J., Darwin, I., Tomcat: The Definitive Guide, O'Reilly, 2007
[6] Chamberlin, D., Boyce, R., SEQUEL: A Structured English Query Language, Proceedings of the
1974 ACM SIGFIDET Workshop, 1974
[7] Chappell, D., Understanding .NET, O'Reilly, 2006
[8] Chen, P., The Entity Relationship Model: Toward a Unified View of Data, ACM Transactions on
Database Systems, Vol. 1, Nº 1, 1976
[9] Cheswick, William R., Bellovin, Steven M., Rubin, Aviel D., Firewalls and Internet Security;
Repelling the Wily Hacker, ,
[10] Chown, P., Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security
(TLS), RFC3268, 2002
[11] Codd E., The Relational Model for Database Management, Addison-Wesley, 1990
[12] Coombs, J., Renear, A., DeRose, S., Markup Systems and the Future of Scholarly Text
Processing, Communications of the ACM, 1987
[13] Cooper, D., Santesson, S., Farrell, S., Boyen, S. Housley, R., Polk, W., Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List (CRL) Profile, RFC5280, 2008
[14] Cooper, M., Dzambasow, Y., Hesse, P., Joseph, S., Nicholas, R., Internet X.509 Public Key
Infrastructure: Certification Path Building, RFC4158, 2005
[15] Crespo, R., Processadores de Linguagens – da Concepção à Implementação, IST Press, 2001
[16] Crockford, D., The application/json Media Type for JavaScript Object Notation (JSON), RFC4627,
2006
[17] Dierks, T., Allen, C., The TLS Protocol Version 1.0, RFC2246, 1999
[18] Dierks, T., Rescorla E., The Transport Layer Security (TLS) Protocol Version 1.1, RFC4346,
2006
[19] Dierks, T., Rescorla E., The Transport Layer Security (TLS) Protocol Version 1.2, RFC5246,
2008
[20] Eby, P., Python Web Server Gateway Interface v1.0, PEP 333, 2003
[21] Fielding, R. T., Architectural Styles and the Design of Network-Based Software Architectures,
PhD Dissertation. Dept. of Information and Computer Science, University of California, Irvine., 2000
[22] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., Berners-Lee, T., Hypertext
Transfer Protocol - HTTP/1.1, RFC2616, 1999
[23] Flanagan, D., JavaScript: The Definitive Guide, O'Reilly, 2006
[24] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., Stewart, L.,
HTTP Authentication: Basic and Digest Access Authentication, RFC2617, 1999
[25] Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types,
80
RFC2046, 1996
[26] Freed, N., Borenstein, N., Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance
Criteria and Examples, RFC2049, 1996
[27] Freed, N., Borenstein, N., Multipurpose internet mail extensions (MIME) Part One: Format of
internet message bodies, RFC2045, 1996
[28] Freed, N., Klensin, J., Postel, J., Multipurpose Internet Mail Extensions (MIME) Part Four:
Registration Procedures, RFC2048, 1996
[29] Goodman, D. Morrison, M., JavaScript Bible, John Wiley and Sons, 2004
[30] Grabish, M., Orlovski, S., Yager, R., Fuzzy Aggregation of Numerical Preferences, Paper, 1999
[31] Henderson, C., Building Scalable Web Sites - Building, Scaling, and Optimizing the Next
Generation of Web Applications, O'Reilly, 2006
[32] Hoffman, P., The WAIS URI Scheme, RFC4156, 2005
[33] Holdener A., Ajax: The Definitive Guide, O'Reilly, 2008
[34] Holovaty, A., Kaplan-Moss, J., The Definitive Guide to Django - Web Development Done Right,
Apress, 2009
[35] Hunt, Andrew, Thomas, David, The Pragmatic Programmer: From Journeyman to Master,
Addison Wesley, 1999
[36] Juneau, J., Baker, J., Ng, V., Wierzbicki, F., Munoz, L., Definitive Guide to Jython, Apress, 2010
[37] Khare, R., Lawrence, S., Upgrading to TLS Within HTTP/1.1, RFC2817, 2000
[38] Kristol, D., Montulli, L., HTTP State Management Mechanism, RFC2965, 2000
[39] Kronke, D., Database Processing: Fundamentals, Design, and Implementation, Prentice Hall,
2005
[40] Kurose, James F., Ross, Keith W., Computer Networking, a Top-Down Approach Featuring the
Internet (3ª Edição), Addison Wesley, 2005
[41] Lamport, L., LaTeX: A Document Preparation System, Addison-Wesley, 1994
[42] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., Jones, L., SOCKS Protocol Version 5,
RFC1928, 1996
[43] Lindley, C., jQuery Cookbook: Solutions & Examples for jQuery Developers, O'Reilly, 2009
[44] Luotonen, A., Tunneling TCP based protocols through Web proxy servers, Paper, 1998
[45] Lutz, M., Learning Python, O'Reilly, 2009
[46] Moats, R., URN Syntax, RFC2141, 1997
[47] Mockapetris, P., Domain Names - Concepts and Facilities, RFC1034, 1987
[48] Mockapetris, P., Domain Names - Implementation and Specification, RFC1035, 1987
[49] Moore, K., MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header
Extensions for Non-ASCII Text, RFC2047, 1996
[50] Otte, R., Patrick, P., Roy, M., Understanding CORBA, Prentice Hall, 1995
[51] Pierre, M., Fullton, J., Gamiel, K., Goldman, J., Kahle, B., Junze, J., Morris, H., Schiettecatte, F.,
WAIS over Z39.50-1988, RFC1625, 1994
[52] Postel, J., Reynolds. J., File Transfer Protocol (FTP), RFC959, 1985
81
[53] Reenskaug, Trygve, The Model-View-Controller (MVC): Its Past and Present, Paper, 2003
[54] Reid, G., Thinking in PostScript, Addison-Wesley, 1990
[55] Rescorla E., HTTP Over TLS, RFC2818, 2000
[56] Richardson, L., Ruby, S., RESTful Web Services, O'Reilly, 2007
[57] Ruby, S., Thomas, D., Hansson, D., Agile Web Development with Rails, The Pragmatic
Bookshelf, 2009
[58] Rusty, E., Effective XML, Addison-Wesley, 2004
[59] Schmitt, C., CSS Cookbook, O'Reilly, 2009
[60] Silberschatz, A., Korth, H., Sudarshan, S., Database System Concepts, McGraw-Hill, 2001
[61] Sollins, K., Masinter, L., Functional Requirements for Uniform Resource Names, RFC1737, 1994
[62] W3C CSS Working Group, Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification,
W3C, 2009
[63] W3C DOM Working Group, Document Object Model (DOM) Level 2 Core Specification, W3C,
2000
[64] W3C HTML Working Group, HTML 5.0, W3C, 2010
[65] W3C HTML Working Group, XHTML 1.1 Specification, W3C, 2001
[66] Weisfield, Matt., The Object-Oriented Thought Process, Paperback, 2008
[67] Xu, R., Wunsh, D., Clustering (IEEE Press Series on Computational Intelligence), John Wiley and
Sons, 2009
[68] Zimmerman, Hubert, IEEE Transactions and Communications, Vol COM-28, Nº 4, Paper, 1980
82
Anexo A – Operações básicas sobre o SGBD
Definimos os seguintes modelos como base para os exemplos:
class Library(models.Model):
name = models.CharField(max_length=200)
address = models.CharField(max_length=200)
class Book(models.Model):
library = models.ForeignKey(Library)
name = models.CharField(max_length=200)
author = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
• Retornar uma lista com todos os objectos do modelo “Book”:
◦ book_list = Book.objects.all()
• Retornar uma lista com todos os objectos do modelo “Book” associados a uma “Library”
anteriormente retornada, ordenando por ordem descendente de “autor”:
◦ library = Library.objects.get(name = “City”)
◦ book_list = Book.objects.fiter(library = library).order_by(“-author”)
• Inserir um novo objecto “Library”:
◦ library = Library(name='LibName', address='LibAddress')
◦ library.save()
• Alterar o nome de um objecto “Library” depois de retornado:
◦ library = Library.objects.get(name = “City Library”)
◦ library.name = “Town Library”
◦ library.save()
• Apagar um ou vários objectos “Library” cujo atributo “address” é “Street A”
◦ Library.objects.filter(address = “Street A”).delete()
83
Anexo B – Métodos para obtenção de semelhanças
São aqui descritos os métodos de cálculo das semelhanças entre atributos, sendo que o valor
1 corresponde a uma semelhança total e o valor 0 corresponde a não existir qualquer semelhança.
Alguns dos atributos especificados correspondem apenas à entidade perfil, outros atributos
correspondem apenas à entidade oferta e existem atributos comuns correspondentes às duas
entidades.
Os métodos de cálculo são precedidos da(s) entidade(s) a que se referem.
Perfil e Oferta: cidade
Se cidade1 = cidade2, semelhança = 1, c.c semelhança = 0
Perfil e Oferta: país
Se país1 = país2, semelhança = 1, c.c semelhança = 0
Oferta: distância máxima ao local de trabalho
Se distancia1 < distancia2 (do modelo) , semelhança = 1
Se |distancia1 – distancia2| > 100, semelhança = 0
semelhança = (100 – |distancia1 – distancia2|) / 100
Perfil e Oferta: grau académico
Se grau académico1 = grau académico2, semelhança = 1
Se existir academicdegreesimilarity(grau académico1,grau académico2)
semelhança = academicdegreesimilarity(grau académico1,grau académico2)
c.c semelhança = 0
Perfil e Oferta: universidade
Se universidade1 = universidade2, semelhança = 1
Se existir universitysimilarity(universidade1,universidade2)
semelhança = universitysimilarity(universidade1,universidade2)
c.c semelhança = 0
Perfil e Oferta: curso
Se curso1 = curso2, semelhança = 1
Se existir academiccoursesimilarity(curso1,curso2)
semelhança = academiccoursesimilarity(curso1,curso2)
c.c semelhança = 0
84
Perfil e Oferta: curso completo
Se curso completo1 = curso completo2, semelhança = 1, c.c semelhança = 0
Oferta: média de curso
Se média de curso1 < média de curso2 (do modelo), semelhança = 1
Se média de curso1 > média de curso2 – 5 (do modelo), semelhança = 0
semelhança = (5 – |média de curso1 – média de curso2|) / 5
Perfil: média de curso
Se média de curso1 > média de curso2 (do modelo), semelhança = 1
Se média de curso1 < média de curso2 – 5 (do modelo), semelhança = 0
semelhança = (5 – |média de curso1 – média de curso2|) / 5
Perfil e Oferta: área profissional
Se área profissional1 = área profissional2, semelhança = 1
Se existir jobareasimilarity(área profissional1,área profissional2)
semelhança = jobareasimilarity(área profissional1,área profissional2)
c.c semelhança = 0
Perfil e Oferta: emprego
Se emprego1 = emprego2, semelhança = 1
Se existir jobsimilarity(emprego1,emprego2)
semelhança = jobsimilarity(emprego1,emprego2)
c.c semelhança = 0
Perfil e Oferta: palavras chave
Calcular total de palavras chave no modelo
Calcular total de palavras chave no comparado
Calcular total de palavras chave iguais
Se total de palavras chave no modelo = 0, semelhança = 0
semelhança = total de palavras chave iguais / total de palavras chave no modelo
Oferta: experiência profissional na área (meses)
Se epa1 < epa2 (do modelo), semelhança = 1
Se |epa1 – epa2| > 100, semelhança = 0
semelhança = (100 – |epa1 – epa2|) / 100
85
Perfil: experiência profissional na área (meses)
Se epa1 > epa2 (do modelo), semelhança = 1
Se |epa1 – epa2| > 100, semelhança = 0
semelhança = (100 – |epa1 – epa2|) / 100
Oferta: dias para início de actividade
Se dia1 > dia2 (do modelo), semelhança = 1
Se |epa1 – epa2| > 30, semelhança = 0
semelhança = (30 – |epa1 – epa2|) / 30
Perfil: dias para início de actividade
Se dia1 < dia2 (do modelo), semelhança = 1
Se |epa1 – epa2| > 30, semelhança = 0
semelhança = (30 – |epa1 – epa2|) / 30
Oferta: horas disponíveis por dia
Se hdd1 <= hdd2 (do modelo), semelhança = 1, c.c semelhança = 0
Perfil: horas disponíveis por dia
Se hdd1 >= hdd2 (do modelo), semelhança = 1, c.c semelhança = 0
Oferta: horas de diária de início de actividade
Se hdia1 >= hdia2 (do modelo), semelhança = 1, c.c semelhança = 0
Perfil: horas de diária de início de actividade
Se hdia1 <= hdia2 (do modelo), semelhança = 1, c.c semelhança = 0
Oferta: horas de diária de fim de actividade
Se hdfa1 <= hdfa2 (do modelo), semelhança = 1, c.c semelhança = 0
Perfil: horas de diária de fim de actividade
Se hdfa1 >= hdfa2 (do modelo), semelhança = 1, c.c semelhança = 0
Oferta: disponibilidade para viajar
Se dv1 <= dv2 (do modelo), semelhança = 1, c.c semelhança = 0
Perfil: disponibilidade para viajar
Se dv1 >= dv2 (do modelo), semelhança = 1, c.c semelhança = 0
86
Oferta: carta de condução
Se dv1 <= dv2 (do modelo), semelhança = 1, c.c semelhança = 0
Perfil: carta de condução
Se dv1 >= dv2 (do modelo), semelhança = 1, c.c semelhança = 0
Oferta: salário em euros
Se se1 >= se2 (modelo), semelhança = 1
Calcular metade do salário do modelo
Se se1 < metade do salário do modelo, semelhança = 0
semelhança = (metade do salário do modelo - (se2 - se1)) / metade do salário do modelo
Perfil: salário em euros
Se se1 <= se2 (modelo), semelhança = 1
Calcular dobro do salário do modelo
Se se1 > dobro do salário do modelo, semelhança = 0
semelhança = (dobro do salário do modelo - (se1 - se2)) / dobro do salário do modelo
Oferta: salário máximo em euros
Se sme1 >= sme2 (modelo), semelhança = 1, c.c semelhança = 0
Perfil: salário mínimo em euros
Se sme1 <= sme2 (modelo), semelhança = 1, c.c semelhança = 0
Perfil: data de início de curso superior
Se ics1 >= ics2 (modelo), semelhança = 1, c.c semelhança = 0
Perfil: data de fim de curso superior
Se ics1 <= ics2 (modelo), semelhança = 1, c.c semelhança = 0
Perfil: experiência profissional total (meses)
Se ept1 > ept2 (do modelo), semelhança = 1
Se |ept1 – ept2| > 100, semelhança = 0
semelhança = (100 – |ept1 – ept2|) / 100
87
Anexo C – Modelo Relacional de Dados (Entidades)marketplace_user
pk id INT(11)username VARCHAR(40)password VARCHAR(200)active TINYINT(1)expired TINYINT(1)creation_date DATE
nl expiration_date DATElast_access_date DATEtype VARCHAR(1)
Tabela 14: Entidade User
marketplace_candidatepk id INT(11)fk user_id INT(11)
first_name VARCHAR(40)last_name VARCHAR(40)middle_names VARCHAR(80)address VARCHAR(200)zip_code VARCHAR(15)zip_code_city VARCHAR(40)
fk city_id INT(11)fk country_id INT(11)
birth_date DATEemail VARCHAR(200)phone VARCHAR(14)mobile VARCHAR(14)active TINYINT(1)gender TINYINT(1)visibility_first_name INT(11)vivsibility_last_name INT(11)visibility_middle_names INT(11)visibility_address INT(11)visibility_zip_code INT(11)visibility_zip_code_city INT(11)visibility_birth_date INT(11)visibility_email INT(11)visibility_phone INT(11)visibility_mobile INT(11)visibility_gender INT(11)
Tabela 15: Entidade Candidate
marketplace_candidatebookmarkedofferpk id INT(11)fk candidate_id INT(11)fk offer_id INT(11)
bookmarked_date DATETIME
Tabela 16: Entidade CandidateBookmarkedOffer
88
marketplace_companypk id INT(11)fk user_id INT(11)
company_name VARCHAR(200)nif VARCHAR(14)email VARCHAR(200)phone1 VARCHAR(14)phone2 VARCHAR(14)fax VARCHAR(14)address VARCHAR(200)zip_code VARCHAR(15)zip_code_city VARCHAR(40)
fk city_id INT(11)fk country_id INT(11)
visibility_company_name INT(11)visibility_nif INT(11)visibility_email INT(11)visibility_phone1 INT(11)visibility_phone2 INT(11)visibility_fax INT(11)visibility_address INT(11)visibility_zip_code INT(11)visibility_zip_code_city INT(11)
Tabela 17: Entidade Company
marketplace_authenticationticketpk id INT(11)fk user_id INT(11)
ticket VARCHAR(200)state INT(11)creation_date DATETIME
nl usage_date DATETIMEexpiration_date DATETIMEdescription VARCHAR(400)duration_months INT(11)company VARCHAR(50)visibility INT(11)
Tabela 18: Entidade AuthenticationTicket
marketplace_candidateareamaintechnologypk id INT(11)fk profile_id INT(11)
technology VARCHAR(80)description VARCHAR(200)experience_months INT(11)visibility INT(11)
Tabela 19: Entidade CandidateAreaMainTechnology
89
marketplace_candidateprofilepk id INT(11)fk candidate_id INT(11)
profile_name VARCHAR(40)fk appliance_city_id INT(11)fk appliance_country_id INT(11)fk academic_degree_id INT(11)
fk, nl academic_school_id INT(11)fk, nl academic_course_id INT(11)
is_complete TINYINT(1)course_start_date DATEcourse_end_date DATEcourse_average INT(11)prof_experience_time_months INT(11)prof_experience_area_time_months INT(11)
fk appliance_job_area_id INT(11)fk appliance_job_id INT(11)
appliance_job_key_words VARCHAR(200)appliance_job_description VARCHAR(200)available_start_time_days INT(11)available_hours INT(11)available_hours_from INT(11)available_hours_to INT(11)available_travel TINYINT(1)driver_license TINYINT(1)salary_euros INT(11)salary_euros_min INT(11)creation_date DATETIMEvisibility_profile_name INT(11)visibility_academic_school INT(11)visibility_course_start_date INT(11)visibility_course_end_date INT(11)visibility_course_average INT(11)visibility_is_complete INT(11)visibility_appliance_job_key_words INT(11)visibility_prof_experience_time_months INT(11)visibility_prof_experience_area_time_months INT(11)visibility_available_start_time_days INT(11)visibility_available_hours INT(11)visibility_available_hours_from INT(11)visibility_available_hours_to INT(11)visibility_available_travel INT(11)visibility_driver_license INT(11)visibility_salary_euros INT(11)
Tabela 20: Entidade CandidateProfile
marketplace_candidateappliedofferpk id INT(11)fk candidate_id INT(11)fk offer_id INT(11)
appliance_date DATETIME
Tabela 21: Entidade CandidateAppliedOffer
90
marketplace_companyofferpk id INT(11)fk company_id INT(11)
offer_name VARCHAR(50)working_place_address VARCHAR(200)
fk working_place_country_id INT(11)fk working_place_city_id INT(11)
working_place_max_distance_km INT(11)fk academic_degree_id INT(11)
fk, nl academic_school_id INT(11)fk, nl academic_course_id INT(11)
is_complete TINYINT(1)course_average INT(11)
fk job_area_id INT(11)fk job_id INT(11)
job_key_words VARCHAR(200)job_description VARCHAR(200)prof_experience_area_time_months INT(11)available_start_time_days INT(11)available_day_hours INT(11)available_hours_from INT(11)available_hours_to INT(11)available_travel TINYINT(1)driver_license TINYINT(1)salary_euros INT(11)salary_euros_max INT(11)creation_date DATETIMEvisibility_offer_name INT(11)visibility_working_place_address INT(11)visibility_working_place_max_distance_km INT(11)visibility_woring_place_city INT(11)visibility_is_complete INT(11)visibility_course_average INT(11)visibility_job_key_words INT(11)visibility_prof_experience_area_time_months INT(11)visibility_available_start_time_days INT(11)visibility_available_day_hours INT(11)visibility_available_hours_from INT(11)visibility_available_hours_to INT(11)visibility_prof_experience_time_months INT(11)visibility_available_travel INT(11)visibility_driver_license INT(11)visibility_salary_euros INT(11)
Tabela 22: Entidade CompanyOffer
marketplace_countrypk id INT(11)
country_name VARCHAR(200)
Tabela 23: Entidade Country
91
marketplace_candidateareamainfunctionpk id INT(11)fk profile_id INT(11)
function VARCHAR(80)description VARCHAR(200)company_name VARCHAR(80)experience_months INT(11)visibility INT(11)
Tabela 24: Entidade CandidateAreaMainFunction
marketplace_candidateprofessionalcoursepk id INT(11)fk profile_id INT(11)
professional_course VARCHAR(80)description VARCHAR(200)start_date DATEduration_hours INT(11)visibility INT(11)
Tabela 25: Entidade CandidateProfessionalCourse
marketplace_candidateoldjobpk id INT(11)fk candidate_id INT(11)fk job_area_id INT(11)fk job_id INT(11)
description VARCHAR(400)duration_months INT(11)company VARCHAR(50)visibility INT(11)
Tabela 26: Entidade CandidateOldJob
marketplace_companybookmarkedprofilepk id INT(11)fk company_id INT(11)fk profile_id INT(11)
bookmarked_date DATETIME
Tabela 27: Entidade CompanyBookmarkedProfile
marketplace_citypk id INT(11)fk country_id INT(11)
city_name VARCHAR(50)
Tabela 28: Entidade City
92
marketplace_candidatemodelofferpk id INT(11)fk candidate_id INT(11)fk working_place_city_id INT(11)fk working_place_country_id INT(11)
working_place_max_distance_km INT(11)fk academic_degree_id INT(11)
fk, nl academic_school_id INT(11)fk, nl academic_course_id INT(11)
is_complete TINYINT(1)course_average INT(11)
fk job_area_id INT(11)fk job_id INT(11)
job_key_words VARCHAR(200)prof_experience_area_time_months INT(11)available_start_time_days INT(11)available_day_hours INT(11)available_hours_from INT(11)available_hours_to INT(11)available_travel TINYINT(1)driver_license TINYINT(1)salary_euros INT(11)salary_euros_max INT(11)weight_working_place_city_id INT(11)weight_working_place_country_id INT(11)weight_working_place_max_distance_km INT(11)weight_academic_degree_id INT(11)weight_academic_school_id INT(11)weight_academic_course_id INT(11)weight_is_complete INT(11)weight_course_average INT(11)weight_job_area_id INT(11)weight_job_id INT(11)weight_job_key_words INT(11)weight_prof_experience_area_time_months INT(11)weight_available_start_time_days INT(11)weight_available_day_hours INT(11)weight_available_hours_from INT(11)weight_available_hours_to INT(11)weight_available_travel INT(11)weight_driver_license INT(11)weight_salary_euros INT(11)weight_salary_euros_max INT(11)veto_working_place_city_id TINYINT(1)veto_working_place_country_id TINYINT(1)veto_working_place_max_distance_km TINYINT(1)veto_academic_degree_id TINYINT(1)veto_academic_school_id TINYINT(1)veto_academic_course_id TINYINT(1)veto_is_complete TINYINT(1)veto_course_average TINYINT(1)veto_job_area_id TINYINT(1)veto_job_id TINYINT(1)veto_job_key_words TINYINT(1)veto_prof_experience_area_time_months TINYINT(1)veto_available_start_time_days TINYINT(1)
93
marketplace_candidatemodelofferveto_available_day_hours TINYINT(1)veto_available_hours_from TINYINT(1)veto_available_hours_to TINYINT(1)veto_available_travel TINYINT(1)veto_driver_license TINYINT(1)veto_salary_euros TINYINT(1)veto_salary_euros_max TINYINT(1)pref_working_place_city_id TINYINT(1)pref_working_place_country_id TINYINT(1)pref_working_place_max_distance_km TINYINT(1)pref_academic_degree_id TINYINT(1)pref_academic_school_id TINYINT(1)pref_academic_course_id TINYINT(1)pref_is_complete TINYINT(1)pref_course_average TINYINT(1)pref_job_area_id TINYINT(1)pref_job_id TINYINT(1)pref_job_key_words TINYINT(1)pref_prof_experience_area_time_months TINYINT(1)pref_available_start_time_days TINYINT(1)pref_available_day_hours TINYINT(1)pref_available_hours_from TINYINT(1)pref_available_hours_to TINYINT(1)pref_available_travel TINYINT(1)pref_driver_license TINYINT(1)pref_salary_euros TINYINT(1)pref_salary_euros_max TINYINT(1)
Tabela 29: Entidade CandidateModelOffer
marketplace_companyappliedprofilepk id INT(11)fk company_id INT(11)fk profile_id INT(11)
appliance_date DATETIME
Tabela 30: Entidade CompanyAppliedProfile
marketplace_universitypk id INT(11)fk country_id INT(11)
university_name VARCHAR(200)short_name VARCHAR(20)
Tabela 31: Entidade University
marketplace_jobsimilaritypk id INT(11)fk job_one_id INT(11)fk job_two_id INT(11)
similarity DECIMAL(3,2)
Tabela 32: Entidade JobSimilarity
94
marketplace_companymodelprofilepk id INT(11)fk company_id INT(11)fk appliance_city_id INT(11)fk appliance_country_id INT(11)fk academic_degree_id INT(11)
fk, nl academic_school_id INT(11)fk, nl academic_course_id INT(11)
is_complete TINYINT(1)course_start_date DATEcourse_end_date DATEcourse_average INT(11)prof_experience_time_months INT(11)prof_experience_area_time_months INT(11)
fk appliance_job_area_id INT(11)fk appliance_job_id INT(11)
appliance_job_key_words VARCHAR(200)available_start_time_days INT(11)available_hours INT(11)available_hours_from INT(11)available_hours_to INT(11)available_travel TINYINT(1)driver_license TINYINT(1)salary_euros INT(11)salary_euros_min INT(11)weight_appliance_city_id INT(11)weight_appliance_country_id INT(11)weight_academic_degree_id INT(11)weight_academic_school_id INT(11)weight_academic_course_id INT(11)weight_is_complete INT(11)weight_course_start_date INT(11)weight_course_end_date INT(11)weight_course_average INT(11)weight_prof_experience_time_months INT(11)weight_prof_experience_area_time_months INT(11)weight_appliance_job_area_id INT(11)weight_appliance_job_id INT(11)weight_appliance_job_key_words INT(11)weight_available_start_time_days INT(11)weight_available_hours INT(11)weight_available_hours_from INT(11)weight_available_hours_to INT(11)weight_available_travel INT(11)weight_driver_license INT(11)weight_salary_euros INT(11)weight_salary_euros_min INT(11)veto_appliance_city_id TINYINT(1)veto_appliance_country_id TINYINT(1)veto_academic_degree_id TINYINT(1)veto_academic_school_id TINYINT(1)veto_academic_course_id TINYINT(1)veto_is_complete TINYINT(1)veto_course_start_date TINYINT(1)veto_course_end_date TINYINT(1)veto_course_average TINYINT(1)
95
marketplace_companymodelprofileveto_prof_experience_time_months TINYINT(1)veto_prof_experience_area_time_months TINYINT(1)veto_appliance_job_area_id TINYINT(1)veto_appliance_job_id TINYINT(1)veto_appliance_job_key_words TINYINT(1)veto_available_start_time_days TINYINT(1)veto_available_hours TINYINT(1)veto_available_hours_from TINYINT(1)veto_available_hours_to TINYINT(1)veto_available_travel TINYINT(1)veto_driver_license TINYINT(1)veto_salary_euros TINYINT(1)veto_salary_euros_min TINYINT(1)pref_appliance_city_id TINYINT(1)pref_appliance_country_id TINYINT(1)pref_academic_degree_id TINYINT(1)pref_academic_school_id TINYINT(1)pref_academic_course_id TINYINT(1)pref_is_complete TINYINT(1)pref_course_start_date TINYINT(1)pref_course_end_date TINYINT(1)pref_course_average TINYINT(1)pref_prof_experience_time_months TINYINT(1)pref_prof_experience_area_time_months TINYINT(1)pref_appliance_job_area_id TINYINT(1)pref_appliance_job_id TINYINT(1)pref_appliance_job_key_words TINYINT(1)pref_available_start_time_days TINYINT(1)pref_available_hours TINYINT(1)pref_available_hours_from TINYINT(1)pref_available_hours_to TINYINT(1)pref_available_travel TINYINT(1)pref_driver_license TINYINT(1)pref_salary_euros TINYINT(1)pref_salary_euros_min TINYINT(1)
Tabela 33: Entidade CompanyModelProfile
marketplace_universitycoursepk id INT(11)fk university_id INT(11)
course_name VARCHAR(200)
Tabela 34: Entidade UniversityCourse
marketplace_academicdegreepk id INT(11)fk country_id INT(11)
degree VARCHAR(100)
Tabela 35: Entidade AcademicDegree
96
marketplace_jobareapk id INT(11)
country_id INT(11)area_name VARCHAR(100)
Tabela 36: Entidade JobArea
marketplace_jobpk id INT(11)fk job_area_id INT(11)
job_name VARCHAR(100)
Tabela 37: Entidade Job
marketplace_universitysimilaritypk id INT(11)fk university_one_id INT(11)fk university_two_id INT(11)
similarity DECIMAL(3,2)
Tabela 38: Entidade UniversitySimilarity
marketplace_universitycoursesimilaritypk id INT(11)fk university_course_one_id INT(11)fk university_course_two_id INT(11)
similarity DECIMAL(3,2)
Tabela 39: Entidade UniversityCourseSimilarity
marketplace_academicdegreesimilaritypk id INT(11)fk academic_degree_one_id INT(11)fk academic_degree_two_id INT(11)
similarity DECIMAL(3,2)
Tabela 40: Entidade AcademicDegreeSimilarity
marketplace_jobareasimilaritypk id INT(11)fk job_area_one_id INT(11)fk job_area_two_id INT(11)
similarity DECIMAL(3,2)
Tabela 41: Entidade JobAreaSimilarity
Legenda:
pk - chave-primária nl - atributo com possibilidade de ser nulo
fk - chave-estrangeira
97
Anexo D – Modelo Relacional de Dados (Relações)
User 1,1 – 0,N AuthenticationTicket
User 1,1 – 0,1 Candidate
User 1,1 – 0,1 Company
Country 1,1 – 0,N City
Country 1,1 – 0,N University
Country 1,1 – 0,N AcademicDegree
Country 1,1 – 0,N JobArea
Country 1,1 – 0,N Candidate
Country 1,1 – 0,N CandidateProfile
Country 1,1 – 0,N CandidateModelOffer
Country 1,1 – 0,N Company
Country 1,1 – 0,N CompanyOffer
Country 1,1 – 0,N CompanyModelProfile
City 1,1 – 0,N Candidate
City 1,1 – 0,N CandidateProfile
City 1,1 – 0,N Company
City 1,1 – 0,N CompanyOffer
City 1,1 – 0,N CandidateModelOffer
City 1,1 – 0,N CompanyModelProfile
JobArea 1,1 – 0,N Job
JobArea 1,1 – 0,N JobAreaSimilarity (2 chaves-estrangeiras)
JobArea 1,1 – 0,N CandidateProfile
JobArea 1,1 – 0,N CandidateOldJob
JobArea 1,1 – 0,N CandidateModelOffer
JobArea 1,1 – 0,N CompanyOffer
JobArea 1,1 – 0,N CompanyModelProfile
Job 1,1 – 0,N JobSimilarity (2 chaves-estrangeiras)
Job 1,1 – 0,N CandidateProfile
Job 1,1 – 0,N CandidateOldJob
Job 1,1 – 0,N CandidateModelOffer
Job 1,1 – 0,N CompanyOffer
Job 1,1 – 0,N CompanyModelProfile
University 1,1 – 0,N UniversitySimilarity (2 chaves-estrangeiras)
University 1,1 – 0,N UniversityCourse
University 0,1 – 0,N CandidateProfile
University 0,1 – 0,N CandidateModelOffer
98
University 0,1 – 0,N CompanyOffer
University 0,1 – 0,N CompanyModelProfile
UniversityCourse 0,1 – 0,N UniversityCourseSimilarity (2 chaves-estrangeiras)
UniversityCourse 0,1 – 0,N CandidateProfile
UniversityCourse 0,1 – 0,N CandidateModelOffer
UniversityCourse 0,1 – 0,N CompanyOffer
UniversityCourse 0,1 – 0,N CompanyModelProfile
AcademicDegree 1,1 – 0,N AcademicDegree Similarity (2 chaves-estrangeiras)
AcademicDegree 1,1 – 0,N CandidateProfile
AcademicDegree 1,1 – 0,N CandidateModelOffer
AcademicDegree 1,1 – 0,N CompanyOffer
AcademicDegree 1,1 – 0,N CompanyModelProfile
Candidate 1,1 – 0,N CandidateProfile
Candidate 1,1 – 0,N CandidateOldJob
Candidate 1,1 – 0,N CandidateModelOffer
Candidate 1,1 – 0,N CandidateBookmarkedOffer
Candidate 1,1 – 0,N CandidateAppliedOffer
Company 1,1 – 0,N CompanyOffer
Company 1,1 – 0,N CompanyModelProfile
Company 1,1 – 0,N CompanyBookmarkedProfile
Company 1,1 – 0,N CompanyAppliedProfile
CandidateProfile 1,1 – 0,N CandidateAreaMainTechnology
CandidateProfile 1,1 – 0,N CandidateAreaMainFunction
CandidateProfile 1,1 – 0,N CandidateProfessionalCourse
CandidateProfile 1,1 – 0,N CompanyBookMarkedProfile
CandidateProfile 1,1 – 0,N CompanyAppliedProfile
CompanyOffer 1,1 – 0,N CandidateBookmarkedOffer
CompanyOffer 1,1 – 0,N CandidateAppliedOffer
Legenda:
1,1: Participação obrigatória, Cardinalidade 1
0,1: Participação facultativa, Cardinalidade 1
0,N: Participação facultativa, Cardinalidade N
99
