Sistema de Gestão de Recursos Móveis · Resumo Cada vez mais, ... 4.1. Spring Framework 3.0 ... Figura 13 – Arquitectura da Spring MVC Framework 3.0

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Sistema de Gestão de Recursos Móveis

João Manuel Ferreira Gouveia

Mestrado Integrado em Engenharia Informática e Computação

Orientador: António Miguel Pontes Pimenta Monteiro

17 de Janeiro de 2011

Sistema de Gestão de Recursos Móveis

João Manuel Ferreira Gouveia

Mestrado Integrado em Engenharia Informática e Computação

Aprovado em provas públicas pelo Júri:

Presidente: Ana Paula Rocha

Vogal Externo: Paulo Sousa (ISEP/IPP-DEI)

Orientador: António Miguel Pontes Pimenta Monteiro

____________________________________________________

9 de Fevereiro de 2011

i

Resumo

Cada vez mais, as tecnologias de mobilidade e os dispositivos móveis são a chave para

acelerar e optimizar processos e operações de negócio. Este facto torna as tecnologias de

mobilidade no próximo nível da infraestrutura das Tecnologias de Informação (TI) das

organizações. Em particular, a crescente área de «Gestão de Recursos Móveis» em tempo real,

do original Mobile Resource Management ou, simplesmente, MRM.

Esta Dissertação insere-se no contexto descrito, onde há uma necessidade de sistemas

integrados e escaláveis que permitam a monitorização e controlo das operações e aumentem a

eficiência operacional. Além disso, pretende-se acrescentar o suporte a indicadores de gestão

para Apoio à Decisão.

A Dissertação tem como objectivo principal a concepção e teste da arquitectura e

infraestrutura de uma solução empresarial capaz de responder aos requisitos esperados para uma

aplicação MRM num contexto empresarial, com adição de uma componente de Apoio à Decisão

e recorrendo apenas a tecnologias de Código Aberto.

A Dissertação demonstra uma solução empresarial inovadora capaz de gerir, em tempo

real, recursos móveis georreferenciados e que integra ainda uma componente de Apoio à

Decisão.

Trata-se de um trabalho extenso que resultou numa solução que reúne todas as vantagens

de uma arquitectura adequada a aplicações empresariais e as vantagens das mais adequadas e

avançadas tecnologias de Código Aberto.

ii

iii

Abstract

Increasingly, mobile technologies and mobile devices are the key to speed and streamline

business processes and operations. This makes mobile technologies the next level of enterprise

Information Technology (IT) infrastructure. In particular, there are reliable studies that point out

the growing area of Mobile Resource Management in real time.

This Dissertation is within the scope of MRM enterprise solutions, where the market

demands integrated and scalable solutions that enable the operation‟s monitoring and

operational efficiency. In addition, we intend to add support for management indicators

(Decision Support).

The Dissertation's main goal is to design and test an enterprise solution that meets the

expected requirements for a MRM application in a business context, integrating a Business

Intelligence component and using only Open Source technologies.

The Dissertation introduces an innovative enterprise solution capable of managing geo-

referenced mobile resources in real time, with an integrated Business Intelligence component.

This extensive Dissertation resulted in a solution that combines all the advantages of the

appropriate enterprise application architectures and the challenging State-of-the-Art Open

Source technologies.

iv

v

Agradecimentos

No momento de concluir esta Dissertação, não posso deixar de agradecer a todos os

Professores, colegas e amigos que me ensinaram, apoiaram e incentivaram ao longo de todos

estes anos de estudo e trabalho.

A todos os que contribuíram directamente ou indirectamente para a realização desta

Dissertação, manifesto a minha gratidão, com um especial agradecimento:

Ao Prof. Miguel Pimenta Monteiro, por todo o apoio e orientação da Dissertação;

Ao Eng.º Jorge Soares von Doellinger, pelo apoio e amizade sempre demonstrado;

À Capgemini Portugal, pelas condições necessárias ao desenvolvimento da Dissertação;

A todos os colegas e amigos da unidade de Technology Services, da Capgemini Portugal,

por toda a amizade e incentivo;

Aos meus familiares, pela compreensão que têm demonstrado ao apoiarem e incentivarem

a minha dedicação e empenho.

vi

vii

Conteúdo

Resumo ................................................................................................................................ i

Abstract ............................................................................................................................ iii

Agradecimentos ..................................................................................................................v

Lista de Figuras ................................................................................................................ xi

Notação ........................................................................................................................... xiii

Acrónimos e abreviaturas utilizadas: ............................................................................ xiii

Capítulo 1

Introdução ..........................................................................................................................1

1.1. Enquadramento .....................................................................................................1

1.1.1. Mobile Resource Management .....................................................................1

1.1.2. Business Intelligence ....................................................................................2

1.2. Descrição da Dissertação ......................................................................................2

1.3. Objectivos e Resultados Esperados.......................................................................2

1.4. Organização do Documento..................................................................................2

Capítulo 2

Estado da Arte ....................................................................................................................3

2.1. Avaliação do Mercado ..........................................................................................3

2.1.1. Segmentação Actual .....................................................................................3

2.1.2. Caracterização do Mercado Alvo ..................................................................4

2.2. Ambiente da Industria ..........................................................................................4

2.2.1. Tendências e Previsões do Mercado .............................................................4

2.2.2. Atractividade do Mercado.............................................................................5

2.2.3. Análise SWOT..................................................................................................6

2.3. Soluções de Mobilidade Empresarial ....................................................................7

2.4. Plataformas de Desenvolvimento de Aplicações Móveis......................................8

2.5. Soluções no Mercado............................................................................................8

2.6. Aspectos Inovadores ........................................................................................... 10

Capítulo 3

Arquitectura do Sistema .................................................................................................. 13

viii

3.1. Visão Geral ......................................................................................................... 13

3.2. Análise Funcional do Sistema ............................................................................. 14

3.2.1. Definições ................................................................................................... 14

3.2.2. Actores........................................................................................................ 16

3.2.3. User Stories ................................................................................................ 17

3.2.4. Fluxo de Dados ........................................................................................... 17

3.3. Arquitectura Física ............................................................................................. 18

3.4. Arquitectura do Software .................................................................................... 20

3.4.1. Modelo da Arquitectura .............................................................................. 20

3.4.2. Descrição da Arquitectura........................................................................... 21

3.5. Tecnologias e Arquitectura ................................................................................. 22

Capítulo 4

Frameworks de Desenvolvimento ................................................................................... 25

4.1. Spring Framework 3.0 ........................................................................................ 25

4.1.1. Arquitectura ................................................................................................ 25

4.1.2. Tecnologias................................................................................................. 27

4.1.3. Estratégias de Desenvolvimento ................................................................. 30

4.2. Liferay Portal 6.0 ................................................................................................ 32

4.2.1. Arquitectura ................................................................................................ 33

4.2.2. Tecnologias................................................................................................. 33

4.2.3. Estratégias de Desenvolvimento ................................................................. 34

4.3. Pentaho BI Platform 3.6 ..................................................................................... 35

4.3.1. BI Platform e Arquitectura.......................................................................... 35

4.3.2. Reporting .................................................................................................... 37

4.3.3. Data Integration .......................................................................................... 37

4.3.4. Analysis Services ........................................................................................ 37

4.3.5. Data Mining ................................................................................................ 37

Capítulo 5

Desenvolvimento e Implementação ................................................................................. 39

5.1. Infraestrutura e Ambiente de Desenvolvimento .................................................. 39

5.1.1. Servidor MySQL 5.1 .................................................................................. 39

5.1.2. MySQL Workbench 5.2 .............................................................................. 40

5.1.3. SpringSource Tool Suite 2.3.2 .................................................................... 41

5.1.4. Servidor Liferay Portal 6.0 ......................................................................... 42

5.1.5. Servidor Pentaho 3.6 ................................................................................... 43

5.2. Especificação da Implementação ........................................................................ 44

5.2.1. Método de Desenvolvimento ...................................................................... 44

5.2.2. Visão Geral ................................................................................................. 45

5.2.3. Base de Dados ............................................................................................ 47

ix

5.2.4. Spring Portlets ............................................................................................ 49

5.2.5. Portal Liferay .............................................................................................. 52

5.2.6. Pentaho - Business Intelligence .................................................................. 53

5.3. Resultados Alcançados ....................................................................................... 53

Capítulo 6

Conclusões e Trabalho Futuro ........................................................................................ 57

Referências ....................................................................................................................... 59

CONTEÚDO

x

xi

Lista de Figuras

Figura 1 – Evolução das Iniciativas de Mobilidade (Aberdeen Group, 2009) ........................................... 5 Figura 2 – Diagrama de Porter: Principais Influências no Mercado de Soluções de Mobilidade .............. 6 Figura 3 – Análise SWOT da Solução MRM .............................................................................................. 7 Figura 4 – Diagrama UML do Modelo Funcional .................................................................................... 14 Figura 5 – Exemplo de um Portal com Portlets ...................................................................................... 15 Figura 6 – Exemplo de um Dashboard.................................................................................................... 16 Figura 7 - Diagrama do Fluxo de Dados da Aplicação............................................................................. 18 Figura 8 - Diagrama da Arquitectura Física ............................................................................................ 19 Figura 9 - Modelo da Arquitectura Model-View-Controller (Oracle, 2010) ............................................ 21 Figura 10 – Arquitectura de Software da Aplicação (MVC) .................................................................... 22 Figura 11 – Tecnologias da Arquitectura do Software ........................................................................... 23 Figura 12 – Tecnologias e Linguagens Envolvidas nas Respectivas Camadas da Aplicação .................... 24 Figura 13 – Arquitectura da Spring MVC Framework 3.0 ....................................................................... 26 Figura 14 – Diagrama de Funcionamento do DispatcherServlet da Spring MVC .................................... 31 Figura 15 – Diagrama de Sequência do Processo de Funcionamento de Portlets .................................. 32 Figura 16 – Arquitectura do Liferay Portal ............................................................................................. 33 Figura 17 – Organização das Ferramentas da Pentaho BI Suite CE ........................................................ 35 Figura 18 – Arquitectura do Pentaho BI Platform (Pentaho Community, 2008) .................................... 36 Figura 19 – Exemplo do Interface Gráfico do MySQL Workbench .......................................................... 40 Figura 20 – Interface da SpringSource Tools Suite ................................................................................. 41 Figura 21 – Funcionalidades Instaladas no IDE da SpringSource Tool Suite ........................................... 42 Figura 22 – Página Inicial do Portal Liferay ............................................................................................ 43 Figura 23 – Página Inicial do Servidor da Plataforma Pentaho BI .......................................................... 44 Figura 24 – Modelo da Aplicação Web ................................................................................................... 45 Figura 25 – Arquitectura Geral da Implementação da Solução .............................................................. 46 Figura 26 – Modelo Relacional UML da Base de Dados OLPT ................................................................ 47 Figura 27 – Modelo e Funcionamento da Aplicação Web ...................................................................... 50 Figura 28 – Organização do Projecto no IDE .......................................................................................... 51 Figura 29 – Estrutura da Aplicação Web ................................................................................................ 52 Figura 30 – Demonstração do Portal e do Portlet Spring da Aplicação MRM ........................................ 55 Figura 31 – Demonstração do Tema do Portal Liferay para Smartphone ............................................... 55 Figura 32 – Demonstração de Painel de Indicadores Pentaho no Liferay .............................................. 56

LISTA DE FIGURAS

xii

xiii

Notação

a) O método de primeiro elemento e data do ISO 690 é o standard internacional

usado neste documento para especificar os elementos incluídos nas referências

bibliográficas;

b) «Nomenclatura adaptada» - identifica a nomenclatura adaptada ou traduzida de

nomes, termos, disciplinas, conceitos, etc. de língua estrangeira;

c) http://link/ - os endereços e ligações Web são apresentados em itálico;

d) Código de programação ou Directórios - o código ou nomes de programação,

os caminhos de directórios ou nomes de directórios são apresentados com o tipo de

letra Consolas (tamanho 10);

Acrónimos e abreviaturas utilizadas:

AOP – Aspect-Oriented Programming

API – Application Program Interface

CRM – Costumer Relationship Management

ERP – Enterprise Resource Planning

ETL – Extraction, Transformation and Loading

GIS – Geographic Information System

IDE – Integrated Development Environment

JSP – JavaServer Pages

OLAP – On-line Analytic Processing

OOP – Object-Oriented Programming

PDA – Personal Digital Assitant

RAM – Random Access Memory

SDK – Software Development Kit

TI – Tecnologias de Informação

URL – Uniform Resource Locator

NOTAÇÃO

xiv

1

Capítulo 1

Introdução

Este documento é elaborado no âmbito da Dissertação do Mestrado Integrado em

Engenharia Informática e Computação, da Faculdade de Engenharia da Universidade do Porto.

Esta introdução ao Dissertação inclui o seu enquadramento, a descrição do âmbito, os

objectivos e a organização do documento.

1.1. Enquadramento

As Tecnologias de Informação (TI) são uma imposição para as organizações que

pretendem competir no mercado. Se inicialmente, o papel das TI era essencialmente a

automatização dos processos operacionais das organizações, esse papel tem evoluído

consideravelmente. (Santos, et al., 2009) Neste momento, as TI, além do suporte aos processos

operacionais, permitem aumentar o conhecimento das organizações: sobre si própria; sobre as

entidades externas e sobre a sua capacidade de influência no mercado. (Santos, et al., 2009)

Actualmente, vários indicadores de mercado apontam para as tecnologias de mobilidade

como o próximo nível de infraestrutura das TI que suportam as organizações. A corroborar,

existem estudos de referência que indicam a importância e a tendência das tecnologias de

monitorização, navegação e dos dispositivos móveis nas organizações. Ainda, os indicadores

dos mesmos, apontam para um aumento considerável no investimento e na competição por

serviços baseados na localização. Tudo isto faz crer que a actual área em grande crescimento

das organizações é a área da gestão de recursos móveis em tempo real, o Mobile Resource

Management. (Intergraph Corporation, 2005)

Da mesma forma, o êxito das empresas depende de sistemas que apoiem a tomada de

decisão com base no conhecimento das empresas, através da informação obtida das TI. Onde

esse conhecimento é obtido através de processos e/ou tarefas de Business Intelligence.

Nesta Dissertação o conceito de Mobile Resource Management e de Business Intelligence

entendem-se da forma enunciada a seguir, no âmbito do mesmo.

1.1.1. Mobile Resource Management

O Mobile Resource Management (ou MRM) é definido como a capacidade de monitorizar

o progresso de recursos móveis em tempo real, com o objectivo de atribuir a tarefa correcta ao

recurso correcto, com o equipamento adequado, numa localização precisa, na hora certa.

(Intergraph Corporation, 2005)

Introdução

2

Um sistema MRM deverá saber onde estão os seus recursos móveis, onde eles estiveram e

onde eles devem estar, de forma a gerir eficazmente o volume de trabalho e a melhorar a

resposta dos recursos em função das exigências. (Intergraph Corporation, 2005)

1.1.2. Business Intelligence

O termo Business Intelligence (ou BI) tem sido adoptado para substituir a designação de

Sistemas de Suporte à Decisão. (Ramos, et al., 2009)

Os sistemas de BI dispõem de um conjunto de ferramentas analíticas para extracção de

informação relevante, a partir de dados armazenados. Estes sistemas melhoram a

disponibilidade e a qualidade da informação para a tomada de decisão. (Ramos, et al., 2009)

1.2. Descrição da Dissertação

Esta Dissertação consiste na concepção e teste de uma solução de MRM empresarial,

principalmente em termos da sua arquitectura e infraestrutura, para a gestão de tarefas e

colaboradores em tempo real capaz de incluir a monitorização dos colaboradores com recurso à

georreferenciação, a par da troca de informação técnica associada a um cenário empresarial.

Ainda, a aplicação deve permitir a modularização dos dados obtidos para uma vertente de

Business Intelligence.

A Dissertação foi proposta pela Capgemini Portugal, Serviços de Consultadoria e

Informática, S.A. e desenvolvido em Lisboa, nas suas instalações.

1.3. Objectivos e Resultados Esperados

Concepção de uma aplicação empresarial capaz de responder aos requisitos e

funcionalidades descritos no ponto 1.1;

Recorrer exclusivamente a tecnologias de Código Aberto;

Estudar diferentes tecnologias capazes de integrar uma solução;

Provar a capacidade e a interoperabilidade das tecnologias de Código Aberto

escolhidas para a solução.

1.4. Organização do Documento

Para além da introdução, esta dissertação contém mais 5 capítulos. No capítulo 2, é

descrito o estado da arte onde, além do enquadramento no mercado, é feita a análise das

soluções no mercado e dos aspectos inovadores desta Dissertação. No capítulo 3, é descrita a

arquitectura do sistema que incluí a análise funcional e a apresentação das tecnologias por cada

camada da arquitectura. No capítulo 4, é apresentado o estudo das frameworks de

desenvolvimento. No capítulo 5, é descrito o ambiente de desenvolvimento, a sua configuração

e as especificações e opções da implementação. No capítulo 6, é feita a discussão do trabalho

desenvolvido e apresentação do trabalho futuro.

3

Capítulo 2

Estado da Arte

Este estudo do Estado da Arte tem como objectivo principal identificar as últimas soluções

e tecnologias utilizadas para implementar soluções de mobilidade empresarial.

Para uma melhor percepção do Estado da Arte, e em primeiro lugar, é necessário definir o

enquadramento da aplicação. Assim, na secção 2.1, é analisado o Mercado Actual e é definido o

Mercado Alvo da aplicação.

Nas secções 2.2 e 2.3, é apresentado o ambiente de competição onde se insere a aplicação

MRM, as oportunidades e a análise do grau de interesse deste tipo de aplicações.

Nas secções 2.4 e 2.5, são definidas as características gerais que uma solução de

mobilidade empresarial deve ter e as plataformas que podem suportar aplicações do tipo.

Por fim, nas duas últimas secções, são identificadas as soluções apresentadas pelas

