Intelligent e-job Marketplace

Transcrição

1 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 2

2 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

3 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

4 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

5 ÍNDICE Agradecimentos... 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 - Introdução Motivação Objectivos Breve Abordagem sobre sites existentes Conteúdo Teórico Django Introdução ao Django Estrutura de um Projecto Django Linguagem de Programação Python Desenvolvimento orientado por testes Descrição e objectivos Programação em TDD TDD comparado ao Método Tradicional Processo de codificação de testes Testes como documentação Testes no Django Interacção Cliente Servidor Request - Response O protocolo HTTP O protocolo HTTPS REST Representational State Transfer Restrições da arquitectura REST Elementos da arquitectura REST A interface REST aplicada ao protocolo HTTP Vantagens do uso de uma interface REST Interpretação da Resposta Browser HTML - HyperText Markup Language CSS Cascade Style Sheet JavaScript JQuery v

6 Formulários Linguagem de Templating Geração de páginas dinâmicas Vantagens do uso de Templating Sistema de Templating do Django Funcionalidades O Sistema de Herança Notas sobre o uso de templating Acesso ao SGBD Definição de SGBD Modelos de Dados Linguagem de Base de Dados Relacional Django camada de acesso ao SGBD Escolha de SGBD Trabalho Desenvolvido Infra-estrutura Arquitectura Servidor HTTP Servidor Aplicacional SGBD Memcached Sistema Operativo A Aplicação Entidades e Relações Descrição dos Recursos da Aplicação Registo de utilizadores Sessões e Autenticação Estrutura dos Documentos HTML Gerados Logging Internacionalização Modelo de Dados Desenvolvido Visibilidade dos atributos Opções de campos dependentes de escolhas Validação dos Atributos introduzidos Estrutura de Directorias e ficheiros Algoritmo de Classificação de Perfis e Ofertas Conceito de Agregação Critério de Medida Comparação entre os Critérios de Medida Pesquisas vi

7 Implementação da Operação de Agregação Testes Efectuados e Resultados Conclusão Bibliografia... 8 Anexo A Operações básicas sobre o SGBD 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

8 LISTA DE FIGURAS Figura : Página inicial 3 Figura 2: Página inicial 4 Figura 3: Página inicial 5 Figura 4: Página inicial aeiou.expressoemprego.pt...6 Figura 5: Página inicial 6 Figura 6: Página inicial 7 Figura 7: Página inicial 8 Figura 8: Página inicial 9 Figura 9: Página inicial 9 Figura : Etapas do processo TDD... 9 Figura : Arquitectura Cliente-Servidor Figura 2: Componentes REST e interacções Figura 3: Arquitectura de produção da aplicação...43 Figura 4: Modelo Relacional de Dados parcial...56 viii

9 LISTA DE TABELAS Tabela : Exemplo de User... Tabela 2: Comparação de resultados obtidos com alguns critérios de medida...67 Tabela 3: Perfis Modelo usados em testes... 7 Tabela 4: Ofertas Modelo usadas em testes... 7 Tabela 5: Perfis usados em testes Tabela 6: Ofertas usadas em testes Tabela 7: Semelhança de Graus Académicos Tabela 8: Semelhança de Universidades Tabela 9: Semelhança de Cursos Superiores Tabela : Semelhança de Áreas Profissionais Tabela : Semelhança de Empregos Tabela 2: Resultados da pesquisa pelo Algoritmo de Classificação (Perfis)...73 Tabela 3: Resultados da pesquisa pelo Algoritmo de Classificação (Ofertas)...73 Tabela 4: Entidade User Tabela 5: Entidade Candidate Tabela 6: Entidade CandidateBookmarkedOffer...88 Tabela 7: Entidade Company Tabela 8: Entidade AuthenticationTicket Tabela 9: Entidade CandidateAreaMainTechnology...89 Tabela 2: Entidade CandidateProfile... 9 Tabela 2: Entidade CandidateAppliedOffer... 9 Tabela 22: Entidade CompanyOffer... 9 Tabela 23: Entidade Country... 9 Tabela 24: Entidade CandidateAreaMainFunction...92 Tabela 25: Entidade CandidateProfessionalCourse...92 Tabela 26: Entidade CandidateOldJob Tabela 27: Entidade CompanyBookmarkedProfile...92 Tabela 28: Entidade City Tabela 29: Entidade CandidateModelOffer Tabela 3: Entidade CompanyAppliedProfile Tabela 3: Entidade University Tabela 32: Entidade JobSimilarity Tabela 33: Entidade CompanyModelProfile Tabela 34: Entidade UniversityCourse Tabela 35: Entidade AcademicDegree Tabela 36: Entidade JobArea Tabela 37: Entidade Job Tabela 38: Entidade UniversitySimilarity ix

