tiago manuel machado ribeiro oliveiraintranet.dei.uminho.pt/gdmi/galeria/temas/pdf/48039.pdf ·...
TRANSCRIPT
Tiago Manuel Machado Ribeiro Oliveira
Sistema de Informação Dedicadocom Site de Vendas e Bases de Dados
T
iago
Man
uel M
acha
do O
liveir
a
Outubro de 2010UMin
ho |
201
0Si
stem
a de
Info
rmaç
ão D
edic
ado
com
Site
de
Vend
as e
Bas
es d
e Da
dos
Universidade do MinhoEscola de Engenharia
Outubro de 2010
Dissertação de MestradoCiclo de Estudos Integrados Conducentes aoGrau de Mestre em Engenharia Electrónica Industrial e Computadores
Trabalho efectuado sob a orientação doProfessor Doutor Sérgio Adriano Fernandes Lopes
Tiago Manuel Machado Ribeiro Oliveira
Sistema de Informação Dedicadocom Site de Vendas e Bases de Dados
Universidade do MinhoEscola de Engenharia
iii
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!
v
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 back-
end 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.
vii
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.
viii
Í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 ..................................................................................................................... 1
1.1 Descrição do Trabalho ........................................................................................ 2
1.2 Estrutura da Dissertação ......................................................................................... 3
2. Fundamentos Teóricos.................................................................................................. 5
2.1 Joomla ..................................................................................................................... 5
2.1.1 Instalação e Utilização ..................................................................................... 7
2.1.2 Vantagens e Desvantagens .............................................................................. 8
2.2 Web Services ........................................................................................................... 9
2.3 Daemons ............................................................................................................... 10
2.4 Triggers ................................................................................................................. 12
2.5 Padrão Model-View-Controller ............................................................................. 12
2.5.1 Aplicações Web sob o modelo MVC .............................................................. 13
2.5.2 Joomla MVC ................................................................................................... 14
2.6 Linguagem de Comandos de Modems .................................................................. 15
2.7 Bison/Flex .............................................................................................................. 18
3. Descrição da empresa IVV Automação ....................................................................... 23
3.1 A empresa e seus clientes ..................................................................................... 23
3.2 Servidor IVV .......................................................................................................... 24
3.3 Servidor do novo site ............................................................................................ 25
ix
3.3.1 Componentes Joomla instalados ................................................................... 26
4. Mecanismo de Sincronização das Bases de Dados ..................................................... 35
4.1 Descrição do Problema ......................................................................................... 35
4.2 Exportação de dados do Servidor IVV para o Servidor Site .................................. 36
4.2.1 Instalação do driver ODBC ............................................................................. 37
4.2.2 Implementação dos scripts PHP .................................................................... 38
4.3 Desenvolvimento do mecanismo de sincronização ............................................. 47
4.3.1 Comunicação entre Servidor Site e Servidor IVV ........................................... 47
4.3.2 Comunicação entre Servidor IVV e Servidor Site ........................................... 54
5. Desenvolvimento do site ............................................................................................ 57
5.1 Configuração e adaptação do Joomla ................................................................... 57
5.2 Componente de funcionalidades dinâmicas ........................................................ 61
6. Desenvolvimento do Sistema de Encomendas por SMS ............................................ 71
6.1 Módulo GSM ......................................................................................................... 71
6.2 Descrição do Sistema ............................................................................................ 72
6.3 Implementação do Software ................................................................................ 73
6.3.1 Configuração da porta USB do PC.................................................................. 74
6.3.2 Configuração do módulo GSM ....................................................................... 75
6.3.3 Parsing de uma mensagem SMS recebida .................................................... 76
6.3.4 Tratamento dos dados recebidos, e ligações à base de dados ..................... 79
7. Conclusões e Sugestões para Trabalho Futuro ........................................................... 83
8. Referências .................................................................................................................. 85
8.1 Internet ................................................................................................................. 85
8.2 Livros ..................................................................................................................... 85
x
Í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 ..................................................................... 10
Figura 5 - Fluxograma genérico de um Daemon ............................................................. 11
Figura 6 - Estrutura em código C de um daemon ........................................................... 11
Figura 7 - Sistema MVC ................................................................................................... 14
Figura 8 - Estrutura de ficheiros Joomla MVC ................................................................ 14
Figura 9 - Sequência de analisador léxico e sintáctico ................................................... 18
Figura 10 - Funcionamento do Flex ................................................................................ 19
Figura 11 - Análise lexical e sintáctica de uma frase ...................................................... 21
Figura 12 - Diagrama estrutural da empresa IVV e seus clientes ................................... 23
Figura 13 - Servidor IVV: software instalado .................................................................. 24
Figura 14 - Servidor do site: software instalado ............................................................. 25
Figura 15 - Menu de back-end do VirtueMart ................................................................ 27
Figura 16 - Menu de back-end do Huru Helpdesk .......................................................... 30
Figura 17 - Menu de back-end do Joom!Fish .................................................................. 32
Figura 18 –View customers ............................................................................................. 36
Figura 19 – View cl .......................................................................................................... 36
Figura 20 - Diagrama de funcionamento do ODBC ......................................................... 37
Figura 21 - Relação entre as principais tabelas referentes aos produtos ...................... 39
Figura 22 - Fluxograma de script PHP para importar produtos ...................................... 40
Figura 23 - Excerto de código PHP do script de importação dos produtos .................... 41
Figura 24 - Representação dos dados da tabela jos_core_acl_aro_groups ................... 42
Figura 25 - Relação entre as principais tabelas referentes aos clientes ......................... 43
Figura 26 - Fluxograma para geração de palavra-chave para Joomla ............................ 44
Figura 27 - Fluxograma de script PHP para importar os dados dos clientes .................. 46
Figura 28 - Diagrama de funcionamento do mecanismo de sincronização (site → ivv) 48
xi
Figura 29 - Código SQL de um trigger do mecanismo de sincronização ........................ 49
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 ................ 50
Figura 32 – Fluxograma da rotina C do cliente do Web service do mecanismo de
sincronização (site→ivv) ................................................................................................. 51
Figura 33 - Fluxograma da rotina C do servidor webservice do mecanismo de
sincronização (site→ivv) ................................................................................................. 52
Figura 34 - Documento WSDL do webservice do mecanismo de sincronização (site→ivv)
........................................................................................................................................ 53
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) ............................................................................................... 55
Figura 37 - Layout da página princiapl do front-end do site (antes do login) ................ 58
Figura 38 - Layout da página princiapl do front-end do site (depois do login) .............. 59
Figura 39 - Layout do menu principal do componente Huru Helpdesk no front-end do
site ................................................................................................................................... 59
Figura 40 - Layout do componente Huru Helpdesk, para inserir novo tópico, no front-
end do site ....................................................................................................................... 60
Figura 41 - Layout do menu principal do componente Remository no front-end do site
........................................................................................................................................ 61
Figura 42 - Relação entre as tabelas da base de dados da página dinâmica ................. 62
Figura 43 - Relacionamento entre itens da página dinâmica ......................................... 63
Figura 44 – Relação entre as tabelas de idiomas da base de dados da página dinâmica
........................................................................................................................................ 64
Figura 45 – Fluxograma da implementação da página index.php .................................. 64
Figura 46 - Fluxograma da função de impressão do menu dinâmico ............................ 65
Figura 47 - Layout da página índex.php do componente de funcionalidades dinâmicas
........................................................................................................................................ 66
Figura 48 - Layout do menu da página index.php, utilizando a recursividade ............... 66
Figura 49 - Layout da página ‘Gestão de Páginas’ do componente de funcionalidades
dinâmicas ........................................................................................................................ 67
xii
Figura 50 - Layout da página ‘Adicionar Funcionários’ do componente de
funcionalidades dinâmicas .............................................................................................. 68
Figura 51 - Layout da página ‘Gerir Permissões’ do componente de funcionalidades
dinâmicas ........................................................................................................................ 69
Figura 52 - Layout da página ‘Empréstimos’ do componente de funcionalidades
dinâmicas ........................................................................................................................ 70
Figura 53 - Layout da página ‘Conta Corrente’ do componente de funcionalidades
dinâmicas ........................................................................................................................ 70
Figura 54 - Módulo Wavecom Fastrack .......................................................................... 72
Figura 55 - Fluxograma de configuração da porta ttyUSB0 ............................................ 74
Figura 56 - Fluxograma de configuração do módulo GSM (parte 1) .............................. 75
Figura 57 - Fluxograma de configuração do módulo GSM (parte 2) .............................. 76
Figura 58 – Regras gramaticais do ficheiro parser.y ....................................................... 78
Figura 59 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 1)
........................................................................................................................................ 80
Figura 60 - Fluxograma do tratamento dos dados recebidos do módulo GSM (parte 2)
........................................................................................................................................ 81
xiii
Índice de Tabelas
Tabela 1 - Parâmetros do comando AT+CNMI ............................................................... 17
Tabela 2 - Exemplo de tokens para o gerador léxico ...................................................... 19
Tabela 3 - Tabela jos_vm_shopper_group ..................................................................... 42
Tabela 4 - Características do módulo GSM Wavecom Fastrack Supreme 10 ................. 71
Tabela 5 - Tokens definidos no ficheiro scan.l ................................................................ 77
xiv
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
1
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.
2
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 front-
end, possui um outro interface para a administração da empresa, denominado back-
end. O back-end permite fazer a gestão do conteúdo apresentado no front-end, assim
como personalizar o aspecto de todo o site.
3
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.
4
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.
5
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 1.5.15).
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]
6
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 Plug-
ins 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 back-
end 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
7
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.
2.1.1 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 4.3.10
O servidor de base de dados MySQL 3.23
A instalação do Joomla segue os seguintes passos:
Download dos ficheiros do Joomla (http://www.joomla.org/download.html)
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:
http://localhost/Joomla)
Seguir os passos da instalação no próprio browser
Figura 3 - Menu de Instalação Joomla
8
Depois de terminada a instalação, para se aceder ao back-end do site utiliza-se
o endereço http://localhost/Joomla/administrator, e para se aceder ao front-end
utiliza-se o endereço http://localhost/Joomla.
2.1.2 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).
9
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.
10
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
11
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.
Figura 5 - Fluxograma genérico de um Daemon
Figura 6 - Estrutura em código C de um daemon
pid_t pid, sid;
/* Bifurcação do processo “pai” */
pid = fork();
if (pid < 0) {
exit(EXIT_FAILURE);
}
/* 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
}
12
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.
13
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.
2.5.1 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
14
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
2.5.2 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
15
A framework Joomla está totalmente detalhada em
http://api.joomla.org/classtrees_Joomla-Framework.html, 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 07.07 especifica o estilo desses
16
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.
17
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.
18
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.
19
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
20
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.
21
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.
23
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, anti-
intrusã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
24
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.
25
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
26
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.
3.3.1 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.
3.3.1.1 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.
27
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);
28
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;
29
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).
3.3.1.2 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.
30
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_emailmsg – que armazena todos os emails enviados entre
utilizadores;
jos_huruhelpdesk_langstrings – que contém as labels apresentadas com a
respectiva tradução para outros idiomas;
31
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).
3.3.1.3 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;
32
3.3.1.4 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 back-
end 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.
33
3.3.1.5 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.
35
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).
36
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.
37
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.
4.2.1 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
Para a instalação do ODBC no Ubuntu é necessária a instalação dos seguintes
pacotes:
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.
38
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 = 192.168.0.15 // 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
4.2.2 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
39
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.
40
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
41
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.
<?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
…
?>
42
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:
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
jos_vm_shopper_group
shopper_group_id shopper_group_name
1 Distribuidor
2 Desconto Tabela
3 Agente
4 Revenda
43
(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
44
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 palavras-
chave 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
45
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 email 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.
46
Figura 27 - Fluxograma de script PHP para importar os dados dos clientes
47
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.
4.3.1 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, …).
48
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:
49
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 31.
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
50
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
#!/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(); // tornar o processo filho líder da sessão
umask(0); // 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
}
}
?>
51
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 33.
52
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 34.
53
Figura 34 - Documento WSDL do webservice do mecanismo de sincronização (site→ivv)
<?xml version="1.0"?>
<definitions name="MyDefinition"
targetNamespace="urn:myTargetNamespace"
xmlns:tns="urn:myTns"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns="http://schemas.xmlsoap.org/wsdl/">
<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="http://schemas.xmlsoap.org/soap/http"/>
<operation name="service_encomendas">
<soap:operation soapAction=""/>
<input>
<soap:body use="encoded"
namespace="urn:myInputNamespace"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</input>
<output>
<soap:body use="encoded"
namespace="urn:myOutputNamespace"
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
</output>
</operation>
</binding>
<service name="MyService">
<documentation>Mecanismo de sincronização IVV .
</documentation>
<port name="MyPort" binding="tns:MyBinding">
<soap:address
location="http://192.168.0.15/service_encomendas/servidor_e
ncomendas.php"/>
</port>
</service>
</definitions>
54
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.
55
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)
57
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.
58
Figura 37 - Layout da página princiapl do front-end do site (antes do login)
59
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
60
Figura 40 - Layout do componente Huru Helpdesk, para inserir novo tópico, no front-end do site
61
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,
62
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
63
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
64
‘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
(http://www.smartmenus.org/). 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
65
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 insere-
se os scripts:
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
<script type="text/javascript" src="menu/c_config.js"></script>
<script type="text/javascript" src="menu/c_smartmenus.js"></script>
66
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
67
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
68
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 51.
69
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.
70
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.
71
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.) 0.48A @ 5.5 V
Size (mm) 73 x 54.5 x 25.5
Weight 89
Operating temperature range -30oC to +75oC
TCP/IP & Internet Plug-in
GPS Plug-in
Tabela 4 - Características do módulo GSM Wavecom Fastrack Supreme 10
72
Figura 54 - Módulo Wavecom Fastrack
Este módulo pode ser encontrado no mercado por um preço de €149.99
(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 €650.
6.2 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
73
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.
74
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 115200 (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.
75
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)
76
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.
6.3.3 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).
77
TOKEN EXPRESSÃO REGULAR
number [0-9]+
read ["]"REC UNREAD"["]
sm ["]"SM"["]
ID ","{number}
CMGR \+CMGR:
CMTI \+CMTI:
OKAY OK
DATE "\""{number}"/"{number}"/"{number}","{number}":"{number}":"
{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 58.
78
Figura 58 – Regras gramaticais do ficheiro parser.y
79
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.
6.3.4 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”, “+351933333333”,,”10/03/01, 09:30:58+00”,”0120
2”\nOK”, cujo parsing extrai o número de telefone do remetente (phone_num:
“+351933333333”) e a mensagem SMS enviada pelo utilizador (mensagem: ”0120 2”).
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,
80
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)
81
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;
82
jos_vm_order_item – onde nesta tabela são inseridos os dados referentes ao
produto encomendado, assim como da quantidade requerida na encomenda;
jos_vm_orders – onde se encontram todas as encomendas (definidas pelo seu
id), e também os dados sobre possíveis descontos, o id do vendedor e o preço
total da encomenda;
jos_vm_order_payment – onde é definido o tipo de pagamento para a
encomenda em causa, sendo que neste serviço de encomendas foi pré-definido
utilizar sempre o método de pagamento na entrega do produto
Esta rotina apenas efectua a inserção dos dados do produto e do cliente nestas
tabelas, tendo em conta os parâmetros recebidos: número de identificação do
utilizador; número de identificação do produto; e, quantidade requerida para
encomenda.
83
7. Conclusões e Sugestões para Trabalho Futuro
Esta tese descreve a implementação de um sistema de informação para a
empresa IVV Automação. O trabalho colocou várias metas a alcançar, como o
desenvolvimento de um site com objectivos comerciais, cujas funcionalidades se
distinguem principalmente pelo catálogo de produtos e sua possível encomenda
online, pelo serviço de help desk prestado ao utilizador, e também pelo componente
de funcionalidades dinâmicas. Uma outra meta alcançada foi a sincronização de bases
de dados, com estruturas e servidores de tecnologia diferentes. Por fim foi também
implementado o canal de interacção com o cliente através de SMS. O trabalho
desenvolvido na parte Web foi suportado pelo recurso às linguagens HTML, PHP,
Javascript e CSS, com o suporte às duas bases de dados distintas (MySQL e MSSQL),
sendo que o número de tecnologias e linguagens disponíveis para o desenvolvimento
de aplicações neste ramo são inúmeras. A solução encontrada para o mecanismo de
sincronização das bases de dados é uma solução fiável, e comprova que as tecnologias
utilizadas nesse sistema podem ser utilizadas em mecanismos com os mesmos fins que
este. Em relação ao sistema de encomendas por SMS, pode concluir-se que, no ponto
de vista do utilizador, não é uma solução muito prática, visto que obriga o utilizador a
saber os códigos de identificação dos produtos (sku’s). Do ponto de vista tecnológico é
uma solução robusta, e que proporcionou (assim como o restante trabalho) um
adquirir de know-how bastante importante na minha formação, abrangendo as
capacidades de desenvolvimento de algoritmos, e também a experiência com várias
tecnologias.
O trabalho apresentado nesta tese demonstra uma solução fiável e eficaz para
a comercialização de produtos recorrendo à Internet e ao serviço de mensagens SMS.
Pode concluir-se que a utilização de um CMS permite a criação de uma solução
eficiente e com performance equivalente ou superior a sites desenvolvidos de raiz,
podendo facilmente ser criado um sítio Web que contém uma parte administrativa
(back-end). A utilização do Joomla em si proporciona o reaproveitamento de vários
componentes já desenvolvidos (muitos deles gratuitos), o que reduz em certa parte o
volume de trabalho para desenvolver o site. O que se torna mais complicado é quando
84
é necessário realizar alterações a algum desses componentes, visto que requer o
estudo do código destes, para encontrar os locais onde é necessário fazer alterações e
para não “quebrar” o desenho do componente.
A experiência prática adquirida permite concluir que o ambiente empresarial
acrescenta requisitos e restrições comparativamente ao ambiente académico. Muitas
vezes, neste tipo de ambiente, é mais importante que as soluções resolvam o
problema do que propriamente a qualidade. Isto faz com que as inovações aos
produtos e serviços não sejam tanto uma ruptura, mas antes dêem alguma
continuidade ao que já existe.
Todo o trabalho desenvolvido e descrito nesta dissertação foi devidamente
testado, e neste momento, falta apenas à empresa IVV Automação, caso assim o
deseje, tornar o sistema e o site acessíveis fora da rede informática da mesma, para
que os seus clientes possam usufruir do trabalho realizado.
Em termos de possíveis trabalhos futuros, pode incluir-se principalmente a
utilização de uma central PBX no sistema de encomendas, o que permitiria ao cliente
da empresa realizar pedidos de encomenda por voz de forma interactiva (seguindo
informações disponibilizadas pela ‘voz’ da central), eliminando assim a contra-partida
da necessidade do utilizador saber os sku’s dos produtos. Quanto ao site em si, este
poderá ter bastante trabalho futuro, visto que a qualquer momento podem ser
adicionados novos componentes (por exemplo um componente de chat Live Support),
módulos (por exemplo um módulo que active/desactive recebimento de Newsletter
pelo utilizador) ou templates no Joomla, e também poderão ser adicionadas novas
páginas no componente de funcionalidades dinâmicas. Relativamente a este
componente, também poderá ser totalmente desenvolvido no modelo MVC.
85
8. Referências
[1] http://www.internetworldstats.com/stats.htm
[2] http://joomlapt.com
[4] http://help.joomla.org/content/view/1938/310/
[5] http://www.mactech.com/articles/mactech/Vol.16/16.07/UsingFlexandBison/
[6] http://virtuemart.net/
[7] http://www.huruhelpdesk.net/
[8] http://www.jevents.net/
[9] http://www.joomfish.net/
[10] http://remository.com/
[11] http://www.easysoft.com/developer/interfaces/odbc/linux.html
[12]http://www.gprsmodems.co.uk/acatalog/Online_Catalogue_Wavecom_GSM_GPR
S_Modems_100.html#a627
[13] http://pccompci.com/Baud_Rate.html
8.1 Internet
http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_1
http://www.roseindia.net/mysql/mysql5/triggers.shtml
http://en.wikipedia.org/wiki/Hayes_command_set
http://www.developershome.com/sms/howToSendSMSFromPC.asp
8.2 Livros
PHP 5 for Dummies, de Janet Valade, 2004 Wiley Publishing, Inc.
Practical PHP and MySQL: building eight dynamic web applications, de Jono Bacon,
2007 Pearson Education, Inc.
Wireless EDGE Modems, 2008 Multi-Tech Systems, Inc.