principais empresas do ramo, entre outras existentes no mercado, e identificados os aspectos

inovadores que se pretenderam incluir nesta Dissertação.

2.1. Avaliação do Mercado

Esta avaliação do Mercado é feita com o estudo da sua segmentação actual do tecido

empresarial português e a caracterização do Mercado Alvo.

2.1.1. Segmentação Actual

Na estrutura empresarial portuguesa as PME representam 99,6% das unidades empresariais

criando cerca de 3/4 dos empregos privados e realizam mais de metade dos negócios em

Portugal. (IAPMEI, 2008)

Dentro desta classe dimensional encontram-se empresas dos mais diversos sectores de

mercado com necessidades distintas. Deste mercado pretende-se identificar um segmento

essencialmente caracterizado pela necessidade de gestão de recursos móveis. Assim, com base

nos sectores de mercado existentes (Ministério da Ecónomia e da Inovação), destacam-se os

sectores de Comércio e Distribuição, Serviços e Transportes.

Se observarmos o retrato sectorial do país, as perspectivas de atractividade deste segmento

são animadoras. Só os sectores de Comércio e Serviços representam cerca de 3/4 das unidades

empresariais em actividade, geram mais de metade dos empregos privados em Portugal e

aproximadamente 2/3 dos negócios do país. Em particular, o sector de Serviços gerava em 2005

mais de 1/4 dos empregos privados, sendo o principal sector empregador em Portugal. Sendo

também, este último, o sector que mais cresceu em Portugal entre os anos 2000 e 2005.

(IAPMEI, 2008) Representando em 2009, 3/4 do Valor acrescentado bruto e 60,5% do emprego.

Estado da Arte

4

(AICEP , 2010) Em suma, os sectores económicos que mais crescem e com maiores

perspectivas de crescimento são os que constituem o segmento de mercado identificado.

A identificação da necessidade de soluções MRM à medida para um segmento de mercado

crescente e desta dimensão, justifica a necessidade da solução que se pretende desenvolver.

2.1.2. Caracterização do Mercado Alvo

Dos sectores de Comércio e Distribuição, Serviços e Transportes, pretende-se desenvolver

uma solução para pequenas e médias empresas que sigam as tendências da evolução da

mobilidade empresarial, que necessitem de gerir tarefas e mobilidade de colaboradores em

tempo-real de forma optimizada, independentemente do grau de informatização da sua

actividade. Contudo, pode-se ainda enquadrar serviços ligados ao sector público.

Assim, o mercado alvo caracteriza-se pelas seguintes necessidades:

Gestão de mobilidade de colaboradores em tempo-real;

Gestão de tarefas em função, ou não, do posicionamento geográfico dos colaboradores

em tempo-real;

Monitorização do posicionamento de colaboradores;

Processos de gestão optimizados;

Análise da eficácia da gestão de colaboradores e tarefas optimizada;

Análise da eficiência e eficácia de colaboradores;

Baixos custos de aquisição e implementação de soluções integradas;

Soluções integradas capazes e preparadas para acompanhar a evolução das tecnologias

com baixos custos.

No Sector do Comércio e Distribuição e no Sector de Serviços serão essencialmente

grossistas dos mais variados ramos (retalho e bens de consumo, tabaco, informática, gás, pneus,

etc.) ou empresas de comércio com serviço de distribuição/entrega e empresas prestadoras de

serviços ao domicílio (reparações, assistência técnica, instalação de equipamentos, limpeza,

etc.).

2.2. Ambiente da Industria

Nesta secção é focado o ambiente empresarial onde se insere a Dissertação.

2.2.1. Tendências e Previsões do Mercado

O sector das organizações de TI pode ser afectado, essencialmente, por tendências

económicas e tecnológicas.

Poderia esperar-se que as empresas, face à corrente crise económica, apresentassem uma

redução no orçamento nos seus planos de mobilidade. Mas, pelo contrário, as empresas

mantiveram-se fiéis aos seus planos de mobilidade ou tornaram os planos ainda mais

ambiciosos. Segundo pesquisas feitas por empresas independentes, a mobilidade empresarial é o

futuro mais previsível e torna-se cada vez mais uma vantagem competitiva no panorama do

mercado actual. (E-Commerce Times, 2009)

Os dados indicam que as empresas com mais sucesso no seu plano de mobilidade

conseguiram até 40% mais de produtividade nos colaboradores, 35% na satisfação dos clientes

e, inclusive, 25% na retenção de empregos. Agilidade, flexibilidade e velocidade de resposta,

são benefícios que qualquer organização que compita no mercado quer atingir. (E-Commerce

Times, 2009)

Contudo, apesar do elevado interesse nestes benefícios, há sempre um esforço contínuo

para redução de custos nos seus planos, o que resulta, por exemplo, em reduzir o orçamento

para dispositivos (cada vez mais evoluídos e dispendiosos) e, consequentemente, recorrer a

Estado da Arte

5

dispositivos pessoais dos próprios colaboradores para trabalho. Esta estratégia faz com que os

dispositivos, actores do sistema, não sejam normalizados e haja uma migração dos serviços de

manutenção internos para serviços outsource. (E-Commerce Times, 2009) Consequentemente,

esta estratégia de poupança, levanta questões de segurança, risco e responsabilidade para as

empresas.

A constante evolução tecnológica, por um lado, obriga as empresas a adoptar estratégias

que aumentam os custos de adaptação dos seus sistemas, os custos com dispositivos roubados

ou por intrusão. São estratégias que, além de atingirem a contabilidade, podem levantar questões

de legitimidade. Por outro lado, a evolução responde com soluções que minimizam estas

desvantagens, como protocolos eficazes na segurança da rede, VPN e encriptação de dados on-

device. (E-Commerce Times, 2009) Assim, para atenuar os riscos da constante evolução e

crescimento das TI, as empresas de maior sucesso exigem aos seus empregados o cumprimento

das normas de segurança, autenticação e acesso.

Esta análise das tendências e previsões de mercado é baseada no estudo “More Mobility –

Less Budget: The 2009 Enterprise Mobility Benchmark” (Aberdeen Group, 2009) pela

Aberdeen Group e é, na sua essência, corroborada pelo estudo mais recente “Enterprise

Mobility Strategies 2010” (Aberdeen Group, Dezembro 2009) realizado pela mesma empresa.

2.2.2. Atractividade do Mercado

Ainda no estudo “More Mobility – Less Budget: The 2009 Enterprise Mobility

Benchmark” (Aberdeen Group, 2009) da Aberdeen Group, foi apresentado o resultado de um

inquérito ilustrativo da atractividade do mercado de soluções de mobilidade empresariais. Nesse

inquérito, foi verificado um aumento de 42%, em relação ao inquérito anterior, nos inquiridos

que responderam que têm iniciativas de mobilidade em curso e uma descida de 93% nos que

responderam que não tinham nenhuma iniciativa do tipo (Figura 1). (E-Commerce Times, 2009)

Figura 1 – Evolução das Iniciativas de Mobilidade (Aberdeen Group, 2009)

Neste ponto, também é importante analisar o contexto do mercado das soluções de

mobilidade. Assim, com uma Análise de Porter pretende-se perceber quanto o contexto pode

afectar a atractividade deste mercado.

Poder negocial dos fornecedores: no ramo das TI pode existir alguma pressão dos

fornecedores de hardware ou dispositivos necessários à implementação das soluções de

mobilidade, depende da existência de restrições impostas ao nível das plataformas a utilizar.

Ainda derivado dessas restrições, existe ainda o factor das empresas fornecedoras de software

licenciado a integrar numa solução de mobilidade.

Estado da Arte

6

Poder negocial dos clientes: na conjuntura actual os clientes podem estar sensíveis ao

preço da implementação de TI. Influência da dimensão do cliente e da solução a implementar.

Por outro lado, existe um número considerável potenciais clientes no mercado e a necessidade

soluções de mobilidade é cada vez maior.

Ameaça de substitutos: empresas com menor fundo de maneio podem optar por

aplicações normalizadas para colmatar apenas as suas necessidades básicas de mobilidade.

Contudo, as empresas com iniciativas de mobilidade em curso, dificilmente mudarão o seu

plano pois, os custos associados à mudança deste tipo de soluções são muito elevados.

Ameaça de novas entradas: as necessidades de investimento e o capital vultuoso para o

arranque de uma actividade neste ramo são, talvez, a principal barreira à entrada de novos

substitutos. Os clientes fidelizam-se às actuais empresas competidoras por preferência ou por

diferenciação das soluções e o respectivo suporte.

Rivalidade entre concorrentes: No mercado global, não existe nenhuma empresa

dominante. Contudo, a rivalidade é atenuada pela dimensão do mercado que é muito grande e

pela diferenciação das soluções de mobilidade entre as empresas competidoras.

Em baixo, na Figura 2, é possível observar o respectivo diagrama de Porter.

Figura 2 – Diagrama de Porter: Principais Influências no Mercado de Soluções de Mobilidade

2.2.3. Análise SWOT

Assumindo a total capacidade interna para a execução do projecto, podemos concluir a

Análise dos Sectores de Negócio com a Análise SWOT da solução MRM estudada e

desenvolvida.

Pontos Fortes

Recurso a apenas tecnologias de Código Aberto normalizadas;

Baixo custo;

Independência da tecnologia de Base de Dados;

Estado da Arte

7

Inclusão de uma componente de Apoio à Decisão na solução, através de uma

plataforma e ferramentas de Business Intelligence.

Pontos Fracos

Não é uma solução integrada para uma cadeia de negócio completa;

Os serviços disponibilizados na solução podem ser considerados limitados (ex.:

não tem serviços do tipo Context-aware).

Oportunidades

Crescimento do mercado de aplicações de mobilidade empresarial;

Identificação de um Mercado Alvo com défice de soluções à medida.

Ameaças

Adopção da mesma estratégia e das mesmas tecnologias por parte da concorrência;

Empresas de menor dimensão que ofereçam soluções com custos ainda mais

reduzidos;

Soluções de custos reduzidos em detrimento da qualidade e fiabilidade.

Em baixo, na Figura 3, é possível observar a matriz da análise SWOT apresentada.

Figura 3 – Análise SWOT da Solução MRM

2.3. Soluções de Mobilidade Empresarial

As soluções de mobilidade empresarial podem integrar plataformas de colaboração móvel

ou simples serviços de informação contextualizada, permitem comunicação por vídeo, voz e

texto.

Na sua generalidade, as soluções de mobilidade fazem a captura, tratamento e visualização

de informação contextual de processos de negócio em tempo real. Esta informação

contextualizada pode ser, por exemplo, a localização de um bem móvel, o seu estado (ex.: em

movimento ou não), as suas condições de conservação (ex.: temperatura e pressão) ou a

localização de uma pessoa e respectiva disponibilidade.

Assim, com as actuais tecnologias é possível implementar aplicações de mobilidade

empresarial que permitem responder aos mais variados tipos de necessidades, tais como:

Estado da Arte

8

Inserção e actualização de informação no imediato - Sincronização;

Suporte à decisão em tempo real;

Georreferenciação;

Planeamento e escalonamento de actividades;

Optimização de actividades;

Inventariação de bens através de sistemas de código de barras/RFID no terreno;

Facturação on-site;

Integração em soluções empresariais;

Gestão e auditoria completas;

Segurança.

2.4. Plataformas de Desenvolvimento de Aplicações Móveis

Existem várias plataformas para o desenvolvimento de aplicações de mobilidade. Contudo,

a escolha da plataforma de desenvolvimento deve ser bem decidida de acordo com a

especificação da implementação ou com a predominância no mercado ou ainda com base numa

aposta na tendência do mercado. Por norma, as plataformas não são compatíveis entre si e cada

dispositivo móvel apenas suporta uma plataforma específica, com a possível excepção do Java

ME.

As principais plataformas que suportam dispositivos de diferentes fabricantes são:

Java ME;

Symbian;

Android;

.NET Compact Framework;

Windows Mobile e Windows Phone;

Palm OS.

Destinadas apenas a um fabricante, existem as plataformas BlackBerry, iPhone OS (iOS) e,

mais recentemente, a Samsung Bada e Nokia MeeGo, uma evolução do Nokia Maemo.

2.5. Soluções no Mercado

Todas as grandes empresas de Consultadoria e/ou de Tecnologias de Informação, com

mais ou menos ênfase, apresentam soluções de mobilidade para responder às diferentes

necessidades empresariais.

De seguida, são apresentadas as características das soluções de mobilidade empresarial

apresentadas por algumas das maiores empresas do ramo: HP, IBM & Cisco, CSC e Accenture.

Depois, serão apresentadas as soluções das empresas encontradas no mercado português, Sinfic

e Geoglobal, que apresentam, com mais detalhe, soluções muito próximas da solução que se

pretende desenvolver.

HP A HP apresenta a capacidade de desenvolver soluções móveis optimizadas para os

diferentes tipos de dispositivos móveis (PDA, smartphone, etc.). Esta oferta pode também ser

completada com recurso a Sistemas de Informação Geográfica (GIS). Assim, a HP apresenta

soluções capacitadas de tecnologias de identificação automática, incluindo código de barras,

imagens, RFID e serviços baseados em localização, tais como GPS e sistemas de localização em

tempo real. (HP, 2010)

Estas tecnologias são usadas tipicamente para aplicações de Acompanhamento e Gestão,

Gestão de cadeias de fornecimento, Logística, Gestão de Processos e Segurança. (HP, 2010)

Estado da Arte

9

IBM & Cisco A IBM e a Cisco formaram uma aliança com o objectivo de integrar os seus processos de

negócio, conhecimento da indústria, tecnologias de informação e trabalho em rede. (Cisco,

2010)

Esta aliança, sem referência a um produto concreto ou solução com um fim específico,

apresenta a capacidade de desenvolver soluções de mobilidade empresarial com base em três

componentes: serviços Mobility User, Motion Network e Borderless Access. (Cisco, 2010)

Pretendem assim que as suas soluções de mobilidade permitam a captura e integração

dinâmica de informação contextual em processos de negócio em tempo real. (Cisco, 2010) Com

base nas tecnologias associadas aos componentes Mobility User e Borderless Access (Wi-Fi,

VPN, Voip, Cloud-based services, etc.), a ideia consiste em permitir os colaboradores e clientes

comunicarem e partilharem dados entre si de forma segura, independentemente da sua

localização, dispositivo ou aplicação/plataforma a usar. Ainda, as tecnologias envolvidas na

componente Motion Network permitem, essencialmente, serviços de Localização Context-

aware. (Cisco, 2010) Estes serviços recorrem às tecnologias da rede para localizar os

dispositivos móveis e dinamizar essa informação com informação contextualizada através de

Presence Applications. Com base neste serviço, é possível actualizar e saber o estado de um

colaborador em tempo real com base na sua localização e as regras definidas pelo utilizador. Por

exemplo, se um colaborador saiu da cafetaria para ir para uma reunião, ao entrar na sala de

reuniões o estado do colaborador no seu dispositivo passará para ocupado de acordo com o seu

contexto (ex.: reunião) e o seu dispositivo será automaticamente configurado para modo

silencioso. Consequentemente, na tentativa de comunicação com este colaborador, visto que

este está ocupado (em reunião), o sistema poderá permitir, no contexto, reencaminhar a

chamada para um colaborador alternativo que esteja disponível. (Cisco, 2010)

CSC A CSC apresenta a solução Mobile Enterprise como um sistema modular e completo com

o objectivo de facilitar a adaptação das soluções de mobilidade às diferentes indústrias e

respectivas necessidades. O seu sistema pretende integrar aplicações empresariais (incluindo

integração com sistemas ERP, CRM, etc.) e de produtividade de acordo com os papéis nas

empresas. Assim, o sistema está diferenciado em duas partes: Mobile Worker e Mobile

Executive. (CSC, 2010)

A solução Mobile Worker não é dependente de uma única plataforma, é compatível com

diversos tipos de dispositivos móveis: PDA, BlackBerry, Notebook, etc. A solução pode

também recorrer aos mais diversos dispositivos de acordo com necessidades específicas: RFID,

leitura de Código de Barras, GPS, GIS, vídeo e voz. O que possibilita desenvolver diferentes

soluções industriais: gestão de armazéns, gestão de turnos e inspecções, monitorização e gestão

de tarefas e recursos, gestão de workflows, serviços de pontos de entrega com ordens de compra

e/ou venda, etc. (CSC, 2010)

Com foco nas necessidades de gestores de negócio em constante movimento, a CSC

apresenta a solução Mobile Executive que fornece serviços baseados nas necessidades de

trabalho remoto. Tal como a solução anterior, é compatível com diversos dispositivos móveis.

Através dos quais dispõe de diversas funcionalidades, tais como: ferramentas de gestão de

informação pessoal (email, calendário, tarefas, etc.), assim como acesso a uma plataforma que

possibilita o acesso a aplicações empresariais (ERP, CRM, etc.). (CSC, 2010)

Accenture A Accenture como empresa de tecnologias de informação, consultadoria e outsourcing

oferece soluções móveis e todo um conjunto de serviços de apoio de forma a maximizar a sua

implementação, o seu uso e a sua aceitação no contexto empresarial. Dispõe também de um

Innovation Center for Open Source, significado da crescente importância das tecnologias Open

Source.

As soluções da Accenture são apresentadas de uma forma genérica, sem identificar

aplicações, funcionalidades ou recursos específicos. Apresenta as soluções sob a forma de

serviços e as ferramentas de desenvolvimento de aplicações móveis. Assim, Accenture pretende

Estado da Arte

10

desenvolver aplicações móveis inovadoras e à medida começando, em primeiro lugar, por uma

estratégia de mobilidade empresarial (Mobile Enterprise Strategy). Depois, para reduzir a

complexidade, o custo e o tempo de desenvolvimento associado com o desenvolvimento deste

tipo de soluções, apresenta uma Framework de arquitectura para aplicações Windows Mobile

com suporte para múltiplos utilizadores (Avanade Connected Arquitecture) e uma ferramenta