10 Tabela 39: Entidade UniversityCourseSimilarity...97 Tabela 4: Entidade AcademicDegreeSimilarity...97 Tabela 4: Entidade JobAreaSimilarity x

11 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

12 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

13 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

14 WAIS Wide Area Information Server XML extensible Markup Language XP Extreme Programming YAML YAML Ain't Markup Language ou Yet Another Markup Language xiv

15 - INTRODUÇÃO. - 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..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

16 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

17 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. Figura : Página inicial O site é 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

18 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. O site é 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 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 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. Figura 2: Página inicial 4

19 O site é 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. Figura 3: Página inicial 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

20 sector. Figura 4: Página inicial aeiou.expressoemprego.pt O site é um site derivado do site principal internacional 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. Figura 5: Página inicial 6

21 O site é 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 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. Figura 6: Página inicial O site é 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 , 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

22 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. Figura 7: Página inicial O site é um site de emprego do Reino Unido apresentando funcionalidades bastante interessantes. As principais são o registo de empregadores e candidatos, o envio de a candidatos e empregadores se alguma oferta ou perfil são inseridos cumprindo alguns critérios como área profissional (jobs by ). 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 palavraschave 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 palavraschave 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

23 Figura 8: Página inicial O site é 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 e a introdução de fotografia e currículo. As pesquisas podem ser efectuadas por emprego, data, sector, país e actividade. Figura 9: Página inicial 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

24 3 - CONTEÚDO TEÓRICO 3. - 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 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: User pk id int() username varchar(3) name varchar() Tabela : 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 :

25 class Reporter(models.Model): class Article(models.Model): full_name = models.charfield(max_length=7) pub_date = models.datetimefield() headline = models.charfield(max_length=2) def unicode (self): content = models.textfield() return self.full_name 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

26 no capítulo 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 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. 2

27 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 3

28 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 (chavesestrangeiras), é 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 4

29 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 5

30 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 shell 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. Cliente de uma aplicação por linha de comando 6

31 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 LINGUAGEM DE PROGRAMAÇÃO PYTHON A linguagem de programação Python foi a linguagem usada para o desenvolvimento deste projecto. O Python [45] cap., é 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., ou seja, permite a estruturação da programação em classes com atributos e comportamentos (métodos) próprios, gozando das propriedades de herança 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 Uma classe pode herdar o comportamento de outra. Uma classe pode redefinir parte do seu comportamento relativamente a outra classe de onde herda esse comportamento. 2 7

32 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 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 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 [], 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 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 8

33 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 ilustra os vários passos do TDD. Figura : Etapas do processo 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 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 9

34 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 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. 2

35 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 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 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 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 REQUEST - RESPONSE O ciclo Request-Response é um padrão de troca de informação habitualmente utilizado por 2

36 arquitecturas Cliente-Servidor. Embora possa ser implementado de forma assíncrona 2, em que a resposta pode ser retornada mais tarde no tempo, a implementação comum é síncrona 3. 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 [2] 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 A Figura mostra a arquitectura Cliente-Servidor: Figura : Arquitectura Cliente-Servidor 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 [4] cap. 3.5, embora já tenha sido usado sobre protocolos não fiáveis como o UDP User Datagram Protocol [4] cap 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 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

37 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 99 por Tim Berners-Lee. A primeira versão do protocolo, posteriormente designada por HTTP/.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 [4] 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/., tendo nesta altura sido nomeada a versão anterior como HTTP/.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/. vem suprir o que ainda não tinha sido melhorado na versão HTTP/.. 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/., 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. 3, 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

