Tiago Manuel Machado Ribeiro Oliveira. Sistema de Informação Dedicado com Site de Vendas e Bases de Dados. Universidade do Minho Escola de Engenharia

Transcrição

1 Universidade do Minho Escola de Engenharia Tiago Manuel Machado Ribeiro Oliveira Sistema de Informação Dedicado com Site de Vendas e Bases de Dados UMinho 2010 Tiago Manuel Machado Oliveira Sistema de Informação Dedicado com Site de Vendas e Bases de Dados Outubro de 2010

2

3 Universidade do Minho Escola de Engenharia Tiago Manuel Machado Ribeiro Oliveira Sistema de Informação Dedicado com Site de Vendas e Bases de Dados Dissertação de Mestrado Ciclo de Estudos Integrados Conducentes ao Grau de Mestre em Engenharia Electrónica Industrial e Computadores Trabalho efectuado sob a orientação do Professor Doutor Sérgio Adriano Fernandes Lopes Outubro de 2010

4 Agradecimentos Gostaria de deixar aqui registado o meu agradecimento a todas as pessoas que de alguma forma contribuíram para a realização desta dissertação, sem deixar de lado as pessoas que sempre me acompanharam ao longo da minha vida académica. De entre essas pessoas gostaria de salientar o meu orientador Professor Doutor Sérgio Adriano Fernandes Lopes, cujo apoio e orientação foram essenciais para atingir todos os objectivos propostos. Em segundo lugar, mas não menos importante, gostaria de agradecer ao grupo onde estive inserido durante a fase de mestrado, o Grupo de Investigação em Sistemas Embebidos (E.S.R.G), por todo o apoio prestado, quer por parte dos colegas, quer por parte de todos os professores, em especial ao Professor Doutor Adriano José C. Tavares. Não posso também deixar de agradecer à empresa IVV Automação, pela forma como me acolheu, e pela oportunidade que me concedeu em efectuar esta dissertação, disponibilizando-me um grupo de apoio excelente que me proporcionou um crescimento profissional e pessoal de grande valor. Por último um agradecimento muito importante a toda a minha família! iii

5

6 Resumo Este trabalho consiste no desenvolvimento de um sistema de informação para a empresa IVV Automação, que suporte a venda dos seus produtos através da Internet e do SMS. Este sistema é composto por duas bases de dados, um sítio Web e um serviço de encomendas por SMS. No que diz respeito às bases de dados, foi implementado um sistema de comunicação entre um servidor já existente na empresa (com um servidor MSSQL onde estão alocados dados de produtos e clientes da empresa) e um novo servidor (onde está alocado o sítio Web e uma base de dados MySQL, para suporte ao sítio Web). Este sistema de comunicação efectua a troca de dados bidireccional de forma a manter a sincronização dos dados de clientes, produtos e encomendas nas duas bases de dados, recorrendo para isso a tecnologias como webservices, daemons e triggers. Quanto ao site Web, este é composto por um front-end e um back-end. O backend permite à administração da IVV gerir utilizadores por grupos, produtos com preços diferenciados por grupo de utilizador, encomendas, e todo o conteúdo a ser disponibilizado no sítio Web. Para além disso disponibiliza uma área de gestão de funcionalidades dinâmicas que permite adicionar/eliminar páginas que forneçam funcionalidades adicionais. Uma dessas funcionalidades, implementada de raíz, é a criação e gestão de permissões de utilizadores por parte de uma empresa cliente. O front-end é efectivamente todo o conteúdo disponibilizado para interacção com o utilizador, e é composto por componentes de catálogo e encomenda de produtos, de serviço help-desk, de agenda, de downloads, e da área de funcionalidades dinâmicas. Por último, o serviço de encomendas por SMS é desenvolvido com recurso a um módulo GSM, ligado ao computador onde está instalado o novo servidor, via porta série. Este serviço inclui o desenvolvimento de uma aplicação, sob a forma de daemon, para processamento de encomendas e comunicação com módulo GSM. v

7

8 Abstract This work consist in the development of an information system for IVV Automação company, which supports selling their products through the Internet and SMS. This system consists of two databases, a website and an orders service via SMS. With regard to databases, there is a communication system in an existing server in the company (with a MSSQL server where products and customers data are allocated) and a new server (wherein the website and a MySQL database are allocated). This communication system performs data exchange in order to maintain two-way synchronization of customer data, products and orders in the two databases, using for that technologies such as webservices, daemons, and triggers. As for the website, this is composed of a front-end and back-end. The back-end allows the administration of IVV to manage users by groups, products with different prices per group of users, orders, and all content available on the website. It also provides a dynamic features management area that allows to add/delete pages providing additional functionality. One such feature, implemented from scratch, is the creation and management of users permissions by a client company. The front end is actually all the content available for user interaction, and is composed of catalog and ordering products components, service, help desk, calendar, downloads, and the area of dynamic features. Finally, the orders service by SMS is developed using a GSM module, connected via serial port to the computer where the new server is installed. It includes the development of a daemon application for order processing and communication with GSM module. vii

9 Índice Agradecimentos... iii Resumo... v Abstract...vii Índice... viii Índice de Figuras... x Índice de Tabelas... xiii Lista de Siglas e Acrónimos... xiv 1. Introdução Descrição do Trabalho Estrutura da Dissertação Fundamentos Teóricos Joomla Instalação e Utilização Vantagens e Desvantagens Web Services Daemons Triggers Padrão Model-View-Controller Aplicações Web sob o modelo MVC Joomla MVC Linguagem de Comandos de Modems Bison/Flex Descrição da empresa IVV Automação A empresa e seus clientes Servidor IVV Servidor do novo site viii

10 3.3.1 Componentes Joomla instalados Mecanismo de Sincronização das Bases de Dados Descrição do Problema Exportação de dados do Servidor IVV para o Servidor Site Instalação do driver ODBC Implementação dos scripts PHP Desenvolvimento do mecanismo de sincronização Comunicação entre Servidor Site e Servidor IVV Comunicação entre Servidor IVV e Servidor Site Desenvolvimento do site Configuração e adaptação do Joomla Componente de funcionalidades dinâmicas Desenvolvimento do Sistema de Encomendas por SMS Módulo GSM Descrição do Sistema Implementação do Software Configuração da porta USB do PC Configuração do módulo GSM Parsing de uma mensagem SMS recebida Tratamento dos dados recebidos, e ligações à base de dados Conclusões e Sugestões para Trabalho Futuro Referências Internet Livros ix

11 Índice de Figuras Figura 1 Diagrama da arquitectura do sistema... 3 Figura 2 - Arquitectura Joomla... 6 Figura 3 - Menu de Instalação Joomla... 7 Figura 4 - Funcionamento de Webservices Figura 5 - Fluxograma genérico de um Daemon Figura 6 - Estrutura em código C de um daemon Figura 7 - Sistema MVC Figura 8 - Estrutura de ficheiros Joomla MVC Figura 9 - Sequência de analisador léxico e sintáctico Figura 10 - Funcionamento do Flex Figura 11 - Análise lexical e sintáctica de uma frase Figura 12 - Diagrama estrutural da empresa IVV e seus clientes Figura 13 - Servidor IVV: software instalado Figura 14 - Servidor do site: software instalado Figura 15 - Menu de back-end do VirtueMart Figura 16 - Menu de back-end do Huru Helpdesk Figura 17 - Menu de back-end do Joom!Fish Figura 18 View customers Figura 19 View cl Figura 20 - Diagrama de funcionamento do ODBC Figura 21 - Relação entre as principais tabelas referentes aos produtos Figura 22 - Fluxograma de script PHP para importar produtos Figura 23 - Excerto de código PHP do script de importação dos produtos Figura 24 - Representação dos dados da tabela jos_core_acl_aro_groups Figura 25 - Relação entre as principais tabelas referentes aos clientes Figura 26 - Fluxograma para geração de palavra-chave para Joomla Figura 27 - Fluxograma de script PHP para importar os dados dos clientes Figura 28 - Diagrama de funcionamento do mecanismo de sincronização (site ivv) 48 x

12 Figura 29 - Código SQL de um trigger do mecanismo de sincronização Figura 30 - Fluxograma do processamento do daemon de verificação da tabela jobs.. 49 Figura 31 - Excerto de código PHP do daemon de verificação da tabela jobs Figura 32 Fluxograma da rotina C do cliente do Web service do mecanismo de sincronização (site ivv) Figura 33 - Fluxograma da rotina C do servidor webservice do mecanismo de sincronização (site ivv) Figura 34 - Documento WSDL do webservice do mecanismo de sincronização (site ivv) Figura 35 - Diagrama de funcionamento do mecanismo de sincronização (ivv site) 54 Figura 36 - Fluxograma da rotina C do ficheiro servidor.php do mecanismo de sincronização (ivv site) Figura 37 - Layout da página princiapl do front-end do site (antes do login) Figura 38 - Layout da página princiapl do front-end do site (depois do login) Figura 39 - Layout do menu principal do componente Huru Helpdesk no front-end do site Figura 40 - Layout do componente Huru Helpdesk, para inserir novo tópico, no frontend do site Figura 41 - Layout do menu principal do componente Remository no front-end do site Figura 42 - Relação entre as tabelas da base de dados da página dinâmica Figura 43 - Relacionamento entre itens da página dinâmica Figura 44 Relação entre as tabelas de idiomas da base de dados da página dinâmica Figura 45 Fluxograma da implementação da página index.php Figura 46 - Fluxograma da função de impressão do menu dinâmico Figura 47 - Layout da página índex.php do componente de funcionalidades dinâmicas Figura 48 - Layout do menu da página index.php, utilizando a recursividade Figura 49 - Layout da página Gestão de Páginas do componente de funcionalidades dinâmicas xi

13 Figura 50 - Layout da página Adicionar Funcionários do componente de funcionalidades dinâmicas Figura 51 - Layout da página Gerir Permissões do componente de funcionalidades dinâmicas Figura 52 - Layout da página Empréstimos do componente de funcionalidades dinâmicas Figura 53 - Layout da página Conta Corrente do componente de funcionalidades dinâmicas Figura 54 - Módulo Wavecom Fastrack Figura 55 - Fluxograma de configuração da porta ttyusb Figura 56 - Fluxograma de configuração do módulo GSM (parte 1) Figura 57 - Fluxograma de configuração do módulo GSM (parte 2) Figura 58 Regras gramaticais do ficheiro parser.y Figura 59 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 1) Figura 60 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 2) xii

14 Índice de Tabelas Tabela 1 - Parâmetros do comando AT+CNMI Tabela 2 - Exemplo de tokens para o gerador léxico Tabela 3 - Tabela jos_vm_shopper_group Tabela 4 - Características do módulo GSM Wavecom Fastrack Supreme Tabela 5 - Tokens definidos no ficheiro scan.l xiii

15 Lista de Siglas e Acrónimos HTML HyperText Markup Language HTTP HyperText Transfer Protocol PHP Hypertext Preprocessor CSS Cascading Style Sheets SQL Structured Query Language PC Personal Computer SIM Subscriber Identity Module PIN Personal Identification Number RS-232 Recommended Standard 232 XML extensible Markup Language SOAP Simple Object Access Protocol W3C World Wide Web Consortium WSDL Web Service Description Language MVC (Model View Controller) ODBC Open Data Base Connectivity API Application Programming Interface SDK Software Development Kit ACL Access Control Lists ARO Access Request Object md5 Message-Digest algorithm 5 USB Universal Serial Bus AST Abstract syntax tree PBX Private Branch Exchange CMS Content Management System SMS Short Message Service xiv