para iPhone de gestão de aplicações móveis e integração com armazéns de dados (Enterprise

iPhone Toolbox). (Accenture, 2010) As restantes soluções apresentadas são serviços através de

plataformas da Accenture ou serviços hospedados na Accenture que se desviam bastante do tipo

de solução que se pretende desenvolver. (Accenture, 2010)

Das tecnologias utilizadas para o desenvolvimento das soluções empresariais, a Accenture

apresenta ainda soluções baseadas em Open Source Software (OSS), mostra o crescente

interesse da adopção por parte de organizações de Tecnologias de Informação e destaca a

vantagem de baixos custos de licenciamento e manutenção. (Accenture, 2010) Através do

Accenture Innovation Center for Open Source, a Accenture pretende criar a possibilidade dos

seus clientes comprovarem funcionamento de soluções Open Source em ambientes simulados,

avaliados e testados pelo Centro. (Accenture, 2010) Assim, a Accenture definiu arquitecturas

comprovadas que contêm tecnologias Open Source para as áreas que mais podem beneficiar:

arquitecturas do tipo Service-oriented (SOA), Server virtualization, Portais Web, Gestão de

conteúdos e dados, Business Intelligence (BI) e Aplicações Web. (Accenture, 2010)

Sinfic A Sinfic apresenta soluções de mobilidade integradas e automatizadas, com tratamento de

informação em tempo real. A sua oferta pretende assegurar a optimização de todo o processo de

uma cadeia de valor de uma organização, desde a produção e armazenamento, até à venda e

distribuição. (Sinfic, 2010)

Próximo da solução MRM que se pretende desenvolver, apresentam sistemas de gestão e

optimização de rotas, consumos e posicionamento, gestão de tarefas (definindo perfis de

clientes, perfis de técnicos, prioridades, etc.), gestão de stocks globais e individuais e gestão de

mensagens. (Sinfic, 2010)

Geoglobal A Geoglobal apresenta nos seus serviços o GeoMob, uma solução de gestão e controlo de

bens e recursos móveis. (Geoglobal, 2010) A solução destina-se essencialmente à logística.

Permite o rastreio de todas as encomendas a entregar, integrando em tempo real toda a

informação das operações de distribuição. (Geoglobal, 2008)

A solução GeoMob recorre a tecnologias de comunicação GPRS e Wi-fi associadas a

tecnologias de GPS para localização e monitorização de frotas. Utiliza ainda a leitura de códigos

de barras e RFID para identificação de operações, objectos, intervenientes e locais. (Geoglobal,

2008)

2.6. Aspectos Inovadores

Face ao Estado da Arte, os aspectos inovadores e de diferenciação da solução especificada

e implementada incluem os seguintes:

Tecnologia – o recurso exclusivo a tecnologias de Código Aberto normalizadas permite

desenvolver soluções aplicacionais estáveis e modulares, disponíveis para diferentes áreas de

negócio e acessíveis a pequenas e médias empresas.

Simplicidade – a solução pretende optimizar as operações empresariais em tempo real de

forma simples e escalável. Ao se eliminar as funcionalidades pesadas das soluções comuns

pretende-se explorar um Mercado Alvo bem definido. Além disso, pretende-se adoptar uma

comunicação entre Front Office e Back Office eficiente que, em conjunto com as tecnologias, irá

optimizar os custos de operação sem prejudicar a optimização das operações.

Estado da Arte

11

Reforço da decisão – integração de uma forte componente de Business Intelligence que irá

permitir a análise dos dados gerados pelo sistema, com todas as potencialidades associadas.

Dadas as soluções presentes no mercado, o tipo e o Mercado Alvo da solução que se pretende

desenvolver, a integração e inclusão deste módulo torna-a, sem dúvida, uma solução/aplicação

inovadora.

Estado da Arte

12

13

Capítulo 3

Arquitectura do Sistema

A Arquitectura do Sistema é o modelo conceptual que define a estrutura, comportamento e

a funcionalidade do sistema.

Este capítulo inicia-se com a Visão Geral do sistema onde é apresentada uma divisão

lógica do mesmo. De seguida, é apresentada a Análise Funcional do Sistema, onde são

identificadas as suas funcionalidades e comportamento.

Na secção 3.3, são identificados os componentes físicos que podem suportar o sistema.

Na secção 3.4, é apresentado o modelo da arquitectura de software utilizada e só depois a

representação da arquitectura solução baseada no modelo apresentado.

Este capítulo termina com a identificação das tecnologias e o seu enquadramento na

arquitectura de software apresentada.

3.1. Visão Geral

O desenvolvimento do sistema é dividido em 4 módulos funcionais:

Back Office – Módulo de gestão de tarefas e colaboradores: responsável pelo

(re)planeamento e (re)escalonamento de tarefas;

Front Office – Módulo da interacção dos colaboradores com o sistema: comunicação

e troca de dados do negócio em tempo real;

BI – Módulo de extracção e transformação de dados da componente de Apoio à

Decisão (Business Intelligence);

Administração – Módulo de gestão e administração de utilizadores e configuração do

sistema.

O respectivo diagrama UML do Modelo Funcional apresenta-se na Figura 4 (incluindo as

suas dependências). No modelo apresentado, o Front Office depende da actividade do módulo

de Back Office. O módulo da Administração opera através do módulo de Back Office. O módulo

de BI opera sobre os dados recolhidos no Back Office.


14

Figura 4 – Diagrama UML do Modelo Funcional

3.2. Análise Funcional do Sistema

A Análise Funcional descreve o comportamento do sistema através da definição das suas

funções e especificação dos componentes da aplicação.

3.2.1. Definições

Antes de se iniciar a Análise Funcional é necessário definir conceitos importantes para a

correcta compreensão do sistema que se pretende analisar.

Portal Um portal consiste num grupo de páginas Web que estão, por norma, associadas a

utilizadores, cujo acesso, organização e permissões é gerido por um conjunto de utilizadores-

administradores desse portal.

Actualmente e por norma, todos os Portais suportam páginas Web dinâmicas que são

constituídas por uma ou mais janelas. Cada janela contém um ou mais Portlets. Por sua vez, um

Portlet tem associado uma lógica de negócio do lado do servidor e uma interface do lado do

cliente.

Portlet Portlets são componentes orientados à Web que disponibilizam conteúdos dinâmicos. Os

Portlets são suportados em páginas Web dinâmicas e, devido ao facto de terem especificações

padrão de desenvolvimento (na especificação Java EE), são reutilizáveis e portáveis. Esta

característica fez com que os Portlets ganhassem bastantes adeptos no desenvolvimento de

portais para a Web. (Oracle) Na Figura 5 é possível visualizar um exemplo de Portlets num

portal.


15

Figura 5 – Exemplo de um Portal com Portlets

Business Intelligence Os sistemas de Business Intelligence (BI) pretendem melhorar a disponibilidade e

qualidade da informação gerada por um sistema. Para tal é necessário conjugar dados com um

conjunto de ferramentas analíticas de forma a se obter informação relevante para a tomada de

decisão.

Os sistemas de BI extraem informação útil através de ferramentas de análise, a partir de

dados recolhidos das operações do sistema que integram. As tarefas associadas ao BI e à

respectiva gestão do conhecimento, são:

Análise dos dados históricos e actuais da organização para elaboração de previsões;

Criação de possíveis cenários na introdução ou alteração de variáveis;

Permitir a análise e o acesso a dados para responder a questões não predefinidas;

Análise detalhada da organização (aprofundamento do conhecimento).

Dashboard Dentro do conceito de BI existem vários conceitos importantes mas, dada a extensão do

tema, o enfoque da Dissertação foi restringido à integração da componente de BI num sistema

MRM. Como tal, o conceito mais relevante é o de dashboard.

Um dashboard pode ser traduzido como um «Painel de Indicadores». Em BI, os

indicadores são o resultado das tarefas de análise dos dados através de ferramentas analíticas

adequadas. Os indicadores são normalmente representados por diferentes tipos de gráficos. Por

sua vez, os tipos de gráficos têm que ser adequados aos dados que se pretendem apresentar

como indicador.

Assim, um dashboard pode ser definido como um conjunto de gráficos/indicadores

resultantes dos processos de análise de dados associados ao BI, com o objectivo de apoiar a

tomada de decisões. Na Figura 6 é possível visualizar um exemplo de um dashboard constituído

por Portlets.


16

Figura 6 – Exemplo de um Dashboard

Deslocação, Movimento, Percurso O sistema MRM descrito centra-se nos conceitos de deslocação, movimento e percurso.

Uma deslocação tem sempre associada a si um local georreferenciado (uma coordenada de

GPS), uma ou mais tarefas a executar nesse local e um ou mais recursos necessários para a sua

execução.

Se duas deslocações forem representadas como dois pontos num mapa, um movimento

será a linha que une esses dois pontos. Ou, por outras palavras, um movimento num mapa

georreferenciado interessa apenas o ponto de partida e o ponto de chegada, independente do

trajecto adoptado para chegar do inicial ao final.

Assim, um percurso será um conjunto de movimentos cujos pontos de chegada são iguais

aos pontos de partida do movimento seguinte, excepto no caso do primeiro e último movimento

de um percurso.

Estes conceitos foram elaborados aquando da concepção do modelo relacional da base de

dados. A dissecação de percursos em movimentos e movimentos em deslocações foi a solução

encontrada mais eficaz para persistir os dados necessários.

3.2.2. Actores

Os principais actores do sistema incluem:

Utilizador não autenticado – Utilizador não registado ou que ainda não efectuou a

autenticação no sistema. Não possui qualquer tipo de permissões de acesso ao sistema a não ser,

o acesso à página inicial do portal e ao formulário de autenticação.

Operacional – Utilizador registado e autenticado no sistema, com permissões de acesso

através de um portal Web ou aplicação para dispositivos móveis. Considerados os utilizadores

de Front Office, terão acesso à informação relativa à sua actividade e ao preenchimento de

pequenos relatórios pré-definidos.

Operador – Utilizador registado e autenticado no sistema, com permissões de acesso

através de um portal Web. Considerados os utilizadores de Back Office, podem consultar e gerir


17

os recursos da organização de acordo com as funcionalidades do sistema e lógica do contexto

empresarial.

Administrador – Utilizador registado e autenticado no sistema com permissão total sobre

todas as suas funcionalidades tais como, efectuar operações relativas à gestão de utilizadores e

manutenção do sistema.

3.2.3. User Stories

As User Stories são uma definição de alto nível dos requisitos do sistema. Faz parte das

metodologias ágeis de desenvolvimento de software, mais especificamente da metodologia

Extreme Programming (XP) e desempenha um papel importante no planeamento da

implementação. (Wells, 2010)

Segue-se a apresentação das User Stories do sistema, cada ponto corresponde a uma única

User Story e pode representar um requisito funcional ou não funcional:

Os utilizadores não autenticados no sistema têm que se autenticar obrigatoriamente.

Os utilizadores autenticados podem configurar os seus dados de acesso ao sistema.

Os utilizadores autenticados podem alterar os seus dados pessoais.

Os utilizadores podem consultar os dados de Business Intelligence desde que lhes seja

dada permissão por um Administrador.

As deslocações devem ser atribuídas de acordo com parâmetros de optimização.

As deslocações devem ser geridas apenas através do Back Office por um Operador ou,

sempre que possível, automaticamente pelo sistema.

Os Operadores podem gerir operacionais, tarefas, deslocações e percursos.

Os Operadores podem atribuir percursos constituídos por deslocações a operacionais.

Os Operadores devem certificar-se que as tarefas são associadas a deslocações e

atribuídas a operacionais cumprindo os requisitos estabelecidos para o efeito, quer

sejam atribuídas por si ou automaticamente pelo sistema.

Os Operadores terão acesso a um Sistema de Informação Geográfica para efeitos das

suas operações.

Os Operadores podem elaborar relatórios de anomalias da operação do sistema.

Os Operacionais terão acesso ao sistema através dos seus dispositivos móveis.

Os Operacionais terão acesso aos percursos pré-estabelecidos e calculados, associados

aos seus Planos de Tarefas do dia.

Os Operacionais poderão visualizar os percursos em dispositivos móveis apropriados.

O trajecto a percorrer entre as deslocações de um percurso será calculado pelo próprio

dispositivo do Operacional, apropriado para o efeito.

Os Operacionais não podem gerir os seus Planos de Tarefas.

Os Operacionais, após uma deslocação, podem preencher individualmente um Relatório

de Execução de Tarefas atribuídas a si para aquela deslocação.

Os Operacionais podem elaborar pequenos relatórios ou actualizar o seu estado de

acordo com eventuais problemas ou reparos relacionados com a sua actividade.

Os Administradores podem modificar todas as configurações do sistema e operar com

todas as funcionalidades no mesmo.

3.2.4. Fluxo de Dados

Na Figura 7 é apresentado o Diagrama de Fluxo de Dados do Sistema onde é possível

verificar a lógica do funcionamento, a ordem das operações e as funcionalidades do sistema.

Com o objectivo de facilitar a percepção do funcionamento do sistema, no Diagrama de

Fluxo de Dados referido só está representado a persistência dos objectos do tipo Tarefa através


18

do mapeamento objecto-relacional para a base de dados. Contudo, todos os dados gerados pelas

actividades do sistema ou recolhidos pelo sistema são mapeados e persistidos em base de dados.

Os Operadores de Back Office introduzem no sistema as tarefas a executar. Após essa

introdução, o sistema deve fazer o planeamento e o escalonamento das tarefas segundo critérios

de prioridade e disponibilidade dos recursos necessários à sua execução. As tarefas são

associadas a deslocações que vão constituir os percursos a efectuar pelos Operacionais durante

um dia. Após o planeamento e o cálculo dos percursos, o sistema atribui os mesmos aos

Operacionais, constituindo o Plano de Tarefas a ser executado no dia. Os Operacionais

preenchem Relatórios de Execução de Tarefas no final da execução das tarefas associadas a uma

deslocação. A actualização da localização dos colaboradores é feita aquando da submissão dos

referidos relatórios ou aquando da actualização do estado do colaborador.

Na componente de BI, através da respectiva plataforma e com recurso a ferramentas

analíticas faz-se a selecção dos dados relevantes da Base de Dados Operacional (BD OLPT)

(dados gerados e recolhidos pelo sistema). Faz-se também a respectiva modelação e

armazenamento numa Data Warehouse através de um processo de ETL. Depois procede-se à

construção e apresentação dos dashboards com todos os indicadores pretendidos.

Figura 7 - Diagrama do Fluxo de Dados da Aplicação

3.3. Arquitectura Física

Na

Figura 8 é apresentado a estrutura física de alto nível do sistema a desenvolver, o

Diagrama da Arquitectura Física.


19

Figura 8 - Diagrama da Arquitectura Física


20

Os principais intervenientes incluem os seguintes:

Dispositivo móvel – pode ser Tablet PC, PDA, smartphone ou outro dispositivo móvel

capaz de suportar as funcionalidades pretendidas para os Operacionais através do Portal.

Computadores pessoais – máquina a partir do qual é possível aceder ao sistema e operar

no mesmo de acordo com o tipo de utilizador e as funções designadas ao mesmo. Não

necessariamente apenas a partir da intranet mas também, a partir da rede externa.

Servidor Web – máquina onde será alojada a aplicação ou plataforma do sistema.

Servidor de Base de Dados – máquina onde será alojada a Base de Dados necessária ao

funcionamento do sistema.

3.4. Arquitectura do Software

3.4.1. Modelo da Arquitectura

Sendo um dos requisitos a garantia de uma aplicação empresarial completamente de

Código Aberto, foi decidido que toda a Arquitectura do Software deveria assentar sobre

plataforma Java.

Esta opção foi feita com base na necessidade da interoperabilidade e compatibilidade entre

diferentes frameworks e com a eventual necessidade de integração com outros sistemas. Além

disso, para integrar esta solução foram estudadas as melhores ferramentas, frameworks e

plataformas de Código Aberto para integrar a solução. Após esse estudo, concluiu-se que o

conjunto de frameworks e plataformas seleccionadas são todas desenvolvidas com tecnologias

Java. Desta forma, faz todo o sentido orientar e adequar a Arquitectura de Software à plataforma

Java EE.

Assim, tratando-se de uma aplicação empresarial em Java e orientada à Web, a plataforma

é necessariamente a Java Platform, Enterprise Edition (Java EE). Além desta, existe ainda a

Java Platform, Standard Edition (Java SE), a Java Platform, Micro Edition (Java ME) e a Java

FX. (Oracle, 2010)

A plataforma Java EE foi construída sobre a plataforma Java SE. Assim, a plataforma Java

EE além das funcionalidades da Java SE (desde classes básicas a classes de alto nível utilizadas

para redes, segurança, acesso a base de dados, interfaces gráficas e XML parsing), disponibiliza

uma API e um runtime environment para o desenvolvimento de aplicações empresariais de

grande escala, multi-tiered (com áreas funcionais separadas em camadas chamadas tiers),

escaláveis, estáveis e seguras. (Oracle, 2010)

A plataforma Java EE está concebida de forma a dar completa liberdade no desenho de

arquitecturas de aplicações empresariais. Embora isso permita utilizar os componentes da

plataforma ao gosto do arquitecto da aplicação, nem sempre as opções tomadas são as mais

benéficas para o sistema onde será integrada. O arquitecto do sistema pode até encontrar

situações em que ele próprio tenha dificuldade em decidir sobre a opção que optimiza a robustez

e a eficiência da aplicação. Para colmatar as falhas que poderão surgir desta liberdade, a Sun

(agora Oracle) criou o programa Java Blueprints. Este programa constitui um guia com

exemplos concretos para que os programadores e arquitectos de sistemas sobre a Java EE

saibam maximizar as suas vantagens, assim como identificar os modelos de arquitectura e de

programação que melhor se adequam ao tipo de desenvolvimento e implementação das suas

aplicações.

Com o programa Java Blueprints, a actual Oracle, pretende educar a comunidade Java

através da definição de um conjunto de recomendações de modelos de programação das

aplicações, de guias orientadoras e arquitecturas para cenários de aplicações no mundo real.