38 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 xx, 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 2 Created. Caso contrário, deve ser enviada uma de duas respostas de sucesso: 2 - OK ou 24 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: 2 OK, 22 Accepted ou 24 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 2 OK. O método CONNECT é reservado na especificação para uso com um proxy [4] cap , 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 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) [2] cap 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

39 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 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 HTTPS, 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. descrito por [7], sido desenvolvido com base no SSL 3.. A versão de TLS. é descrita por [8] e a versão mais recente TLS.2 é descrita por [9]. A breve descrição aqui apresentada baseia-se em [37], [55] e [9]. 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 []. 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 2 HTTPS Hyper Text Transfer Protocol over SSL Secure Socket Layer Entidade que emite certificados digitais, na qual cliente e servidor confiam. 25

40 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.59v3. Este standard assume um sistema de CA hierárquicos para a emissão de certificados Public Key Infrastructure (PKI) [4]. O tipo X.59v3 é definido em [3]. 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 facto para comunicações seguras na World Wide Web REST REPRESENTATIONAL STATE TRANSFER O conceito REST, introduzido em [2] 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/. 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/ 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 userinterface e é melhorada a escalabilidade pela simplificação dos componentes do servidor, permitindo De facto - expressão latina que significa na prática, mas sem ter sido regulamentado por lei. Elementos de texto, dados, gráficos, áudio e vídeo ligados de forma a que o utilizador possa navegar entre eles. 2 26

41 que a evolução destes dois componentes seja independente. A segunda restrição define que a interacção entre cliente e servidor seja stateless, 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 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 2 Sem estado Dispositivos desenhados para controlar e monitorizar o acesso a uma rede restrita. [4] cap

42 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 [6] 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 type. 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 [4] cap. 4.3, a proxy, e o user-agent, ou seja no nosso caso o browser. A Figura 2 mostra-nos as interacções que existem entre os vários componentes, os conectores existentes, com ou sem cache e o fluxo de dados. Figura 2: Componentes REST e interacções [2] cap. 5 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 [5]. 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 [5] e [32], que é um sistema separado da arquitectura web. Ver [27], [25], [49], [28], [26] 28

43 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 [2] cap 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: 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 iremos receber essa lista. Para aceder aos valores de uma determinada categoria basta, da mesma forma, invocar o URL 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 subcategorias poder-se-ia, eventualmente, aceder-se-ia ao URL aceder ao URL ou Para, por exemplo, aceder à lista de produtos da categoria inside e a um produto específico ao URL 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 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

44 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 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 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 2 (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 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 mapping.py) foi feito usando a arquitectura REST INTERPRETAÇÃO DA RESPOSTA 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. 3

45 Entre os browsers mais populares enumeramos o Mozilla Firefox, o Internet Explorer, o Google Chrome, o Safari e o Opera 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 [2]. 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 [4] 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 [5], rodeada por um sinal de menor < e um sinal de maior >. Exemplo de um elemento com atributos: <tag attribute= atr >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., é suficiente a declaração <!doctype html>. Para versões anteriores era necessário usar a declaração em que explicitamente era definido o DTD (Document Type Definition), onde era designada a linguagem 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. Contém as definições gramaticais da linguagem. 3

46 A definição de estilo do documento é feita entre as tags <style> indicação do URL para o ficheiro que contém as definições de estilo type="text/css">, habitualmente definida dentro das tags <head> e e </style>, ou através da <link rel="stylesheet" href="/style.css" </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 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 JQUERY O JQuery é uma biblioteca open-source de JavaScript que define uma conjunto de funções de 32

47 modo a facilitar as interacções entre o DOM e a linguagem JavaScript [43] cap.. 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 FORMULÁRIOS Os formulários permitem a interacção, sem o uso de scripts, entre cliente e servidor [64] cap. 4.. 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

48 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 LINGUAGEM DE TEMPLATING 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., 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 branding. 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 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 branding ou brand management gestão de marcas 34