16 1. Introdução As estruturas de suporte à Internet têm sofrido melhoramentos bastante significativos, o que conduziu a um aumento muito significativo do número de utilizadores e de sistemas baseados em estruturas Web. Actualmente a população mundial está estimada em 6,8 mil milhões de pessoas, sendo que aproximadamente 26,6% (1,8 mil milhões) dessas pessoas utilizam a Internet. [1] Esta globalização da Internet leva a que vários tipos de organizações (e.g. governos, empresas, serviços de saúde) utilizem este meio de comunicação como forma principal de comunicarem com o seu público-alvo, e no caso de empresas, estas poderem aumentar significativamente os seus lucros, através do marketing neste meio. Com o aumento da utilização da Internet, foram também surgindo novas ferramentas que apoiam o desenvolvimento de aplicações para ela orientadas. Ferramentas essas que suportam o seu funcionamento em linguagens como HTML, PHP, Javascript, CSS, Flash, permitindo a um maior número de pessoas desenvolver uma aplicação Web, sem ter de recorrer a um programador experiente para o fazer. Um tipo de ferramenta que tem vindo a ser utilizada por vários desenvolvedores de aplicações Web é o tipo Content Management System (CMS), que para além de permitir desenvolver uma aplicação Web dinâmica, permite que esta seja desenvolvida por várias pessoas em simultâneo, recorrendo para isso a uma implementação por módulos. Ao permitir este tipo de implementação, é possível a um desenvolvedor encontrar módulos já desenvolvidos (muitos deles open source), e utilizá-los assim na sua aplicação, sem ter que recorrer a uma implementação de raiz. No que diz respeito aos dados disponibilizados na Internet, estes encontram-se muitas vezes armazenados em bases de dados, alocadas em servidores. O recurso a estes sistemas de armazenamento é indeclinável, visto que tornam possível disponibilizar conteúdos dinâmicos ao utilizador, isto é, conteúdos que não estão escritos directamente (estáticos) no código da aplicação Web, e que podem ser alterados facilmente na base de dados. 1

17 Para além da expansão do número de utilizadores de Internet, o mundo tem vindo a assistir a um aumento muito significativo de utilizadores de telemóveis, assim como funcionalidades e serviços orientados para estes. Tendo em conta essa tendência, é possível encontrar servidores SMS em diversas aplicações, tais como em domótica, concursos televisivos e serviços de encomendas. 1.1 Descrição do Trabalho Este trabalho surge da necessidade de inovar o site da empresa IVV Automação, nomeadamente renovando e optimizando o seu sistema de vendas e encomendas via Web, e também adicionando um sistema de encomendas por SMS. A implementação de um site dinâmico com um interface de simples utilização para o utilizador cliente permite um aumento significativo de vendas, assim como simplifica a gestão dos clientes e das suas encomendas por parte da administração de uma empresa. Aliando a este factor a implementação de um sistema de encomendas por SMS, permite ao cliente optar por um novo meio para realizar encomendas, o que poderá também ajudar ao aumento de vendas por parte da empresa. A empresa IVV Automação já possuía um site que utilizava com o mesmo propósito. No entanto, este era independente do sistema de gestão da empresa, nomeadamente do seu software de gestão PHC, pelo que a empresa decidiu inovar e criar um novo site em que houvesse uma certa sincronização entre ambos. Para a implementação de um site sincronizado com o software de gestão, foi desenvolvido um sistema isolado do próprio código fonte do site, ou seja, cujos ficheiros de código do sistema nenhuma ligação têm com o código do site, que faz a interpretação e a transferência de dados entre a base de dados do sistema de gestão da empresa e a base de dados do novo site. O site, para além do interface para o cliente da empresa, denominado frontend, possui um outro interface para a administração da empresa, denominado backend. O back-end permite fazer a gestão do conteúdo apresentado no front-end, assim como personalizar o aspecto de todo o site. 2

18 O sistema de encomendas por SMS também está conectado à base de dados do site. Este sistema trata da recepção das mensagens de texto enviadas pelo cliente com novas encomendas, e que insere-as ou não na base de dados. A arquitectura de todo o sistema encontra-se ilustrada na Figura 1. Figura 1 Diagrama da arquitectura do sistema 1.2 Estrutura da Dissertação Esta dissertação encontra-se estruturada em 9 capítulos, com o objectivo de apresentar o trabalho realizado nesta dissertação. Depois deste capítulo introdutório apresenta-se o capítulo 2, onde são apresentados os principais fundamentos teóricos referentes às tecnologias e ferramentas utilizadas n o desenvolvimento do trabalho. No capítulo 3 é elaborada uma descrição da empresa IVV Automação, da sua relação com os seus clientes, dos servidores utilizados durante o trabalho e também a apresentação dos componentes Joomla utilizados neste trabalho. 3

19 O capítulo 4 descreve a implementação do mecanismo de sincronização das bases de dados, que efectua a transferência de dados entre elas. O capítulo 5 apresenta o desenvolvimento do site, incluindo o componente de funcionalidades dinâmicas. No capítulo 6 é apresentada a implementação do sistema de encomendas por SMS. No capítulo 7 são apresentadas as conclusões do trabalho realizado, e perspectivas de melhoramentos dos sistemas implementados. 4

20 2. Fundamentos Teóricos 2.1 Joomla O Joomla é um CMS, que surgiu no ano de 2005, e que foi desenvolvido a partir de um outro CMS, o Mambo. [2] O objectivo do Joomla é facilitar o design, desenvolvimento, implantação e manutenção de sites Web. Sendo este um projecto open-source, totalmente desenvolvido em PHP e HTML e com ligação a base de dados MySQL, apresenta-se actualmente numa versão estável (Novembro de 2009, versão ). O interface do Joomla está dividido em duas partes: o front-end e o back-end. Entende-se por front-end como sendo a área que está acessível para visualização a qualquer utilizador que visite o site, ou seja, é onde todo o conteúdo informativo do site é publicado pela administração do site, podendo a visualização desse conteúdo estar limitada de acordo com as restrições estabelecidas pela administração. O back-end do site é a área de administração, que é restrita a utilizadores da administração. Nesta área existe um vasto leque de ferramentas, que ajudam o administrador na criação, edição e gestão do conteúdo do site, como publicação e instalação de novos módulos, componentes e outras utilidades do site. É também no back-end que o administrador configura o funcionamento do CMS, como por exemplo atribuir as já referidas permissões de acesso a conteúdos (textos, imagens, vídeos ), adicionar ou remover utilizadores, adicionar e editar conteúdos, assim como modificar o aspecto das páginas com recurso à edição do código HTML e/ou CSS do template utilizado, ou mesmo instalar um novo template. O Joomla CMS é implementado sobre a Framework Joomla, conforme descrito na Figura 2, que é composta por inúmeras classes e métodos PHP. [3] 5

21 Figura 2 - Arquitectura Joomla Para a elaboração de um site é necessário entender o funcionamento da camada de extensões, que é composta pelo template do site (aspecto e disposição dos objectos do site), por componentes e módulos. O Joomla CMS permite realizar a instalação e remoção de extensões, podendo assim serem adicionadas ou removidas funcionalidades ao site. Estas extensões podem ser encontradas facilmente no site do Joomla, podendo ser open-source ou comerciais. Quando forem requeridas funcionalidades específicas e não houver extensões que sirvam os objectivos, a administração do site pode desenvolver a sua própria extensão, necessitando para isso compreender a Framework Joomla. Os componentes são todas as aplicações que possuem um menu de configuração a partir do back-end do site, para definir parâmetros sobre o funcionamento do componente no front-end. Os componentes são responsáveis por adicionar funcionalidades como: galerias de imagens, criação dinâmica de formulários, comércio electrónico, banners publicitários, help-desk, estatísticas, entre muitas outras. Os componentes podem muitas vezes vir acompanhados de módulos ou Plugins para completarem as suas funcionalidades. Os módulos são extensões mais pequenas relativamente aos componentes, que têm como objectivo desempenhar pequenas tarefas, tanto no front-end como no backend do site. Como exemplo de módulos temos menus, calendários, carrinhos de compras, formulários de login, entre outras. Os módulos são os únicos objectos de um site Joomla que podem ser atribuídos a um local do template, e o seu aspecto é, como tudo o resto no Joomla, da completa responsabilidade do template. No entanto, caso o template permita, existe a possibilidade de definir parâmetros do módulo para alterar 6