Através deste programa faz ainda a divulgação das novas tecnologias e funcionalidades da


21

plataforma e aborda questões como escalabilidade, portabilidade e interoperabilidade, entre

outros assuntos que tenham impacto no futuro e sucesso da plataforma Java. (Oracle, 2010)

Para a arquitectura no Java BluePrints podemos encontrar os padrões de arquitectura

recomendados, os Java EE Patterns. Com estes padrões recomendados (padrões testados e com

provas dadas) pretende-se solucionar problemas de projecto recorrentes e problemas das

consequências e do impacto das soluções. (Oracle, 2010) Deste modo, a arquitectura de

software adoptada para a aplicação segue o modelo Model-View-Controller (MVC). (Oracle,

2010)

No modelo de arquitectura MVC faz-se a separação dos dados da aplicação (Model), da

apresentação dos dados (View), e da lógica de negócio (Controller). Na Figura 10 é apresentado

o diagrama que representa o modelo de arquitectura MVC. (Oracle, 2010)

Figura 9 - Modelo da Arquitectura Model-View-Controller (Oracle, 2010)

Esta organização, suporta melhor a escalabilidade (múltiplos utilizadores), facilita

modificações e a manutenção das aplicações, já que as respectivas camadas podem ser

desenvolvidas e testadas em separado.

3.4.2. Descrição da Arquitectura

Para a solução MRM pretende-se que a interface do utilizador do sistema seja

desenvolvida e organizada num portal. Sob esse portal estará a funcionar a aplicação com toda a

lógica de negócio, de acordo com a Análise Funcional e respectiva persistência. Assim, o portal

deverá fornecer toda a informação e todos os dados necessários para as funções dos Operadores

e dos Operacionais, segundo os requisitos da aplicação. Paralelamente existe a plataforma de

Business Intelligence, cujos indicadores (resultado das tarefas associadas ao BI) devem ser

visualizados no portal.

De acordo com a estrutura da aplicação descrita, na Figura 10 é apresentada a arquitectura

de software genérica da aplicação, segundo a arquitectura MVC padrão. Nela é possível

visualizar a estrutura e a organização das diferentes camadas da solução e a sua correspondência

com o padrão MVC incluindo, a integração com as camadas associadas à componente de

Business Intelligence.


22

Figura 10 – Arquitectura de Software da Aplicação (MVC)

Nas camadas mais baixas da aplicação que correspondem ao Model da arquitectura,

encontram-se a Base de Dados e a Abstracção da Base de Dados. A Base de Dados com sistema

OLTP (Online Transaction Processing), está encarregue de suportar todas as transacções

necessárias em tempo real. Por sua vez, a camada de Abstracção da Base de Dados faz o

mapeamento objecto-relacional. Este mapeamento permite relacionar as tabelas da Base de

Dados com os objectos da linguagem de programação da aplicação ou, por outras palavras e

neste caso, permite a persistência dos objectos da linguagem Java em Base de Dados.

No correspondente ao Controller da arquitectura existe a Integração Aplicacional. A

Integração Aplicacional será o núcleo da aplicação que é desenvolvido em Java e que suporta

toda a lógica de negócio e comportamento da aplicação.

Na componente View da arquitectura existe o portal que suporta todas as funcionalidades

associadas à interface do utilizador da aplicação através de páginas Web dinâmicas.

Paralelamente irá funcionar a plataforma de Business Intelligence. A plataforma integra a

solução de forma independente da aplicação. Esta inclui as suas próprias camadas e interface,

com as respectivas ferramentas associadas às tarefas de Business Intelligence. Tem acesso à

Base de Dados OLTP da aplicação e ao conhecimento da lógica de negócio, necessário para as

ferramentas ETL (Extract, Transform and Load). Ou seja, a própria plataforma tem as

ferramentas necessárias para a extracção dos dados da Base de Dados OLTP, a sua

transformação e carregamento para uma Base de Dados que irá funcionar como armazém de

dados, a Data Warehouse. Por fim, a plataforma integra-se na componente View da aplicação

(no portal) através da visualização de dashboards, os indicadores de apoio à decisão.

3.5. Tecnologias e Arquitectura

Um dos requisitos e factor de inovação da Dissertação é a concepção de uma solução com

recurso exclusivo a tecnologias de Código Aberto. O estudo das tecnologias capazes de integrar

a solução não é simples. As tecnologias envolvidas estão em constante evolução e de forma

pouco linear. Tanto podem dar um salto qualitativo grande entre versões, como dar um salto

pequeno apenas para correcção de bugs. O tempo entre os lançamentos das versões pode

também variar consideravelmente, o que, por vezes, torna difícil de prever a sua evolução e o

seu futuro.

Após o estudo das características das tecnologias candidatas à solução, foram feitos alguns

testes de integração das mesmas. No resultado do estudo e dos testes efectuados, foram

seleccionadas as tecnologias que reuniam as melhores características, em conformidade com a


23

arquitectura apresentada. Na Figura 11 são apresentadas as tecnologias seleccionadas para as

diferentes camadas e módulos da Arquitectura de Software apresentada.

Figura 11 – Tecnologias da Arquitectura do Software

Para o portal foi seleccionado o Liferay Portal, versão 6.0. A Liferay apresenta uma

infraestrutura de especificação e gestão de portais, tecnologicamente bastante evoluída e com

bastantes implementações e aplicações reais. Apresenta clientes importantes como a CISCO, a

T-Mobile, a China Mobile, etc.

A aplicação será implementada com recurso à framework desenvolvida pela SpringSource,

a Spring Framework, versão 3.0.4. A SpringSource tem parceiros como a VMware, Accenture,

JTeam, Terracotta, etc. A aplicação será desenvolvida de forma a responder às funcionalidades

esperadas e será suportada no portal. Pretende-se assim que as operações dos utilizadores sejam

executadas na aplicação através do portal.

Na camada de abstracção de dados são utilizadas algumas funcionalidades disponibilizadas

pela Spring Framework, o módulo Spring ORM. O Spring ORM em conjunto com as

funcionalidades de Mapeamento Objecto-Relacional do Hibernate3, constituem a camada de

persistência da aplicação.

Os dados da aplicação são persistidos numa Base de Dados desenvolvida num servidor

MySQL 5.1, com todas as tecnologias associadas.

A execução das tarefas de Business Intelligence estão a cargo da plataforma Pentaho,

versão 3.6.0. A Pentaho disponibiliza uma suite completa, a Pentaho BI Suite, com as suas

próprias ferramentas de ETL, Análise, Reporting e Data Mining. A plataforma Pentaho BI

opera sobre a Base de Dados da aplicação e persiste os dados resultantes na sua própria Base de

Dados do tipo Data Warehouse. Tal como o portal Liferay, a plataforma Pentaho tem duas

versões, a Community Edition e a Enterprise Edition. No caso da Enterprise Edition, a Pentaho

disponibiliza ainda uma ferramenta específica para a construção de dashboards.

As versões das tecnologias apresentadas são as versões finais (não beta) mais actualizadas

até à data do início dos trabalhos da Dissertação. Apenas as ferramentas da Pentaho BI Suite

não têm especificada a versão porque estas pertencem à Suite mas funcionam e são lançadas de

forma independente da Plataforma (mas operam sobre a mesma). Além disso, as tarefas de BI e

o funcionamento das respectivas ferramentas não são o enfoque da Dissertação, apenas a sua

integração na solução/sistema de MRM.

As tecnologias foram seleccionadas de forma a maximizar a sua integração e as respectivas

funcionalidades. Toda a solução apresentada tem em comum a Spring Framework. Quer o

Liferay Portal, quer a Pentaho BI Platform, têm uma parceria de desenvolvimento com a


24

SpringSource. Consequentemente, faz todo o sentido desenvolver a aplicação MRM também

com recurso à Spring Framework.

A decisão sobre as tecnologias teve por base o seu grau de integrabilidade, as suas

funcionalidades, a sua interface gráfica (importante no caso do BI) e o facto de terem, no geral,

as tecnologias mais sofisticadas do seu Estado da Arte.

Para trabalhar nas tecnologias e frameworks apresentadas para o desenvolvimento da

solução é necessário ter um conhecimento alargado das tecnologias Web da plataforma Java EE,

das respectivas linguagens e funcionalidades. Na Figura 12 é apresentado um sumário de todas

as tecnologias envolvidas, em função das respectivas camadas da aplicação.

Figura 12 – Tecnologias e Linguagens Envolvidas nas Respectivas Camadas da Aplicação

Na Figura 12, é possível concluir que as tecnologias envolvidas na Dissertação são de facto

extensas e que além de oferecerem um leque grande de hipóteses de desenvolvimento, permitem

personalizar completamente a aplicação.

No capítulo seguinte, as arquitecturas e as tecnologias das frameworks de desenvolvimento

apresentam-se com mais detalhe, resumindo-se as suas características principais e as suas

potencialidades.

25

Capítulo 4

Frameworks de Desenvolvimento

No presente capítulo são apresentadas as arquitecturas, as tecnologias e as principais

funcionalidades das frameworks de desenvolvimento utilizadas na solução empresarial, de

forma ordenada: Spring Framework, Liferay Portal e Pentaho BI Platform.

4.1. Spring Framework 3.0

A Spring Framework é uma plataforma Java para desenvolvimento de aplicações Java. A

framework permite ao programador concentrar-se no desenvolvimento da aplicação sem se

preocupar com a estrutura da mesma. (Spring Source, 2010)

A Spring Framework traz bastantes vantagens para quem desenvolve as aplicações. Esta

permite implementar métodos em Java:

Para transacções em Bases de Dados sem ter que lidar com APIs específicas para

transacções;

Como procedimentos remotos sem recorrer a funções específicas de Java RMI;

Para gestão de operações sem ter que lidar com as APIs do JMX (Java Management

Extensions);

Para gerir e manipular mensagens sem utilizar as APIs do JMS (Java Message Service).

Todas estas vantagens estão relacionadas com o conceito de Dependecy Injection (DI) e

Inversion of Control (IoC) no desenvolvimento da Spring Framework. Estas duas características

serão apresentadas como parte das tecnologias.

4.1.1. Arquitectura

A sua arquitectura é modular. Permite desde o desenvolvimento de aplicações Java sobre

somente a plataforma Java SE, ao desenvolvimento de aplicações empresariais de grande escala

sobre a plataforma Java EE. (Spring Source, 2010)

As bibliotecas e recursos da framework estão organizados em cerca de 20 módulos. Os

principais módulos da framework são agrupados em Spring Core Container, Data

Access/Integration, Web, Aspect-Oriented Programming (AOP) e Test, conforme apresentado

na Figura 13. (Spring Source, 2010)


26

Figura 13 – Arquitectura da Spring MVC Framework 3.0

No núcleo da framework, o Core Container, estão contidos os módulos Core, Beans,

Context e Expression Language.

O Core e o Beans são os módulos principais da framework e que incluem as características

IoC e DI.

O módulo Beans implementa uma BeanFactory avançada que remove a necessidade de

criar classes Singleton ao nível da programação da aplicação Java e permite separar a

configuração e a especificação, das dependências da programação da aplicação. A interface da

BeanFactory tem um mecanismo de configuração avançada capaz de suportar qualquer tipo de

objecto. Tem ainda uma subinterface, a ApplicationContext que adiciona mais funcionalidades

orientadas a aplicações empresariais. Esta última interface representa o denominado IoC

Container que é responsável por instanciar, configurar e construir os mais diversos tipos de

Beans. (Spring Source, 2010)

O módulo Context, implementado sobre os módulos Core e Beans, permite aceder aos

objectos de forma parecida com um JNDI registry. Dá suporte a funcionalidades que

complementam o módulo Beans tais como: internacionalização (ex.: facilita a utilização de

diferentes linguagens na mesma aplicação), propagação de eventos, carregamento de recursos,

criação de contextos de forma transparente (ex.: criação de Servlet Containers). (Spring Source,

2010)

O módulo Expression Language é uma extensão da Unified Expression Language (Unified

EL) da especificação JSP 2.1, uma linguagem avançada para manipulação de objectos em

runtime denominada SpEL (Spring Expression Language). A linguagem permite

funcionalidades do tipo get e set de propriedades de objectos, invocação de métodos, operadores

lógicos e aritméticos e utilização de variáveis pelo nome, entre outras funcionalidades. A SpEL

é complementar ao módulo Context, permitindo alternativas de implementação que aumentam a

transparência das aplicações. (Spring Source, 2010)


27

A camada Data Access/Integration consiste nos módulos JDBC, ORM, JMS e

Transaction.

O módulo JDBC (Java Database Connectivity) permite a abstracção da camada JDBC. Não

é necessário fazer qualquer tipo de programação associada ao estabelecimento de ligação com

Bases de Dados, enviar SQL statements ou processamento de resultados específicos da Base de

Dados. (Spring Source, 2010)

O módulo ORM permite integração com as APIs mais populares associadas ao

mapeamento Objecto-relacional, tais como: JPA, JDO, Hibernate e iBatis. Assim, com este

módulo é possível combinar todas as funcionalidades da Spring Framework com a framework

de mapeamento Objecto-relacional pretendida. (Spring Source, 2010)

O módulo OXM suporta a abstracção da implementação do mapeamento de

Objectos/XML para JAXB, Castor, XMLBeans, JiBX e XStream.

O Java Messaging Service (JMS) contém o envio e recepção de mensagens.

O módulo Transaction torna a programação das transacções transparentes. Faz a gestão das

transacções para classes Java que implementem interfaces e para POJOs (Plain Old Java

Objects), o que permite a escrita do código uma única vez e também beneficiar de estratégias de

transacções em diferentes contextos aplicacionais. (Spring Source, 2010)

A camada Web consiste nos módulos: Web, Web-Servlet, Web-Struts e Web-Portlet.

O módulo Web permite a integração de funcionalidades orientadas à Web e a inicialização

do mencionado IoC Container com Servlet Listeners e o contexto da aplicação orientada à Web.

(Spring Source, 2010)

O módulo Web-Servlet contém a Spring Web MVC Framework. Permite a clara separação

da lógica da aplicação, do modelo de dados e das Web forms. A framework está implementada

em redor do DispatcherServlet que faz a resolução de pedidos e das Views a apresentar de

acordo com a localização e tema, bem como suporte de upload de ficheiros. (Spring Source,

2010)

O módulo Web-Struts suporta as classes de integração do Struts numa aplicação Spring

mas trata-se de um módulo que está descontinuado. Não se justifica a sua integração tendo-se

acesso ao Spring Web MVC Framework que é muito mais vantajosa que a solução clássica do

Struts. (Spring Source, 2010)

O módulo Web-Portlet possibilita a implementação da arquitectura MVC em Portlets, com

todas as funcionalidades do módulo Web-Servlet. (Spring Source, 2010)

O módulo AOP permite uma implementação conforme uma programação do tipo Aspect-

Oriented. A tecnologia associada a este módulo será analisada no ponto seguinte, relativo às

tecnologias da Spring Framework. (Spring Source, 2010)

O último módulo, Test, disponibiliza os componentes de teste para as aplicações Spring

com JUnit ou TestNG. Permite carregar os contextos das aplicações Spring

(ApplicationContext) e possibilita o uso de uma espécie de falsos objectos (mock objects) que

possibilitam testes isolados. (Spring Source, 2010)

4.1.2. Tecnologias

Inversion of Control e Dependency Injection Conforme já referido a Spring Framework implementa o principio de Inversion of Control

(IoC). Também conhecido como Dependency Injection (DI).

Em termos gerais, na Spring, DI é o processo onde os objectos definem as suas

dependências (que podem ser outros objectos) através da passagem das mesmas como

argumentos ao seu construtor (numa factory) ou através da definição das dependências como

propriedades da instância do objecto, após ter sido criado. Ou, por outras palavras, o próprio

Bean é que controla a instanciação e localização das suas dependências na construção directa da

classe. (Spring Source, 2010)

Na realidade, existe uma discussão na comunidade Java sobre qual dos dois termos o mais

correcto. (Fowler, 2004) Apesar de não haver uma conformidade nas opiniões, é aceite que o

termo IoC é demasiado genérico para ser anunciado como uma característica de uma framework


28

porque uma framework que não tem algum tipo de «inversão de controlo» deixa de ser uma

framework. Ou seja, o objectivo de uma framework é sempre “inverter o controlo” sobre um

determinado aspecto do desenvolvimento, onde a mesma assume o controlo na vez do

programador.

Nessa lógica, no caso da Spring Framework, é aceitável dizer que o IoC desta framework

consiste na Dependency Injection nos Beans da aplicação.

Com o princípio de DI, o código torna-se mais limpo quando os objectos são criados com

as suas próprias dependências. Desta forma o objecto não necessita de procurar as suas

dependências, nem saber a localização e as classes das mesmas. (Spring Source, 2010)

Esta funcionalidade obriga a existência de algum tipo de resolução na construção dos

Beans pois a declaração das suas dependências tem que corresponder aos respectivos

construtores. Neste caso, o próprio IoC Container valida a configuração de cada Bean no

momento da sua criação, incluindo a validação da referência das dependências dos Beans.


Os Beans podem ter diferentes âmbitos, uns podem estar pré-instanciados e são criados

aquando da criação do IoC Container, outros só são criados quando são necessários. Na prática,

com o princípio de DI, a criação de um Bean normalmente causa a criação de um grafo de

Beans, assim que as suas dependências e as suas dependências das dependências (e assim

consecutivamente) são criadas e atribuídas/ligadas entre si. (Spring Source, 2010)

Validation, Data Binding e Type Conversion As tecnologias Validation e Data Binding são complementares e constituem uma solução

de validação que integra as validações na camada de integração aplicacional. Ou seja, com estas

duas tecnologias, os processos de validação não estão presos à camada Web das aplicações.

Estas permitem utilizar as classes de validação como plug-ins das outras camadas da aplicação.

Para tal, a Spring tem as interfaces denominadas Validator e DataBinder que transformam esta

funcionalidade acessível e fácil para diferentes camadas da aplicação. Assim é possível validar