49 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..). 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 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. 5. Os formatos poderão ser variados, embora os mais comuns sejam HTML, XML (extensible Markup Language) [58], JSON (JavaScript Object Notation) [6], 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..). 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 FUNCIONALIDADES O sistema de templating do Django permite três tipos de entidades [34] cap. 4, pp. 4: 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

50 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 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 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

51 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 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 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 [6], pp.. 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 [6] cap. : 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 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 [6] cap. 8, o Modelo Relacional de Objectos [6] cap. 9, o modelo Entidade-Relação [8] e o modelo Relacional [] 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

52 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 [6] 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:. 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

53 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 [6] 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 EntidadeRelaçã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 t inclui um atributo que é uma chave-primária de outra tabela t2, este atributo tem o nome de chave-estrangeira de t referenciando t2. Assim, iremos apresentar os passos a seguir de modo a transformar o modelo EntidadeRelação no modelo Relacional:. 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

54 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 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 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 4

55 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 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. 4

56 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 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 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

57 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 3 apresenta o esquema do fluxo tal como explicado. Figura 3: Arquitectura de produção da aplicação É apresentada na Figura 3 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

58 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 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 e 3.3.3, virtual hosting e a possibilidade de implementação, através de configuração, de load-balancing entre várias instâncias do servidor 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 [2]. 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.2, pp 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 Uso de vários domínios com um único endereço IP. 44

59 Jython. O Jython [36] é uma implementação de Python que é executada na plataforma Java. 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 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... 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 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 3) 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. 2 Java JVM (Java Virtual Machine) O sistema de clustering do MySQL não foi testado neste projecto. 45

60 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 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 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 4). 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 5), nomeadamente os seus dados pessoais. 46

61 Um candidato pode ter perfis, ofertas modelo, ofertas marcadas, ofertas respondidas e antigos empregos. Assim foram definidas as entidades candidateprofile (Tabela 2), 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 9). 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 6) e candidateappliedoffer (Tabela 2). 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 7. 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 3), 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

62 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 3, 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 4), universitycoursesimilarity (Tabela 39), jobareasimilarity (Tabela 4) e jobsimilarity (Tabela 32). Estes contêm a informação da semelhança existente entre as várias instâncias dessas entidades. Respectivamente, universidades, universitysimilarity traduz as semelhanças existentes entre 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 8), 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) DESCRIÇÃO DOS RECURSOS DA APLICAÇÃO A aplicação disponibiliza uma página inicial que qualquer utilizador poderá visualizar e onde 48

63 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 determinado recurso for e o endereço correspondente a um 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 ou 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 /company /candidate ou 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

64 fique disponível para a pesquisa e visualização pelos empregadores. Os dados necessários são os que constam na Tabela 2. 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 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 . 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 é 5

65 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 . 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 5

66 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 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 utilizadores. 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 8) e é enviado um ao utilizador com o recurso ao qual deve aceder, com o token gerado como parâmetro. Será enviado ao utilizador um URL da forma O utilizador visualiza, entretanto, uma mensagem que indica que irá receber um contendo dados necessários à validação do seu registo. Desta forma, é validado que o que o utilizador introduziu é um 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. 2 É guardado o hashing da password misturado com uma string de sal, através do algoritmo SHA256 de 32 bits. Um token é uma combinação de letras e dígitos único. 52

67 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 e 2, é realizada a operação xor em bits com o tempo actual em micro-segundos desde de Janeiro de 97 e é feito o hashing desse valor misturado com uma string de sal, através do algoritmo SHA256 de 32 bits 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

68 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 ESTRUTURA DOS DOCUMENTOS HTML GERADOS Como já foi abordado no capítulo , 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 ), 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 LOGGING Uma aplicação deve registar num ficheiro as acções mais importantes realizadas durante a 54

69 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. 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 [3] cap.. 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 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 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. 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

70 assim o modelo Relacional. As entidades referidas correspondem às tabelas, e os seus atributos às colunas constituintes das tabelas. Na Figura 4 é apresentado o modelo Relacional parcial, contendo apenas as entidades que persistem os dados passíveis de serem criados e alterados pelos candidatos e empregadores. Figura 4: Modelo Relacional de Dados parcial 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 chaveestrangeira 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