22 a sua aparência individual. Na área de administração, o menu módulos contém uma lista de todos os módulos instalados no próprio site Instalação e Utilização Os requisitos mínimos para instalação e utilização do Joomla são: [4] O servidor Web Apache 1.3 O ambiente de desenvolvimento PHP O servidor de base de dados MySQL 3.23 A instalação do Joomla segue os seguintes passos: Download dos ficheiros do Joomla ( Extracção dos ficheiros para a directoria do servidor instalado no sistema (por exemplo C:\xampp\htdocs\Joomla) Abrir um browser e inserir o endereço respectivo (por exemplo: Seguir os passos da instalação no próprio browser Figura 3 - Menu de Instalação Joomla 7

23 Depois de terminada a instalação, para se aceder ao back-end do site utiliza-se o endereço e para se aceder ao front-end utiliza-se o endereço Vantagens e Desvantagens O desenvolvimento de um site pode ser feito com recurso a vários tipos de software, entre os mais comuns existem softwares de desenvolvimento Web como Adobe Dreamweaver ou Microsoft Front Page, ou utilizando um CMS como o Joomla ou Wordpress. As principais vantagens em utilizar um CMS são: Gerir desenvolvimento de um site num ambiente colaborativo; Edição e publicação de conteúdo no site sem necessidade obrigatória de conhecimentos de programação; Estruturação e alteração de layouts simples, com recurso a templates; Utilização de módulos e componentes já existentes, para inserir novas funcionalidades no site; Abstracção da comunicação com a base de dados. Todas estas vantagens fazem com que a utilização de um CMS se torne bastante comum no mundo informático. No que diz respeito a desvantagens, também é possível encontrar na utilização de um CMS como o Joomla. A principal desvantagem surge quando o criador do site se depara com a necessidade de implementar uma funcionalidade única e dedicada às suas necessidades. Quando se trata de desenvolver um componente ou um módulo para o Joomla surgem inúmeras dificuldades, dada a necessidade de compreender a Framework Joomla e também compreender a programação segundo a arquitectura Model View Controller (MVC). 8

24 Para além dessa desvantagem, também se torna complexo quando existem aplicações externas que necessitam inserir dados directamente na base de dados do Joomla, isto porque para isso é necessário compreender a ligação entre os dados de todas as tabelas existentes (o que ultrapassa as 100 tabelas quando existem alguns componentes instalados em simultâneo). 2.2 Web Services Esta tecnologia é utilizada na troca de dados entre aplicações, nomeadamente aplicações desenvolvidas em linguagens de programação diferentes, e/ou sobre sistemas operativos diferentes. Os Web services servem para disponibilizar serviços interactivos na Web, podendo existir uma aplicação servidora (a qual disponibiliza o serviço) e uma ou mais aplicações cliente (as quais requisitam o serviço). Estas aplicações utilizam o mecanismo de transporte HTTP, sendo as suas mensagens transmitidas no formato XML e definidas pelo protocolo SOAP. O protocolo SOAP foi definido pelo consórcio W3C para a troca de mensagens em ambientes independentes de plataforma e/ou linguagem de programação, daí se ter adequado perfeitamente ao conceito dos Web services. Para que qualquer cliente consiga saber quais os métodos disponibilizados pelo servidor e respectiva definição (parâmetros de entrada e retorno), é necessário criar um documento (ou utilizar ferramentas para o gerar) escrito em WSDL. Após a elaboração deste documento, o cliente acede-o para saber a localização da aplicação servidora e para obter as informações sobre os métodos disponibilizados por ela, conforme ilustrado na Figura 4. 9

25 Figura 4 - Funcionamento de Webservices 2.3 Daemons Daemons são programas executados num processo em background em sistemas operativos do tipo Unix, e que são colocados em execução durante o arranque (boot) do sistema. Este conceito pode ser equiparado ao dos Windows services em sistemas operativos Windows. O processo que é executado no boot do sistema torna-se num daemon aquando da bifurcação (forking) de um processo filho e pela terminação do processo pai imediata, isto é, quando o processo pai é executado no arranque do sistema, este inicia um processo paralelo, idêntico a si próprio (filho), e termina a sua execução, mantendo a execução do filho em background no sistema, ficando assim o processo órfão a cargo do processo init (processo cujo PID é 1, ou seja, é o pai de todos os processos do sistema). Quando um daemon inicia o seu processamento em background, é comum que este seja utilizado para monitorizar constantemente algum evento, mantendo assim pequenos ciclos de processamento, e invocar uma rotina de processamento quando detecta esse mesmo evento, tal como ilustrado na Figura 5. Outra característica singular de um daemon é que este não mantém qualquer interacção directa com o utilizador, ou seja, não dispõe de um interface para o 10

26 utilizador como um programa comum, podendo apenas responder a sinais (signals) provenientes do utilizador, se estiver programado para tal. Os daemons podem ser implementados em várias linguagens de programação, sendo a mais utilizada a linguagem C/C++. Um esqueleto de código C de um daemon é apresentado na Figura 6. pid_t pid, sid; /* Bifurcação do processo pai */ pid = fork(); if (pid < 0) { exit(exit_failure); } Figura 5 - Fluxograma genérico de um Daemon /* Se o novo processo tem PID, podemos terminar o processo pai */ if (pid > 0) { exit(exit_success); } umask(0); // limpar o umask /* Criar um novo SID para o processo filho */ sid = setsid(); if (sid < 0) { exit(exit_failure); /* Fechar os file descriptors standards */ close(stdin_fileno); close(stdout_fileno); close(stderr_fileno); /* Processamento do daemon no ciclo infinito */ while (1) { // Fazer a monitorização de um evento aqui no ciclo } Figura 6 - Estrutura em código C de um daemon 11

27 2.4 Triggers Os triggers são um mecanismo suportado pelos sistemas gestores de bases de dados (como o MySQL e MSSQL), que permite executar um bloco de código SQL, aquando de uma alteração na base de dados. O trigger é definido para responder automaticamente a um evento ocorrido numa determinada tabela de uma base de dados, sendo a sua resposta composta então por um bloco de código SQL. Estes mecanismos são utilizados em inúmeras situações, por exemplo: Validação de conteúdo inserido numa tabela; Utilizar conteúdo inserido numa tabela para inserir numa outra tabela; Detectar alterações num determinado campo de uma tabela. Quando o trigger é definido no sistema gestor de bases de dados, é necessário definir o seu nome, a tabela que este irá monitorizar, a condição de disparo do procedimento, e qual o código de procedimento a ser executado. 2.5 Padrão Model-View-Controller O MVC é uma arquitectura de software, descrita pela primeira vez em 1978, por Trygve Reenskaug, caracterizada por isolar o domínio lógico do programa, da parte de interface com o utilizador. Para cumprir tal objectivo, são definidas três classes: Model, View e Controller. Classe Controller Esta classe interpreta eventos, normalmente provenientes do utilizador. Ao analisar qual a acção tomada pelo utilizador, esta classe informa a classe Model e/ou a classe View, para que estas se alterem de acordo com a referida acção. 12

28 Classe Model É a classe responsável por fornecer rotinas de manipulação dos dados de entrada e saída, ou seja, é a classe que manipula o modelo dos dados exibidos. Classe View A classe View é a que se encarrega do layout da aplicação, ou seja, que mostra o conteúdo ao utilizador. Esta classe não modifica quaisquer dados, apenas os apresenta Aplicações Web sob o modelo MVC A arquitectura MVC é utilizada em várias aplicações Web, em particular sítios da Internet, e os seus blocos são utilizados com o seguinte intuito (ilustrado na Figura 7): A classe Model representa a estrutura de dados. Normalmente contém métodos de inserção, alteração ou leitura de dados do sistema de armazenamento (normalmente base de dados) utilizado pela aplicação. Por exemplo no caso de uma submissão de um formulário HTML por parte do utilizador, é esta classe que poderá se encarregar de guardar os dados submetidos no sistema de armazenamento; A classe Controller é utilizada como intermediária entre o utilizador e a classe Model ou View, isto é, interpreta os pedidos realizados pelo utilizador, associa um método do Model a esse evento, para assim gerar a resposta correcta, de acordo com o pedido realizado. Seguindo o exemplo utilizado para a classe Model, a classe Controller é responsável por detectar o pedido do utilizador (de inserção como no exemplo) e atribuir-lhe o método de inserção presente na classe Model; A classe View fica encarregue de apresentar a resposta ao utilizador, com a resposta obtida da classe Model. Continuando com o exemplo referido, esta 13

29 classe apresentará ao utilizador uma mensagem de sucesso, ou de erro, resultante da operação de inserção por parte da classe Model. Figura 7 - Sistema MVC Joomla MVC Um componente Joomla pode ser desenvolvido para front-end ou back-end, ou para ambos. Em termos de desenvolvimento, este componente tem de seguir uma estrutura de ficheiros específica, como ilustrado na Figura 8. Figura 8 - Estrutura de ficheiros Joomla MVC 14

30 A framework Joomla está totalmente detalhada em e antes de implementar estes ficheiros, é necessário compreender as classes utilizadas nesta implementação: JModel, JController e JView. Estas são classes abstractas, herdeiras da classe Joomla JObject, e que são responsáveis pela utilização da arquitectura MVC. Estas classes possuem atributos e métodos que podem ou não ser utilizados na implementação de um componente Joomla. No ficheiro models/nome.php é definida a classe nomemodelnome, que deriva da classe JModel, utilizando para isso a palavra-chave extends do PHP. Ao utilizar o extends, a classe definida passa a conter os atributos e métodos existentes na classe JModel, sem que seja necessário redefini-los. Dentro dessa classe podem ainda ser definidos novos métodos, com as funcionalidades que desejamos para o próprio componente, por exemplo a de inserir dados no sistema de armazenamento. No ficheiro view.html.php é definida a classe nomeviewnome, que deriva da classe JView (a partir do extends). Nesta classe são definidos métodos relacionados com a apresentação de conteúdo ao utilizador. O ficheiro default.php possui essencialmente código HTML que realiza efectivamente a apresentação do conteúdo, tratado nos métodos do ficheiro explicado anteriormente, na página. No ficheiro controller.php é definida a classe nomecontroller, que deriva da classe JController (também utilizando o extends). Nesta classe são definidos os métodos que manipulam as opções tomadas pelo utilizador. O ficheiro nome.php é o ponto de entrada do componente, onde é instanciado um controlador e lhe é atribuída a tarefa escolhida pelo utilizador. 2.6 Linguagem de Comandos de Modems Neste capítulo é apresentada uma linguagem de comandos especificamente desenvolvida e utilizada para comunicações com modems. A norma ETSI (European Telecommunications Standards Institute) GSM especifica o estilo desses 15

31 comandos, também conhecidos por comandos AT, todos eles compostos por três elementos principais: o prefixo, o corpo do comando, e o carácter de fim de comando. O prefixo consiste nos caracteres AT, seguido do corpo do comando que é constituído por caracteres individuais e, por último, o carácter de fim de comando <CR>. Dado o imenso número de comandos que esta linguagem possui, são aqui explicados apenas os comandos utilizados neste trabalho (sendo que em todos eles o carácter de fim de comando está subentendido). Inicialmente é necessário verificar se existe comunicação entre o software e o modem, e para tal é utilizado o comando AT, ao qual o módulo responderá OK se estiver tudo bem, ou ERROR se a conexão não estiver bem estabelecida. O passo seguinte passa por inserir o código PIN no cartão SIM que se encontra inserido no módulo. Para isso é utilizado o comando AT+CPIN=codigo_PIN. O módulo devolverá OK se o código estiver correcto ou ERROR caso contrário. Depois disso é necessário verificar se o cartão se encontra registado na rede, utilizando o comando AT+CREG?, ao qual o módulo responderá um OK em caso afirmativo, ou um ERROR caso não esteja registado. Poder-se-á de seguida especificar o formato das mensagens através do comando AT+CMGF=parâmetro. As mensagens podem estar no modo PDU (se parâmetro for 0 ) ou no modo de texto (se parâmetro for 1 ). Após o envio do comando, o módulo responde OK caso tenha realizado a configuração com sucesso ou ERROR em caso contrário. Por fim, o último comando de configuração utilizado, é o comando de selecção do modo de alerta de nova mensagem. Este comando permite configurar o modo como o modem reage quando recebe uma nova mensagem SMS. O comando de configuração utilizado é AT+CNMI=parâmetro1,parâmetro2. Os valores permitidos para os parâmetros deste comando são apresentados na Tabela 1. 16

32 Valor do parâmetro1 Valor do parâmetro2 Comportamento do módulo Qualquer valor 0 O módulo não envia qualquer comando de aviso para o PC 0 Qualquer valor O módulo guarda a mensagem SMS recebida na sua memória Qualquer valor 1 O módulo envia comando de aviso para o PC, indicando o índex da mensagem SMS na sua memória 1 Qualquer valor O módulo rejeita qualquer SMS recebida 2 Qualquer valor O módulo guarda a mensagem SMS recebida na sua memória e posteriormente envia o comando de aviso para o PC 3 Qualquer valor O módulo envia directamente o comando de aviso de nova mensagem SMS para o PC Tabela 1 - Parâmetros do comando AT+CNMI No que diz respeito à troca de informação entre módulo e PC, foram utilizados dois comandos, um para ler um SMS e outro para enviar um SMS. O alerta de nova mensagem SMS tem o formato +CMTI: SM, índex_da_mensagem. O campo índex_da_mensagem identifica a mensagem e corresponde à posição desta na memória do cartão SIM presente no módulo. Para ler um SMS, utiliza-se o comando AT+CMGR=índex_da_mensagem, ao qual o módulo responderá com o seguinte comando AT: +CMGR : REC UNREAD, num_tel_remetente,, data_e_hora_recepcao, mensagem \nok. Onde está presente o campo num_tel_remetente, que contém o número de telefone do remetente da mensagem SMS recebida, o campo data_e_hora_recepcao, que contém a data e a hora da recepção da mensagem SMS, e o campo mensagem, que contém a mensagem SMS efectivamente recebida. Para enviar uma mensagem SMS, utiliza-se o comando AT+CMGS = num_tel_destino \nmensagem_a_enviar<sub>. O caractere <SUB> consiste no caractere de controlo CTRL-Z. A isto o módulo responderá +CMGS: índex_da_mensagem\nok, indicando o índice da memória onde a mensagem foi guardada. 17

33 Para apagar qualquer mensagem que se encontre guardada na memória, é utilizado o comando AT+CMGD= índex_da_mensagem, ao qual o módulo responde OK caso tenha realizado a operação com sucesso, ou ERROR caso o índex especificado no comando enviado não contenha nenhuma mensagem. 2.7 Bison/Flex Bison e Flex são duas ferramentas de geração de código C/C++ desenhadas para o desenvolvimento de compiladores. [5] Flex é um gerador de analisadores léxicos e Bison um gerador de analisadores sintácticos. Combinando estas ferramentas é possível construir-se um programa que consiga fazer a análise de uma linguagem. Para isso, utiliza-se o Flex para identificar todas as palavras (tokens) que pertencem a essa linguagem, e recorre-se ao Bison para validar a ordenação desses tokens numa frase. Em termos de implementação, estas ferramentas são utilizadas de forma sequencial, ou seja, a saída do analisador léxico serve de entrada ao analisador sintáctico, conforme representado na Figura 9. Figura 9 - Sequência de analisador léxico e sintáctico Para a geração do analisador léxico, procede-se à definição dos tokens, com recurso a expressões regulares, num ficheiro nomedoficheiro.l. Tomando como exemplo uma linguagem que aceita apenas frases com o formato O um_nome tem numero_anos. Neste ficheiro são definidos os tokens da linguagem apresentados na Tabela 2. 18

34 Token Expressão Regular Significado numero_anos [0-9]+ Este token é composto por um ou mais algarismos, de 0 a 9 um_nome [a-za-z]+ Este token é composto por uma ou mais letras, de a a z, maiúsculas ou minúsculas Tabela 2 - Exemplo de tokens para o gerador léxico As palavras O e tem são definidas sem qualquer expressão regular, visto que nesta linguagem não podem ser alteradas. Após a definição destes tokens, são definidas as regras, ou seja, a string de retorno do analisador léxico para o analisador sintáctico aquando de um match de cada token. Nesta secção também é possível atribuir a uma variável presente no analisador sintáctico, o valor presente em algum token. De acordo com o exemplo utilizado, poder-se-á guardar o valor das variáveis um_nome e numero_anos em variáveis do analisador sintáctico. De salientar que o analisador léxico ignora quaisquer palavras que não estejam definidas na secção das definições dos tokens ou das definições das regras. Por fim recorre-se então ao Flex, através do comando de compilação: $ flex nomedoficheiro.l Nesta compilação é gerado o ficheiro lex.yy.c, que contém o código C do analisador léxico. Figura 10 - Funcionamento do Flex 19

35 Para a geração do analisador sintáctico, procede-se à definição de regras gramaticais, que indicam a ordem válida dos tokens na linguagem, num ficheiro nomedoficheiro.y. Tomando o exemplo utilizado para o analisador léxico, neste ficheiro é definida apenas uma sequência possível de tokens. Essa sequência é definida da seguinte forma: all: O um_nome tem numero_anos Caso o analisador sintáctico receba como entrada uma sequência de tokens diferente das definidas, é utilizada a rotina yyerror(char *s), em que s é a string que contém a sequência recebida. Por fim recorre-se então ao Bison, através do comando de compilação: $ bison d nomedoficheiro.y Nesta compilação são gerados os ficheiros nomedoficheiro.tab.c e nomedoficheiro.tab.h, que correspondem então aos ficheiros C do analisador sintáctico. Depois de serem gerados os analisadores é necessário compilar-se ambos, para a geração de um ficheiro executável (ficheirodesaida), da seguinte forma: $ gcc -o ficheirodesaida lex.yy.c nomedoficheiro.tab.c lm O executável ficheirodesaida que é gerado contém as funcionalidades de analisador léxico e sintáctico encadeadas. Ao ser executado, o analisador léxico lê o ficheiro de entrada yyin (definido no ficheiro nomedoficheiro.y, que pode simplesmente ser um ficheiro de texto), caractere a caractere, e agrupa-os em tokens que foram definidos. A seguir, o analisador sintáctico verifica a ordem como esses tokens estão ordenados. 20

36 Pode utilizar-se estas ferramentas, por exemplo, para fazer a análise de um texto em português, como o demonstrado na Figura 11. Figura 11 - Análise lexical e sintáctica de uma frase O analisador léxico trata de identificar os tokens: Eu, entreguei, -, lhe, o e livro. Depois disso o analisador sintáctico trata de identificar a ordem com que esses tokens aparecem na linguagem, e reconhecer então que se trata de uma frase válida na linguagem definida. Chama-se a isto fazer parsing, isto é, reconhecer se uma frase é gramaticalmente bem construída, e identificar a função de cada token nessa frase. 21

37

38 3. Descrição da empresa IVV Automação 3.1 A empresa e seus clientes A empresa IVV Automação é uma empresa que vende essencialmente hardware e software para sistemas de vigilância, comunicações, anti-roubo, antiintrusão, controlo de acessos e domótica. Os clientes desta empresa são maioritariamente outras empresas, nomeadamente empresas de instalações eléctricas. Dado este facto de os clientes serem outras empresas, o sistema de encomendas da IVV torna-se complexo. Uma empresa cliente da IVV Automação pode ter vários funcionários, tendo cada um desses funcionários permissões diferentes, tal como representado na Figura 12. Cada funcionário pode então possuir autorização para: Realização de encomendas; Consultar conta corrente da empresa cliente; Verificar preços de produtos. Além desta especificação para cada empresa cliente da IVV Automação, esta interessa-se por distinguir os seus clientes por grupos distintos, isto é, cada empresa cliente pertence a um grupo de clientes específico. Cada um desses grupos de clientes possuí também permissões diferentes, e possuí uma tabela de preços específica. Figura 12 - Diagrama estrutural da empresa IVV e seus clientes 23

39 3.2 Servidor IVV Antes de ser explicado todo o trabalho realizado, é necessário ser explicado o ambiente onde este foi elaborado. A empresa IVV Automação, Lda está dotada de um PC (com sistema operativo Windows) onde está instalado um servidor Apache. Nesse PC está também instalado um sistema gestor de bases de dados Microsoft SQL Server (MSSQL), cuja função é armazenar todas as informações referentes aos clientes e produtos da empresa. O software instalado encontra-se ilustrado na Figura 13. Figura 13 - Servidor IVV: software instalado Todos os clientes e produtos da empresa são registados nessa base de dados através do software de gestão e facturação da empresa (PHC). Quanto ao site da empresa, esta já possuía um, o qual estava alocado num servidor externo à empresa (assim como a sua base de dados), e cuja actualização de dados era feita manualmente, ou seja, sem existir qualquer ligação entre os dados presentes na base de dados da empresa e os dados presentes no site da mesma. 24

40 Para a elaboração deste trabalho, um funcionário da empresa implementou novas tabelas no servidor MSSQL (sob a forma de views), provenientes das tabelas do PHC, de forma a reunir nessas tabelas as informações necessárias sobre clientes e produtos, para serem transferidas para o novo servidor implementado (do novo site), e poder ser feita a actualização constante de todos os dados necessários. 3.3 Servidor do novo site Para o desenvolvimento do novo site foi utilizado um PC, onde foi instalado o sistema operativo Ubuntu. Depois disso foi instalado um servidor Apache, um servidor PHP e um sistema gestor de bases de dados MySQL. O software instalado encontra-se ilustrado na Figura 14. Figura 14 - Servidor do site: software instalado 25

41 Para iniciar todo o trabalho foi necessária a instalação do CMS Joomla e dos seus componentes, para ficar assim implementada toda a base de dados de suporte ao site, e poderem ser analisadas todas as tabelas e campos nela existentes Componentes Joomla instalados Após a instalação do CMS Joomla é então possível a instalação de qualquer extensão. Para isso acede-se ao menu de back-end do site e na barra de ferramentas escolhe-se o item Extensões, seguido do item Instalar/Desinstalar. Depois disso efectua-se a escolha do ficheiro de instalação do componente e selecciona-se o botão Instalar. Para este trabalho, após a discussão sobre os requisitos funcionais do site, foi necessária a instalação dos componentes apresentados nos subcapítulos seguintes VirtueMart VirtueMart é um componente Open Source bastante utilizado no comércio electrónico. Este componente é inserido no Joomla como forma de permitir a comercialização de produtos num site. [6] De todos os componentes instalados este é sem dúvida o mais complexo, tanto em termos de funcionalidades, como em número de ficheiros e tabelas da base de dados a ele associados. Em termos de utilização, este possuí um menu de back-end (Figura 15) onde permite ao administrador do site configurar a loja virtual. 26

42 Figura 15 - Menu de back-end do VirtueMart A loja virtual pode conter uma ou mais contas de vendedor, tendo neste trabalho apenas uma, a conta da empresa IVV Automação. Nesta loja são inseridos ou alterados produtos para venda, podendo estes ser inseridos em categorias de produtos. Além dos produtos é possível editar informações de clientes e encomendas efectuadas por estes. No item de Editar Loja é possível alterar a forma como os produtos são apresentados no front-end do site, assim como se estes se apresentam com ou sem preço visível. Em termos de base de dados, este componente tem associadas as seguintes tabelas principais: jos_vm_auth_group onde estão definidos os tipos de utilizadores (administrador, administrador de loja ou cliente); jos_vm_auth_user_group onde é feito o mapeamento dos utilizadores do site aos tipos de utilizadores; jos_vm_auth_user_vendor onde é feita a correspondência dos clientes ao vendedor (neste caso todos os clientes estão associados ao vendedor IVV Automação); 27

43 jos_vm_cart onde são armazenas informações do carrinho de compras de todos os utilizadores; jos_vm_category onde são definidas as categorias dos produtos existentes; jos_vm_category_xref lista as relações parentais entre categorias; jos_vm_creditcard onde são definidos os tipos de cartões de crédito permitidos; jos_vm_manufacturer onde se lista os fabricantes dos produtos; jos_vm_manufacturer_category onde se lista as categorias de fabricantes existentes; jos_vm_orders onde são guardadas todas as encomendas efectuadas; jos_vm_order_history que é utilizada para guardar todas as alterações ou acções tomadas em relação a qualquer encomenda; jos_vm_order_item onde se lista todos os produtos associados a uma encomenda; jos_vm_order_payment onde se lista o método de pagamento escolhido para cada encomenda; jos_vm_order_status onde são definidos os estados possíveis para uma encomenda, tais como pendente ou concluída; jos_vm_order_user_info que é utilizada para efectivamente guardar a encomenda realizada por dado cliente em dado instante; jos_vm_payment_method onde são definidos os métodos de pagamento permitidos pela loja; jos_vm_product que lista todos os produtos da loja; jos_vm_product_attribute que lista os atributos de produtos; jos_vm_product_category_xref que é utilizada para associar os produtos às respectivas categorias de produtos; jos_vm_product_mf_xref que é utilizada para associar os produtos ao respectivo fabricante; jos_vm_product_price onde se lista o preço de cada produto para cada grupo de utilizadores; 28

44 jos_vm_shopper_group que é utilizada para guardar os grupos de clientes existentes, sendo neste trabalho definidos os grupos de revenda, distribuidor, agente e desconto tabela; jos_vm_shopper_vendor_xref onde é associado cada utilizador a um grupo de cliente; jos_vm_user_info que armazena as informações de cada cliente; jos_vm_vendor que armazena as informações de cada vendedor (neste caso apenas da IVV Automação) Huru Helpdesk Este componente, também ele Open Source, é utilizado no Joomla para fornecer suporte electrónico aos utilizadores do site por parte da administração deste, ou até entre utilizadores. [7] No caso da IVV Automação este componente faz bastante sentido visto que pode assim esclarecer dúvidas aos seus clientes, e evitar que estes necessitem de estabelecer contacto telefónico ou até se deslocarem às instalações da empresa para esclarecerem dúvidas técnicas ou mesmo de carácter informativo. Este componente permite no menu de back-end (Figura 16) editar os utilizadores, assim como associa-los a departamentos (por exemplo cliente, técnico, comercial ou administrativo). Permite também editar as categorias de helpdesk, que neste caso estão divididas de acordo com as categorias dos produtos da empresa. 29

45 Figura 16 - Menu de back-end do Huru Helpdesk Em termos de tabelas este componente é um pouco menos complexo em relação ao VirtueMart, e utiliza as seguintes tabelas: jos_huruhelpdesk_attachments que é utilizada para referenciar documentos anexados em alguma mensagem; jos_huruhelpdesk_categories que lista as categorias de assuntos de mensagens (neste caso as categorias principais dos produtos); jos_huruhelpdesk_config que guarda as configurações do componente realizadas no back-end; jos_huruhelpdesk_departments que lista os departamentos definidos (Comercial, Técnico e Administrativo); jos_huruhelpdesk_ msg que armazena todos os s enviados entre utilizadores; jos_huruhelpdesk_langstrings que contém as labels apresentadas com a respectiva tradução para outros idiomas; 30

46 jos_huruhelpdesk_language onde estão definidos os idiomas (neste caso apenas o Português e Inglês); jos_huruhelpdesk_notes onde são guardadas as notas de cada mensagem; jos_huruhelpdesk_priority que lista as prioridades estabelecidas pelo administrador (de muito baixa a emergência); jos_huruhelpdesk_problems onde são guardados todos os tópicos de discussão abertos; jos_huruhelpdesk_status lista os estados possíveis de cada tópico aberto (se este se encontra encerrado, a decorrer ou fechado); jos_huruhelpdesk_users onde estão guardados os utilizadores do serviço de helpdesk (um utilizador do site pode não ser utilizador do serviço) JEvents O component JEvents é um componente Open Source de agenda utilizado no Joomla, que permite à administração da IVV Automação dar a conhecer aos utilizadores do site datas de eventos realizados por esta, tais como workshops. [8] Este componente apresenta no front-end do site uma agenda que pode ser configurada no back-end, em termos de aspecto e em termos de permissões para adicionar e/ou visualizar os eventos adicionados pelo administrador. No que diz respeito a tabelas da base de dados, este apenas possuí, entre outras menos relevantes, as seguintes: jos_jevents_categories que permite guardar as categorias de eventos definidas, assim como a cor com que esta é representada no calendário de front-end; jos_jevents_repetition para armazenar repetições de eventos (semanais, mensais ou anuais); jos_jev_users que guarda os utilizadores da agenda; jos_jevents_vevent que lista o conteúdo dos eventos adicionados; 31

47 Joom!Fish Este componente (como os restantes também é Open Source) permite apresentar um site em múltiplos idiomas. Este aspecto é importante como forma de internacionalizar a comercialização por parte da empresa. [9] Para utilizar o site em múltiplos idiomas é necessário aceder ao menu de backend do componente (Figura 17) e definir traduções para os conteúdos e labels apresentadas no front-end do site, nos idiomas também aí definidos. Neste trabalho foram definidos apenas dois idiomas: português e inglês. Figura 17 - Menu de back-end do Joom!Fish No front-end do site são apresentadas as bandeiras definidas para os idiomas configurados, permitindo assim ao utilizador alterar entre eles. 32

48 Remository O Remository é um componente para gestão de downloads. Este componente permite ao administrador do site definir categorias de downloads e inserir ficheiros para os utilizadores descarregarem. Uma particularidade deste componente é que também permite criar grupos de utilizadores (com permissão para fazer download apenas em categorias autorizadas). [10] Na empresa IVV Automação foram definidas as categorias de Datasheets e Tabelas de Preços. Os grupos de utilizadores definidos foram três, um que permite o download de qualquer documento de ambas as categorias, outro que permite apenas o download de documentos da categoria Datasheets, e por fim o que permite apenas download de documentos da categoria Tabelas de Preços. Quanto ao menu deste componente no back-end do site, este permite editar as categorias e grupos, assim como editar os documentos de cada categoria. Na base de dados, as principais tabelas que dizem respeito a este componente são as seguintes: jos_assignments que atribui a cada utilizador do site um grupo de utilizador do repositório de downloads; jos_downloads_containers onde são definidas as categorias de downloads; jos_downloads_files onde se encontram definidos todos os documentos, indicando a categoria a que cada um pertence; jos_downloads_log contém um histórico de todos os downloads efectuados, guardando inclusive o endereço IP para onde foi feito o download; jos_downloads_repository guarda configurações do componente, tanto de aspecto como de, por exemplo, locais onde são guardados os documentos. 33

49

50 4. Mecanismo de Sincronização das Bases de Dados 4.1 Descrição do Problema A implementação e gestão de bases de dados actualmente são deveras importantes por parte das empresas, dado que é nelas que são guardados os mais variados tipos de informação, tais como dados de clientes e produtos das empresas. Antes da elaboração do site, tal como referido no capítulo introdutório, foi necessário instalar e configurar o novo servidor na empresa, e realizar a exportação dos dados existentes nas views do MSSQL para a nova base de dados de suporte ao site. No que diz respeito às bases de dados, os objectivos estipulados incluem: Cópia dos dados contidos nas views do servidor MSSQL para o novo servidor MySQL; Desenvolvimento de um mecanismo de sincronização das duas bases de dados, que mantenha uma actualização constante de ambas sempre que haja inserção ou alteração de certos dados numa delas. As views implementadas por parte da empresa têm estruturas distintas. As views que dizem respeito aos produtos da empresa foram implementadas com uma estrutura semelhante às instaladas no Joomla. Para cada tabela existente na base de dados do Joomla que diz respeito a dados de produtos, foi implementada uma view com os mesmos campos que essa tabela. Quanto às views que contêm dados dos clientes da empresa, estas nada têm a ver com a estrutura das tabelas referentes aos utilizadores Joomla. Foi implementada uma view que contém dados dos utilizadores do antigo site da empresa (representada na Figura 18), e uma outra view que contém dados dos clientes provenientes das tabelas do PHC (representada na Figura 19). 35

51 Figura 18 View customers Figura 19 View cl 4.2 Exportação de dados do Servidor IVV para o Servidor Site Para a exportação dos dados dos produtos e clientes já existentes no servidor IVV foram utilizados scripts PHP, implementados no servidor do site. O desenvolvimento destes scripts serviu também para adquirir experiência com a linguagem de programação, e para uma familiarização com os dados presentes nas duas bases de dados. 36

52 Dado que no servidor IVV é utilizado o sistema gestor de base de dados MSSQL, foi necessária a instalação de um driver ODBC no servidor do site, para assim ser possível a comunicação entre os scripts PHP e a base de dados MSSQL Instalação do driver ODBC ODBC é um API standard utilizado para trabalhar com sistemas gestores de bases de dados e, conforme ilustrado na Figura 20, é independente da linguagem de programação e do sistema operativo. [11] Figura 20 - Diagrama de funcionamento do ODBC pacotes: Para a instalação do ODBC no Ubuntu é necessária a instalação dos seguintes tdsodbc, inclui o driver ODBC para FreeTDS (Free Tabular Data Stream); freetds-common, contém os ficheiros de configuração para as bibliotecas de cliente FreeTDS; unixodbc, é uma ferramenta de linha de comando que permite estabelecer conexões a bases de dados, através do driver ODBC; php5-odbc, é o módulo ODBC para utilização na linguagem PHP. 37

53 Estes pacotes são instalados a partir do seguinte comando: $ apt-get install tdsodbc freetds-common unixodbc php5-odbc Depois disto é necessária a edição do ficheiro php.ini, para permitir a utilização do driver ODBC em scripts PHP, adicionando-se a seguinte linha ao conteúdo do ficheiro: extension = odbc.so Finalmente, para o driver ODBC poder ser utilizado para comunicar com a base de dados MSSQL, é necessário definir os parâmetros da base de dados no ficheiro de configuração do driver, o ficheiro tds.dsn.template. Este ficheiro serve apenas para configurar um único servidor de base de dados. Nesse ficheiro são definidos então os seguintes parâmetros: Description = Test to freetds // Descrição Driver = TDS // Nome do driver Trace = No // Guardar histórico de conexões Database = ivvss // Nome da base de dados Server = // IP da base de dados Port = 1433 // Porta de escuta da base de dados Após estas configurações basta reiniciar o servidor Apache com o comando: $ sudo apache2ctl -k restart Implementação dos scripts PHP Os scripts PHP têm a finalidade de copiar os dados da base de dados IVV (MSSQL) para a nova base de dados de suporte ao site (MySQL). Foram implementados dois scripts, sendo o primeiro responsável pela cópia de dados dos produtos, e o segundo pela cópia de dados dos clientes. Estes scripts poderiam ter sido implementados num único, mas decidiu-se pela separação para que, em caso de erros 38

54 na passagem de dados, os dados de produtos e clientes pudessem ser tratados separadamente. O primeiro script a ser implementado foi referente aos dados dos produtos e respectivas categorias. Na base de dados do novo site, os dados dos produtos são guardados em algumas tabelas do componente VirtueMart, e como tal, é necessário analisar a relação que existe entre os campos dessas mesmas tabelas, ilustradas na Figura 21. Figura 21 - Relação entre as principais tabelas referentes aos produtos Os primeiros dados a serem importados para o novo servidor são os das categorias, inserindo-as primeiramente na tabela jos_vm_category e de seguida construindo a árvore de relações entre elas na tabela jos_vm_category_xref. Em segundo lugar, são inseridos todos os produtos na tabela jos_vm_product. Depois disto é atribuída a cada produto a respectiva categoria, na tabela jos_vm_product_xref. Por fim, são inseridos os preços de cada produto, de acordo com o grupo de utilizador (shopper_group_id). Como nesta fase ainda se encontram por definir, mas sabendo que são quatro, utiliza-se neste campo os ids 1, 2, 3 e 4. 39

55 Em termos de implementação propriamente dita o script começa por estabelecer a ligação às duas bases de dados. Depois lê linha a linha os dados de cada view da base de dados MSSQL e insere-os na base de dados do novo site. Todo este algoritmo está representado na Figura 22, e um excerto do código PHP deste representado na Figura 23. Figura 22 - Fluxograma de script PHP para importar produtos 40

56 <?php //v_web_precos $query = "SELECT * FROM v_web_precos"; $Database->query( $query ); $dadosprecos=$database->getresultsarray(); /* Variável com todos os dados da tabela de preços de produtos*/ $tabela = 'jos_vm_product_price'; foreach ( $dadosprecos as $linha ) { /* Ciclo que lê linha a linha os dados lidos da tabela v_web_precos */ $query = "INSERT INTO $tabela (product_id, product_price, product_currency, product_price_vdate, product_price_edate, cdate, mdate, shopper_group_id, price_quantity_start, price_quantity_end) VALUES ('{$linha['product_id ']}','{$linha['product_price']}','{$linha['product_currency']}','0','0','','','{$linha['shopper_group_id']}','0','0')"; $db->query($query); } //Fim do foreach?> Figura 23 - Excerto de código PHP do script de importação dos produtos Após a passagem dos dados anteriores, foi necessário implementar outro script para importar os dados dos clientes, e respectivos grupos de clientes, para o novo servidor. Na base de dados do novo site, os dados dos clientes são guardados em algumas tabelas pré-instaladas com o Joomla, assim como em algumas tabelas do VirtueMart e numa do Huru Helpdesk. O Joomla possui por defeito uma tabela na base de dados denominada jos_core_acl_aro_groups. Essa tabela indica os níveis de acesso ao front-end (níveis do lado esquerdo da figura) e ao back-end (níveis do lado direito da figura) do site, e transcreve a árvore representada na Figura 24, tendo esta ordem hierárquica de cima para baixo. 41

57 Figura 24 - Representação dos dados da tabela jos_core_acl_aro_groups Além destes grupos de utilizadores do site, a IVV definiu os seguintes grupos de clientes, na tabela jos_vm_shopper_group: jos_vm_shopper_group shopper_group_id shopper_group_name 1 Distribuidor 2 Desconto Tabela 3 Agente 4 Revenda Tabela 3 - Tabela jos_vm_shopper_group O relacionamento entre as restantes tabelas que guardam os dados dos clientes da empresa (também utilizadores do site) pode ser descrito com base na Figura 25. Na tabela jos_users são inseridos todos os utilizadores Joomla, com o grupo de utilizador definido nos campos usertype e gid. Depois é utilizada a chave primária 42

58 (campo id) da tabela jos_users para preencher o campo value da tabela jos_core_acl_aro, o campo user_id da tabela jos_vm_user_info, o campo user_id da tabela jos_vm_shopper_vendor_xref e o campo joomla_id da tabela jos_huruhelpdesk_users. Na tabela jos_core_acl_groups_aro_map é definido o grupo de utilizador Joomla de cada utilizador, utilizando para isso o campo group_id como chave estrangeira da tabela jos_core_acl_aro_groups. Na tabela jos_vm_shopper_vendor_xref é utilizado como chave estrangeira o campo shopper_group_id, que indica o grupo de cliente IVV do utilizador Joomla inserido. Figura 25 - Relação entre as principais tabelas referentes aos clientes A implementação do script PHP para importar os dados dos clientes do servidor da empresa para o servidor do site foi relativamente mais complicada do que a implementação do script que importa os produtos da empresa. Isto porque, em 43

59 primeiro lugar, na importação dos produtos a empresa implementou os views no seu servidor, de acordo com as tabelas do Joomla. No caso dos clientes existem duas views (customers e cl) no servidor da empresa com os dados de todos os clientes da empresa (view cl) e utilizadores do seu antigo site (view customers). A razão de ser destas duas views é que existiam alguns utilizadores do site que não eram efectivamente clientes, e alguns clientes que não possuíam conta de utilizador no site antigo. Em segundo lugar, a empresa decidiu que queria que todos os clientes e utilizadores já existentes possuíssem conta no novo site. Ao fazer isto seria criada uma nova palavra-chave para cada utilizador e este possuiria apenas permissões de Registered no site (até que entrasse em contacto com a empresa). Primeiramente foi implementado um script PHP para geração de palavraschave no algoritmo de hash utilizado pelo Joomla, o md5 com salt (string de 32 caracteres aleatórios). Como o PHP já possuí um método para gerar o md5 de uma string, este foi utilizado no script. O algoritmo utilizado (Figura 26) consiste em primeiramente gerar uma string de 8 bits, que será a chave que o utilizador utilizará efectivamente como password, e posteriormente gerar o md5 com salt dessa chave. Na base de dados fica guardada a chave codificada. Quando o utilizador efectua o login utilizando a chave normal, o Joomla utiliza um mecanismo de codificação dessa chave e compara com a chave codificada armazenada na base de dados, para assim fazer a validação da password inserida pelo utilizador. Figura 26 - Fluxograma para geração de palavra-chave para Joomla 44

60 Este script é invocado pelo script que importa para a base de dados do site todos os dados dos clientes. Para implementar este último desenvolveu-se o algoritmo representado na Figura 27. O script inicia com a conexão às bases de dados MSSQL e MySQL, guardando posteriormente em duas variáveis o conteúdo presente nas views customers e cl. Depois disto lê linha a linha a variável util_site (que corresponde a uma linha da view customers), começa por guardar os dados do utilizador do site antigo na base de dados MySQL, e verifica se este utilizador tem conta de cliente IVV através do seu número de contribuinte. Caso tenha conta de cliente os campos da view cl são guardados, caso não tenha esses campos são guardados como Null. Depois disso é gerada uma password para esse utilizador, e é guardada a chave normal e o do utilizador num ficheiro clientes.log, para a empresa notificar o utilizador da sua nova password no site. Depois são inseridos todos os dados, acumulados ao longo do script, do utilizador nas tabelas de clientes do site. 45

61 46 Figura 27 - Fluxograma de script PHP para importar os dados dos clientes

62 4.3 Desenvolvimento do mecanismo de sincronização Após a execução dos scripts descritos na secção anterior, a base de dados do novo site fica preenchida com todos os produtos, e dados de todos os clientes, até à data existentes na empresa. Naturalmente, que em qualquer empresa estes dados estão em constante alteração, quer por remoção, edição ou adição. Por esta razão, foi implementado o mecanismo de sincronização que se descreve a seguir. A solução que foi desenhada consiste num sistema bidireccional para a troca de dados, que assenta nas seguintes tecnologias: Triggers; Web services; Daemons. A implementação deste mecanismo foi feita em duas etapas distintas, uma para cada um dos sentidos de propagação dos dados. Primeiramente foi desenvolvida a comunicação entre o servidor do site e o servidor da empresa, cuja finalidade é actualizar a base de dados da empresa sempre que haja uma alteração (de dados seleccionados) na base de dados do site. A segunda etapa foi desenvolver a comunicação inversa, sendo que esta parte foi desenvolvida em conjunto com um funcionário da empresa Comunicação entre Servidor Site e Servidor IVV Para a realização desta etapa foram primeiro identificadas quais as tabelas a monitorizar, isto é, aquelas cuja alteração (inserção ou edição) provoca o envio de dados do servidor do site para o servidor da empresa. As tabelas que a empresa decidiu monitorizar nesta parte do mecanismo dizem respeito apenas aos dados dos clientes, nomeadamente às tabelas jos_users e jos_vm_user_info. A primeira diz respeito a dados dos clientes numa perspectiva de utilizadores do site (username, password, grupo de utilizador, ), e a segunda diz respeito a dados dos clientes efectivamente como tal (morada, telefone, empresa, ). 47

63 Foi então implementado um mecanismo (representado na Figura 28) que utiliza uma nova tabela (denominada por jobs), onde são inseridas, por um trigger, o nome da tabela e id da linha que sofreu alguma alteração. Em background está um daemon que monitoriza constantemente esta nova tabela, e que, quando detecta uma nova inserção na tabela jobs, efectua a leitura dos dados da tabela alterada, e envia-os através de um Web service. Figura 28 - Diagrama de funcionamento do mecanismo de sincronização (site ivv) Foi implementada primeiramente a tabela jobs, com os campos id_job, tabela e id_linha. Para preencher esta tabela, foram definidos quatro triggers (dois para cada tabela monitorizada) na base de dados. Para aceder directamente ao servidor de base de dados MySQL, basta escrever na linha de comandos: $ mysql -u root p. Após estarmos conectados à base de dados, utiliza-se o seguinte código SQL para monitorização de uma tabela: 48

64 CREATE TRIGGER nome_trigger // Nome do trigger AFTER INSERT ON nome_tabela // Nome da tabela a monitorizar FOR EACH ROW // Para cada nova linha inserida nessa tabela INSERT INTO jobs (tabela, id_linha) // Inserir na tabela jobs VALUES ( nome_tabela,new.id); // O nome da tabela e o id da nova linha inserida Figura 29 - Código SQL de um trigger do mecanismo de sincronização Para utilizarmos um trigger de monitorização de edição de uma tabela basta alterar no código SQL a palavra INSERT por UPDATE. Após a instalação dos triggers na base de dados, foi implementado o daemon para monitorizar a tabela jobs. Tal como os scripts de importação dos dados de produtos e clientes, este daemon foi também implementado em PHP, e o seu processamento segue o algoritmo representado na Figura 30. Figura 30 - Fluxograma do processamento do daemon de verificação da tabela jobs A estrutura do código PHP deste daemon encontra-se ilustrada Figura

65 #!/usr/bin/php <?php /* Incluir o ficheiro do cliente webservice */ include( '/var/www/service_encomendas/cliente_encomendas.php' ); $child = pcntl_fork(); if($child) { exit(0); } posix_setsid(); umask(0); // tornar o processo filho líder da sessão // limpar umask // Conexões às bases de dados aqui for($i=0;;$i++) { // Verificar aqui a tabela jobs }?> if($result) { //Existe tarefas na tabela jobs $id_job=$result[0]; $tabela=$result[1]; $id_linha=$result[2]; if(client_service($tabela, $id_linha)==0) { // Webservice concluído com sucesso } // Apagar o job executado } Figura 31 - Excerto de código PHP do daemon de verificação da tabela jobs Após o desenvolvimento do código, é necessário colocar o daemon na configuração do sistema operativo, para que este seja desencadeado sempre que o sistema operativo arranque. Para fazer isso, é executada na consola a seguinte sequência de comandos na shell Linux: $ cd /etc/init.d/ // Mudar para a directoria /etc/init.d $ sudo cp /var/www/service_clientes/daemon_clientes.php. // Copia o ficheiro daemon_clientes.php para a directoria onde nos encontramos $ sudo chmod a+x./daemon_clientes.php // Mudar as permissões de acesso do ficheiro. Os parâmetros a+x permitem que o ficheiro possa ser acedido por qualquer utilizador, e que é executável, respectivamente $ sudo update-rc.d daemon_clientes.php defaults // Actualizar a lista de serviços de arranque do sistema operativo presentes no directório init.d 50

66 Como mostra a figura Figura 30, sempre que o daemon detecta uma nova alteração na tabela jobs, este invoca o cliente de Web service (sob a forma de rotina C). Este cliente efectua também a ligação à base de dados MySQL, verifica qual a tabela que o daemon indicou como alterada, e guarda numa variável toda a linha que sofreu as alterações. Depois disto envia para o servidor do Web service (que se encontra alocado no servidor da empresa) o nome da tabela e a variável com a linha alterada. O algoritmo encontra-se representado na Figura 32. Figura 32 Fluxograma da rotina C do cliente do Web service do mecanismo de sincronização (site ivv) Quanto ao servidor, este disponibiliza um serviço sob a forma de rotina C, que tem como parâmetros de entrada o nome da tabela alterada e um objecto com os dados alterados. Ao ser invocado pelo cliente do Web service, estabelece conexão com a base de dados MSSQL e verifica o nome da tabela. No caso da tabela jos_users verifica o campo username da linha alterada, e faz o INSERT ou o UPDATE, de acordo com a sua existência na view customers. No caso da tabela jos_vm_user_info verifica o campo de NIF da linha alterada, e faz o INSERT ou o UPDATE, de acordo com a sua existência na view cl. O algoritmo encontra-se representado na Figura

67 Figura 33 - Fluxograma da rotina C do servidor webservice do mecanismo de sincronização (site ivv) O documento WSDL que descreve o serviço webservice encontra-se alocado juntamente com o servidor do Web service, e está apresentado na Figura

68 <?xml version="1.0"?> <definitions name="mydefinition" targetnamespace="urn:mytargetnamespace" xmlns:tns="urn:mytns" xmlns:xsd=" xmlns:soap=" xmlns=" <message name="myresponse"> <part name="resparam" type="xsd:string"/> </message> <message name="myrequest"> <part name="reqparam1" type="xsd:string"/> <part name="reqparam2" type="xsd:string"/> </message> <porttype name="myporttype"> <operation name="service_encomendas"> <input message="tns:myrequest"/> <output message="tns:myresponse"/> </operation> </porttype> <binding name="mybinding" type="tns:myporttype"> <soap:binding style="rpc" transport=" <operation name="service_encomendas"> <soap:operation soapaction=""/> <input> <soap:body use="encoded" namespace="urn:myinputnamespace" encodingstyle=" </input> <output> <soap:body use="encoded" namespace="urn:myoutputnamespace" encodingstyle=" </output> </operation> </binding> <service name="myservice"> <documentation>mecanismo de sincronização IVV. </documentation> <port name="myport" binding="tns:mybinding"> <soap:address location=" ncomendas.php"/> </port> </service> </definitions> Figura 34 - Documento WSDL do webservice do mecanismo de sincronização (site ivv) 53

69 4.3.2 Comunicação entre Servidor IVV e Servidor Site Esta etapa do mecanismo de sincronização tem como objectivo monitorizar a inserção ou actualização de um produto na base de dados da empresa, e actualizar a base de dados do site sempre que um desses acontecimentos ocorra. Esta parte do trabalho foi realizada em cooperação com um funcionário da empresa, tendo sido implementado pelo autor desta tese apenas a parte receptora dos dados (do lado do servidor do site). Devido a este facto, nesta secção apenas se descreve o script PHP que realiza a função de servidor do Web service que recebe as actualizações de dados dos produtos, provenientes do cliente de Web service situado no servidor da empresa. Esta parte do mecanismo de sincronização está representada na Figura 35. Figura 35 - Diagrama de funcionamento do mecanismo de sincronização (ivv site) O servidor do Web service recebe a mensagem enviada pelo cliente, e sabe que nessa mensagem pode receber informações para as seguintes tabelas (referentes aos produtos): jos_vm_product; jos_vm_product_price. 54

70 Depois de identificar qual a tabela a que se destinam os dados, o script insere ou actualiza os dados recebidos nas tabelas da base de dados do site, e responde ao cliente com uma mensagem de sucesso ou erro relativa a essa operação, conforme descrito na Figura 36. Figura 36 - Fluxograma da rotina C do ficheiro servidor.php do mecanismo de sincronização (ivv site) 55

71

72 5. Desenvolvimento do site 5.1 Configuração e adaptação do Joomla O desenvolvimento do site em si foi iniciado com a instalação do Joomla e dos componentes descritos anteriormente. De seguida foi pesquisado e instalado um template para o site, procurando dar-lhe um aspecto agradável e moderno. Após a instalação do template foram feitas algumas alterações a nível do código de estilo (CSS) do mesmo, nomeadamente para editar a posição do formulário de login/logout do utilizador. O resultado final do front-end é apresentado na Figura 37 e Figura 38. Para os utilizadores poderem ter acesso no front-end do site aos componentes instalados, foi configurado o main menu deste (item 3 da figura), adicionando um item de acesso a cada componente (incluindo para o item IIVV que diz respeito ao componente de funcionalidades dinâmicas). Além disso foi também configurada uma barra de rodapé onde foram adicionadas hiperligações (item 9) para os sites dos principais fabricantes de produtos da empresa IVV Automação, através da edição do código HTML do template, e também configurado o módulo de twitter (item 8) que acompanhou a instalação do template, acedendo para isso no back-end do site, no menu das extensões, no item gerir módulos. O item 1 das figuras diz respeito ao formulário de login/logout dos utilizadores. O item 2 corresponde a uma caixa de texto para pesquisa de produtos e artigos da empresa. O item 5 corresponde ao front-end do componente JoomFish e o item 7 a um componente de agenda. Por fim o item 4 corresponde a um módulo do Virtuemart, que mostra ao utilizador do site os produtos adicionados ao carrinho de compras virtual, o item 6 representa um módulo do template que apenas realiza uma animação de itens e o item 10 que também vem com o template do site que contém produtos aleatórios para compra, ambos configurados no back-end do site. 57

73 58 Figura 37 - Layout da página princiapl do front-end do site (antes do login)

74 Figura 38 - Layout da página princiapl do front-end do site (depois do login) O aspecto da página dos componentes no front-end, pode observar-se na Figura 39 e Figura 40 para o Huru Helpdesk, e Figura 41 para o Remository. Figura 39 - Layout do menu principal do componente Huru Helpdesk no front-end do site 59

75 60 Figura 40 - Layout do componente Huru Helpdesk, para inserir novo tópico, no front-end do site

76 Figura 41 - Layout do menu principal do componente Remository no front-end do site 5.2 Componente de funcionalidades dinâmicas Este componente, que tomou grande parte do tempo de desenvolvimento do site, não teve uma implementação totalmente de acordo com a arquitectura MVC dos componentes Joomla, mas muitas vezes numa aplicação real, não importa como se atinge a primeira solução, desde que se alcancem os objectivos propostos no tempo disponível. Inicialmente a empresa desejava uma página externa ao site (ou seja, externa ao Joomla), onde os seus clientes poderiam aceder, para obter informações diversificadas. Essa página seria acedida a partir do site (caso o utilizador tivesse permissão para tal), mas seria uma página que poderia sofrer alterações a qualquer instante. Para cumprir tal objectivo, foi implementado um componente Joomla cujo modelo MVC é reduzido ao mínimo necessário a redireccionar o view para uma página PHP/HTML dinâmica externa. A implementação deste componente começou então pelo desenvolvimento da estrutura MVC. O controller deste componente contém apenas o método de display, 61

77 que acciona o visionamento do view. O seu model contém apenas a definição da classe, e não contém qualquer método, uma vez que no view do componente não serão realizadas quaisquer operações. Por fim, o view deste componente utiliza a função header do PHP para redireccionar para o ficheiro index.php da pasta onde é implementada a página externa (pasta essa que se encontra no mesmo servidor do site). Ao fazer o redireccionamento são enviadas, através do método GET do PHP, duas variáveis contendo o id do utilizador do site e o idioma em que este se encontra a utilizar o site. Após a implementação e instalação deste componente no site é iniciada a implementação da página dinâmica proposta pela empresa. Outro requisito imposto pela empresa foi que esta página, tendo como ficheiro inicial o ficheiro index.php, deveria ter ligação a uma nova base de dados (alocada no mesmo servidor do site), para assim definir o conteúdo desta de forma dinâmica. O primeiro objectivo a atingir na página de conteúdo dinâmico é implementar um menu dinâmico, isto é, um menu cujo conteúdo varie, de acordo com o conteúdo definido na base de dados, e de acordo com o utilizador. Para suportar este menu, em primeiro lugar, foram definidas duas tabelas na base de dados: as tabelas paginas e util_pag, ilustradas na Figura 42. Figura 42 - Relação entre as tabelas da base de dados da página dinâmica Na tabela util_pag são definidas as permissões de acesso a cada item, para cada utilizador do site. Ou seja, por exemplo, caso o utilizador com o id 7 tenha 62

78 permissão para aceder ao item de id 2, o campo activo terá o valor 1, caso contrário terá o valor 0. Na tabela paginas são definidos os itens que podem estar presentes no menu, podendo estes ter uma hiperligação para uma página ou não, e podendo cada item possuir itens descendentes de si. Caso o item definido possua hiperligação para uma nova página, é colocado o valor 1 no campo lactivo ; caso contrário, terá o valor 0. Quando o campo lactivo tiver o valor 1, o campo link possuí o nome do ficheiro para onde é feita a hiperligação (por exemplo, nomedapagina.php). No caso do parentesco entre itens, este é definido com recurso aos campos m1, m2 e no. Recorrendo à Figura 43 percebe-se que os campos m1 e m2 indicam a família a que pertence cada item, e a ordem pela qual são apresentados, enquanto o campo no indica o valor do campo m1 da família filha. Caso um item não possua família filha o campo no possui o valor NULL. Figura 43 - Relacionamento entre itens da página dinâmica Depois da construção destas tabelas, são definidas mais duas para lidar com a utilização de multi-idiomas: idiomas e idiomas_string. Com estas tabelas torna-se possível utilizar a definição de um item do menu em vários idiomas, tendo sido apenas neste trabalho definidos dois por defeito: o português e o inglês. Por exemplo um item de menu é adicionado na tabela paginas e é-lhe atribuído o id 1. Na tabela 63

79 idiomas_strings é adicionada uma nova linha onde o campo id_idioma pode corresponder ao idioma inglês, e o campo valor terá a tradução correspondente desse item. Figura 44 Relação entre as tabelas de idiomas da base de dados da página dinâmica Depois da implementação deste conceito que permite um grande dinamismo à página, foi desenvolvido o menu propriamente dito. Para que este pudesse ter um aspecto dinâmico recorreu-se a um exemplo existente, o SmartMenu ( Este estilo de menu é composto por um ficheiro javascript e um ficheiro CSS, que permitem dispor os itens num menu de forma dinâmica, e não por uma lista estática de itens. A implementação da página index.php, que contém o menu principal do componente, foi então realizada de acordo com o seguinte algoritmo: Figura 45 Fluxograma da implementação da página index.php 64

80 Para a impressão do menu é utilizada uma função recursiva, para assim ser possível imprimir todos os itens, incluindo os que possuem itens herdeiros. Essa função recebe uma variável com os itens de menu que o utilizador tem permissão para visualizar, verifica o idioma que o utilizador está a utilizar, e associa o nome do item ao campo valor da tabela idiomas_strings. Depois disso verifica se o item possui família de itens filha. Caso não tenha imprime o item no menu, caso contrário selecciona os itens da família filha e volta a chamar a função, tomando como parâmetro de entrada esses itens. Para a utilização do SmartMenu, no head do código HTML inserese os scripts: <script type="text/javascript" src="menu/c_config.js"></script> <script type="text/javascript" src="menu/c_smartmenus.js"></script> Depois disto, ao utilizar-se as tags HTML <ul> e <li> para apresentar os itens de menu, já estão definidas para permitir hierarquia nos itens. O algoritmo da função de impressão do menu encontra-se representado na Figura 46. Figura 46 - Fluxograma da função de impressão do menu dinâmico 65

81 Após a implementação da página index.php foram implementadas cinco páginas que por defeito foram definidas como itens do menu, e também o item de saída para o site. Depois da inserção destes itens na base de dados, o ficheiro index.php tomou o aspecto da Figura 47. Na Figura 48 é apresentado um item de exemplo para demonstrar a recursividade do menu em funcionamento. Figura 47 - Layout da página índex.php do componente de funcionalidades dinâmicas Figura 48 - Layout do menu da página index.php, utilizando a recursividade A primeira página a ser implementada foi a de gestão de páginas. Esta página tem a finalidade de permitir, a alguém não programador, adicionar e remover novas páginas a este componente de funcionalidades dinâmicas. Para isso foi implementado um formulário que permite preencher os dados de uma nova página na tabela paginas, e que contém uma caixa de texto para inserir o código HTML/PHP da página, sendo depois criado o ficheiro correspondente na pasta pré-definida. Além da criação de uma nova página (ou um item sem hiperligação), permite também editar os parâmetros dos itens já existentes na base de dados, ou até mesmo remover algum deles. A Figura 49 ilustra o layout da página. Uma particularidade desta página é que 66

82 esta apenas é visível no menu pelo administrador do site, tendo sido colocada essa restrição no código da página index.php. Figura 49 - Layout da página Gestão de Páginas do componente de funcionalidades dinâmicas Foi criada uma segunda página direccionada aos utilizadores do site, denominada Adicionar Funcionários. É a partir desta página que um administrador de uma empresa cliente pode adicionar os seus funcionários ao grupo de utilizadores do site. Para isso o utilizador principal (administrador da empresa cliente) tem que preencher um formulário referente aos dados do funcionário que pretende adicionar, e definir as permissões deste em relação ao site, e em relação aos itens do componente de funcionalidades dinâmicas. Como tal esta página apresenta essas 67

83 permissões também de forma dinâmica, isto porque o utilizador principal só poderá atribuir as permissões ao seu funcionário, de acordo com as suas permissões. Ou seja, se por exemplo o utilizador principal não possuir permissões para aceder ao item X, não poderá atribuir ao seu funcionário permissão para aceder a esse mesmo item. O layout desta mesma página pode ser observado na Figura 50. Figura 50 - Layout da página Adicionar Funcionários do componente de funcionalidades dinâmicas A terceira página a ser implementada tem o nome de Gerir Permissões, e tal como o nome indica, permite a um utilizador normal (que tenha permissão para aceder a este item) gerir permissões do grupo de utilizadores da sua empresa. Ou seja, caso um utilizador X da empresa Y tenha permissão para aceder a este item, ele poderá editar as permissões de acesso aos itens (os quais ele tem acesso) de todos os utilizadores da empresa Y. O layout da página pode ser visualizado na Figura

84 Figura 51 - Layout da página Gerir Permissões do componente de funcionalidades dinâmicas As restantes duas páginas dizem respeito à conta do utilizador na empresa IVV Automação. Por isso, ambas têm ligação directa à base de dados MSSQL da empresa. As páginas denominam-se por Empréstimos e Conta Corrente. A primeira refere-se aos empréstimos feitos pela empresa IVV Automação à empresa do utilizador, e a segunda refere-se aos movimentos de conta realizados entre a IVV e a empresa do utilizador. Por motivos de confidencialidade os layouts destas páginas são apresentados na Figura 52 e na Figura 53, com campos ofuscados, respeitando assim os direitos de confidencialidade da empresa. A primeira apresenta uma listagem cujas colunas são: número de cliente, tipo de documento, número do documento, referência do documento, designação do artigo, quantidade de empréstimo e data em que foi realizado. A segunda apresenta uma listagem cujas colunas são: nome do cliente, tipo de documento, número do documento, valor do débito, valor do crédito, data de lançamento e data de vencimento. 69

85 Figura 52 - Layout da página Empréstimos do componente de funcionalidades dinâmicas Figura 53 - Layout da página Conta Corrente do componente de funcionalidades dinâmicas O conteúdo de todas as páginas implementadas por defeito é apresentado consoante o idioma utilizado pelo utilizador. Para isso são utilizados dois ficheiros PHP (pt.php e en.php) que contêm definições de labels utilizadas nessas páginas. Por exemplo, no ficheiro en.php encontra-se a seguinte linha de código: if (!defined('_nome')) DEFINE('_NOME','Name'); Enquanto no ficheiro pt.php tem a seguinte (correspondente à anterior): if (!defined('_nome')) DEFINE('_NOME','Nome'); No início do código de cada uma das páginas implementadas é feito o include do ficheiro de de acordo com idioma que está ser utilizado. Consequentemente, nas páginas onde é utilizada a label _NOME, esta irá apresentar o seu conteúdo como sendo Name ou Nome, consoante o idioma seleccionado pelo utilizador do site. 70

86 6. Desenvolvimento do Sistema de Encomendas por SMS O sistema é composto, em termos de hardware, pelo módulo GSM, um cabo conversor USB RS-232 (isto porque o PC utilizado não é dotado de porta série), e o PC onde se encontra alocado o servidor do site. Em termos de software é constituído por um daemon (escrito em linguagem C) que se encarrega de fazer a comunicação com o módulo, o processamento de dados e a interacção com a base de dados MySQL onde está alocado o site. Este sistema permite a qualquer cliente registado no site da empresa IVV Automação, realizar um pedido de encomenda por SMS. 6.1 Módulo GSM O módulo GSM utilizado é o módulo Wavecom Fastrack Supreme 10 (ver Figura 54), cujas especificações técnicas estão apresentadas na Tabela 4. Característica Valor Core CPU ARM9, 32 bits with cache Speed 26 / 104 MHz External Interruption < 1ms GPIO 2 Analogue Audio 2 RS232 1 Voltage (nominal) 5.5 to 32 V Current (Max.) 5.5 V Size (mm) 73 x 54.5 x 25.5 Weight 89 Operating temperature range -30 o C to +75 o C TCP/IP & Internet Plug-in GPS Plug-in Tabela 4 - Características do módulo GSM Wavecom Fastrack Supreme 10 71

87 Figura 54 - Módulo Wavecom Fastrack Este módulo pode ser encontrado no mercado por um preço de (excluindo a taxa de IVA). [12] Somando a este preço o valor do PC e do cabo conversor de USB para RS-232 utilizado, pode estimar-se que o hardware utilizado neste sistema rondará aproximadamente os Descrição do Sistema Em termos funcionais, o daemon começa por configurar o módulo GSM, e de seguida aguardar pela recepção de notificações sobre a chegada de mensagens SMS enviadas pelo módulo. Quando isso acontece, o daemon lê a mensagem SMS acabada de chegar, faz o parsing da mensagem, e verifica a validade desta. Caso a mensagem seja válida, o daemon toma medidas quanto à possibilidade de inserir ou não uma nova encomenda na base de dados do site, de acordo com a existência do produto na base de dados e da quantidade de produto requerido para encomenda. Em primeiro lugar, foi definida a sintaxe das mensagens que o utilizador deve enviar por SMS. Nesse sentido, foi estabelecido que essas mensagens teriam um dos seguintes formatos: sku_produto [espaço] quantidade_produto sku_produto1 [espaço] quantidade_produto1; [espaço] sku_produton [espaço] quantidade_produton sku_produto1 [espaço] quantidade_produto1; sku_produton [espaço] quantidade_produton 72

88 sku_produto1 [espaço] quantidade_produto1 [espaço] ; [espaço] sku_produton [espaço] quantidade_produton Se uma mensagem enviada pelo utilizador segue uma destas sintaxes, então é considerada válida pelo daemon. Além da sintaxe o daemon verifica também a parte léxica da mensagem, pelo que para considerar a mensagem válida, o(s) parâmetro(s) sku_produto tem/têm de ser compostos apenas por números, assim como o(s) parâmetro(s) quantidade_produto. Para efectuar o reconhecimento do utilizador em questão, o sistema identifica o remetente da mensagem, e procura na base de dados do site o utilizador que tem definido como um dos seus números de telefone esse mesmo remetente. Caso o número do remetente da mensagem não se encontre definido na base de dados, não é efectuado qualquer outro processamento da mensagem, e é enviada uma mensagem de aviso ao remetente em questão, para que este proceda ao seu registo no site da empresa, ou verifique os dados da sua conta no mesmo. 6.3 Implementação do Software A implementação do software foi dividida em quatro partes distintas. A primeira diz respeito à configuração da porta USB do PC (para poder utilizá-la para comunicar com o módulo); a segunda efectua a configuração do módulo com recurso aos comandos AT; a terceira encarrega-se pelo parsing da mensagem recebida, e a última refere-se à conexão à base de dados, validação dos campos utilizados na mensagem, e inserção ou não da encomenda. 73

89 6.3.1 Configuração da porta USB do PC Esta configuração é efectuada recorrendo ao driver de porta série existente no computador, utilizando a porta /dev/ttyusb0, dado que é utilizado o cabo conversor USB RS-232 como ligação física entre os aparelhos. Esse driver é utilizado a partir de rotinas C, para abertura, configuração e envio/recepção de dados. A configuração é feita com os seguintes parâmetros principais: Baud rate de (número de vezes que um sinal eléctrico pode alterar de nível, por unidade de tempo); [13] 8 Bits de dados, 1 stop bit e 0 bits de paridade; Modo NONBLOCK, para que a rotina read retorne imediatamente a leitura de dados da porta. Figura 55 - Fluxograma de configuração da porta ttyusb0 Após a configuração da porta, é então possível comunicar com o módulo GSM, utilizando rotinas de envio e recepção de comandos AT. 74

90 6.3.2 Configuração do módulo GSM Tal como já foi referido, a configuração do módulo é efectuada através do envio de comandos AT, pelo canal de comunicação série. A configuração do módulo é realizada a partir dos comandos indicados no fluxograma da Figura 56. Figura 56 - Fluxograma de configuração do módulo GSM (parte 1) 75

91 Figura 57 - Fluxograma de configuração do módulo GSM (parte 2) Posto isto, o módulo está configurado, e aquando da recepção de uma nova mensagem SMS, envia o comando de aviso de recepção ao daemon, o qual se encarrega de o processar Parsing de uma mensagem SMS recebida Para realizar esta etapa da implementação do software do sistema de encomendas por SMS, recorreu-se ao Flex e ao Bison. Sabendo que o formato dos comandos enviados pelo módulo GSM quando recebe uma nova mensagem SMS, e quando responde ao pedido vindo do PC para a leitura de uma mensagem SMS são, respectivamente, do tipo: +CMTI: SM, índex_da_mensagem +CMGR : REC UNREAD, num_tel_remetente,, data_e_hora_recepcao, mensagem \nok Então, é possível ser feita a análise desses dois comandos, de forma a serem utilizados/extraídos apenas os campos necessários. Para a implementação do parsing destes dois comandos enviados pelo módulo, começou-se pela implementação do ficheiro scan.l. Neste ficheiro foram definidos os tokens a partir de expressões regulares (Tabela 5). 76

92 TOKEN EXPRESSÃO REGULAR number [0-9]+ read ["]"REC UNREAD"["] sm ["]"SM"["] ID ","{number} CMGR \+CMGR: CMTI \+CMTI: OKAY OK "\""{number}"/"{number}"/"{number}","{number}":"{number}":" DATE {number}"+"{number}"\"" NL "\n" NUMBER ["]"+"{number}["] COMMA "," SC ";" SPACE [ ] ANY. Tabela 5 - Tokens definidos no ficheiro scan.l Depois de serem definidos todos os tokens que os comandos enviados pelo módulo GSM podem possuir, são especificadas as regras gramaticais no ficheiro parser.y para o analisador sintáctico converter a estrutura linear dada pela sequência de tokens, numa estrutura hierárquica em árvores Abstract Syntax Tree (AST). As regras gramaticais são expressas utilizando a notação BNF (Backus-Naur Form), que utiliza expressões regulares como componente. No ficheiro parser.y foram então definidas as regras gramaticais presentes na Figura

93 78 Figura 58 Regras gramaticais do ficheiro parser.y

94 Como é possível observar na figura anterior, são utilizadas as variáveis id_msg, phone_num e mensagem para guardar os itens desejados, que se encontram nos comandos enviados pelo módulo GSM. Quando é feito o parsing do comando enviado pelo módulo, o daemon fica com o valor destas variáveis actualizados (visto serem globais para o restante código C), podendo assim efectuar o tratamento desses dados. A validação da mensagem SMS enviada pelo utilizador é feita na regra message, que limita o formato da mensagem às quatro sintaxes definidas Tratamento dos dados recebidos, e ligações à base de dados Após a obtenção dos dados da nova mensagem SMS remetida pelo cliente da empresa, estes necessitam de ser verificados. O algoritmo de validação e processamento está representado nos fluxogramas da Figura 59 e Figura 60. Quando o módulo GSM recebe uma nova mensagem SMS de um cliente, envia a notificação CMTI para o PC, por exemplo +CMTI: SM, 10. Imediatamente após fazer o parsing deste, o daemon envia para o módulo o comando de leitura da mensagem (CMGR) com o id retirado do parsing (id_msg), segundo o exemplo, AT+CMGR=10. Depois disto o módulo envia a notificação CMGR, por exemplo, +CMGR : REC UNREAD, ,, 10/03/01, 09:30:58+00, \nok, cujo parsing extrai o número de telefone do remetente (phone_num: ) e a mensagem SMS enviada pelo utilizador (mensagem: ). Depois da recepção deste último comando utiliza-se a rotina message_validate(phone_num,mensagem), que valida o número do remetente da mensagem SMS e o conteúdo da mensagem. A validação do número do remetente faz uma consulta à base de dados do site para verificar se corresponde a algum cliente registado. A validação da variável mensagem é feita independentemente a cada par {produto,quantidade} (com o formato descrito em 6.1) da encomenda. Para cada par encontrado, é feita conexão à base de dados para verificar a existência do produto e da quantidade requerida em stock. Em caso positivo, é então inserida a respectiva encomenda na base de dados. Se em alguma das validações efectuadas for detectada alguma anomalia, é enviada uma mensagem de erro ao remetente da mensagem SMS, 79

95 caso contrário é enviada uma mensagem de sucesso. No instante que for encontrado um par não válido, a restante encomenda não é realizada. Figura 59 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 1) 80

96 Figura 60 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 2) A rotina de inserção da encomenda efectua também a conexão à base de dados do site que envolve as seguintes tabelas: jos_vm_order_user_info onde são inseridos os dados da conta do utilizador, e também o id da encomenda a efectuar; 81