através da interface Validator os Inputs do utilizador que têm uma ligação dinâmica, criada com

a interface DataBinder, com as classes de validação na camada de integração aplicacional.


A tecnologia Type Conversion, tal como o nome sugere, é um sistema geral de conversão

de tipos de objectos. O sistema desenvolvido na Spring define uma Service Provider Interface

(SPI) que implementa a conversão lógica dos tipos e uma Application Provider Interface (API)

para executar a conversão dos tipos em runtime. (Spring Source, 2010)

Spring Expression Language – SpEL A SpEL é uma linguagem de expressão que permite o acesso e a manipulação de objectos

ou estruturas de objectos em runtime. A sintaxe da linguagem é semelhante a Unified EL (Java

Unified Expression Language), que permite embeber expressões de programação em páginas

Web. A SpEL, comporta-se como uma extensão da referida linguagem, adicionando outras

funcionalidades como invocação de métodos e integração de modelos básicos de expressões

(templates). (Spring Source, 2010)

Existem outras linguagens de expressão em Java, por exemplo, OGNL, MVEL ou JBoss

EL. Contudo, o objectivo da Spring é oferecer uma linguagem bem desenvolvida e

completamente integrada, que possa ser usada em todos os produtos oferecidos pela mesma.


Entre outras funcionalidades da linguagem, destacam-se (Spring Source, 2010):

Operadores relacionais e booleanos;

Expressões regulares;

Acesso a propriedades, arrays, listas e maps;

Invocação de métodos;

Atribuição de variáveis;

Construção de arrays;

Modelos de expressões (templates).


29

Para se ter uma noção do funcionamento da tecnologia Type Conversion e de como a

linguagem SpEL pode ser usada, apresenta-se o seguinte exemplo (Spring Source, 2010):

(…) // Uma classe que representa uma lista de booleanos class Simple { public List<Boolean> booleanList = new ArrayList<Boolean>(); } (…) // Nova lista de booleanos Simple simple = new Simple(); // Adiciona true à lista simple.booleanList.add(true); // Cria o serviço de conversão por contexto (tecnologia Type Conversion) StandardEvaluationContext simpleContext = new StandardEvaluationContext(simple); /* O valor false é passado como String. A SpEL e o service de conversão irão * reconhecer correctamente que o valor do tipo String tem ser passado para * Booleano e só depois adicionado */ parser.parseExpression("booleanList[0]").setValue(simpleContext, "false"); // b terá o valor booleano false Boolean b = simple.booleanList.get(0); (…)

No excerto apresentado é utilizado um exemplo que pode ser usado para adicionar

facilmente inputs do utilizador a estruturas de programação mas, a SpEL pode também ser

usada, por exemplo, em configurações de Beans em XML.

Aspect-Oriented Programming (AOP) A tecnologia Aspect-Oriented Programming da Spring complementa a Object-Oriented

Programming (OOP) que proporciona uma outra forma de pensar sobre a estrutura dos

programas. Enquanto na OOP a unidade central é a classe, na AOP a unidade central é o Aspect.


Um Aspect é a modularização/concretização de um interesse partilhado entre diferentes

classes. Por exemplo, a gestão de transacções é um interesse partilhado por várias classes de

uma aplicação Java empresarial. No Spring AOP, o conceito Aspect é implementado através de

classes normais ou classes com anotações (suporta @AspectJ). (Spring Source, 2010)

Uma aplicação Spring recorre naturalmente à tecnologia AOP quando se requer serviços

ou pacotes de serviços middleware (ex.: pooling). (Spring Source, 2010)

Contudo, existe a Spring AOP Framework que fornece serviços empresariais,

especialmente para substituição de serviços de EJBs, dos quais se destaca a gestão declarativa

de transacções. Neste exemplo, há um forte interesse do recurso à AOP framework para

substituir a tecnologia Container-Managed Transactions dos EJB (EJB CMT) da plataforma

Java EE. Uma das vantagens oferecidas sem equivalente na EJB CMT é a possibilidade da

existência de regras para rollbacks das transacções que permite, por exemplo, apanhar

excepções não suportadas, geradas pelo código que executa no contexto actual de uma

transacção e lançadas para a Stack. (Spring Source, 2010)


30

Testing A tecnologia Testing baseia-se no valor acrescentado que o principio IoC traz aos testes

unitários (Unit Testing) e na framework de testes de integração (Spring Framework Integration

Testing). (Spring Source, 2010)

Por sua vez, a DI faz com que o código da aplicação seja menos dependente do seu

container que as tradicionais aplicações Java EE. Isso permite testar os POJOs da aplicação com

JUnit ou TestNG, simplesmente instanciando-os com o operador new. Assim como, utilizar

falsos objectos (mock objects) para testar partes da aplicação isoladamente. (Spring Source,

2010)

Se as recomendações de arquitectura da Spring forem seguidas, a aplicação terá as suas

camadas e componentes definidos de forma clara. Por exemplo, deverá ser possível testar a

camada dos serviços da aplicação através da criação de “falsos” DAOs (Data Access Objects)

ou interfaces para repositórios, sem recorrer aos dados reais persistidos na camada de dados

para executar os testes unitários. (Spring Source, 2010)

A framework permite fazer testes de integração (Integration Testing) à aplicação sem ser

necessário publicar a mesma ou liga-la a outra infraestrutura empresarial. Esta possibilita testar

a aplicação:

Na correcta ligação das estruturas e contextos do IoC Container.

No acesso a dados usando JDBC ou ferramentas ORM: testa os statements SQL, as

queries do Hibernate3, o mapeamento de entidades JPA, etc.

A partir da Spring Framework 2.5, os testes unitários e de integração podem ser feitos

através anotações (annotation-driven testing) com a Spring TestContext Framework. (Spring

Source, 2010)

4.1.3. Estratégias de Desenvolvimento

Apenas os principais tópicos e vantagens das tecnologias disponibilizadas pela Spring

Framework foram expostos. Mas já é possível deduzir que são de facto extensas e, com certeza,

leva algum tempo até o programador poder usufruir de todas as vantagens disponibilizadas.

Neste ponto são apresentadas as duas principais alternativas de desenvolvimento Web que

a framework permite. Ambas são estratégias válidas para o desenvolvimento de aplicações Web.

Aplicações Web A opção de desenvolvimento convencional de aplicações Web é baseada em Servlets e

feito com recurso à Spring Web MVC Framework. Conforme já referido, esta framework foi

desenhada em redor do DispatcherServlet que faz a resolução dos pedidos e respectivas páginas,

suporta temas e upload de ficheiros. (Spring Source, 2010)

A Spring Web MVC Framework, tal como outras frameworks de desenvolvimento do

género, é desenhada em redor de um Servlet que faz a resolução de pedidos, do tipo request-

driven.

Na Figura 14 é apresentado o diagrama de funcionamento do DispatcherServlet. Nele é

possível visualizar como as aplicações Web standard desenvolvidas em Spring MVC se

comportam. O padrão de funcionamento do DispatcherServlet em tudo se assemelha ao design

“Front Controller”. (Spring Source, 2010)


31

Figura 14 – Diagrama de Funcionamento do DispatcherServlet da Spring MVC

Portlets A Spring Portlet MVC Framework espelha as funcionalidades da Web MVC Framework,

descritas nos pontos anteriores, para o desenvolvimento de Portlets com especificação JSR-168.


Enquanto no workflow de um Servlet, o pedido de acção está associado a uma resposta

dessa acção e a uma renderização, num Portlet, um pedido pode ter duas fases na resposta do

seu workflow: a fase de acção e a fase de renderização. A fase de acção é executada apenas

quando há um pedido de acção ou uma modificação do sistema. A fase de renderização é

executada só quando há um refresh da interface (um pedido de actualização da página pelo

utilizador). A principal diferença de funcionamento está na distinção destas duas fases, as

acções são executadas uma única vez e as renderizações são executadas várias vezes. Isto

implica uma clara separação das camadas de persistência, daquelas camadas que geram aquilo

que é renderizado para o utilizador. (Spring Source, 2010)

Na Figura 15 é possível observar o diagrama de funcionamento de pedidos em duas fases

dos Portlets, cujos intervenientes das acções são o servidor do portal, o Portlet Container e dois

Portlets, o A e o B. O exemplo do diagrama corresponde ao comportamento de dois Portlets

configurados numa única página de portal, onde o primeiro pedido ao servidor corresponde ao

carregamento ou actualização da página Web e o segundo pedido corresponde ao pedido de uma

acção do Portlet A, sempre através de um Navegador Web.


32

Figura 15 – Diagrama de Sequência do Processo de Funcionamento de Portlets

A divisão dos pedidos a Portlets em duas fazes é um dos pontos fortes da especificação

JSR-168. Por exemplo, numa pesquisa dinâmica os resultados podem ser actualizados com

frequência na interface sem o utilizador executar explicitamente a acção de pesquisa novamente.


Outras frameworks equivalentes tentam esconder esta especificação de pedidos em duas

fases mas, na Spring não há essa intenção, é entendido que isso seria despromover a vantagem

da especificação JSR-168. (Spring Source, 2010)

Tal como a Web MVC Framework está desenhada em redor do DispatcherServlet, a

Portlet MVC Framework, por sua vez, está desenhada em redor do DispatcherPortlet. O

DispatcherPortlet resolve os pedidos e faz a sua delegação para os respectivos handlers. O

mapeamento dessas delegações e as renderizações das respostas são configuráveis. O suporte

para upload de ficheiros é feito da mesma forma que a Web MVC. Já o suporte das

funcionalidades de internacionalização e temas são feitos pelos Portlets Containers (os portais).

Como a exposição destas duas funcionalidades é feita no DispatcherPortlet da mesma forma

que no DispatcherServlet, elas funcionam correctamente. (Spring Source, 2010)

4.2. Liferay Portal 6.0

O Liferay Portal é um portal empresarial Open Source escrito em Java com todas as

funcionalidades associadas a páginas Web, constituídas essencialmente por unidades funcionais,

os Portlets.

O Liferay é o primeiro Java Portlet Container a suportar as especificações JSR-168 e JSR-

286. O portal está bastante avançado em relação a outros do género, é versátil e opera como um

Servlet Java EE em qualquer um dos mais usados Java Servlet Containers (ex.: Apache Tomcat,


33

Glassfish, JBoss, WebShere, etc.). É ainda possível conectar o portal com quase todos os tipos

de servidor de Base de Dados (ex.: MySQL, Hypersonic, HSQLDB, Oracle, PostgreSQL,

Microsoft SQL Server, etc.). Internamente, para gestão de ligações e queries à Base de Dados, é

possível utilizar Hibernate ou JPA.

Com o objectivo de aumentar a flexibilidade do portal, o Liferay usa a Spring Framework

nas suas funcionalidades internas, com todas as metodologias associadas ao Inversion of

Control (IoC) e ao Aspect-Oriented Programming (AoP). Quase todos os serviços e

funcionalidades do portal Liferay podem ser substituídos através de passos relativamente

simples.

Apesar da sua associação às tecnologias Spring, o Liferay suporta Portlets desenvolvidos

com recurso a outras tecnologias, desde que sejam de acordo com as especificações JSR-168 ou

286. O portal suporta várias frameworks de desenvolvimento de Portlets, incluindo Struts,

Spring MVC, Java Server Faces (JSF), a par da sua própria framework. Para os templates dos

Portlets, também suporta várias tecnologias, incluindo Velocity, Freemarker e Vanilla JSP.

4.2.1. Arquitectura

O portal Liferay tem uma arquitectura SOA. Permite aos utilizadores acederem de

qualquer dispositivo e aos programadores acederem através da API exposta via SOAP, RMI,

XML-RPC, JSON, etc.

Figura 16 – Arquitectura do Liferay Portal

Com os princípios SOA, o portal foi desenhado para suportar diversos tipos de Portlet,

cache de páginas, alojamento virtual dinâmico. Integra ainda LDAP e SSO, segurança, etc.

Em particular, o Enterprise Service Bus (ESB) funciona como um gestor central de

ligações a infraestruturas empresariais que permite ligar aplicações e serviços exteriores, com

facilidade. Por exemplo, através do ESB é possível integrar o portal com SharePoint, BPM, etc.

4.2.2. Tecnologias

O portal suporta praticamente todas as tecnologias associadas à Web e as já referidas

tecnologias associadas à Spring Framework. Assim, nesta secção apenas se justifica referir a

única tecnologia particular do portal, o Web Application Integrator (WAI).


34

Web Application Integrator (WAI) O WAI disponibiliza uma forma rápida de integrar aplicações Java Servlet normalizadas

no portal. Basta copiar o ficheiro WAR (Web Application Archive) de uma aplicação para a

pasta de integração e a aplicação será automaticamente configurada com os ficheiros

necessários e disponibilizada através de Portlets ou, mais especificamente, iFrame Portlets.

4.2.3. Estratégias de Desenvolvimento

O desenvolvimento do portal pode ser feito com diferentes tipos de extensões. Umas

extensões podem alterar o núcleo do portal, enquanto outras podem acrescentar novas

funcionalidades ao mesmo. O importante é escolher a estratégia de desenvolvimento mais

adequada, de forma a poupar tempo e esforço e assegurar a compatibilidade da extensão com

futuras versões.

As opções de desenvolvimento são Portlets, Themes (temas), Layout Templates (visual e

disposição das páginas), Hooks (funcionalidades) e Ext plugins (modificações ao portal). Todas

estas opções podem ser publicadas no servidor do portal automaticamente pelo WAI como

plugins.

Portlets Os Portlets são os componentes mais importantes de um portal, sendo eles que contêm

toda a funcionalidade. Os Portlets funcionam como pequenas aplicações Web e o portal (um

Portlet Container) é responsável por agregar os Portlets que são visualizados em páginas Web

dinâmicas. (Liferay, 2010)

Os Portlets são a extensão menos invasiva do Liferay Portal, são inteiramente contidos

neles próprios e em caso de erro, não impedem o funcionamento do portal. Um único projecto

(plugin) deste tipo pode implementar múltiplos Portlets, sendo assim possível dividir uma única

aplicação em pequenas unidades funcionais que podem ser visualizadas e dispostas

dinamicamente numa página Web. (Liferay, 2010)

Os Portlets podem ser desenvolvidos com as próprias frameworks disponibilizadas pela

Liferay: a MVCPortlet e a AlloyPortlet. Pode usar-se também outra Framework de

desenvolvimento de Portlets, como no caso da solução apresentada, a Spring Portlet MVC

Framework.

Themes A opção de desenvolvimento Theme permite implementar plugins do tipo «Tema». Num

Theme é possível fazer alterações ao visual do portal através de uma combinação de CSS,

imagens e Velocity templates.

Na maioria dos casos as modificações são feitas exclusivamente através de CSS. Contudo,

no caso de se pretender modificações mais profundas à disposição e aos elementos do próprio

portal, é possível desenvolver templates que se sobrepõem às definições do portal que vêm por

defeito. (Liferay, 2010)

Layout Templates Os plugins do tipo Layout Template são em tudo idênticos aos Themes (temas) mas, em

vez de modificarem o visual do portal, modificam apenas a sua disposição. Os Layout Template

são escritos em Velocity. (Liferay, 2010)

Hooks As modificações às funcionalidades do núcleo do Liferay devem ser feitas através de

plugins do tipo Hook. Os Hooks podem modificar as propriedades do portal ou acrescentar

acções ao iniciar e encerrar do portal, no login e logout dos utilizadores, na criação e destruição

de sessões. Numa perspectiva de IoC, o Liferay permite substituir qualquer funcionalidade ou

serviço do seu núcleo por uma implementação personalizada dos mesmos, tal como os JSP

templates por defeito no portal. (Liferay, 2010)


35

Ext plugins A opção Ext plugins é a que dá mais flexibilidade na modificação do núcleo do Liferay

Portal, permitindo modificar qualquer classe através da substituição da sua implementação.

Pode-se considerar como uma modificação de mais baixo nível. A substituição de classes tem

riscos e custos acrescidos, além de que não é garantida a sua compatibilidade com futuras

versões do portal. Tal como os restantes plugins, os Ext plugins são publicados automaticamente

pelo WAI mas requerem ainda o reiniciar do servidor para terem efeito. (Liferay, 2010)

4.3. Pentaho BI Platform 3.6

A Pentaho BI Suite é uma plataforma que implementa componentes de BI orientados à

construção de soluções empresariais.

No caso da plataforma Pentaho BI e para a solução apresentada, não é necessário recorrer à

sua framework para fazer qualquer tipo de desenvolvimento ou integração. Ou seja, ao nível das

funcionalidades do BI, não é suposto fazer-se qualquer tipo de implementação. Ao nível da

integração, a plataforma deverá ter implementado os seus próprios mecanismos de integração,

pretendendo-se que necessite apenas de configuração.

As funcionalidades e ferramentas referidas neste ponto serão apenas as disponibilizadas

com a Community Edition (CE) da plataforma Pentaho BI Suite. Na Figura 17, são apresentados

os projectos associados à plataforma Pentaho BI, da versão CE, com as respectivas ferramentas

disponibilizadas.

Figura 17 – Organização das Ferramentas da Pentaho BI Suite CE

4.3.1. BI Platform e Arquitectura

A Pentaho BI Platform é o núcleo ou a base da Pentaho BI Suite, fornece toda arquitectura

e infraestrutura necessária para a construção de soluções de BI. Corre em servidor Web (ex.:

Tomcat) e tem um controlador central que funciona como um motor de workflows. A plataforma

funciona como um processo centralizado. Todas as actividades/tarefas de BI desenvolvidas com

as ferramentas resultam na definição de processos de diferentes naturezas em forma de

workflow que são executados pelo motor de workflows. (Pentaho Corporation, 2008)

Esta forma de funcionamento centralizado é o factor de diferenciação em relação a outras

plataformas de BI. A arquitectura e o código completamente originais, com integração de outros

componentes de Código Aberto, formam uma plataforma de BI avançada, original, escalável e

modular. (Pentaho Corporation, 2008)

