Instituto Politécnico da Guarda
Escola Superior de Tecnologia e Gestão
Gestão de Reservas: Casa do Pastor
Ricardo Miguel Dias Antunes - No 1009694Projeto Aplicado no Curso
de Engenharia Informática em contexto de estágio
Instituto Politécnico da Guarda
Escola Superior de Tecnologia e Gestão
Gestão de Reservas: Casa do Pastor
Ricardo Miguel Dias Antunes - No 1009694Projeto Aplicado no Curso
de Engenharia Informática em contexto de estágio
Supervisor: Carlos Fernando Duarte Pais - Sócio-gerente - Ideias
Soberbas
Orientador: Mestre Paulo Jorge Costa Nunes, Professor Adjunto da
Unidade Técnico-Cientí ca de Informática da ESTG.
Agradecimentos
O desempenho no desenvolvimento deste projeto em contexto de estágio não teria sido o mesmo sem o apoio, a colaboração e a paciência de algumas pessoas, às quais gostaria de aqui mostrar o meu reconhecimento.
Em primeiro lugar, como não poderia deixar de ser, quero deixar um agradecimento a todos os familiares e amigos que sempre me apoiaram e incentivaram no percurso deste projeto.
Em segundo lugar, um agradecimento aos professores da Unidade Curricular Projeto de Informática, Professor Paulo Nunes e Professor Noel Lopes.
Em terceiro lugar, e não menos importante, um agradecimento à Diretora da Escola Superior de Tecnologia e Gestão, Professora Doutora Maria Clara Silveira pelo seu apoio e disponibilidade.
Gostaria também de deixar um agradecimento ao sócio-gerente da empresa Ideias So-berbas, Carlos Fernando Duarte Pais por todo o apoio e dedicação demonstrada, bem como à Anabela Filomena Santos Pinto Pais, igualmente sócia-gerente da mesma empresa, por toda a sua disponibilidade e apoio prestado no desenvolvimento do projeto.
Por m, um agradecimento muito especial à minha namorada pela compreensão, paciência, carinho, apoio e dedicação que sempre demonstrou.
Resumo
Este documento descreve o trabalho realizado no âmbito da Unidade Curricular Pro-jeto de Informática na Licenciatura em Engenharia Informática da Escola Superior de Tecnologia e Gestão no Instituto Politécnico da Guarda.
A evolução tecnológica tem permitido, cada vez mais, que tudo o que tem a ver com reservas, possa ser guardado em formato digital de uma forma simples, fazendo com que a procura de aplicações para o efeito cresça cada vez mais.
O trabalho consistiu no desenvolvimento de uma aplicação web na linguagem de programação PHP e gestor de base de dados MySQL, que permitisse ao cliente consultar o calendário das casas numa determinada data, de forma a que pudesse criar a sua reserva sabendo que casas havia disponíveis nessa mesma data. Para além disso, foi também criada uma plataforma de gestão, direcionada para os gestores e administrador, onde ca guardada toda a informação das reservas, e onde estes podem editar, eliminar e inserir todos os registos de forma simpli cada.
Palavras Chave
Evolução Tecnológica, Aplicação web, PHP, MySQL, reservas online, plataforma de gestão.
Abstract
This document describes the work done under the discipline Projeto de Informática in the graduation in Engenharia Informática from Escola Superior de Tecnologia e Gestão in the Instituto Politécnico da Guarda.
The technological evolution allowed, more and more, that everything that has to do with reservations, could be stored in digital format from a simple way, causing the search for applications for this purpose growing more and more.
The work consists to develope one web aplication on programming language of PHP and database manager MySQL, that allowed the clients consulting the calendar of all the houses in a certain date, so that he could creat his reservation knowing that houses were available. In addition, has also created a management platform, directed from managers and administrator, where all the information from reservations are stored, and where they can edit, delete and insert all records in a simpli ed way.
Key words
Technological evolution, web aplication, PHP, MySQL, online reservations, mana-gement platform.
Conteúdo
1 Introdução 12 1.1 Instituição de acolhimento . . . 13 1.2 Motivação . . . 13 1.3 Solução . . . 13 1.4 Contribuição . . . 13 1.5 Estrutura do documento . . . 142 De nição do problema e objetivos previstos 15 2.1 De nição do problema . . . 15
2.2 Objetivos previstos . . . 15
3 Metodologia e resultados esperados 17 3.1 Metodologia . . . 17
3.2 Descrição das tarefas . . . 18
3.3 Resultados esperados . . . 19 4 Tecnologias utilizadas 20 4.1 Tecnologias web . . . 20 4.1.1 HTML . . . 21 4.1.2 XML . . . 24 4.1.3 XHTML . . . 25 4.1.4 CSS . . . 25 4.1.5 Javascript . . . 28 4.1.6 SQL . . . 28
4.1.6.1 DDL Linguagem de De nição de Dados . . . 29
4.1.6.2 DML Linguagem de Manipulação de Dados . . . . 29
4.1.6.3 DCL Linguagem de Controlo de Dados . . . 29
4.1.6.4 DTL Linguagem de Transação de Dados . . . 30
4.1.6.5 DQL Linguagem de Consulta de Dados . . . 30
4.1.7 Linguagem de programação PHP . . . 30
4.2 Software utilizado . . . 31
4.2.1 Adobe Systems . . . 31
4.2.1.1 Adobe Dreamweaver . . . 32
4.2.1.2 Adobe Fireworks . . . 32
4.2.2 Apache Friends - XAMPP . . . 32
4.2.2.1 XAMPP control . . . 32
4.2.2.2 phpMyAdmin . . . 33 4
4.2.2.3 Apache . . . 35 4.2.2.4 MySQL . . . 35 4.2.3 Core FTP LE . . . 35 5 Implementação da solução 37 5.1 Arquitetura . . . 37 5.2 Base de dados . . . 37 5.2.1 Modelo relacional . . . 37
5.2.2 Descrição das tabelas . . . 39
5.2.2.1 Atividades . . . 39 5.2.2.2 Casas . . . 39 5.2.2.3 Clientes . . . 40 5.2.2.4 Reservas . . . 40 5.2.2.5 Estado . . . 40 5.2.2.6 EstadoReserva . . . 41 5.2.2.7 ActividadesReserva . . . 41 5.2.2.8 CasasReserva . . . 42 5.2.2.9 Gestores . . . 42 5.2.2.10 Administrador . . . 43 5.2.2.11 Historico . . . 43
5.2.3 Criação da base de dados no servidor MySQL . . . 44
5.3 FrontO ce . . . 44 5.3.1 Mapa do site . . . 44 5.3.2 Calendário . . . 46 5.3.3 Criação da reserva . . . 46 5.4 BackO ce . . . 48 5.4.1 Gestores . . . 48 5.4.1.1 Mapa do site . . . 50 5.4.1.2 Login . . . 51 5.4.1.3 Consultar calendário . . . 52
5.4.1.4 Casas, Atividades e Clientes . . . 52
5.4.1.5 Reservas . . . 53
5.4.1.6 Expansão da reserva . . . 54
5.4.1.7 Editar conta do gestor . . . 57
5.4.2 Administrador . . . 57
5.4.2.1 Mapa do site . . . 57
5.4.2.2 Histórico . . . 58
5.4.2.3 Contas de gestores . . . 59
5.5 Colocação e divulgação online . . . 59
5.5.1 Registo de domínios . . . 59
5.5.2 Servidor da empresa . . . 61
5.5.3 Divulgação online . . . 62
5.5.3.1 Criação da base de dados e transferência de cheiros da aplicação . . . 62
6 Conclusões e trabalho futuro 65
6.1 Conclusões . . . 65
6.2 Trabalho futuro . . . 65
A Listagens 69 A.1 Página de consulta do calendário do FrontO ce . . . 69
A.2 Script SQL para criação da base de dados no servidor MySQL . . . . 73
A.3 Página web inicial da aplicação BackO ce . . . 77
A.4 Guardar cookies dos Gestores/Administrador . . . 79
A.5 Eliminar cookies dos Gestores/Administrador . . . 80
A.6 Exemplo de envio de email de con rmação . . . 80
A.7 Exemplo de validação de dados . . . 81
A.8 Validação Email . . . 82
Lista de Figuras
3.1 Tarefas. . . 18
3.2 Mapa de Gant. . . 18
4.1 As três camadas das tecnologias web. . . 21
4.2 Página web. Preços de alojamento na Casa do Pastor. . . 22
4.3 Página web formatada com CSS. Preços de alojamento na Casa do Pastor. . . 26
4.4 Interface inicial do XAMPP. . . 33
4.5 Página de administração do Apache. . . 33
4.6 Interface principal do phpMyAdmin. . . 34
4.7 Exemplo de estrutura de tabela.. . . 34
5.1 Arquitetura. . . 38
5.2 Modelo Relacional (ER). . . 38
5.3 Calendário Cliente. . . 45
5.4 Criar Reserva. . . 46
5.5 Lista das Casas disponíveis. . . 47
5.6 Página de login. . . 51
5.7 Lista de todas as casas existentes. . . 53
5.8 Lista de todas as reservas existentes. . . 53
5.9 Edição do estado da reserva. . . 54
5.10 Exemplo de email de con rmação. . . 55
5.11 Inserção de nova casa numa reserva. . . 56
5.12 Tabela de Histórico. . . 59
5.13 Tabela de Gestores. . . 60
A.1 Resultado da página Reservas. . . 84
Lista de Tabelas
5.1 Estrutura da tabela de atividades. . . 39
5.2 Estrutura da tabela de casas. . . 40
5.3 Estrutura da tabela de clientes. . . 40
5.4 Estrutura da tabela das reservas. . . 41
5.5 Estrutura da tabela de estados. . . 41
5.6 Estrutura da tabela do estado de cada reserva. . . 41
5.7 Estrutura da tabela de atividades da reserva. . . 42
5.8 Estrutura da tabela de casas da reserva. . . 42
5.9 Estrutura da tabela de gestores. . . 43
5.10 Estrutura da tabela do administrador. . . 43
5.11 Estrutura da tabela do historico. . . 43
5.12 Características principais do alojamento. . . 61
5.13 Características das Ferramentas de Gestão. . . 62
5.14 Características das Ferramentas de Gestão. . . 62
Lista de listagens
1 Exemplo de um documento HTML. . . 23
2 Exemplo de código XML. . . 25
3 Exemplo de uma folha de estilos. . . 26
4 Exemplo de um documento HTML. . . 27
5 Exemplo de uma função JavaScript. . . 28
6 Exemplo prático de uma DDL. . . 29
7 Exemplo prático de uma DML. . . 29
8 Exemplo prático de uma DQL. . . 30
9 Exemplo de código PHP. . . 31
10 Veri cação das casas livres. . . 49
11 Código PHP para veri car se o gestor está autenti cado. . . 52
12 Instrução SQL para inserir uma casa para a respetiva reserva. . . 56
13 Instrução SQL para inserir uma casa para a respetiva reserva. . . 57
14 Instrução SQL para inserir uma casa para a respetiva reserva. . . 57
15 Ligação á base de dados do servidor nal. . . 63
16 Função JavaScript para guardar cookies. . . 63
Glossário
bps Bits por segundo.
CPU A unidade central de processamento ou CPU (Central Processing Unit). FTP Protocolo de transferência de cheiros (File Transfer Protocol).
IP Protocolo de internet (Internet Protocol).
IT Tecnologias de informação (Information technology). Mbits Um milhão de bits.
Página Web Conhecida também pelo inglês webpage, é uma página na World Wide Web, normalmente no formato HTML, com ligações de hipertexto que permi-tem a navegação entre outras páginas ou secções.
Open Web Platform coleção de tecnologias Web desenvolvidas pela W3C e por outros corpos de normalização, como o Unicode Consortium, Internet Engineering Task Force, entre outros.
W3C World Wide Web Consortium é um consórcio internacional que visa desen-volver padrões para a criação e interpretação de conteúdos para a Web.
WWW World Wide Web é um sistema de documentação em todos os formatos (textos, imagens, vídeos) que são interligados e executados na internet.
PHP Hypertext Preprocessor, originalmente Personal Home Page.
Servidor Web Um programa de computador responsável por aceitar pedidos HTTP de clientes, geralmente os navegadores, e servi-los com respostas HTTP, in-cluindo opcionalmente dados, que geralmente são páginas web, tais como documentos HTML com objetos embutidos.
Site Um website ou site é um conjunto de páginas web, isto é, de hipertextos acessíveis geralmente pelo protocolo HTTP na internet.
HTTP Hipertext Transfer Protocol, ou em Português, Protocolo de Transferência de Hipertexto é um protocolo de comunicação.
plugin ou módulo de extensão, é um programa de computador usado para adi-cionar funções a outros programas maiores, provendo funcionalidades especiais ou especí cas.
script as linguagens de script servem para estender a funcionalidade de um programa e/ou para o controlar.
11
IETF Internet Engineering Task Force, é uma comunidade internacional ampla e aberta (técnicos, agências, fabricantes, fornecedores, pesquisadores) preocupada com a evolução da arquitetura da Internet e o seu perfeito funcionamento.
Backbone esquema de ligações centrais de um sistema amplo, tipicamente de elevado desempenho.
SGML o Standard Generalized Markup Language é uma metalinguagem através da qual se pode de nir linguagens de marcação para documentos
Unicode padrão que permite aos computadores representar e manipular, de forma consistente, texto de qualquer sistema de escrita existente
Cookie testemunho de conexão, ou, simplesmente, testemunho, é um grupo de dados trocados entre o navegador e o servidor de páginas web, colocado num arquivo ( cheiro) de texto criado no computador do utilizador, sendo que a sua principal função é a de manter a persistência de sessões HTTP
Capítulo 1
Introdução
O presente relatório descreve o projeto em contexto de estágio desenvolvido pelo aluno Ricardo Miguel Dias Antunes, na empresa Ideias Soberbas, no âmbito da disciplina de Projeto de Informática na Escola Superior de Tecnologia e Gestão no Instituto Politécnico da Guarda.
A Casa do Pastor está situada na aldeia rústica da Póvoa Velha, de ambiente cam-pestre rodeado por montanhas, paisagens verdejantes e pelo "`silêncio"' da natureza, a cerca de 5 quilómetros de Seia, e é constituída por um conjunto de casas datadas de 1868, de turismo de habitação, destinada a todas as faixas etárias.
Na Casa do Pastor as reservas são feitas apenas através de contacto telefónico, e estas são guardadas numa agenda em formato de papel. Por um lado, o contacto telefónico é interessante no que diz respeito ao contacto entre cliente e gestores, por outro, este contacto exige disponibilidade durante aquele tempo por parte de ambos os lados. Quanto à agenda, cada vez se torna menos e caz, uma vez que nem sempre tudo ca apontado, e por vezes não se sabe exatamente onde se apontaram os dados da reserva, o que pode ser bastante desvantajoso quer para o cliente quer para a Casa em si.
A relação entre evolução das tecnologias e adaptação das pessoas não evoluiu da mesma forma, o que faz com que pessoas com uma maior idade possam ter di cul-dades em se adequarem ás tecnologias, mesmo sabendo que estas podem ser muito favoráveis. Neste caso em particular, a pessoa que trata das reservas que tem já uma certa idade, acredita que a agenda em formato de papel é muito mais simples e e caz do que partir para um sistema informático; no entanto, acontece que por vezes se perdem dados das reservas na sua agenda.
O projeto consistiu em desenvolver uma aplicação web de forma a facilitar, por um lado, a criação da reserva por parte do cliente, e, por outro lado, a gestão desta por parte dos gestores.
O projeto enquadra-se no âmbito e complexidade adequada às competências adqui-ridas no curso:
• Autonomia e capacidade de de nir objetivos; • Capacidade de modelação de problemas;
CAPÍTULO 1. INTRODUÇÃO 13 • Saber elaborar relatórios de análise, desenho e implementação de soluções; • Gestão de tempo e cumprimento de prazos;
O projeto obedeceu às seguintes condições:
• Ter um orientador docente da Unidade Técnico-Cientí ca de Informática da Escola Superior de Tecnologia e Gestão do Instituto Politécnico da Guarda, assim como um supervisor direto na empresa;
• Ter um plano de desenvolvimento aprovado pelo diretor do curso;
1.1 Instituição de acolhimento
A Ideias Soberbas, agência de comunicação fundada a 28 de Janeiro de 2000, tem como principal objetivo a criação e implementação de páginas de Internet total-mente personalizadas e soluções de comunicação empresarial, publicidade e meios de divulgação.
1.2 Motivação
A principal motivação para o desenvolvimento deste projeto é a possibilidade em contribuir para melhoria da gestão de reservas da Casa do Pastor, quer a nível do cliente, quer a nível de quem trata destas e para fazer com que a criação de uma reserva se torne mais acessível. Também a possibilidade de poder trabalhar com novas tecnologias com as quais nunca tive oportunidade de trabalhar, principalmente a linguagem de programação PHP e gestor de bases de dados MySQL.
Para além das motivações pessoais, existiram ainda motivações a nível da empresa, nomeadamente a nível económico.
1.3 Solução
A solução proposta consiste no desenvolvimento, implementação e teste de uma aplicação web com um BackO ce para gestão dinâmica de reservas com as diversas informações, criadas posteriormente pelo cliente no respetivo FrontO ce.
Esta solução traz várias vantagens, quer para o cliente, quer para os gestores da Casa do Pastor, uma vez que todos podem agora criar/editar reservas sem terem que se encontrar cara a cara ou contactarem-se através de telefones/telemóveis.
1.4 Contribuição
A contribuição principal deste trabalho é o desenvolvimento, implementação e teste de uma aplicação web que auxilie a criação e gestão de reservas, de forma acessível e a evitar perdas desnecessárias de dados e uma má gestão do tempo.
CAPÍTULO 1. INTRODUÇÃO 14
1.5 Estrutura do documento
O documento compreende cinco capítulos para além do presente capítulo, e está organizado da seguinte forma:
• No segundo capítulo é descrita a de nição do problema e objetivos previstos -apresentação do problema e dos objetivos do projeto;
• No terceiro capítulo é descrita a metodologia e a calendarização do projeto -apresentação das metodologias usadas no desenvolvimento do projeto realizado e a sua calendarização;
• No quarto capítulo são descritas todas as tecnologias utilizadas utilizadas na implementação do projeto;
• No quinto capítulo é descrito de forma detalhada todo o trabalho realizado, desde a base de dados até à aplicação web;
• No sexto capítulo são apresentadas as considerações nais sobre o trabalho desenvolvido e possível trabalho futuro;
Capítulo 2
De nição do problema e objetivos
previstos
2.1 De nição do problema
Desenvolver uma aplicação web, permitindo aos clientes da Casa do Pastor efetuar reservas de casas. A aplicação deve garantir algumas funcionalidades, tais como: consultar o calendário das casas e criar a reserva com todos os dados requeridos. Desenvolver uma plataforma de gestão de acesso restrito aos gestores e ao adminis-trador, onde serão geridos os dados das reservas, casas, atividades e gestores da Casa do Pastor. Deve ser desenvolvimento um módulo que permita consultar o histórico de todas as operações efetuadas sobre os dados da aplicação web pelos gestores. Os principais problemas a resolver são os seguintes:
• Como obter todos os dados da Casa do Pastor;
• Como integrar a aplicação web num web site já existente; • Como integrar toda a informação com a reserva:
Atividades; Casas;
Dados do Cliente;
• Como apresentar ao cliente apenas as casas disponíveis aquando da criação da reserva;
• Como preservar todos os dados sem qualquer perda de informação;
2.2 Objetivos previstos
Segue-se a seguir a lista dos principais objetivos de nidos no início do projeto, sendo que estes poderão ser ou não implementados, dependendo de vários fatores.
• Desenvolver uma aplicação web de suporte à criação e gestão de reservas; 15
CAPÍTULO 2. DEFINIÇÃO DO PROBLEMA E OBJETIVOS PREVISTOS 16 • Integrar a informação da Casa do Pastor na aplicação web;
• Relacionar os dados dos clientes e das suas reservas para ns estatísticos; • Integrar a aplicação no web site já existente;
Capítulo 3
Metodologia e resultados esperados
3.1 Metodologia
A metodologia utilizada para desenvolver, implementar, testar e colocar online a aplicação web foi a seguinte:
1. Utilizar Visio para de nir a arquitetura da aplicação;
2. Utilizar MySQL e phpMyAdmin para a criação da base de dados; 3. Utilizar CSS para a criação das folhas de estilo;
4. Utilizar HTML para a criação da estrutura base das páginas;
5. Utilizar Javascript para a criação de cookies e reencaminhamentos entre pági-nas;
6. Utilizar PHP para criar as páginas dinâmicas; 7. Utilizar Dreamweaver para a criação da aplicação; 8. Utilizar Fireworks para a criação e edição de imagens
9. Utilizar XAMPP para realizar testes e análise de e ciência e abilidade da aplicação na própria máquina;
10. Utilizar Core FTP LE para a transferência da aplicação para o servidor online; 11. Utilizar TeXnicCenter para a documentação do projeto num relatório;
Para reduzir e agilizar o número de reuniões com o supervisor na empresa, foi acor-dado que periodicamente o estagiário deveria apresentar-lhe o trabalho desenvolvido. Permitindo ao supervisor acompanhar a evolução da aplicação web e garantir que o projeto nal corresponda ao que foi solicitado pela empresa.
CAPÍTULO 3. METODOLOGIA E RESULTADOS ESPERADOS 18
3.2 Descrição das tarefas
As principais tarefas foram:
• Tarefa 1 Análise dos requisitos;
• Tarefa 2 Obtenção de dados da Casa do Pastor:
1. Estudo sobre casas existentes e respetivas características; 2. Estudo sobre eventuais descontos para as reservas;
• Tarefa 3 Aquisição e estudo das várias API's necessárias para a criação do projeto;
• Tarefa 4 Criação da base de dados (MySQL, phpMyAdmin); • Tarefa 5 Criação das folhas de estilo (CSS);
• Tarefa 6 Criação dos módulos de programação (PHP, HTML, Javascript); • Tarefa 7 Testes da aplicação;
• Tarefa 8 Colocação e divulgação online na aplicação web; • Tarefa 9 Elaboração do relatório.
O agendamento das tarefas é apresentado na gura 3.1.
Figura 3.1: Tarefas.
O respetivo Mapa de Gantt é apresentado na gura 3.2.
CAPÍTULO 3. METODOLOGIA E RESULTADOS ESPERADOS 19
3.3 Resultados esperados
No nal do projeto espera-se que a aplicação web esteja terminada e pronta a ser usada pelos utilizadores nais, permitindo ao cliente:
1. Consultar o calendário das casas para saber quando estão livres e ocupadas; 2. Efetuar reservas de casas;
3. Receber informações sobre o estado das reservas na sua conta de correio ele-trónico;
Na plataforma de gestão online os gestores deverão poder: 1. Consultar o calendário das casas;
2. Editar, eliminar e inserir casas; 3. Editar, eliminar e inserir atividades; 4. Editar, eliminar e inserir clientes; 5. Editar, eliminar e inserir reservas:
(a) Editar dados da reserva;
(b) Editar dados do respetivo cliente;
(c) Editar, eliminar e inserir casas da reserva; (d) Editar, eliminar e inserir atividades da reserva;
(e) Editar o estado da reserva; (f) Editar o desconto da reserva; 6. Editar os seus dados pessoais;
Ainda na plataforma de gestão, os administradores poderão, para além de tudo o que os gestores podem:
1. Consultar o histórico de todas as operações feitas pelos gestores por data; 2. Editar, eliminar e inserir contas de gestores;
Capítulo 4
Tecnologias utilizadas
Para a realização da aplicação web é necessária a utilização de diversas tecnologias da web, descritas nas secções seguintes. Estas tecnologias são padronizadas pela consórcio internacional W3C com cerca de 300 membros, constituída por empresas, órgãos governamentais e organizações independentes, e que visa desenvolver padrões para a criação e a interpretação de conteúdos para a Web [4].
O conjunto de tecnologias abertas, denominadas por Open Web Platform, padro-nizadas pelo consórcio W3C permitem que qualquer pessoa possa utilizá-las para desenvolver qualquer tipo de aplicação sem ter de pedir permissão ou obter qual-quer licença do consórcio W3C.
4.1 Tecnologias web
O desenvolvimento de páginas web pode ser realizado baseado num modelo de três camadas: estrutura, apresentação e comportamento [13]:
1. Estrutura Também chamada camada de base, são produzidos os conteúdos e a sua estrutura. Com apenas esta camada os utilizadores podem ver a página através de qualquer browser;
2. Apresentação É de nida a aparência do conteúdo na página, incluindo tipo de letra, cor do texto, alinhamento do texto e das imagens, entre muitos outros aspetos estéticos;
3. Comportamento É de nida a interação com o utilizador e a página, como por exemplo os botões ou links que mudam de cor ou de imagem quando o utilizador passa o cursor por cima deles;
A gura 4.1, ilustra diversas tecnologias web agrupadas em três acamadas para o desenvolvimento de páginas web.
A separação do código HTML, CSS e JavaScript e armazenamento em cheiros separados apresenta as seguintes vantagens:
• Permite a reutilização;
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 21
Figura 4.1: As três camadas das tecnologias web. • Fácil de localizar;
• Fácil de manter;
4.1.1 HTML
A linguagem utilizada para publicação de informação na World Wide Web é o HTML. Esta linguagem de marcação permite escrever documentos HTML com o m de produzir páginas web [3], que, basicamente, se trata de um conjunto de mar-cas (tags) que servem para de nir a forma como se apresentará o conteúdo da página web. Tim Berners-Lee criou o HTML original e a primeira versão foi esboçada por ele e Dan Connolly, e publicada em 1993 na IETF.
O objetivo da criação da linguagem HTML foi de divulgação de informação, no entanto, nunca se pensou que a Internet chegaria a ser uma área com carácter multimédia, sendo que o HTML acabou por ser criado sem capacidades de dar respostas a todos os possíveis usos que lhe poderiam dar. No entanto, com o passar do tempo foram sendo incorporadas modi cações, as quais são hoje os standards da linguagem. A última versão do HTML a ser padronizada pelo consorcio W3C foi o padrão HTML 4.01 e ocorreu em dezembro de 1999 [6]. Desde então foram realizados muitos esforços para padronizar a versão HTML5.
A primeira especi cação do HTML5 foi apresentada no início de 2008, e está desde então em fase de esboço, e prevê-se que a versão nal seja publicada no nal de 2014. O HTML5 tem novas funcionalidades baseadas no HTML, CSS, DOM, e JavaScript; reduz a necessidade de utilização de plugins externos (Flash, entre outros); melhor
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 22 controlo de erros; mais marcas para substituir scripts, é bastante independente dos dispositivos (computador, telemóvel, tablets); permite armazenamento local de da-dos.
Steve Jobs em abril de 2010 publicou uma carta pública intitulada "Re exões sobre o Adobe Flash", onde concluía que o HTML5 tornaria o Adobe Flash desnecessário, quer para assistir vídeo, quer para exibir qualquer conteúdo web [11]. Em novembro de 2011 a empresa de software Adobe anunciou a interrupção do desenvolvimento de Flash para dispositivos móveis e redirecionou os seus esforços para o desenvolvimento de ferramentas utilizando HTML5 [1].
Um documento HTML é uma hierarquia de elementos a partir de uma raiz, elemento html. Na primeira linha do documento, e antes do elemento html, existe uma decla-ração que contem informações sobre a versão do documento HTML (<!DOCTYPE html ...>). O elemento html é constituído por duas componentes:
1. Uma secção de cabeçalho declarativa Delimitado pelo elemento head; 2. Um corpo, que contém o conteúdo real do documento Delimitado pelo
elemento body;
Na listagem 1 é ilustrado um exemplo de um documento HTML 4.01 Strict. A primeira linha contem informações sobre a versão do HTML. Na segunda linha é iniciado o documento HTML; na linha 4 é indicado o titulo do documento e na linha 6 é carregada a folha de estilos que edita o documento; na linha 7 é iniciado o corpo do documento; na linha 9 é iniciada a tabela com a ilustração das casas e dos preços. A linha 20 representa uma marca de parágrafo.
A página web resultante do documento HTML da listagem 1 é apresentado na gura 4.2. À esquerda no browser Internet Explorer e à direita no browser Google Chrome.
Figura 4.2: Página web. Preços de alojamento na Casa do Pastor.
Esta tecnologia foi utilizada para criar a estrutura geral de todas as páginas, tais como a inserção de tabelas, imagens e informação.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 23
Listagem 1 Exemplo de um documento HTML.
1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" %"http://www.w3.org/TR/html4/strict.dtd">
2: <html> 3: <head>
4: <title>Preços de alojamento na Casa do Pastor</title>
5: <!-- <link rel='stylesheet' type='text/css' href='css1.css'> --> 6: </head>
7: <body>
8: <h1>Lista preços das casas</h1> 9: <table>
10: <tr><th>Casas</th><th>Preço época baixa</th><th> %Preço época alta</th></tr>
11: <tr><td>Casa da Eira</td><td>100 </td><td>175 </td></tr> 12: <tr><td>Casa Grande</td><td>95 </td><td>150 </td></tr> 13: <tr><td>Casa do Meio</td><td>85 </td><td>14 </td></tr> 14: <tr><td>Casa do Adro I</td><td>65 </td><td>85 </td></tr> 15: <tr><td>Casa do Adro II</td><td>80 </td><td>120 </td></tr> 16: <tr><td>Casa do Ski</td><td>65 </td><td>85 </td></tr> 17: <tr><td>Casa da Laginha</td><td>75 </td><td>110 </td></tr> 18: <tr><td>Casa da Laginha II</td><td>75 </td><td>110 </td></tr> 19: </table>
20: <p>Os preços apresentados na tabela anterior são por dia e para um máximo de 10 pessoas por casa.</p>
21: </body> 22: </html>
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 24
4.1.2 XML
O XML (eXtensible Markup Language) é uma linguagem de marcação para de nir linguagens de marcação especí cas [5]. O objetivo foi criar uma linguagem de mar-cação que combinasse a exibilidade da SGML com a simplicidade da HTML. A sua loso a foi incorporada seguindo vários princípios, tais como:
• Separação do conteúdo da formatação;
• Possibilidade de criação de tags sem qualquer limitação;
• Utilização de cheiros para validação da estrutura (DTDs e XML Schema); • Integração com várias bases de dados;
• Concentração na estrutura da informação e não na sua aparência; Principais vantagens do XML:
• É um padrão aberto Facilidade para converter para formatos proprietários; • É baseado em texto Unicode Fácil de escrever e ler, fácil de processar,
menos incompatibilidades;
• Promover a separação entre estrutura, conteúdo e apresentação;
• Pode representar as estruturas de dados relevantes da computação (listas, re-gistos, árvores);
• É auto-documentado (DTDs e XML Schemas), sendo que o próprio formato descreve a sua estrutura e nomes de campos;
• É editável Devido à sua popularidade nos dias de hoje, com diferentes níveis de automação, em qualquer ambiente;
• É a ferramenta mais comum para as transmissões de dados entre todos os tipos de aplicações;
No entanto, devido à sintaxe do XML ser redundante a representação de uma es-trutura de dados pode tornar-se relativamente grande em relação a outras repre-sentações. Desta forma, a redundância pode afetar a e ciência das aplicações que utilizam o XML para armazenamento, transmissão e processamento e os seu custo associado.
A listagem 2 apresenta um exemplo de código XML. A primeira linha é obrigatória e deve ser escrita na primeira linha do cheiro de texto. A referida linha indica que o documento é XML versão 1.0. O utilizador pode de nir as marcas e os atributos que entender para marcar os seus dados. Por exemplo, a marca nome, marca a palavra "Ricardo"como sendo um nome.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 25 Listagem 2 Exemplo de código XML.
1: <?xml version="1.0" ?> 2: <cartao-simples> 3: <foto href="ricardo.gif" /> 4: <nome>Ricardo</nome> 5: <apelido>Antunes</apelido> 6: <endereco>
7: <rua>Lugar do Bacelo, Bloco B, 2o direito.</rua>
8: <codigo_postal>6300-000 - Guarda</codigo_postal> 9: </endereco> 10: <email>antenas963@hotmail.com></email> 11: <telefone tipo="trabalho" > 12: <extensao>120</extensao> 13: <numero>271084703</numero> 14: </telefone> 15: <telefone tipo="telemovel" > 16: <numero>962466767</numero> 17: </telefone> 18: </cartao-simples>
4.1.3 XHTML
O XHTML (eXtensible Hypertext Markup Language) é uma reformulação da lin-guagem de marcação HTML, baseada em XML, que combina as tags de marcação HTML com as regras da XML [3]. Este processo de padronização tem em vista a exibição de páginas web em diversos dispositivos, com a intenção de melhorar a aces-sibilidade. Apesar de não existirem grandes diferenças entre o HTML e o XHTML, o XHTML consegue ser intercetado por qualquer dispositivo, independentemente da plataforma utilizada, o que não é conseguido pelo HTML, visto que as marcações do XHTML possuem sentido semântico para as máquinas.
4.1.4 CSS
As folhas de estilo CSS, siglas de Cascading Style Sheets, são uma linguagem de estilos utilizada para de nir a apresentação de documentos escritos em linguagens como HTML ou XML [3], provendo assim a separação entre o formato e o conteúdo de um documento. Assim sendo, em vez de se colocar a formatação dentro do cheiro do documento, é criada uma ligação para uma folha de estilos armazenada num cheiro externo com extensão ".css", e todo o documento ca com as respetivas formatações. O principal benefício das folhas de estilo é que quando se pretender alterar a aparência do documento, basta alterar a folha de estilos sem ter que mudar nada no conteúdo.
A listagem 3 apresenta um exemplo de uma folha de estilos. Da linha 1 à linha 4 estão as formatações das tabelas; da linha 5 à linha 8 as formatações da borda (th
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 26 representa uma célula com letras a negrito e centrada por padrão e td representa uma célula normal), sendo que na linha 9 é atribuída à linha th e na linha 10 a cor da linha td. Da linha 11 à linha 15 são as formatações da marca h1 com tamanho da fonte 18 pixeis, cor castanha e letras maiúsculas.
Listagem 3 Exemplo de uma folha de estilos.
1: table {
2: border-collapse: collapse; 3: border: solid 1px blue; 4: }
5: th, td {
6: border: solid 1px black; 7: padding: 4px; 8: } 9: th {color:blue; } 10: td {text-align:center;} 11: h1 { 12: font-size: 18pt; 13: color: brown; 14: font-variant:small-caps; 15: }
A página web resultante do documento HTML da listagem 4 formatada com a folha de estilos da listagem 3, é apresentado na gura 4.3. À esquerda no browser Internet Explorer e à direita no browser Google Chrome. Nota-se que a diferença entre a listagem 1 e a listagem 4 é apenas a linha 5, que permite que (no caso da segunda) a folha de estilos seja aplicada a este documento.
Figura 4.3: Página web formatada com CSS. Preços de alojamento na Casa do Pastor.
Esta tecnologia foi utilizada para formatar todas as páginas web. Dentro dessas formatações encontram-se, principalmente, a formatação do fundo das páginas e o tamanho, tipo e cor de letras.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 27
Listagem 4 Exemplo de um documento HTML.
1: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" %"http://www.w3.org/TR/html4/strict.dtd">
2: <html> 3: <head>
4: <title>Preços de alojamento na Casa do Pastor</title> 5: <link rel='stylesheet' type='text/css' href='css1.css'> 6: </head>
7: <body>
8: <h1>Lista preços das casas</h1> 9: <table>
10: <tr><th>Casas</th><th>Preço época baixa</th><th> %Preço época alta</th></tr>
11: <tr><td>Casa da Eira</td><td>100 </td><td>175 </td></tr> 12: <tr><td>Casa Grande</td><td>95 </td><td>150 </td></tr> 13: <tr><td>Casa do Meio</td><td>85 </td><td>14 </td></tr> 14: <tr><td>Casa do Adro I</td><td>65 </td><td>85 </td></tr> 15: <tr><td>Casa do Adro II</td><td>80 </td><td>120 </td></tr> 16: <tr><td>Casa do Ski</td><td>65 </td><td>85 </td></tr> 17: <tr><td>Casa da Laginha</td><td>75 </td><td>110 </td></tr> 18: <tr><td>Casa da Laginha II</td><td>75 </td><td>110 </td></tr> 19: </table>
20: <p>Os preços apresentados na tabela anterior são por dia e para um máximo de 10 pessoas por casa.</p>
21: </body> 22: </html>
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 28
4.1.5 Javascript
A linguagem de script JavaScript foi criado originalmente por Brendan Eich da Nets-cape [3], com o primeiro nome de Mocha, e posteriormente mudado para LiveScript e atualmente JavaScript, é uma linguagem de script baseada em ECMAScript e é atualmente a principal linguagem de programação do lado do cliente em navegadores web. LiveScript foi o nome o cial da linguagem quando foi lançada pela primeira vez na versão beta do navegador Netscape 2.0 em Setembro de 1995, mas viu o seu nome alterado para JavaScript em Dezembro do mesmo ano num conjunto com a Sun Microsystems. Esta foi concebida para ser uma linguagem script orientada a objetos baseada em protótipos; possui suporte à programação funcional e apresenta recursos como funções de alto nível indisponíveis em linguagens como o Java e o C++.
A listagem 5 apresenta o exemplo de uma função JavaScript, que tem também al-gum código PHP incluído. A função recebe os parâmetros nome do cookie, respetivo valor e número de dias (cookieName,cookieValue,nDays), que são de seguida utili-zados para criar um cookie com esses mesmos parâmetros document.cookie = cookieName+"="+escape(cookieValue)+"; expires="+expire.toGMTString()+"; path=/"+"; domain=.<?php echo $_SERVER['HTTP_HOST']; ?>".
Listagem 5 Exemplo de uma função JavaScript.
function SetCookie(cookieName,cookieValue,nDays) { var today = new Date();
var expire = new Date();
if (nDays==null || nDays==0) nDays=1;
expire.setTime(today.getTime() + 3600000*24*nDays); document.cookie = cookieName+"="+escape(cookieValue)+"; expires="+expire.toGMTString()+"; path=/"+"; domain=. <?php echo $_SERVER['HTTP_HOST']; ?>";
}
A tecnologia Javascript foi utilizada no presente projeto essencialmente para a cri-ação de cookies e efetuar o reencaminhamento entre páginas.
4.1.6 SQL
A história da linguagem SQL começa em Junho e 1970 com E. F. Codd [7], que propôs um modelo que é ainda hoje considerado a base de trabalho para qualquer sistema de gestão de base de dados relacional. A primeira implementação da lin-guagem SEQUEL foi realizada pela IBM e tinha por objetivo a implementação do modelo de Codd. A evolução desta linguagem deu por m origem ao SQL. Nos dias de hoje SQL é considerada um standard dos sistemas gestores de bases de dados relacionais, sendo que todos os fabricantes a integram nos seus produtos.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 29 4.1.6.1 DDL Linguagem de De nição de Dados
Uma DDL permite ao utilizador de nir tabelas novas e elementos associados. Os comandos básicos da DDL são o "Create", o "Drop"e o "Alter", que servem para criar, eliminar ou alterar, respetivamente, por exemplo, tabelas.
A listagem 6 apresenta um exemplo prático de uma DDL utilizada para a criação da tabela "casas"na base de dados.
Listagem 6 Exemplo prático de uma DDL.
CREATE TABLE IF NOT EXISTS `casas` (
`ID_Casa` int(2) NOT NULL AUTO_INCREMENT, `Nome` varchar(50) NOT NULL,
`Tipologia` varchar(10) NOT NULL, `Capacidade` int(2) NOT NULL,
`Preco_Epoca_Baixa` int(3) NOT NULL, `Preco_Epoca_Alta` int(3) NOT NULL, PRIMARY KEY (`ID_Casa`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=9 ;
4.1.6.2 DML Linguagem de Manipulação de Dados
DML é utilizada para realizar inclusões, consultas, alterações e exclusões de dados presentes em registos. Os comandos utilizados são o "Select", "Update", "Insert"e "Delete", que servem, respetivamente, para selecionar, atualizar, inserir ou eliminar dados de uma tabela.
A listagem 7 apresenta um exemplo prático de uma DML utilizada para atualizar os dados da tabela "casas".
Listagem 7 Exemplo prático de uma DML.
$sql4="UPDATE `casasreserva` SET `N_Pessoas` = '$npessoas', `N_Camas_Extra` = '$ncamas', `N_Bercos` = '$nbercos',
`Data_Entrada` = '$dataentrada', `Data_Saida` = '$datasaida', `Preco_Casa` = '$preco' WHERE ID_Reserva = '$IDReserva'
AND ID_Casa = '$idcasa'";
4.1.6.3 DCL Linguagem de Controlo de Dados
DCL é utilizado para controlar os aspetos de autorização de dados e licenças de utilizadores de forma a controlar quem tem acesso para ver ou manipular os dados dentro da base de dados. Os comandos utilizados são o "Grant"e o "Revoke", que servem, respetivamente, para autorizar a execução de operações ou para remover essa mesma capacidade de executar operações.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 30 No presente projeto isto não foi utilizado, uma vez que todas as alterações feitas às tabelas da base de dados têm validações.
4.1.6.4 DTL Linguagem de Transação de Dados
DTL serve para proceder a transações na base de dados, tipicamente utilizado em bancos. Os comandos utilizados são o "Begin Work"para dar início à transação, o "Commit"para enviar todos os dados da mudança de forma permanente e o "Roll-back"que faz com que todas as as mudanças nos dados existentes desde o último "Commit"ou "Rollback"sejam anuladas.
Tal como as DCL, não foram usadas quaisquer transações para este projeto. 4.1.6.5 DQL Linguagem de Consulta de Dados
DQL tem apenas um comando, o SELECT, que permite apenas ao utilizador fazer uma consulta a uma ou várias tabelas. Esta operação faz igualmente parte da DML. A listagem 8 apresenta um exemplo prático de uma DML que permite obter os campos Nome, Capacidade, Preco_Epoca_Alta, Preco_Epoca_Baixa de todos os registos da tabela casas.
Listagem 8 Exemplo prático de uma DQL.
%$sqlca="select * from casas, casasreserva where %casasreserva.ID_Reserva = " . $IDReserva . " and %casas.ID_Casa = casasreserva.ID_Casa";
SELECT Nome, Capacidade, Preco\_Epoca\_Alta, Preco\_Epoca\_Baixa FROM casas;
No presente projeto, a tecnologia SQL foi utilizada para aceder a dados presentes na Base de dados, bem como para editar, eliminar ou inserir novos registos nessa mesma base de dados.
4.1.7 Linguagem de programação PHP
A linguagem de programação PHP foi criado em 1995 por Rasmus Lerdorf [12], inicialmente denominado por "Personal Home Page"e agora por "Hypertext Pre-processor", era originalmente usada apenas para o desenvolvimento de aplicações presentes e atuantes do lado do servidor, capazes de gerar conteúdo dinâmico da World Wide Web. O código é interpretado no lado do servidor pelo módulo PHP, podendo este aceder a bases de dados, conexões de rede, entre outros, para criar a página nal, apresentada posteriormente ao cliente. Ao longo dos anos a evolução da linguagem foi notória, passando a oferecer funcionalidades em linha de comando. É possível utilizar o PHP na maioria dos sistemas operativos de forma gratuita. Este é o concorrente direto da tecnologia ASP, pertencente à Microsoft, e é utilizado em aplicações bem conhecidas, como o Facebook, Joomla, WordPress ou Magento.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 31 A listagem 9 apresenta um excerto de código PHP da aplicação web desenvolvida. Inicialmente a aplicação veri ca se existe alguma mensagem guardada nas variáveis de sessão if (isset($_Request['Mensagem'])); se existir, é visto se essa men-sagem não é nula if ($_REQUEST['Menmen-sagem'] != null), e, caso não seja nula, é guardada na variável '$Mensagem' o seu valor, caso contrário é guardado o conjunto vazio $Mensagem = . No caso de não existir qualquer mensagem guardada nas variáveis de sessão, à variável '$Mensagem' é-lhe atribuído o conjunto vazio também. Listagem 9 Exemplo de código PHP.
1: if (isset($_REQUEST['Mensagem'])) 2: { 3: if ($_REQUEST['Mensagem'] != null) 4: { 5: $Mensagem = $_REQUEST['Mensagem']; 6: } 7: else 8: { 9: $Mensagem = ''; 10: } 11: } 12: else 13: { 14: $Mensagem = ''; 15: }
A tecnologia PHP foi utilizada no projeto essencialmente como plataforma de apoio à visualização, edição, eliminação e inserção de dados na base de dados. Para além disso, foi ainda utilizada para a leitura de cookies, para guardar e ler dados com recurso aos métodos '$GET', '$POST' e também o '$REQUEST'.
4.2 Software utilizado
No desenvolvimento do projeto foram utilizadas alguns aplicações, apresentados nas secções seguintes.
4.2.1 Adobe Systems
A Adobe System, fundada em Dezembro de 1982 por John Warnock e Charles Ges-chke, é uma companhia norte-americana que desenvolve programas de computador, sediada em San Jose, Califórnia. A Adobe produz programas para, por exemplo, desenvolvimento de páginas web (Dreamweaver), criação e edição de imagens (Pho-toshop, Fireworks), criação de animações (Flash), entre outros.
Para o presente projeto, foram utilizados dois programas da distribuição Adobe: Dreamweaver e Fireworks, que serão explicados de seguida.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 32 4.2.1.1 Adobe Dreamweaver
O Adobe Dreamweaver (antigo Macromedia Dreamweaver) é um software de desen-volvimento de aplicações web, criado pela Macromedia (adquirida posteriormente pela Adobe Systems), e que está atualmente na versão CS6. As suas versões inicias serviam apenas como editor HTML WYSIWYG, que signi ca "`What You See Is Wath You Get"', mas as versões mais recentes incorporam um suporte a várias tec-nologias web, tais como o XHTML, CSS, JavaScript, PHP, ASP.NET, JSP, entre outras linguagens do lado do servidor.
A versão utilizada para o projeto foi a versão CS5, lançado a 12 de Abril de 2010. Foi com este software que toda a aplicação foi desenvolvida.
4.2.1.2 Adobe Fireworks
O Adobe Fireworks, tal como o Adobe Dreamweaver, foi desenvolvido pela Macro-media, e posteriormente adquirido pela Adobe. O Fireworks é um editor de imagens, em que as suas funcionalidades focam a publicação grá ca na Internet, incluindo as-sim suporte a GIF animado e PNG, para além de possuir uma ótima compressão de imagens. Foi a partir da versão MS que ganhou integração com outros produtos da mesma linha, tais como o Dreamweaver ou o Flash.
A versão utilizada para o projeto foi, tal como o Dreamweaver, a versão CS5, lan-çada, igualmente, em 2010.
O Fireworks foi utilizado para a criação e edição de imagens a utilizar em todas as páginas web.
4.2.2 Apache Friends - XAMPP
Uma vez que o projeto foi feito em PHP e este é executado no servidor, para o poder testar na minha máquina tive que utilizar o software XAMPP, que é um servidor independente de plataforma, de uso livre, e que consiste principalmente na base de dados MySQL, no servidos web Apache e os interpretadores para linguagens de script (PHP e Perl). O seu nome provem da abreviação de X (para qualquer sistema operativo), Apache, MySQL, PHP, Perl.
4.2.2.1 XAMPP control
O interface inicial do XAMPP é o visto na 4.4. É aqui que os serviços (Apache, MySQL, etc) são inicializados (clicando em "Start"), e a partir do qual temos acesso ás con gurações desses mesmos serviços (clicando em "Con g"). O Apache é o simulador de servidor, que foi utilizado para poder correr a aplicação na minha máquina, e utiliza por norma o porto 80. O MySQL é o serviço de gestão de bases de dados e usa o porto 3306. Clicando nos botões "Admin"vamos para a página de administração do Apache ou do MySQL.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 33
Figura 4.4: Interface inicial do XAMPP.
Nos cheiros de con guração é possível alterar as de nições e todas as propriedades de cada ferramenta, no entanto é preciso saber mexer nestes cheiros e saber bem o que se pretende.
O botão "Admin"à frente do "Apache"levanos para a página mostrada na gura 4.5, enquanto que o "Admin"do "MySQL"nos leva para o phpMyAdmin.
Figura 4.5: Página de administração do Apache. 4.2.2.2 phpMyAdmin
O phpMyAdmin é o gestor de base de dados MySQL, que tem o interface visto na gura 4.6. Do lado esquerdo podemos ver todas as bases de dados criadas, na caixa de texto do lado direito podemos ver as características do MySQL e nas duas caixas de texto centrais podemos ver as de nições gerais do interface (como por
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 34 exemplo a linguagem e o tamanho da fonte). Podemos ainda ver no menu na parte superior da janela um ícone que nos permitem criar novas base de dados ("Banco de Dados"), outro que nos permite executar comandos diretos de SQL ("SQL"), dois que nos permitem importar e exportar bases de dados ("Import"e "Export", respetivamente), entre outros.
Figura 4.6: Interface principal do phpMyAdmin.
Clicando na base de dados "casadopastor", do lado esquerdo da janela, vai-nos abrir uma página com todas as tabelas desta base de dados, onde podemos consultar a estrutura desta, os seus dados, ou então inserir novas tabelas. Clicando no nome de qualquer uma delas, vemos a estrutura dos seus campos, tal como podemos ver na gura 4.7. É possível alterar um campo (clicando em "Alterar"), eliminá-lo ("Eliminar"), ou então inserir uma nova coluna, na parte inferior da gura, no botão "Executar".
Figura 4.7: Exemplo de estrutura de tabela.. Para colocar a base de dados num servidor é necessário:
• Exportar a base de dados existente na minha máquina; • Importá-la para a nova base de dados do servidor;
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 35 Para exportar é apenas necessário selecionar a nossa base de dados, clicar no menu superior em "Exportar", selecionar o formato pretendido (no meu caso, escolhi for-mato SQL), escolher as tabelas pretendidas (normalmente serão todas), escolher os dados que queremos (apenas tabelas, apenas dados, ou tabela com todos os dados), clicar em "Executar"e será recebido um cheiro SQL (neste caso) com toda a estru-tura da base de dados. Estas são as de nições principais, no entanto, existem mais de nições na exportação da base de dados que podem ser alterados.
De seguida, para importar a base de dados para o servidor, é apenas necessário importar o cheiro SQL, clicando em "Importar", de seguida em "Escolher cheiro", procurar o cheiro SQL, e clicar em "Executar". Depois disto, toda a estrutura e dados da base de dados exportada anteriormente, cará disponível na nova base de dados.
No presente projeto, este software foi utilizado para a criação e gestão de toda a base de dados.
4.2.2.3 Apache
O Apache é o mais bem sucedido servidor web livre, criado em 1995 por Rob McCool [8], que era na altura funcionário da NCSA (National Center for Supercomputing Applications). Segundo estudos realizados em 2007 e em 2010, o Apache serve já mais de 50% dos sites existentes, dos quais cerca de 65% dos milhões dos sites exis-tentes mais movimentados no mundo. É a principal tecnologia da Apache Software Foundation, responsável por mais de uma dezena de projetos envolvendo tecnologias de transmissão via web e processamento de dados. As suas funcionalidades são man-tidas através de uma estrutura de módulos, permitindo inclusive que o utilizador escreva os seus próprios módulos utilizando a API do software.
O Apache foi utilizado para simular o servidor PHP na minha máquina e para testar todas as páginas criadas.
4.2.2.4 MySQL
O MySQL foi criado na Suécia na década de 80, por David Axmark, Allan Larsson e Michael Monty Widenius [8], que têm trabalhado juntos desde então. É um sistema de gestão de bases de dados (SGBD), que utiliza a linguagem SQL (Linguagem de Consulta Estruturada) como interface. É atualmente uma das bases de dados mais populares, com mais de 10 milhões de instalações por todo mundo, tais como a NASA, Dataprev, HP, Nokia, Sony, U.S. Army, Cisco Systems, Google, entre outros.
4.2.3 Core FTP LE
Para proceder à transferência de cheiros, quer para o servidor de testes, quer para o servidor nal, foi utilizado o programa Core FTP LE, que é um cliente FTP (File Transfer Protocol) seguro para Windows, desenvolvido pela "CoreFTP.com"[9], que permite ao utilizador transferir cheiros para o servidor pretendido, depois de feita a autenticação nesse mesmo servidor.
CAPÍTULO 4. TECNOLOGIAS UTILIZADAS 36 O Core FTP LE foi utilizado para a transferência de todos os cheiros da aplicação desenvolvida para os servidores, quer de testes, quer nal.
Capítulo 5
Implementação da solução
Tanto o FrontO ce como o BackO ce foram desenvolvidos no Dreamweaver, com recurso às tecnologias HTML, CSS, PHP e JavaScript, enquanto que toda a base de dados foi desenvolvida em SQL com recurso à ferramenta MySQL, como já descrito anteriormente.
Os endereços das páginas web são os seguintes:
1. Casa do Pastor http://www.casadopastor.com/.
2. FrontO ce http://www.casadopastor.com/pt/index.php/pt/alojamento.
3. Backo ce http://www.casadopastor.com/pt/reservas/.
5.1 Arquitetura
Na gura 5.1 é apresentada a estrutura da arquitetura de navegação do site. Inici-almente o Cliente faz um pedido através do seu computador pessoal via HTTP ao Servidor Web. Este, por sua vez, veri ca se a página web requerida pelo Cliente é conteúdo HTML; se for HTML, transmite de imediato a resposta HTML para o Cliente, caso contrário (se for um pedido de conteúdo PHP) faz o pedido PHP ao Processador PHP. O processador PHP pode ainda, se necessário, fazer consultas ao Servidor de Base de Dados, o qual lhe devolve os dados respetivos dessa mesma consulta, e, por m, envia a resposta HTML para o Servidor Web e, por sua vez, ao Cliente. O mesmo acontece com os gestores e administrador, no entanto estes podem ter também acesso através da rede local.
5.2 Base de dados
5.2.1 Modelo relacional
Todos os dados são armazenados numa base de dados (casadopa_reservas) desen-volvida para o efeito. Na gura 5.2 é apresentado o modelo relacional da base de dados.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 38
Figura 5.1: Arquitetura.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 39 Todas as ligações existentes indicam obrigatoriedade, à exceção da ligação entre a tabela "estadoreserva"e "gestores", em que na tabela "estadoreserva"é guardado o ID do gestor, mas este não é obrigatório, uma vez que vai car posteriormente guardado na tabela "historico".
5.2.2 Descrição das tabelas
Nesta secção é apresentada a descrição da estrutura das tabelas da base de dados, que inclui o dicionário de dados de cada uma das tabelas, e o signi cado de cada uma delas.
De forma a abreviar a descrição das tabelas, são utilizadas algumas siglas: • D Permite dígitos de 0 a 9.
• L Permite letras de 'a' a 'Z' e espaço. • CP Chave primária.
• CE Chave estrangeira. 5.2.2.1 Atividades
Na tabela 5.1 apresenta-se a estrutura da tabela relativa às atividades disponíveis para os clientes, onde podemos ver o ID da atividade, o seu nome, o número máximo de pessoas que podem entrar na atividade e a respetiva idade mínima.
Campo Tipo Tamanho Validações Descrição
ID_Actividade (CP) Inteiro 2 [1..99] Número sequencial que identi ca univocamente cada atividade Nome Texto 30 6=branco, [DL] Nome da atividade
Max_Pessoas Inteiro 2 [0..99] Numero máximo de pessoas a participar na atividade
Idade_Min Inteiro 2 [0..99] Idade mínima das pessoas para participar na atividade
Tabela 5.1: Estrutura da tabela de atividades.
As atividades não são da responsabilidade da Casa do Pastor, sendo meramente informativas para o cliente, daí não terem nenhum preço associado.
5.2.2.2 Casas
Na tabela 5.2 apresenta-se a estrutura da tabela relativa às casas disponíveis para os clientes. Nesta podemos ver o ID da casa, o seu nome, tipologia e a capacidade máxima, bem como os preços da época alta e da época baixa.
A tipologia da casa serve apenas como informação, sendo que para o cálculo da capacidade e do preço não interfere.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 40
Campo Tipo Tamanho Validações Descrição
ID_Casa (CP) Inteiro 2 [1..99] Número sequencial que identi ca univocamente cada casa
Nome Texto 50 6=branco, [DL] Nome da casa
Tipologia Texto 10 6=branco, [DL] Tipologia da casa (meramente informativa)
Capacidade Inteiro 2 [0..99] Capacidade máxima da casa Preco_Epoca_Alta Inteiro 3 [0..999] Preço da casa em época alta Preco_Epoca_Baixa Inteiro 3 [0..999] Preço da casa em época baixa
Tabela 5.2: Estrutura da tabela de casas. 5.2.2.3 Clientes
Na tabela 5.3 apresenta-se a estrutura da tabela relativa aos clientes. É aqui que podemos ver o ID do cliente, o seu nome, morada, mail, telefone, telemóvel e bilhete de identidade.
Campo Tipo Tamanho Validações Descrição
ID_Cliente (CP) Inteiro 5 [1..99999] Número sequencial que identi ca univocamente cada cliente Nome Texto 50 6=branco, [DL] Nome do cliente
Morada Texto 100 6=branco, [DL] Morada do cliente Mail Texto 50 6=branco, [DL] Mail do cliente Telefone Inteiro 15 15 dígitos de 0 a 9 Telefone do cliente Telemovel Inteiro 15 15 dígitos de 0 a 9 Telemóvel do cliente
BI Inteiro 13 13 6= branco, [DL] Bilhete de Identidade do cliente
Tabela 5.3: Estrutura da tabela de clientes.
Os clientes da Casa do Pastor nem sempre são Portugueses, logo, o telefone e o telemóvel têm limite de 15 dígitos para precaver essas situações. Já o BI do cliente, uma vez que existem BI's que têm, para além de números, também letras, apenas se faz a validação de este não ser nulo, mas pode conter informação não correta, já que este é um dado informativo.
5.2.2.4 Reservas
Na tabela 5.4 apresenta-se a estrutura da tabela relativa às reservas. Aqui podemos ver os dados gerais da reserva, tais como o nome, o ID do Cliente inerente à reserva, o ID do estado em que esta se encontra, o número total de pessoas (e em particular de crianças, bebés, adultos e séniors), o número de animais, as datas de entrada e de saída, entre outros.
5.2.2.5 Estado
Na tabela 5.5 apresenta-se a estrutura da tabela relativa aos estados, onde podemos ver o ID do Estado e a sua descrição.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 41
Campo Tipo Tamanho Validações Descrição
ID_Reserva (CP) Inteiro 5 [1..99999] Número sequencial que identi ca univocamente cada reserva NomeReserva Texto 40 6=branco, [DL] Nome da Reserva
ID_Cliente (CE) Inteiro 5 [1..99999] Número identi cativo do cliente que efetuou a reserva
N_Bebes Inteiro 2 [0..99] Número de bebés N_Criancas Inteiro 2 [0..99] Número de crianças
N_Adultos Inteiro 2 [0..99] Número de adultos N_Seniors Inteiro 2 [0..99] Número de séniors N_Pessoas Inteiro 2 [0..99] Número de pessoas N_Animais Inteiro 2 [0..99] Número de animais N_Camas_Extra Inteiro 2 [0..99] Número de camas extra
N_Bercos Inteiro 2 [0..99] Número de berços Data_Entrada Data Data Válida Data de entrada
Data_Saida Data Data Válida Data de saída Preco_Reserva Real 5.2 [0,00..99999,99] Preço da reserva
Desconto Inteiro 2 [0..99] Desconto da reserva
Tabela 5.4: Estrutura da tabela das reservas.
Campo Tipo Tamanho Validações Descrição
ID_Estado (CP) Inteiro 2 [1..99] Número sequencial que identi ca univocamente cada estado Descricao Texto 30 6=branco, [DL] Descrição do estado
Tabela 5.5: Estrutura da tabela de estados. 5.2.2.6 EstadoReserva
Na tabela 5.6 apresenta-se a estrutura da tabela relativa ao estado individual de cada reserva, onde é guardado o ID da Reserva, do Estado, do Gestor que efetuou a alteração, e a data da alteração.
Campo Tipo Tamanho Validações Descrição
ID_Reserva (CE) Inteiro 5 [1..99999] Número que identi ca univoca-mente cada reserva
ID_Estado (CE) Inteiro 2 [1..99] Número que identi ca o estado referente à reserva
ID_Gestor (CE) Inteiro 2 [1..99], pode ser nulo Número que identi ca o gestor que atualizou o estado da reserva Data Data Data Válida Data de alteração do estado da
reserva
Tabela 5.6: Estrutura da tabela do estado de cada reserva. Tal como referido anteriormente, o ID do Gestor pode ser nulo.
5.2.2.7 ActividadesReserva
Na tabela 5.7 apresenta-se a estrutura da tabela relativa às atividades inerentes às reservas, na qual podemos ver o ID da Reserva e da Atividade, o número de pessoas
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 42 que nela vão participar e a respetiva data.
Campo Tipo Tamanho Validações Descrição
ID_Reserva (CE) Inteiro 5 [1..99999] Número que identi ca univoca-mente cada reserva
ID_Actividade (CE) Inteiro 2 [1..99] Número que identi ca a ativi-dade associada à reserva
N_Pessoas Inteiro 2 [0..99] Número de pessoas que partici-parão na atividade
Data Data Data Válida Data da atividade
Tabela 5.7: Estrutura da tabela de atividades da reserva. 5.2.2.8 CasasReserva
Na tabela 5.8 apresenta-se a estrutura da tabela relativa às casas inerentes às reser-vas. Aqui podemos ver o ID da Reserva e da Casa, o número de pessoas que nela vão habitar, as datas de entrada e saída, entre outros.
Campo Tipo Tamanho Validações Descrição
ID_Reserva (CE) Inteiro 5 [1..99999] Número que identi ca univoca-mente cada reserva
ID_Casa (CE) Inteiro 2 [1..99] Número que identi ca a casa as-sociada à reserva
N_Pessoas Inteiro 2 [0..99] Número de pessoas que irão ha-bitar a casa
N_Camas_Extra Inteiro 1 [0..9] Número de camas extra necessá-rias para a casa
N_Bercos Inteiro 1 [0..9] Número de berços necessárias para a casa
Data_Entrada Data Data Válida Data de entrada na casa Data_Saida Data Data Válida Data de saída da casa Preco_Casa Inteiro 5 [1..99999] Preço total da casa
Tabela 5.8: Estrutura da tabela de casas da reserva.
Uma vez que o desconto não atua diretamente no preço da casa, esse valor é inteiro e não do tipo oat.
5.2.2.9 Gestores
Na tabela 5.9 apresenta-se a estrutura da tabela relativa aos gestores, na qual po-demos ver os dados de cada gestor, tal como o seu ID, nome, telemóvel, mail, entre outros.
A password do gestor é guardada de forma encriptada, isto é, se a password for por exemplo "`gestor"' não irá guardar "`gestor"', mas sim o resultado da encriptação.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 43
Campo Tipo Tamanho Validações Descrição
ID_Gestor (CP) Inteiro 2 [1..99] Número que identi ca univoca-mente cada gestor
Nome Texto 50 6=branco, [DL] Nome do gestor Telemovel Inteiro 9 9 dígitos de 0 a 9 Telefone do gestor
Mail Texto 50 6=branco, [DL] Mail do gestor BI Inteiro 8 8 dígitos de 0 a 9 Telefone do gestor Morada Texto 100 6=branco, [DL] Morada do gestor Password Texto 50 6=branco, [DL] Password do gestor
Tabela 5.9: Estrutura da tabela de gestores.
Campo Tipo Tamanho Validações Descrição
ID_Administrador (CP) Inteiro 2 [1..99] Número que identi ca univoca-mente cada administrador Nome Texto 50 6=branco, [DL] Nome do administrador Password Texto 50 6=branco, [DL] Password do administrador
Tabela 5.10: Estrutura da tabela do administrador. 5.2.2.10 Administrador
Na tabela 5.10 apresenta-se a estrutura da tabela relativa ao administrador, onde se pode ver o seu ID, nome e password.
Tal como no caso dos gestores, a password do administrador é guardada igualmente encriptada. Apesar de o objetivo da aplicação ser a existência de apenas um admi-nistrador, para evitar que um dia mais tarde se queiram mais administradores, foi dada uma margem de dois dígitos para o respetivo ID.
5.2.2.11 Historico
Na tabela 5.11 apresenta-se a estrutura da tabela relativa ao histórico, que é onde cam guardadas todas as operações de edição e remoção de registos do sistema para poderem ser mais tarde vistos pelo administrador.
Campo Tipo Tamanho Validações Descrição
Data Data Data Válida Data da realização da operação. IDGestor Inteiro 2 [1..99] Número que identi ca o gestor
que efetuou a operação.
Operacao Texto 500 6=branco, [DL] Descrição da operação realizada.
Tabela 5.11: Estrutura da tabela do historico.
O campo "`IDGestor"' é onde ca guardado o ID do Gestor que efetuou a opera-ção, no entanto, se um administrador efetuar alguma operaopera-ção, ca também aqui registado, mas com IDGestor = 0, para haver diferenciação de quem fez o quê. O campo "`Operacao"' é onde ca guardada detalhadamente, com todos os campos necessários, a operação que o gestor ou o administrador zeram, de forma a que, caso necessário, o administrador possa repôr os dados.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 44
5.2.3 Criação da base de dados no servidor MySQL
A criação da base de dados e tabelas no servidor MySQL (https://b23.hocnet. org:2083/3rdparty/phpMyAdmin/index.php) foi realizada através do script SQL apresentado em anexo A.2, com a opção Import do phpmyadmin.
5.3 FrontO ce
O FrontO ce do projeto refere-se à parte da aplicação à qual o utilizador nal tem acesso. Entende-se por utilizador nal todos os clientes da Casa do Pastor que irão utilizar a aplicação web para criarem as suas reservas. Esta parte da aplicação web está embebida do site o cial da Casa do Pastor, tendo sido criadas duas páginas, para:
1. O calendário, onde o cliente consulta o calendário de todas as casas. 2. Efetuar reservas.
Apesar das páginas da aplicação web estarem embebidas no projeto, quando por exemplo o cliente começa a inserir reservas, a página principal não vai atualizar, mas onde ele estará a inserir os dados irá funcionar como um site independente.
5.3.1 Mapa do site
Por um lado, temos a parte do calendário, que é apenas uma página:
• CalendarioCli
Por outro, temos a criação da reserva, que inclui já várias páginas:
• CriarReserva
Veri carDesponibilidade ∗ InfoCasas
· Con rmacao 1. Finalizacao
Nas secções seguintes e apresentado com detalhe o modo de navegação e funciona-mento da aplicação do lado do cliente.
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 45
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 46
5.3.2 Calendário
Na gura 5.3 é apresentada a vista inicial da página onde o cliente pode consultar o calendário de todas as casas, numa determinada data, de forma a saber se uma determinada casa se encontra ocupada ou não na data escolhida. Sempre que a página é carregada é visto se existem dados guardados no método "POST"(mês, ano e casa), e, caso exista, é mostrado o calendário do mês e ano selecionado da respetiva casa, caso contrário a casa que ca selecionada é a primeira casa da lista da tabela da base de dados, vendo-se o mês e ano atual.
Esta aparência é obtida a partir do código do anexo A.1.
5.3.3 Criação da reserva
Na gura 5.4 é apresentada a vista inicial da página onde o cliente começa a criar a sua reserva. Aqui o cliente irá inserir o número de pessoas e as datas de entrada e de saída. Clicando em "Seguinte", passará (caso se veri que) para a página seguinte, continuando com a inserção dos dados da reserva, sendo que a próxima página apresentada será dentro da mesma página do site, mas dentro da criação da reserva será uma página diferente.
Figura 5.4: Criar Reserva.
A página para onde é seguidamente reencaminhado, é uma página onde o cliente tem que inserir dois tipos de dados diferentes:
1. Em primeiro lugar, os dados relativos ao próprio cliente, tais como o Nome, Morada, Telefone e/ou Telemóvel, email, entre outros.
2. Depois, os dados relativos à reserva no geral, bem como o Nome da reserva, o número de crianças, número de adultos, número de animais, etc.
Ambas as páginas passam por um processo de validação de todos os dados inseridos, como pode ser demonstrado pelo código presente no anexo A.7. Todos os dados têm que ser válidos, sendo que o número de pessoas tem que ser um valor numérico,
CAPÍTULO 5. IMPLEMENTAÇÃO DA SOLUÇÃO 47 caso contrário volta para a página anterior para ser novamente inserido; da mesma forma, as datas de entrada e de saída, são igualmente validadas, e se estas estiverem inseridas de forma errada, volta igualmente para a página anterior para serem no-vamente inseridos. A função ValidaData veri ca se a data inserida é válida ou não e veri ca se esta é uma data superior à data atual: se tudo isto se veri car, então a data é válida, caso contrário é uma data inválida.
Tal como todos os dados são validados, o email do cliente tem que ser igualmente validado, e essa validação está demonstrada no anexo A.8. Todos os emails têm que ser do formato exemplo@exemplo.exe.
Se todos os dados inseridos estiverem corretos, é levado para a página que contém uma lista com as casas livres nas datas escolhidas, tal como se pode ver na gura 5.5.
Figura 5.5: Lista das Casas disponíveis.
É aqui que o cliente escolhe as casas pretendidas (tantas quanto necessário para todas as pessoas). Nesta lista pode-se ver o nome da casa, a capacidade total, e os preços da época alta e época baixa.
Esta lista é obtida com recurso ao código mostrado na listagem 10. Inicialmente é feito um Select à tabela das casas da reserva de forma a guardar numa lista todas as