A plataforma tem um sistema complexo de funcionalidades, associadas a: servidores Java

EE, segurança, portais, workflows, motores de regras, geração de gráficos, colaboração, gestão

de conteúdos, análise de dados e modelação. Muitos dos componentes que integram as


36

funcionalidades são desenvolvidos sobre normas e podem ser substituídos por outros produtos.

(Pentaho Corporation, 2008)

Na Figura 18 é apresentada a arquitectura da plataforma, onde se apresentam os

componentes desenvolvidos pela Pentaho, os componentes de Código Aberto integrados na

plataforma e as tecnologias clientes envolvidas (ver legenda da figura).

Figura 18 – Arquitectura do Pentaho BI Platform (Pentaho Community, 2008)

O Solution Engine é centro de toda a arquitectura e gere o acesso aos componentes da

plataforma.

A plataforma fornece serviços para aplicações Web exteriores. Os serviços têm acesso ao

Solution Engine e aos componentes da interface do utilizador. Os serviços podem ainda ser

chamados pelo motor de workflows para executar acções do sistema.

Um sistema de auditoria da própria plataforma faz a monitorização da performance dos

diferentes componentes de geração de relatórios e extracção de dados.

Os Componentes são módulos que podem ser adicionados ao sistema.

Todos os motores têm os respectivos componentes que os integram, o que os torna motores

completamente modulares. É possível inclusive acrescentar novos motores desenvolvendo

apenas os respectivos componentes de integração. (Pentaho Corporation, 2008)


37

4.3.2. Reporting

O projecto Pentaho Reporting Community Edition inclui: Pentaho Report Designer,

Pentaho Report Engine, Pentaho Reporting SDK e partilha as bibliotecas mais comuns

associadas ao reporting com a restante plataforma de BI. Estas ferramentas Open Source

permitem a criação de relatórios analíticos (com indicadores) e relacionais (de diferentes fontes

de informação) e exportá-los para: PDF, Excel, HTML, Text, Rich-TExt-File, XML e CSV.

(Pentaho Corporation, 2010)

4.3.3. Data Integration

A distribuição do Pentaho Data Integration Community Edition é a base de todas as tarefas

associadas ao BI, constituindo a distribuição no cliente das ferramentas ETL. O Pentaho Data

Integration implementa ferramentas gráficas e intuitivas, com um ambiente do tipo drag and

drop. (Pentaho Corporation, 2010)

Tal como é suposto pelo processo ETL, estas ferramentas permitem:

Extracção de dados – recolhe dados de diversas fontes e faz a sua homogeneização;

Transformação de dados – limpeza de dados com a identificação de erros e aplicação

de possíveis correcções e conversão de dados para os formatos que vão ser persistidos

na Data Warehouse;

Carregamento de dados – persistência dos dados transformados em Data Warehouses,

incluindo tarefas como: ordenação, agregação, consolidação e verificação da

integridade dos dados. (Ramos, et al., 2009)

4.3.4. Analysis Services

O Pentaho Analysis Services Community Edition é um servidor com a tecnologia Online

Analytical Processing (OLAP) que permite aos utilizadores do sistema analisar grandes

quantidades de informação, em diferentes perspectivas e em tempo real. (Pentaho Corporation,

2010)

O servidor tem uma arquitectura ROLAP (Relational OLAP). Nesta arquitectura o servidor

funciona como intermediário entre a base de dados relacional e as ferramentas clientes que

fazem a análise dos dados. Um servidor ROLAP tem um gestor de base de dados relacionais

para armazenar e gerir os dados que serão analisados posteriormente. (Ramos, et al., 2009)

Os utilizadores poderão explorar os dados, manipulando-os sobre as diferentes

perspectivas, de acordo com o esquema de modelação de dados utilizado.

4.3.5. Data Mining

O projecto Pentaho Data Mining disponibiliza um conjunto de ferramentas de Data Mining

e aprendizagem do sistema. Explora os dados e aprende com o sistema e com a lógica do

negócio, através de regras de associação, classificação, regressão, algoritmos de criação de

clusters, etc. (Pentaho Corporation, 2010)

O objectivo do Data Mining é encontrar relacionamentos, padrões ou modelos a partir dá

análise de grandes quantidades de dados.


38

39

Capítulo 5

Desenvolvimento e Implementação

Neste capítulo, é apresentada a infraestrutura de desenvolvimento, incluindo a instalação e

a configuração das plataformas e frameworks apresentadas no capítulo anterior. Nas secções

seguintes, são apresentadas e discutidas as soluções encontradas, relativas a diferentes aspectos

da integração e interoperabilidade das tecnologias. O capítulo conclui com os resultados

alcançados no desenvolvimento da solução.

5.1. Infraestrutura e Ambiente de Desenvolvimento

O Ambiente de Desenvolvimento necessário para desenvolver a solução é bastante

exigente a nível computacional. Requer uma máquina (ou mais) com capacidade suficiente para

correr um servidor de Base de Dados, um ou dois servidores Web (depende da intenção do

arquitecto do sistema) e um emulador de smartphone para testes da componente móvel.

Neste caso, o componente da solução mais exigente ao nível de recursos computacionais é

o componente de Business Intelligence. Para se ter uma noção da exigência dos recursos, os

requisitos recomendados para a plataforma Pentaho BI são 2Gb de RAM e um processador com

dois núcleos a 64bits (dual-core x64).

O Ambiente de Desenvolvimento apresentado é configurado em ambiente Windows. Nas

secções seguintes, da 5.1.1 à 5.1.5, são apresentados os passos de instalação dos componentes

que constituem o ambiente de desenvolvimento com as respectivas interfaces.

Os requisitos principais são a instalação do .NET Framework versão 3.5 e o Java

Development Kit (JDK) actualizado. No ambiente de desenvolvimento testado, é usado o JDK

versão 6, actualização 21.

5.1.1. Servidor MySQL 5.1

O servidor MySQL é bastante simples e rápido de instalar. Basta aceder à página Web de

downloads da MySQL e escolher o download da aplicação de instalação do „MySQL

Community Server‟.

Depois de terminado o download, corre-se a aplicação de instalação e segue-se todos os

passos da instalação recomendada. A Base de Dados deverá ser do tipo OLTP, sem necessidade

de qualquer configuração excepcional.

O MySQL Community Server é a Base de Dados Open Source mais popular, suportada por

uma grande comunidade de programadores e adeptos de software aberto.

A versão 5.1 do servidor é a utilizada no ambiente de desenvolvimento da solução.


40

5.1.2. MySQL Workbench 5.2

Na mesma página de download do servidor MySQL, faz-se o download do MySQL

Workbench.

A sua instalação é trivial, basta seguir os passos de instalação e as opções de configuração

recomendadas.

O MySQL Workbench é a um ambiente integrado de ferramentas de:

Desenho e modelação de Bases de Dados;

Desenvolvimento SQL (em substituição do anterior MySQL Query Browser);

Administração de Bases de Dados (em substituição do anterior MySQL Administrator

e em alternativa à linha de comandos MySQL).

Figura 19 – Exemplo do Interface Gráfico do MySQL Workbench

O ambiente integrado desta interface gráfica facilita e agiliza o desenvolvimento de Bases

de Dados. A partir da interface é possível aceder à ferramenta de criação de modelos

relacionais, a MySQL Model. Esta ferramenta permite escolher a notação pretendida para as

relações e os objectos do modelo e gerar os scripts SQL a partir do mesmo, entre outras

funcionalidades mais avançadas.

A ferramenta de administração de Bases de Dados, a Admin, permite gerir o servidor,

configurar todos os parâmetros e variáveis associadas às Bases de Dados MySQL, monitorizar a

ligações e o estado do servidor, entre outras opções.

A última ferramenta da interface a apresentar é a MySQL Editor. Com esta ferramenta é

possível estabelecer uma ligação a um servidor MySQL instanciado e fazer todo o tipo de

operações que o SQL permite, incluindo a criação de Vistas e de Rotinas. A principal vantagem

é a possibilidade de gerir facilmente mais do que um Schema de uma BD e executar

rapidamente os scripts SQL, por exemplo, gerados pelo MySQL Model.


41

5.1.3. SpringSource Tool Suite 2.3.2

O SpringSource Tool Suite (STS) é uma ferramenta para desenvolvimento de aplicações

Java empresariais personalizada e configurada em função da estratégia de desenvolvimento da

Spring.

O download do STS é feito através do sítio da SpringSource.

O STS tem uma interface bastante familiar, é desenvolvida com base no Eclipse IDE (ver

Figura 20). Incluí ferramentas para o desenvolvimento de aplicações empresariais com base nas

tecnologias Java, Spring, Groovy and Grails e desenvolvimento OSGi. (SpringSource, 2010)

Figura 20 – Interface da SpringSource Tools Suite

A distribuição da ferramenta vem ainda com um servidor Apache Tomcat (TC) optimizado

para Spring. O TC Server Developer Edition tem uma interface gráfica que permite identificar e

diagnosticar problemas de aplicações através de métricas de desempenho em tempo real.

(SpringSource, 2010)

Para o ambiente de desenvolvimento da solução é necessário proceder a alguns passos de

configuração e instalação das tecnologias de desenvolvimento no STS (o IDE). Incluindo as

ferramentas para as estratégias de desenvolvimento do Liferay.

Configuração do IDE

1) Após o download do STS a partir do sítio da SpringSource, executar o instalador e

instalar com as opções recomendadas;

2) Após a instalação, verificar no IDE se a versão do JRE configurada por defeito no STS,

é a da distribuição do JDK instalado;

3) No STS, instalar as ferramentas do Hibernate através do seu Update Site:

http://download.jboss.org/jbosstools/updates/stable/;

4) No STS, instalar o SDK do Liferay também através do seu Update Site:

http://releases.liferay.com/tools/ide/eclipse/helios/stable/;


42

5) Fazer o download do ficheiro em arquivo com o compilador Jikes e extrair o ficheiro

para o directório mais conveniente;

6) Fazer o download do ficheiro em arquivo dos binários do construtor Ant e extrair o

ficheiro para o directório mais conveniente;

7) Para o funcionamento correcto das ferramentas é necessário configurar as seguintes

Variáveis de Ambiente do Windows:

a. «JAVA_HOME» a apontar para o directório do JDK;

b. «JIKES_HOME» a apontar para o directório do compilador Jikes;

c. «ANT_HOME» para o directório onde foi extraído no ponto anterior

d. Acrescentar «%JIKES_HOME%\bin», «%JAVA_HOME%\bin» e «%ANT_HOME%\bin»

à variável «Path»

Se a configuração do IDE for feita com sucesso, deverão aparecer os símbolos das

funcionalidades instaladas (Hibernate e Liferay), na visualização de “About” (Figura 21).

Figura 21 – Funcionalidades Instaladas no IDE da SpringSource Tool Suite

5.1.4. Servidor Liferay Portal 6.0

As instruções de instalação e configuração das ferramentas necessárias para as estratégias

de desenvolvimento do portal, foram consideradas no ponto anterior, aquando da instalação do

IDE. Contudo, é ainda necessário configurar o servidor do portal Liferay para ser utilizado no

IDE.

Como o IDE de desenvolvimento para o portal é o mesmo, dispensa-se qualquer

introdução ao mesmo neste ponto.

Configuração do servidor Liferay no IDE

1) No sítio do Liferay, fazer o download das distribuições da comunidade do Plugins SDK

e do pacote do portal com o servidor Tomcat;

2) Configurar o Liferay Plugins SDK no IDE, adicionando o respectivo directório em

«Installed SDKs» do IDE;

3) Configurar a instância do servidor Tomcat do portal no IDE, adicionando o runtime

environment do mesmo.

Caso a configuração seja terminada com sucesso, a instancia do servidor deverá aparecer

no separador Servers da interface apresentada (Figura 20).

Para testar o servidor e o portal, basta seleccionar o mesmo na aba apropriada do IDE e

iniciá-lo. No final do arranque do servidor, o sítio do portal deverá abrir automaticamente no


43

navegador pré-definido. Caso não aconteça, pode-se abrir o mesmo manualmente e navegar até

http://localhost/.

Na Figura 22 é apresentada a página inicial do portal Liferay. A autenticação de testes é

feita com o correio electrónico «[email protected]» e a palavra passe «test».

Figura 22 – Página Inicial do Portal Liferay

5.1.5. Servidor Pentaho 3.6

O desenvolvimento de Business Intelligence não é objectivo da Dissertação, pelo que é

desprezada a apresentação e configuração das ferramentas disponibilizadas na Pentaho BI Suite,

referidas no capítulo 4. Interessa apenas configurar o servidor para a implementação da

integração das tecnologias e funcionamento da plataforma Pentaho BI no conjunto da solução.

Configuração do servidor

1) No sítio da Pentaho, nos projectos da comunidade, fazer o download do servidor

Tomcat com a plataforma Pentaho BI;

2) Configurar as seguintes Variáveis de Ambiente do Windows:

a. «CATALINA_HOME» a apontar para o directório do servidor Tomcat da

plataforma;

b. «CATALINA_OPTS» com o seguinte valor:

-Xms256m -Xmx768m -XX:MaxPermSize=256m -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000

3) Iniciar a plataforma de BI executando o ficheiro «start-pentaho.bat» localizado na

pasta «biserver-ce» do ficheiro transferido e extraído;

4) Para experimentar ou trabalhar com a plataforma de imediato, basta aceder através do

navegador de internet, a http:/localhost:8080/;

5) Para acrescentar fontes de dados à plataforma, aceder à consola de administração que

pode ser iniciada com a execução do ficheiro «start-pac.bat» na pasta

«administration-console».

A página inicial do servidor deverá apresentar-se conforme a Figura 23.


44

Figura 23 – Página Inicial do Servidor da Plataforma Pentaho BI

Depois da configuração do servidor da plataforma Pentaho BI, pode-se explorar as

demonstrações da plataforma.

Para todas as tarefas de BI (ETL, Reporting, etc.) é necessário o download das respectivas

ferramentas da plataforma.

5.2. Especificação da Implementação

Sobre a especificação da implementação, em primeiro lugar são apresentados os métodos

de desenvolvimento utilizados durante a concepção e implementação da solução.

Em segundo lugar é apresentado a visão e o funcionamento geral da solução desenvolvida

com base nas tecnologias apresentadas anteriormente.

Depois, são apresentadas as opções de integração e as especificações da implementação

das tecnologias.

5.2.1. Método de Desenvolvimento

No desenvolvimento da solução foram usados processos ágeis de desenvolvimento de

software da metodologia XP (Extreme Programming). (Wells, 2010)

Apesar de haver outros processos de desenvolvimento ágeis, os processos da metodologia

XP são os mais adequados ao tipo de projecto/desenvolvimento que se pretende fazer. O XP

adequa-se bem quando os requerimentos do sistema podem mudar ao longo da implementação

ou não há uma ideia concreta da solução final. Nesta metodologia, o desenvolvimento é feito

com pequenas equipas, com o método de «Programação em Pares», do original Pair

Programming. A implementação da solução é feita de forma iterativa e a programação das

funcionalidades feita por pares de programadores num só computador. O tempo de

desenvolvimento deste método em comparação com o tempo de desenvolvimento das

funcionalidades por programadores independentes estima-se que seja equivalente mas, a

qualidade do código de programação é quase sempre superior. Contudo, neste aspecto, a

implementação efectuada foi feita apenas pelo autor.

O conceito usado e mais relevante desta metodologia é a «História do Utilizador», do

original User Story. Uma User Story descreve um problema a ser resolvido pelo sistema-


45

solução. Não descreve a solução, não usa linguagem técnica, nem expressões típicas dos

tradicionais levantamentos de requisitos. Em vez disso, utilizam-se expressões simples e

directas sobre o que sistema “faz”, como se se tratassem de comandos ao sistema. Num

levantamento de requisitos tradicional, corresponde aos requisitos funcionais e não funcionais.

Do XP, foi ainda utilizado o Test-driven Development que pode ser traduzido como

«Desenvolvimento Orientado a Testes». Neste tipo de desenvolvimento os métodos de teste são

implementados primeiro que os métodos funcionais a testar. A vantagem principal deste tipo de

desenvolvimento é o teste da aplicação em pequenos passos e a possibilidade de reformular e

aprovar o seu desenho antes de avançar com a implementação de novas funcionalidades.

Contudo, apesar de aparentemente ser um princípio básico, requer uma grande disciplina, já que

a tendência do programador é fazer precisamente o oposto. (Ambler, 2010)

5.2.2. Visão Geral

A aplicação de gestão de recursos móveis consiste numa aplicação Web desenvolvida em

Spring Portlet MVC Framework, que funcionará como um plugin para portais Web.

A aplicação é constituída por vários Portlets, cada um com a sua funcionalidade. Por sua

vez, apesar de os Portlets serem implementados como módulos funcionais independentes, no

seu conjunto, fazem parte de uma única aplicação Spring, onde partilham os dados e a lógica

entre si, implementando assim todas as funcionalidades da aplicação.

Como se trata de uma aplicação baseada em Portlets ela não funciona por si só, necessita

de um portal (um Portlet Container) onde possa ser alojada.

A Figura 24 ilustra a organização e estrutura do modelo da aplicação descrito. Contendo a

aplicação Web a definição dos Portlets, a estrutura e a lógica da aplicação e as tecnologias de

persistência dos dados na Base de Dados (BD). Neste caso, o acesso à BD é feito através de um

mapeamento objecto-relacional com Hibernate3. O portal Liferay funciona de forma

independente e suporta aplicações Web desenvolvidas com a Spring Portlet MVC Framework

que, por sua vez, fornece todas as tecnologias necessárias ao desenvolvimento da aplicação

MRM.

Figura 24 – Modelo da Aplicação Web


46

O portal Liferay necessita da sua própria BD para funcionar. Na BD, o portal persiste toda

a informação sobre os utilizadores, a sua gestão (hierarquia, permissões, etc.), a organização do

portal, as estrutura das páginas Web dinâmicas, a localização dos temas, das imagens, etc. Ou

seja, o portal persiste todas as suas funcionalidades e configurações nas suas próprias tabelas, na

BD.

A Arquitectura Geral da Solução (apresentada na Figura 25) ilustra o funcionamento de

toda a solução e a organização das suas diferentes camadas e módulos.

Figura 25 – Arquitectura Geral da Implementação da Solução

Nesta solução existem várias Bases de Dados envolvidas. O portal tem uma BD

independente da BD OLTP da aplicação MRM. A plataforma de BI, dada a sua arquitectura,

necessita das suas próprias Bases de Dados operacionais e uma Data Warehouse onde irá

persistir os dados já modelados.

O acesso ao portal pode ser feito através de dispositivos móveis ou através de

computadores pessoais. No contexto empresarial apresentado, os dispositivos móveis estão

associados aos Operacionais de Front Office e os computadores pessoais aos Operadores de

Back Office. O portal será o responsável por gerir o acesso e a apresentação dos Portlets nas

diferentes perspectivas dos utilizadores.

Para a componente de BI, o acesso aos dados da aplicação MRM é feito através das

ferramentas Pentaho que irão, por sua vez, recorrer ao motor da plataforma Pentaho BI para

executar as tarefas associadas à modulação dos dados. As tarefas de BI irão resultar em

indicadores de Apoio à Decisão, em forma de relatórios e gráficos que poderão ser visualizados

em Portlets iFrame. Estes Portlets limitam-se a requisitar a visualização dos indicadores através

de pedidos URL ao servidor Pentaho.


47

5.2.3. Base de Dados

O Modelo Relacional da Base de Dados desenvolvido e implementado é apresentado na

Figura 26.

Figura 26 – Modelo Relacional UML da Base de Dados OLPT

A camada de persistência da aplicação necessita de uma Base de Dados desenhada à

medida do negócio. Assim, para o efeito de prova, supôs-se que a BD deveria suportar um


48

negócio de instalação e manutenção de dispositivos em casa de clientes e capaz de guardar

indicadores primários de BI suficientes para a demonstração da componente de Apoio à

Decisão.

Segue-se a explicação e a descrição de todos os objectos representados do Modelo

Relacional (Figura 26), incluindo as suas relações:

Utilizadores – toda a informação relativa aos utilizadores do sistema MRM. Os

utilizadores são classificados por tipos de utilizadores (operadores, operacionais,

administradores, etc.), têm estados (de baixa, activo, de férias, etc.), têm uma

classificação de desempenho e podem estar associados a uma Deslocação ou mais.

Tipos_Utilizadores – todos os tipos de utilizadores do sistema. Os utilizadores

têm que ter sempre associado um tipo.

Estado_Utilizadores – todos os tipos de estados dos utilizadores do sistema. Os

utilizadores têm que ter sempre associado um estado.

Classificacoes_Colaboradores – histórico de todas as classificações atribuídas

aos utilizadores ao longo do tempo. A classificação pode estar associada a um factor de

desempenho e todos os colaboradores têm que ter uma classificação.

Utilizadores_has_TempoPrevisto – todos os tempos previstos de cada utilizador

para a execução de cada um dos tipos de tarefas. Permite avaliar o tempo que cada

utilizador demora a executar as tarefas, em função do tipo de tarefa.

Tarefas – toda a informação necessária à execução das tarefas. As tarefas podem

ter um cliente e/ou um dispositivo associado que, por sua vez estará necessariamente

atribuido a um cliente. As tarefas têm tipos de tarefas e problemas relativos à falha da

execução das mesmas.

Tipos_Tarefas – todos os tipos de tarefas do sistema. Todas as tarefas têm que

necessariamente ter um tipo.

Tarefas_has_Tipos_Problemas – todos os problemas associados à não execução

de uma tarefa. Ou seja, cada tarefa pode ter um ou mais problemas pré-definidos

associados à falha da sua execução.

Tipos_Problemas – todos os tipos de problemas associados à falha da execução

das tarefas do sistema. As tarefas executadas com sucesso não têm problemas

associados.

Clientes – toda a informação relativa aos clientes. Os clientes podem ter zero ou

mais dispositivos associados assim como, tarefas.

Dispositivos – toda a informação relativa aos dispositivos que podem ser

necessários à execução das tarefas e atribuídos a clientes.

Tipos_Dispositivos – todos os tipos de dispositivos. Todos os dispositivos têm que

necessariamente ter um tipo.

Deslocacoes – toda a informação necessária a uma deslocação. A tabela de

deslocações é o objecto central do modelo relacional. Uma deslocação pode ter mais do

que uma tarefa associada a essa deslocação. Contudo, uma deslocação tem apenas um

utilizador que a irá efectuar. Uma deslocação pertence sempre a um percurso a realizar

por um utilizador.

Percursos – toda a informação relativa ao histórico dos percursos, incluindo os

quilómetros previstos para o percurso. Os percursos são constituídos por movimentos

entre deslocações.

Movimentos – toda a informação calculada pelo dispositivo do utilizador entre

duas deslocações. Efectua um histórico dos movimentos efectuados entre duas

deslocações.

Tipos_Estados_Percursos – todos os tipos de estados dos percursos. Os percursos

têm que necessariamente ter um estado associado.

Dos objectos descritos, interessa destacar a solução utilizada para persistir os percursos a

efectuar pelos utilizadores. A ideia surge da necessidade de um utilizador ter mais do que uma

deslocação a efectuar num dia e ser necessário um percurso para percorrer essas deslocações. Os


49

percursos têm um movimento entre duas deslocações. As deslocações são ordenadas numa

sequência de movimentos. O conjunto dos movimentos entre deslocações consecutivas forma o

percurso a efectuar.

A dinâmica dos percursos apresentada permite calcular no Back Office a sequência das

deslocações que minimiza os quilómetros percorridos e passar para o Front Office apenas o

ficheiro com um formato de itinerário que deverá ser carregado por um dispositivo GPS

apropriado.

Os formatos de ficheiros de itinerários mais conhecidos são GPX (GPS Exchange Format),

ITN (TomTom Navigator Itinerary File) e KML (Keyhole Markup Language File, usado no

Google Earth).

O modelo permite ainda suportar as modificações ao percurso de um utilizador. Ou seja,

permite fazer um replaneamento das tarefas e dos percursos ao longo do dia e guardar o seu

histórico.

5.2.4. Spring Portlets

Na aplicação Spring existem 3 camadas. A camada de «Visualização» ou View

corresponde à componente de visualização dos Portlets no portal. A camada da Integração

Aplicacional corresponde à estrutura e lógica da aplicação e, na perspectiva do modelo MVC,

ao módulo Controller. A camada da abstracção da Base de Dados, o módulo Model do modelo

MVC, corresponde à tecnologia Hibernate3 que faz o mapeamento objecto-relacional (ou

camada ORM).

A Persistência Nesta solução a persistência é feita através do mapeamento das Entidades (classes POJO –

Plain Old Data Objects) para o Modelo Relacional da BD, através de anotações da API Java

Persistence – Java Persistence Annonations (JPA) – na própria classe da Entidade. Nestas

«Entidades JPA» ou «Entidades Anotadas», o mapeamento é feito através destas anotações do

JDK 5.0 em detrimento dos ficheiros hbm.xml (o ficheiro Hibernate3, descritor do mapeamento

objecto-relacional em formato XML).

Sobre as Entidades está a camada Data Access Object (DAO). O DAO é uma técnica de

persistência que separa o objecto a persistir (a Entidade) da lógica de acesso à Base de Dados.

Na solução é utilizada a framework de persistência Spring DAO.

Esta framework utiliza um método simples para configurar o acesso à BD através da

framework EJB da plataforma Java EE. O método consiste na criação de um Spring Bean com a

configuração do acesso à BD (um DataSource Bean) que é injectado nas classes DAO. Ou seja,

para o efeito, cada classe DAO é definido um novo Bean que o associa ao DataSource Bean.

Além do mapeamento a API do Hibernate3 permite gerir as ligações e as transacções dos

DAO aos dados através de «Sessões» (Session). Estas «Sessões» são criadas/estabelecidas

através do SessionFactory da API do Hibernate3.

Assim, resumidamente, o DAO tem associado a si um DataSource e uma Entidade (POJO).

O DAO implementa os métodos de persistência das Entidades no DataSource que, no caso, será

uma Base de Dados. Os métodos dos DAO estabelecem «Sessões» de ligação à Base de Dados

(BD) através do SessionFactory do Hibernate3. As «Sessões» gerem as ligações e as

transacções para a BD, onde o mapeamento das Entidades para os Objectos da BD é feito

através das anotações (JPA) nas próprias classes das Entidades.

A Estrutura e Lógica da Aplicação A lógica da aplicação está distribuída por um componente de serviços e por um

componente Web.

O componente de serviços é constituído por métodos gestores (Managers) que aplicam a

lógica de negócio relativa à execução de tarefas, cálculos e operações com objectos. Estes

métodos prestam serviços à componente Web e utiliza a camada DAO para a persistência dos

objectos/entidades.


50

A componente Web implementa os «Controladores» (Controllers) da aplicação, onde cada

classe Controller corresponde a um Portlet da aplicação. Assim, cada Portlet tem a sua classe

Controller que gere a sua visualização e recebe os comandos do utilizador. Ou, por outras

palavras, os Controllers de cada Portlet chamam os serviços e gerem a sua visualização de

acordo com os comandos do utilizador.

Os Controllers requisitam ainda os serviços de uma componente de validação para efectuar

todo o tipo de validações relativas aos comandos do utilizador e às operações das classes

Managers, de acordo com a lógica do negócio.

A visualização dos Portlets é implementada em JavaServer Pages (JSPs) (de acordo com a

arquitectura) e com suporte para JavaScript (JS) e Cascading Style Sheets (CSS).

Todo o modelo de funcionamento da aplicação descrito pode ser visualizado na Figura 27.

Figura 27 – Modelo e Funcionamento da Aplicação Web

Conforme já referido, esta implementação da aplicação Web é feita no SpringSource Tool

Suite (IDE) com recurso à Spring Framework ou, mais especificamente, à Spring Portlet MVC

Framework.

O desenvolvimento foi feito a partir de um projecto Spring criado de raiz e está dividido

pelos componentes mencionados. Ou seja, cada componente da estrutura da aplicação

corresponde a um «Pacote» (Package) do projecto (ver Figura 28).

A compilação e publicação da aplicação no servidor do portal Liferay são feitas pela

ferramenta de compilação Java, Apache Ant através de um ficheiro build.xml desenvolvido à

medida da aplicação.


51

Figura 28 – Organização do Projecto no IDE

Configuração da aplicação A configuração da aplicação é dividida em três ficheiros essenciais: web.xml,

portlet.xml e applicationContext.xml.

O web.xml tem as configurações gerais da aplicação ao nível do servidor: configuração

relativa ao sistema de logs do servidor, caminho do ficheiro de configuração do contexto da

aplicação, configuração dos pedidos de renderização, etc.

O applicationContext.xml tem a declaração e configuração de todos os Spring Beans

associados à camada de persistência, entre outras tecnologias disponibilizadas através da Spring

Framework, tais como: Beans para resolução das vistas (JSPs),para tratamento de excepções,

para internacionalização da aplicação, etc.

O portlet.xml tem a declaração dos Portlets da aplicação e todas as configurações

associadas aos mesmos.

Existem ainda os ficheiros XML de configuração de cada Portlet. Este ficheiro de

configuração define o Controller do respectivo Portlet, entre outras definições de contexto que

podem ser específicas do Portlet.


52

Figura 29 – Estrutura da Aplicação Web

5.2.5. Portal Liferay

A configuração da aplicação relativa ao portal Liferay está dividida por três ficheiros:

liferay-plugin-package.properties, liferay-display.xml e liferay-portlet.xml.

O liferay-plugin-package.properties define as propriedades genéricas da aplicação

que funcionará como um plugin para o portal. Um plugin do portal pode ter, entre outras

propriedades, um nome, uma descrição, um autor, uma página de suporte, etc.

O liferay-display.xml declara e configura a categoria dos Portlets da aplicação para o

portal Liferay. Outras definições dos Portlets no portal são feitas no liferay-portlet.xml.

Além do desenvolvimento da aplicação da solução MRM, foi feito um estudo ao acesso do

portal através de smartphones.

Nesse estudo foi desenvolvido um tema e uma funcionalidade para o portal, com as

respectivas estratégias de desenvolvimento Theme e Hook.

O tema desenvolvido altera o CSS e o layout das páginas onde for aplicado. Apresenta os

Portlets da página numa única coluna e a faz o seu redimensionamento, adequando a

visualização do portal para smartphones.

A funcionalidade desenvolvida (o Hook) faz o redireccionamento dos utilizadores para

uma página do portal, quando é acedido por um iPhone ou Android e se efectua a autenticação.

Sem esta funcionalidade o utilizador fica na mesma página inicial após a autenticação. Esta

funcionalidade foi desenvolvida em Velocity1.

Assim, com estas duas implementações é possível redireccionar o utilizador que acede por

um smartphone directamente para a página que tem o tema adaptado ao dispositivo.

1 O Apache Velocity Engine é um motor de templates, de Código Aberto e gratuito. O Velocity

permite o uso de uma linguagem para implementar templates que referenciam objectos definidos em

código Java.


53

5.2.6. Pentaho - Business Intelligence

Entre outros tipos de acesso, a plataforma Pentaho BI permite fazer pedidos e aceder

directamente aos conteúdos gerados (gráficos, dashboard, etc.), resultantes das tarefas de BI,

através de URL.

Todas as tarefas executadas pela plataforma Pentaho BI são definidas por ficheiros XML

denominados Action Sequence. Tal como o nome sugere, estes ficheiros XML definem uma

«sequência de acções» ou seja, definem actividades como queries a Bases de Dados, geração de

relatórios, envio de Emails, etc. e permitem a passagem de dados entre acções dentro do mesmo

Action Sequence ou entre diferentes Action Sequences.

O que a plataforma permite é especificar no URL o Action Sequence correspondente ao

conteúdo que se pretende visualizar, juntamente com os dados de autenticação no servidor.

Depois, o conteúdo é gerado e carregado em páginas HTML.

Por conseguinte, a solução para a integração da componente de Apoio à Decisão no portal

baseia-se precisamente nesta funcionalidade da plataforma através de iFrame Portlets. Esses

Portlets podem ser desenvolvidos de forma mais ou menos sofisticada mas, todos tem o

objectivo de embeber outras páginas HTML dentro do portal. Desta forma, é possível ter um

conjunto de iFrame Portlets pré-definidos com pedidos URL de indicadores da plataforma

Pentaho BI.

Esta solução adoptada permite construir dinamicamente um Painel de Indicadores no portal

Liferay ou construi-lo com a ferramenta Pentaho apropriada e fazer posteriormente o pedido do

mesmo, através de iFrame Portlets.

5.3. Resultados Alcançados

Os estudos, testes e desenvolvimentos efectuados permitem perceber o modo de

implementação, a evolução e a potencialidade das tecnologias utilizadas para a solução.

No caso particular da integração da plataforma Pentaho BI no portal, esperava-se uma

integração mais sofisticada relativamente à apresentada. Existe alguma documentação que

indica que a plataforma inclui Portlets desenvolvidos para integração em portais. Esta

possibilidade foi testada através de intercomunicação de Portlets mas, os resultados

demonstraram que essa funcionalidade ainda não se encontra verdadeiramente funcional e

aplicável. O resultado mais próximo que se conseguiu foi ter o portal Liferay e a plataforma

Pentaho BI no mesmo servidor Tomcat e apresentar um Portlet HTML da plataforma no portal.

Os Portlets mais sofisticados e de real interesse não funcionam no portal.

Esta via de integração pode ter falhado por um de dois motivos. O primeiro motivo pode

prender-se simplesmente com o facto de a funcionalidade dos Portlets da plataforma Pentaho BI

não estar terminada. O segundo motivo pode dever-se à não compatibilidade dos Portlets

implementados na plataforma Pentaho BI, com a versão do portal utilizada. Contudo, o último

motivo é pouco provável, já que o conceito de Portlet é precisamente ser desenvolvido sobre

uma norma e ser portável entre portais.

A pesquisa sobre esta solução de integração da plataforma Pentaho no portal tornou-se

difícil devido à fraca documentação mantida pela comunidade, quer em quantidade, quer na

qualidade dos documentos. Para todas as outras tecnologias das funcionalidades do sistema foi

sempre encontrada a documentação necessária. Embora, no geral, o facto de estas frameworks

de Código Aberto estarem em constante evolução, torna difícil o trabalho das comunidades

acompanharem a evolução e actualizarem a documentação em tempo útil. Como exemplo,

destaca-se novamente a plataforma Pentaho que só no ano 2010 teve três lançamentos de

versões finais, mas a documentação encontrada sobre os temas necessários estão datados de

2006 a 2009.

Dado o insucesso desta solução de integração foi necessário encontrar uma solução

alternativa que permitisse disponibilizar a componente de Apoio à Decisão no portal. Assim, a

alternativa encontrada consiste em formular pedidos de Indicadores ou Painéis de Indicadores

de BI à plataforma Pentaho através de URL, conforme especificado na secção 5.2.6. Ou seja, a


54

plataforma permite publicar, no servidor da mesma, os gráficos ou outros indicadores de BI e

acedê-los directamente através de URL num Navegador Web. Esta funcionalidade pode ser

utilizada no portal com iFrame Portlets.

Em relação ao estudo inicial sobre a integração das tecnologias, apenas a plataforma

Pentaho obrigou a busca de uma alternativa na estratégia. As restantes tecnologias foram

integradas como inicialmente previsto.

Os resultados finais alcançados incluem a implementação total da arquitectura proposta

(mostrada na Figura 10), com a integração e a prova do funcionamento conjunto de todos os

seus componentes, através das seguintes acções:

Desenvolvimento de uma aplicação que demostra a integração das tecnologias em

Spring Portlet MVC, com toda a configuração em XML necessária e construtor Ant à

medida (Figura 30);

Integração da aplicação desenvolvida em Spring Portlet MVC com o portal Liferay

(Figura 30);

Desenvolvimento de um tema simples para smartphone (estratégia de desenvolvimento

Theme do Liferay) (Figura 31);

Desenvolvimento de novas funcionalidades para o portal Liferay com Velocity

(estratégia de desenvolvimento Hook do Liferay), tais como:

o Redireccionamento do utilizador para a sua página pessoal após a autenticação

no portal;

o Redireccionamento do acesso dos utilizadores ao portal através de iPhone ou

Android para a visualização adaptada aos dispositivos;

Integração da plataforma Pentaho BI com o portal Liferay através de iFrame Portlets

com pedidos URL à plataforma dos indicadores de BI (Dashboards, Gráficos,

Relatórios, etc.) (Figura 32);

Prova do não funcionamento da intercomunicação dos Portlets da plataforma Pentaho

BI com o portal Liferay, apesar de estar previsto o seu desenvolvimento e estarem

declarados na Community Edition da plataforma.

Conforme as acções descritas, para integrar e testar as tecnologias solução MRM foi

necessário recorrer a diferentes estratégias de desenvolvimento e desenvolver diferentes

projectos nas diferentes frameworks.

Da Figura 30 à Figura 32 são mostrados alguns dos resultados alcançados.

Na Figura 30 é possível verificar a integração da aplicação MRM desenvolvida em Spring

Portlet MVC Framework no portal Liferay. Do lado esquerdo da imagem, o menu de adição de

Portlets ao portal, onde o Portlet desenvolvido se encontra sob o submenu “Spring Portlet”. Do

lado direito da imagem, o respectivo Portlet, já adicionado.

Para o efeito de teste e demonstração das tecnologias da aplicação MRM, foi desenvolvido

o Portlet que faz a gestão dos tipos de tarefas da solução. Através deste é possível pré-definir os

tipos de tarefas do sistema, efectuando as operações CRUD dos objectos Tipo de Tarefa sobre a

Base de Dados.


55

Figura 30 – Demonstração do Portal e do Portlet Spring da Aplicação MRM

A Figura 31 mostra o resultado da estratégia Theme desenvolvida para o portal, onde o

mesmo Portlet (mostrado na Figura 30) é redimensionado e colocado numa única coluna junto

com outros Portlets. O Hook desenvolvido complementa esta funcionalidade, permitindo o

redireccionamento do utilizador para na página do portal com os Portlets que se pretendem

visualizar em smartphone.

Para o efeito, foi utilizado um emulador de smartphone com o sistema operativo Android.

Figura 31 – Demonstração do Tema do Portal Liferay para Smartphone

Na Figura 32 é possível visualizar o resultado da solução adoptada para a integração da

componente de Apoio à Decisão na solução. Na figura, são mostrados diferentes indicadores de

BI, de exemplo na plataforma Pentaho BI, no portal Liferay.


56

Figura 32 – Demonstração de Painel de Indicadores Pentaho no Liferay

Como o desenvolvimento efectuado é um desenvolvimento de teste e demonstração das

tecnologias, não houve cuidados especiais com a aparência e/ou enquadramento dos Portlets no

portal.

Em suma, os resultados satisfazem plenamente os objectivos da Dissertação, pois

permitem verificar a adequação e integração das tecnologias da solução apresentada às

exigências das funcionalidades esperadas para a aplicação MRM.

As tecnologias utilizadas permitem o desenvolvimento de uma aplicação consistente,

escalável e versátil que pode originar diferentes aplicações MRM adaptadas para diferentes

áreas de negócio. Com estes resultados é possível prever uma aplicação que funcionará com

base numa Base de Dados OLTP e que permitirá operar de forma eficaz, com a possibilidade da

actualização dos estados dos colaboradores em tempo real. O sucesso da integração da

componente de Business Intelligence irá permitir a análise dos dados gerados pelo sistema e

uma componente forte de Apoio à Decisão. Este facto associado às restantes funcionalidades

totalmente desenvolvidas com tecnologias de Código Aberto torna esta aplicação MRM uma

aplicação simples, de baixo custo e inovadora, em função das soluções existentes no mercado.

57

Capítulo 6

Conclusões e Trabalho Futuro

Nesta Dissertação foi concebida uma solução empresarial inovadora que é capaz de gerir

recursos móveis em tempo real e que integra uma componente de Apoio à Decisão. O seu

desenvolvimento foi feito com recurso às melhores práticas de desenvolvimento e às mais

recentes e evoluídas tecnologias de Código Aberto.

A Dissertação envolve um trabalho extenso que se inicia com a fase de enquadramento da

solução a desenvolver no mercado actual, incluindo o posicionamento da solução no mercado,

face às soluções existentes. Na fase seguinte foi feito todo o trabalho de concepção da solução,

com o estudo das frameworks candidatas e das respectivas tecnologias. Na terceira fase foi feita

a demonstração da solução integrada, com o teste e integração das tecnologias numa aplicação

empresarial Java, incluindo o suporte da componente de Apoio à Decisão com a plataforma de

BI. A quarta fase corresponde à escrita e apresentação de todo o trabalho desenvolvido na

Dissertação.

Devido à sua extensão e às tecnologias utilizadas, o trabalho desenvolvido foi bastante

desafiador. Os trabalhos da Dissertação foram executados exclusivamente pelo autor e sem

qualquer tipo de formação prévia sobre as frameworks utilizadas. A aprendizagem foi feita

através de um estudo inicial mas, principalmente aquando da implementação e teste das

tecnologias da solução. Por sua vez, as tecnologias e frameworks de Código Aberto, pelo facto

de estarem em constante evolução e fazerem parte do Estado da Arte, nem sempre têm a

documentação adequada e o melhor suporte ao desenvolvimento.

Contudo, os resultados alcançados consideram-se muito satisfatórios, na medida em que

todos os objectivos intermédios previstos foram alcançados e como tal, o objectivo principal

atingido: a concepção e teste da arquitectura e infraestrutura da aplicação empresarial capaz de

responder aos requisitos esperados para a aplicação MRM num contexto empresarial.

A solução foi desenvolvida com as tecnologias da plataforma Java EE, uma plataforma

transversal, suportada por múltiplas plataformas de desenvolvimento (Oracle, 2010). Sobre esta

plataforma foi desenvolvida uma aplicação de demonstração com recurso as tecnologias

enunciadas que se integra facilmente num portal, neste caso, no portal Liferay. Por sua vez, o

acesso de dispositivos móveis ao portal Liferay ficou testado com o desenvolvimento de um

tema (Theme) para smartphone cujo principal objectivo é adaptar a visualização dos Portlets

para o respectivo dispositivo. Assim como, ficou testado o desenvolvimento de um Hook para o

portal Liferay que detecta e faz o redireccionamento de smartphones para a página adequada ao

dispositivo. Ainda, a componente de Apoio à Decisão ficou integrada na solução através da

possibilidade da visualização dos gráficos e/ou Painéis de Indicadores da plataforma Pentaho no

portal Liferay.

Conclusões e Trabalho Futuro

58

O desenvolvimento efectuado permitiu trabalhar com as diversas estratégias de

desenvolvimento das diferentes frameworks. Para o efeito, foi necessário recorrer a diferentes

linguagens e tecnologias desde o DI da Spring Framework ao Velocity do portal Liferay.

As plataformas e tecnologias seleccionadas para o desenvolvimento da Dissertação foram

escolhidas com base nas suas funcionalidades e no seu Estado da Arte. A framework de

desenvolvimento da Spring Source é das mais avançadas e das que mais tecnologia dispõe, é

completamente modular, permitindo ao programador utilizar exactamente aquilo que precisa da

framework, tendo sempre a hipótese de integrar diferentes tecnologias na sua aplicação. Além

disso, a framework é orientada à utilização do padrão de arquitectura MVC (SpringSource,

2010).

No caso do portal Liferay e da plataforma Pentaho BI, representam o Estado da Arte nas

respectivas categorias de portais e plataformas de BI de Código Aberto. O Liferay é

amplamente usado e testado, com diversos parceiros importantes no universo das TI. A

plataforma Pentaho BI, essencialmente ao nível da Arquitectura, ambiente gráfico e usabilidade,

é a solução de BI de Código Aberto que maior potencial apresenta.

Trabalho Futuro Tendo em conta as funcionalidades previstas para a solução MRM final, a aplicação só fica

completa após o desenvolvimento dos restantes Portlets da aplicação Spring, incluindo o

desenvolvimento e implementação de um algoritmo de planeamento e escalonamento das

tarefas e a geração de percursos para os Operacionais (com exportação para ficheiros de

itinerários para dispositivos GPS). Além disso, recomenda-se o desenvolvimento de um tema

mais adequado para o portal e para smartphone.

Na componente de Business Intelligence será necessário construir dashboards a partir dos

dados resultantes do funcionamento da aplicação MRM, com recurso às ferramentas da

plataforma Pentaho BI.

Ainda na componente de BI, recomenda-se o desenvolvimento de iFrame Portlets que se

adaptem à visualização dos dashboards que forem construídos.

A integração das tecnologias foi testada e a viabilidade da solução foi demonstrada mas, só

após a conclusão destas recomendações é que será possível analisar e provar toda a

potencialidade da solução MRM concebida.

59

Referências

Aberdeen Group. Dezembro 2009. Enterprise Mobility 2010 - More Productivity, Same

Budget. s.l. : Aberdeen Group, Dezembro 2009.

—. 2009. More Mobility – Less Budget: The 2009 Enterprise Mobility Benchmark.

Aberdeen Group Web Site. [Online] Janeiro 27, 2009. http://www.aberdeen.com/aberdeen-

library/5909/RP-enterprise-mobility-applications.aspx.

Accenture. 2010. Accenture Innovation Center for Open Source. [PDF Document] 2010.

—. 2010. Accenture Innovation Center for Open Source. Accennture Web Site. [Online]

2010.

http://www.accenture.com/Global/Technology/Systems_Integration_Consulting/Services/Innov

ationOpenSource.htm.

—. 2010. Accenture Mobile Solutions - Unleashing the power of mobility solutions for

enterprise. [Online] 2010. http://www.accenture.com/NR/rdonlyres/22EE0D46-D554-4A8B-

A04D-5E8C19E405D8/0/Accenture_Mobile_Solutions.pdf.

—. 2010. Accenture Open Source Solutions. Accenture Web Site. [Online] 2010.

http://www.accenture.com/Global/Technology/Open_Source/default.htm.

AICEP . 2010. Portugal - Ficha País (Março 2010). s.l. : Agência para o Investimento e

Comércio Externo de Portugal, 2010.

Ambler, Scott W. 2010. Introduction to Test Driven Design (TDD). [Online] 2010.

http://www.agiledata.org/essays/tdd.html#WhatIsTDD.

Cisco. 2010. Cisco Context-Aware Mobility Solution: Presence Applications. Cisco

Systems Web Site. [Online] 2010.

https://www.cisco.com/en/US/solutions/collateral/ns340/ns394/ns348/ns788/brochure_c22-

497557.html.

—. 2010. Context-Aware Mobility Video. Cisco Systems Web site. [Online] 2010.

https://www.cisco.com/web/strategy/wireless/cam_grn_scrn_vid.html.

—. 2010. IBM - Strategic Alliances - Cysco Systems. Cisco Systems Web Site. [Online]

2010. http://www.cisco.com/web/partners/pr67/pr30/partners_strategic_alliance_.html.

—. 2010. Soluções de mobilidade - Cisco Systems. Cisco Systems Web Site. [Online]

2010. http://www.cisco.com/web/PT/solutions/mobility_index.html.

CSC. 2010. CSC Mobile Enterprise. CSC Web Site. [Online] 2010.

http://www.csc.com/managed_network_services/offerings/41553/41598-mobile_enterprise.

—. 2010. Mobile Executive: solutions for movers & shakers. [PDF Document] 2010.

—. 2010. Mobile Worker: powerfull solutions keep you moving. [PDF Document] 2010.

E-Commerce Times. 2009. E-Commerce News: Handled Devices: Enterprise Mobility:

An Investment That Works Harder, Smarter. E-Commerce Times Web Site. [Online] Setembro

4, 2009.

http://www.ecommercetimes.com/story/66742.html?wlc=1271670252&wlc=1272456443&wlc

=1272896028&wlc=1278256927.

Fowler, Martin. 2004. Martin Fowler - Inversion of Control Containers and the

Dependency Injection Pattern. Martin Fowler's Blog. [Online] 2004.

http://martinfowler.com/articles/injection.html.

Referências

60

Geoglobal. 2010. Geoglobal :: GeoMob. Geoglobal Web Site. [Online] 2010.

http://www.geoglobal.pt/ser_detalhe.php?aId=61.

—. 2008. GeoMob: Solução de Gestão e Controlo de Bens e Recursos Móveis. [Online]

2008. http://www.idc.pt/downloads/events/pres_2008-02-26/07_Geoglobal_2.pdf.

HP. 2010. Mobile Applications Services. HP Enterprise Services. [Online] Julho 2010.

https://h10134.www1.hp.com/services/mobileapps/.

IAPMEI. 2008. Sobre as PME em Portugal. 2008.

Intergraph Corporation. 2005. Mobile Resource Management and Beyond. Directions

Magazine. [Online] 17 de Abril de 2005.

http://www.directionsmag.com/article.php?article_id=831.

Liferay. 2010. Lifery Portal - Development Documentation. [PDF Document] s.l. : Connor

McKay, Editor, 2010.

Liferay, Inc. 2010. Enterprise open source portal and collaboration software. Liferay.com.

[Online] 2010. http://www.liferay.com/.

Ministério da Ecónomia e da Inovação. IAPMEI - Estudos e Informação Económica -

Sectores, Fileiras e Clusters. Instituto de Apoio às Pequenas e Médias Empresas e à Inovação.

[Online] http://www.iapmei.pt/iapmei-art-02.php?id=228&temaid=15.

MySQL. 2010. MySQL :: Download MySQL Workbench. MySQL.com. [Online] 2010.

http://www.mysql.com/downloads/workbench/.

Oracle. Introducing Java Portlet Specifications: JSR 168 and JSR 286. Sun Developer

Network. [Online] http://developers.sun.com/portalserver/reference/techart/jsr168/.

—. 2010. J2EE[tm] Design Patterns > Design Patterns Catalog. J2EE Patterns Catalog.

[Online] 2010. http://www.oracle.com/technetwork/java/index-jsp-136701.html.

—. 2010. Java BluePrints - J2EE Patterns. Java BluePrints: Model-View-Controller.

[Online] 2010. http://www.oracle.com/technetwork/java/mvc-detailed-136062.html.

—. 2010. Java Blueprints Patterns. Sun Developer Network. [Online] 2010.

http://java.sun.com/blueprints/patterns/index.html.

—. 2010. Java Blueprints: Guidelines, Patterns, and code for end-to-end Java applications.

Oracle Technology Network. [Online] 2010. http://www.oracle.com/technetwork/java/index-

jsp-136701.html.

—. 2010. Oracle Technology Network for Java Developers. Oracle Web Site. [Online]

2010. http://www.oracle.com/technetwork/java/index.html.

—. 2010. Your First Cup: An Introduction to the Java EE Platform. [PDF Document]

2010. PartNo: 821–1770–11.

Pentaho Community. 2008. Pentaho Community Wiki. 02. Architecture - BI Platform -

Pentaho Wiki. [Online] Janeiro 30, 2008.

http://wiki.pentaho.com/display/ServerDoc2x/02.+Architecture.

Pentaho Corporation. 2010. Data mining and machine learning used to help you

understand the business better and also improve future performace through predictive analytics.

Weka Project: Pentaho Data Integration. [Online] 2010. http://weka.pentaho.com/.

—. 2008. Introducing the Pentaho BI Suite Community Edition. [PDF Document] 2008.

—. 2010. Open Source analysis OLAP server written in Java. Enabling interactive analysis

of very large datasets stored in SQL databases without writting SQL. Mondrian: Pentaho

Analysis. [Online] 2010. http://mondrian.pentaho.com/.

—. 2010. Open Source ETL designed to bridge the gap between business and IT. Kettle

Project: Pentaho Data Integration. [Online] 2010. http://kettle.pentaho.com/.

—. 2010. Open Source report content creation, generation and distribution from all sources

of information. Pentaho Reporting Project. [Online] 2010. http://reporting.pentaho.com/.

—. 2008. Pentaho Open Source Business Intelligence Platform Technical White Paper.

[PDF Document] 2008.

Ramos, Isabel and Santos, Maribel Yasmina. 2009. Business Intelligence, Tecnologias

da Informação na Gestão do Conhecimento. s.l. : FCA - Editora de Informática, Lda, 2009.

978-972-722-516-3.

Referências

61

Santos, Maribel Yasmina and Ramos, Isabel. 2009. Business Intelligence - Tecnologias

da Informação na Gestão do Conhecimento. Lisboa : FCA - Editora de Infomática, Lda, 2009.

ISBN: 978-972-722-516-3.

Sinfic. 2010. Sinfic - Soluções de Mobilidade Newsletter. Sinfic, SA Web Site. [Online]

2010. http://www.sinfic.pt/SinficNewsletter/sinfic/Newsletter184/UN.MobileSolutions.html.

—. 2010. Soluções de Negócio. Sinfic, SA Web Site. [Online] 2010.

http://sinfic.org/SinficWeb/displayconteudo.do2?numero=23484.

Spring Source. 2010. Spring Framework 3.0.4, Reference Documentation. [PDF

Document] 2010.

SpringSource. 2010. SpringSource Tool Suite -- The Best Development Tool for

Enterprise Java. SpringSource. [Online] 2010. http://www.springsource.com/developer/sts.

Wells, Don. 2010. Extreme Programming Rules. Extreme Programming: A gentle

introduction. [Online] 2010. http://www.extremeprogramming.org/rules.html.

REFERÊNCIAS

62

Documents

Sistema de Gestão de Recursos Móveis · Resumo Cada vez mais, ... 4.1. Spring Framework 3.0 ... Figura 13 – Arquitectura da Spring MVC Framework 3.0