Guião de Relatório de Projecto / Estágiorepositorium.sdum.uminho.pt/bitstream/1822/27908/1/...vii Abstract The technological evolution of the last decades, widespread the use of

i

“Software is like entropy: It is difficult to grasp, weighs nothing, and obeys the Second Law of Thermodynamics;

i.e., it always increases.”

Norman Augustine

iii

Agradecimentos

Este trabalho foi o culminar de um ciclo de 5 anos de estudo, no fundo o ultrapassar de mais

uma etapa na minha vida académica, pessoal e profissional. As pessoas que me rodeiam no

dia-a-dia e que, de alguma forma, me ajudaram durante este longo período merecem sem

dúvida o meu reconhecimento.

Um agradecimento especial à minha namorada, por todo o apoio e companhia nas inúmeras

tarde de trabalho que, sem dúvida, permitiu a entrega desta dissertação dentro do prazo

estabelecido. A juntar a esta agradecimento é de salientar o apoio incondicional da minha

família, que sempre me incentivou e me proporcionou todas as condições necessárias para

terminar os meus estudos e ingressar no mundo profissional.

A nível profissional agradeço a todos os meus colegas da Vortal, que além das ajudas mais

técnicas me proporcionaram um ambiente de trabalho e companheirismo que me ajudou

nesta fase a vários níveis. Um agradecimento especial para o Rui Barreira pela ajuda na

elaboração da dissertação, pelas boas orientações que me concedeu e pela paciência nas

várias revisões de leitura da dissertação.

Ao meu orientador pelo apoio durante a realização da dissertação e por contribuir com

opiniões e ideias que me permitiram melhor o trabalho realizado.

À instituição de ensino, pela oportunidade concedida e por garantir todos os meios que

possibilitaram a realização desta dissertação.

Por fim, a todas as pessoas que de uma maneira ou de outra contribuíram para que esta

dissertação chegasse ao fim. O meu sincero agradecimento a todos.

v

Resumo

A evolução tecnológica das últimas décadas generalizou o uso de software para a substituição

ou suporte de múltiplos processos das empresas e, evidenciou novas perspectivas para o

desenvolvimento de soluções com altos níveis de performance, disponibilidade, escalabilidade

e flexibilidade. No contexto Vortal (empresa líder no mercado de contratação electrónica

português com a plataforma VortalNext>), esta generalização levou à necessidade da

existência mecanismos que permitam aos seus clientes a personalização/criação de áreas de

trabalho dedicadas.

Tendo esta necessidade como foco, são avaliados os diferentes componentes da plataforma

Next>, a metodologia de desenvolvimento atualmente utilizada (Model Driven Architecture) e

quais as melhores aproximações para o desenvolvimento de aplicações no âmbito de uma

plataforma web, focando as suas vantagens e desvantagens a nível arquitetural e aplicacional.

Concluiu-se que todas as soluções estudadas são adequados ao desenvolvimento de

aplicações web, sendo o seu grau de adequação variável com o contexto de utilização. São

soluções diferentes relativamente à complexidade de implementação, aos recursos

necessários, aos riscos envolvidos e à simplicidade de utilização por parte do grupo de

utilizadores finais.

Por fim, é apresentada a arquitetura de um Software Development Kit (são estudadas outras

opções, sendo esta a que oferece mais estabilidade aplicacional e mais vantagens

competitivas) e a sua integração no ecossistema aplicacional e arquitetural da

plataforma maximizando, não apenas a flexibilidade e funcionalidade para o cliente final, como

também a segurança, robustez e fiabilidade do ecossistema da plataforma. A arquitetura

definida em conjunto com o modelo de negócio apresentado formam a linha de ação indicada

para garantir a existência de aplicações personalizadas a serem executadas no ecossistema

VortalNext>.

Palavras-chave (Tema): Arquitetura de Software, Revisão, Reestruturação,

Modelação, Software Development Kit, Aplicações de

Terceiros, Model Driven Architecture.

vii

Abstract

The technological evolution of the last decades, widespread the use of software for the

replacement or support of many company processes and highlighted new perspectives for

developing solutions with high levels of performance, availability, scalability and flexibility. In

the case of Vortal (leader in the Portuguese e-procurement platforms with Vortal Next>), this

generalization led to the need of designing a tool that allows customers to customize/create

dedicated workspaces.

Focusing on this need, the different components of Vortal Next> platform are evaluated, the

currently used development methodology is studied (Model Driven Architecture) as well as what

are the best approaches for developing applications within a web platform, focusing on the

advantages and disadvantages at the architectural and applicational level.

It was concluded that all the solutions are suitable for the development of web applications,

having its degree of suitability to vary according with the context of use. They are different

solutions regarding the implementation complexity, the resources required, the risks involved

and the simplicity of use by the group of end users.

Finally, it is presented the architecture of a Software Development Kit (other options are

studied, but this is the one that offers more stability and more competitive advantages) and its

integration into the platform, maximizing not only the flexibility and functionality to the end

customer, but also the safety, robustness and reliability of the platform ecosystem. The

architecture defined along with the business model presented, form the line of action indicated

to ensure the existence of custom applications to be executed in the Vortal Next> ecosystem.

Keywords: Software Architecture, Revision, Restructuring,

Modeling, Software Development Kit, Third Party

Applications, Model Driven Architecture.

ix

ÍNDICE

1 INTRODUÇÃO ................................................................................................................................ 1

ENQUADRAMENTO ............................................................................................................................. 1

APRESENTAÇÃO DO TEMA .................................................................................................................... 4

OBJECTIVOS DA DISSERTAÇÃO .............................................................................................................. 5

ESTRUTURA DA DISSERTAÇÃO .............................................................................................................. 6

2 MODEL DRIVEN ARCHITETURE ........................................................................................................ 9

MÉTODO DE DESENVOLVIMENTO TRADICIONAL .......................................................................................... 9

MODEL DRIVEN ARCHITECTURE (MDA) ................................................................................................ 10

MODELOS ..................................................................................................................................... 11

PROCESSO DE DESENVOLVIMENTO ....................................................................................................... 11

Platform Independent Model (PIM) ........................................................................................ 12

Platform Specific Model (PSM) .............................................................................................. 13

Código Fonte ....................................................................................................................... 13

Domain Specific Language (DSL) .......................................................................................... 13

Exemplo – Do PIM ao Código ............................................................................................... 14

Tipos de Transformações ..................................................................................................... 15

FERRAMENTAS EXISTENTES ................................................................................................................ 16

VANTAGENS E DESVANTAGENS ............................................................................................................ 17

3 ARQUITETURA VORTAL NEXT> ....................................................................................................... 19

VISÃO GERAL DA ARQUITECTURA ......................................................................................................... 19

ARQUITETURA APLICACIONAL ............................................................................................................. 20

MODELOS EXISTENTES ..................................................................................................................... 21

TRANSFORMAÇÕES ENTRE MODELOS .................................................................................................... 23

PROBLEMAS DA ABORDAGEM/FERRAMENTA............................................................................................ 24

4 INTEGRAÇÃO DE APLICAÇÕES DE TERCEIROS ................................................................................. 25

APPLICATION PROGRAMMING INTERFACE ............................................................................................... 25

SOFTWARE DEVELOPMENT KITS .......................................................................................................... 28

DESENVOLVIMENTO BASEADO EM PLUG-INS ........................................................................................... 30

5 AVALIAÇÃO DAS POSSIBILIDADES .................................................................................................. 35

API’S BASEADAS EM REST ............................................................................................................... 35

Arquitetura e Escalabilidade ................................................................................................. 35

x

Facilidade de Desenvolvimento ............................................................................................. 37

Performance e Interoperabilidade ......................................................................................... 37

Time to Market .................................................................................................................... 38

Vantagem Competitiva ......................................................................................................... 38

SOFTWARE DEVELOPMENT KITS .......................................................................................................... 39



Performance e Interoperabilidade ......................................................................................... 40

Time to Market .................................................................................................................... 41


DESENVOLVIMENTO BASEADO EM PLUG-INS ............................................................................................ 42



Performance ....................................................................................................................... 43

Time to Market .................................................................................................................... 43


COMPARAÇÃO DAS ABORDAGENS ......................................................................................................... 44

6 VORTAL DEVELOPMENT SOFTWARE KIT .......................................................................................... 47

VISÃO GERAL DA ARQUITETURA ........................................................................................................... 47

“4+1” VIEW MODEL ....................................................................................................................... 49

VISTA DE CASOS DE USO .................................................................................................................. 50

PERSPETIVA DE DESENVOLVIMENTO ..................................................................................................... 52

PERSPECTIVA LÓGICA ....................................................................................................................... 53

Design Patterns ................................................................................................................... 53

Controlos do SDK ................................................................................................................ 54

Elementos gráficos ...................................................................................................................... 55

Ações ......................................................................................................................................... 58

DataSources ............................................................................................................................... 59

Páginas ...................................................................................................................................... 60

Vortal Development SDK ...................................................................................................... 62

Motor do SDK ..................................................................................................................... 63

Gerador de Código ...................................................................................................................... 64

Compilador ................................................................................................................................. 66

PERSPETIVA DE PROCESSO ................................................................................................................ 66

PERSPETIVA FISICA .......................................................................................................................... 68

MODELO DE NEGÓCIO ...................................................................................................................... 70

xi

7 CONCLUSÕES .............................................................................................................................. 73

TRABALHO REALIZADO E CONCLUSÕES ................................................................................................. 73

TRABALHO FUTURO ......................................................................................................................... 76

BIBLIOGRAFIA ..................................................................................................................................... 77

ANEXO 1 DIAGRAMA DE CASOS DE USO .......................................................................................... 81

ANEXO 2 DIAGRAMAS DE SEQUÊNCIA ............................................................................................. 82

xiii

Índice de Figuras

Figura 1 – Crescimento da disponibilização API’s _____________________________________________________________ 3

Figura 2 – Processo de desenvolvimento tradicional ___________________________________________________________ 9

Figura 3 – Modelos em MDA _______________________________________________________________________________ 11

Figura 4 – Processo de desenvolvimento da MDA ___________________________________________________________ 12

Figura 5 – Transformações PIM - PSM ______________________________________________________________________ 13

Figura 6 – Exemplo de um PIM _____________________________________________________________________________ 14

Figura 7 – Exemplo de um PSM (PostgresSQL) ______________________________________________________________ 14

Figura 8 – Exemplo de um PSM (MySQL) ___________________________________________________________________ 14

Figura 9 – Exemplo de código PostgresSQL _________________________________________________________________ 15

Figura 10 – Exemplo de código MySQL _____________________________________________________________________ 15

Figura 11 – Ciclo de transformação através de ferramentas _________________________________________________ 16

Figura 12 – Arquitetura Geral do Sistema ___________________________________________________________________ 19

Figura 13 – Porção de XML de um .mvc ____________________________________________________________________ 21

Figura 14 – Porção de XML de um .bom ____________________________________________________________________ 22

Figura 15 – Porção de XML de um .qry _____________________________________________________________________ 22

Figura 16 – Porção de XML de um .btm ____________________________________________________________________ 22

Figura 17 – Porção de XML de um .mvcman ________________________________________________________________ 23

Figura 18 – Porção de XML de um .rules ___________________________________________________________________ 23

Figura 19 – Porção de XML de um .gg ______________________________________________________________________ 23

Figura 20 – Transformações dos modelos .bom, .qry e .btm _________________________________________________ 24

Figura 21 – Visão geral do funcionamento de uma API ______________________________________________________ 26

Figura 22 – Distribuição dos diferentes tipos de API _________________________________________________________ 27

Figura 23 – Visão Geral de uma Arquitetura Orientada a Plug-Ins ____________________________________________ 30

Figura 24 – Visão Geral da Arquitetura do Eclipse ___________________________________________________________ 31

Figura 25 – Arquitetura Geral da Plataforma Joomla _________________________________________________________ 32

Figura 26 – Visão geral da arquitetura Next> com uma API REST ____________________________________________ 36

Figura 27 – API REST com múltiplas camadas ______________________________________________________________ 36

Figura 28 – Documentação Típica de uma API REST (Twitter) ________________________________________________ 37

Figura 29 – Exemplo de utilização de uma API REST ________________________________________________________ 38

Figura 30 – Visão Geral da Arquitetura Next> com um SDK __________________________________________________ 39

Figura 31 – Visão Geral da Arquitetura Next> com Suporte para Plug-ins _____________________________________ 42

Figura 32 – Arquitetura Macro da Solução __________________________________________________________________ 48

Figura 33 – “4+1” View Model Diagram ____________________________________________________________________ 50

Figura 34 – Diagrama geral de Casos de Uso _______________________________________________________________ 51

Figura 35 – Diagrama de Componentes_____________________________________________________________________ 52

xiv

Figura 36 – Package de Controlos __________________________________________________________________________ 55

Figura 37 – Diagrama geral do padrão Factory ______________________________________________________________ 56

Figura 38 – Diagrama geral do padrão Composite ___________________________________________________________ 57

Figura 39 – Package de ViewElements ______________________________________________________________________ 57

Figura 40 – Package de Actions ____________________________________________________________________________ 59

Figura 41 – Exemplo de instanciação de uma DataSource ___________________________________________________ 60

Figura 42 – Exemplo do código gerado através de uma DataSource __________________________________________ 60

Figura 43 – Package de Datasources _______________________________________________________________________ 60

Figura 44 – Package de Windows ___________________________________________________________________________ 61

Figura 45 – Diagrama geral do padrão Facade ______________________________________________________________ 62

Figura 46 – Facade para o acesso aos serviços da plataforma Next> _________________________________________ 63

Figura 47 – Diagrama geral do Motor do SDK _______________________________________________________________ 64

Figura 48 – Diagrama geral do padrão Strategy _____________________________________________________________ 65

Figura 49 – Package do Code Generator ____________________________________________________________________ 65

Figura 50 – Package do Compiler __________________________________________________________________________ 66

Figura 51 – Diagrama de sequência simplificado da criação de uma aplicação _______________________________ 67

Figura 52 – Diagrama de sequência simplificado da Submissão da Aplicação ________________________________ 68

Figura 53 – Diagrama geral de deploy ______________________________________________________________________ 68

Figura 55 – Diagrama de sequência de Criação de uma Aplicação - I ________________________________________ 82

Figura 56 – Diagrama de sequência de Criação de uma Aplicação – II _______________________________________ 83

Figura 57 – Diagrama de sequência de Submissão da Aplicação _____________________________________________ 84

Figura 58 – Diagrama de sequência de Geração do Ficheiro XML ____________________________________________ 85

Figura 59 - Diagrama de Sequência de Compilação da Aplicação Gerada ____________________________________ 86

xv

Índice de Tabelas

Tabela 1 – Comparação das diferentes abordagens para o desenvolvimento de Third Party Applications no

contexto Vortal Next> _______________________________________________________________________________________ 45

xvi

Notação e Glossário

API Application Programming Interface

B2B Business to Business

BD Base de Dados

BOM Business Object Model

BTM Business Transaction Model

CMS Content Management System

CRUD Create, Read, Update & Detele

CWM Common Warrehouse Metamodel

DC Domain Controller

G2B2B Government Business to Business

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IDE Integrated Development Environment

IIS Internet Information Services

IP Internet Protocol

JSON JavaScript Object Notation

M2M Model to Model

M2T Model to Text

MAN Management

MDA Model Driven Architecture

MDD Model Driven Development

MOF Meta Object Facility

MVC Model View Controller

xvii

OCL Object Constraint Language

OMG Object Management Group

PIM Platform Independent Model

PSM Platform Specific Model

QRY Query

QVT Query, View and Transformation

REST Representation State Transfer

SDK Software Development Kit

SGBD Sistema de Gestão de Base de Dados

STS Security Token Service

TCP Transmission Control Protocol

TTM Time to Market

URI Uniform Resource Identifier

UML Unified Modeling Language

WCF Windows Communication Foundation

XMI XML Metadata Interchange

Introdução

1

1 Introdução

Este capitulo tem o intuito de dar a conhecer o tema da dissertação, apresentando a

necessidade/problema que levou ao seu aparecimento. São apresentados os objetivos macro

da dissertação e a sua contextualização no âmbito da plataforma Vortal Next>.

Enquadramento

O software que no passado apresentava um papel quase acessório na vida de uma empresa é,

neste momento, considerado estratégico. A maioria das empresas estão dependentes da

internet e de serviços que fazem o seu negócio atingir os clientes de forma mais fácil, rápida e

global. A utilização de software nas empresas permite que estas tenham um crescimento mais

acelerado, possibilita a poupança sem a necessidade de minimizar serviços e o

acompanhamento do avanço tecnológico que se faz sentir de dia para dia.

O atual contexto organizacional e de negócio apresenta mudanças constantes no que toca ao

desenvolvimento, à utilização e à manutenção de aplicações. Estas mutações constantes

levam a estudos e esforços para melhorar as práticas de desenvolvimento de software de

forma a atingir o aumento da produtividade, da qualidade e da redução de custos. Como

consequência do aumento da qualidade do software produzido, é necessário que as

arquiteturas aplicacionais sejam adequadas e cumpram um determinado conjunto de

requisitos altamente mutáveis de negócio para negócio e que, muitas das vezes, não são

triviais de atingir.

A arquitetura do software tem, assim, um papel preponderante na qualidade e performance do

mesmo. É importante que se adapte às constantes mudanças tecnológicas e que seja o mais

flexível possível, para que quando seja necessária uma alteração esta seja controlada e pouco

ou nada afete os componentes aplicacionais já existentes.

A correta definição de uma arquitetura é um processo extremamente complexo, dado que é

necessário ter em conta aspectos chave como desempenho, segurança, disponibilidade,

escalabilidade e portabilidade [1].

Desempenho – Definido como o tempo necessário para o sistema dar resposta a um

determinado evento.

Introdução

2

Segurança – Capacidade de o sistema resistir a acessos não autorizados e mesmo

assim fornecer serviços a utilizadores legítimos.

Disponibilidade – Porção de tempo que o sistema se encontra operacional (é

usualmente referido como o intervalo de tempo entre falhas).

Escalabilidade – Define o quão bem a arquitetura pode crescer ou ser modificada de

forma a suportar novas funcionalidades não planeadas inicialmente de forma suave.

Portabilidade – Capacidade de um sistema ser executado em diferentes ambientes

computacionais.

Os conceitos acima apresentados são alguns dos muitos a ter em conta na definição de uma

arquitetura aplicacional e, conseguir que todos eles sejam cumpridos (p.e. tempo de resposta

inferior a 1 segundo e disponibilidade igual a 100%), é uma tarefa bastante complexa que leva

a que existam compromissos de forma a favorecer uns em detrimento de outros [1].

Com a banalização do uso do software, num contexto onde o desenvolvimento de uma

aplicação realmente inovadora é uma tarefa consideravelmente complexa, é importante que

certos grupos de utilizadores sejam envolvidos o mais possível e que tenham uma grande

liberdade de utilização. Uma prática comum, e que tem vindo a ganhar bastante popularidade

(Figura 1), é a disponibilização de uma API/Framework que dê a possibilidade, a conjuntos

particulares de utilizadores, de desenvolverem as suas próprias aplicações (p.e. AppStore,

GoogleAPI, etc.) de forma a corresponder às suas necessidades ou até mesmo a aumentar o

leque de funcionalidades da aplicação. Este tipo de abordagem é cada vez mais recorrente,

sendo um aspeto diferenciador para o sucesso e desenvolvimento de uma plataforma.

Uma plataforma consiste na combinação de uma arquitetura física (hardware) e aplicacional

(software) que, em conjunto, possibilitam a correta disponibilização de um produto de

software. Durante o seu ciclo de vida, novos requisitos e novas necessidades levam à alteração

de vários aspectos do sistema de forma a melhorar a qualidade e acrescentar funcionalidade.

A necessidade de mudança é quase impossível de contornar e uma plataforma que não

evoluiu cai rapidamente em desuso [2].

As alterações podem ser estritamente funcionais (afetam atributos observáveis pelos

utilizadores, como por exemplo, a interface), estritamente arquiteturais (afetam a arquitetura e

são transparentes para o utilizador, como por exemplo, a evolução estrutural e a performance)

Introdução

3

ou uma alteração funcional/arquitetural (mistura das duas referidas, como por exemplo, a

alteração da implementação). [2]

Figura 1 – Crescimento da disponibilização API’s [3]

O desenho de uma ferramenta que permita o desenvolvimento de aplicações a terceiros, é um

processo que exige um elevado esforço de análise e prototipagem. É um processo bastante

diferente do processo de desenvolvimento de uma aplicação comum, já que nesta a

preocupação é o cumprimento dos requisitos inicialmente definidos. O desenvolvimento de

uma ferramenta que permita o desenvolvimento de aplicações tem de englobar todos os

aspetos chave do domínio em questão, dos quais é possível salientar [4]:

De que forma, a segurança dos dados e dos acessos vai ser mantida;

Como garantir a facilidade de evolução da solução;

Qual o mercado alvo (é importante que a ferramenta tenha em conta o conjunto de

utilizadores que a vai utilizar);

Qual a forma de garantir uma utilização fácil e intuitiva;

Qual a informação de suporte, a que os utilizadores finais devem ter acesso.

Empresas pioneiras no desenvolvimento deste tipo de ferramentas (p.e. Google, Facebook,

Apple, Twitter, etc.) disponibilizaram soluções tecnológicas que se revelaram verdadeiras

alavancas para o aparecimento de processos de inovação que quebraram verdadeiras

barreiras sociais e tecnológicas derivando na criação de novas empresas, novas ferramentas e

novas áreas de aplicação.

A Vortal, apresenta-se como uma empresa líder no mercado de contratação eletrónica

português, com o intuito de tornar a sua plataforma (Vortal Next>) numa referência

Introdução

4

internacional da área. Para isso, é necessário que a plataforma vá de acordo com as

necessidades dos utilizadores, que garanta a melhor experiência de utilização possível e que

se diferencie dos produtos de software concorrentes. No contexto Next>, o desenho de uma

ferramenta que permita utilizadores desenvolverem as suas próprias aplicações e sua

respetiva implementação poderá ser a alavanca necessária para a distinção dos concorrentes

diretos e para a construção de uma vasta comunidade de utilizadores (da plataforma Next> e

que desenvolvem aplicações através da ferramenta).

Em suma, a possibilidade de um conjunto particular de utilizadores ser capaz de desenvolver

as suas próprias aplicações de uma forma rápida, simples e eficaz é extremamente importante

para o sucesso, reconhecimento e diferenciação de um produto de software.

Apresentação do tema

A Vortal é uma empresa especializada em plataformas eletrónicas na área da contratação

pública e privada de vários sectores, que neste momento se encontra em grande crescimento

e tem o objetivo de se tornar uma referência mundial na área com a nova plataforma, a Vortal

Next>. Com a definição deste objetivo, novas funcionalidades e necessidades surgem de dia

para dia e há, muitas vezes, a reformulação de certas áreas/componentes da plataforma

atual.

Como consequência dos motivos acima apresentados uma das novas necessidades

encontradas, no contexto da Vortal, é a criação de uma ferramenta que permita aos

utilizadores fazerem o desenvolvimento das suas próprias aplicações, como acontece, por

exemplo, com os gigantes da Apple, Google e Microsoft. A disponibilização de uma ferramenta

deste tipo, pode ser um aspeto diferenciador dos concorrentes diretos e pode alavancar o

crescimento da plataforma a nível internacional.

Para a criação desta nova ferramenta, é necessário, numa primeira fase, o levantamento e

estudo da arquitetura aplicacional existente, de todos os seus componentes, das suas relações

e do método de desenvolvimento utilizado. Numa segunda fase é entender quais as soluções

existentes no mercado para a disponibilização deste tipo de soluções e quais os impactos da

sua integração na plataforma da Vortal. Por último, é necessário a definição e a concepção do

protótipo da nova arquitetura.

Introdução

5

Objectivos da dissertação

Durante o período de realização da dissertação é esperado atingir alguns objetivos principais.

Dos objetivos principais é de salientar:

Conhecer os conceitos chave do negócio Business to Business (B2B) e a sua

aplicação na plataforma da Vortal;

o Conhecer todos os processos de B2B implementados na plataforma da Vortal

Next>, sendo capaz de descrever o seu funcionamento.

Conhecer os standards de desenvolvimento Vortal para:

o Especificações funcionais e técnicas (desenvolvimento baseado em Model

Drive Architecture), incluindo normas de documentação.

o Processo de gestão de versões de documentação e software.

Estudar a plataforma Vortal Next> e perceber as suas características (inputs, outputs,

etc.) e funcionalidades de forma a entender os pontos fracos e fortes da arquitetura.

Com o entendimento da arquitetura, é um objetivo, conceber num nova arquitetura

que forneça uma camada de abstração, aos utilizadores onde estes possam fazer os

seus próprios desenvolvimentos.

Elaborar uma metodologia de abordagem estruturada para o estudo e reestruturação

da arquitetura de uma plataforma.

Implementar um caso de estudo, de alguns processos de negócio modelados na nova

arquitetura definida.

Tendo em conta todos os pontos acima referidos, o objetivo desta dissertação é responder a

quatro questões:

1. Qual a melhor aproximação ao desenvolvimento de ferramentas que permitam o

desenvolvimento, por parte de terceiros, de aplicações/extensões no âmbito de

uma plataforma web?

2. De que forma é possível adaptar uma das aproximações ao contexto aplicacional

da plataforma Next>, trazendo valor acrescentado para esta sem por em causa o

seu funcionamento?

Introdução

6

3. Qual o mapeamento físico da solução de forma a garantir escalabilidade,

segurança e performance para uma utilização a nível mundial?

4. Qual o modelo de negócio mais indicado para a comercialização deste tipo de

ferramentas?

As respostas a estas quatro questões são o foco principal da dissertação, pois permitem

ponderar e escolher a melhor abordagem para o desenvolvimento de third party applications

no contexto arquitetural e aplicacional da plataforma Next>.

Estrutura da Dissertação

Esta dissertação encontra-se dividida em sete capítulos principais: Introdução, Model Driven

Architeture, Arquitetura Vortal Next>, Integração de Aplicações de Terceiros, Avaliação das

Possibilidades, Vortal Development Software Kit e Conclusões.

O primeiro capítulo (Introdução) tem o intuito de dar a conhecer o tema da dissertação,

apresentando a necessidade/problema que levou ao seu aparecimento. Neste capítulo são

apresentados os objetivos macro da dissertação e a sua contextualização no âmbito da

plataforma Vortal Next>.

No capítulo Model Driven Architecture são apresentados os conceitos fundamentais

relacionados com a Model Driven Architecture, referindo as suas vantagens e desvantagens.

No capítulo Arquitetura Vortal Next> é feita uma breve abordagem da arquitetura da

plataforma Vortal Next>, explicando os principais conceitos internos e os componentes da

mesma. É também explicada a abordagem MDA aplicada pela Vortal.

No capítulo de Integração de Aplicações de Terceiros são apresentadas diversas opções para

permitir o desenvolvimento de aplicações de terceiros, avaliadas as suas capacidades e

impactos. Para cada um das opções, são apresentados os casos de estudo utilizados para

entender a mais valia das soluções.

No capítulo seguinte (Avaliação das Possibilidades) as diferentes abordagens são avaliadas e

mapeadas no contexto aplicacional e arquitetural da plataforma Vortal Next> levando à escolha

de qual a melhor solução.

Introdução

7

No capítulo Vortal Software Development Kit é apresentada a arquitetura da solução a

desenvolver recorrendo a diferentes modelos UML e explicando todos os conceitos associados

à mesma.

Por último, no capítulo de Conclusões é feita uma análise do estudo efetuado durante a

dissertação e são identificados os aspetos a melhorar com a continuação da implementação

da solução.

De notar que a estrutura da dissertação, está diretamente relacionada com o plano de

trabalhos efetuado durante a sua realização. Inicialmente foi importante perceber os conceitos

associados à metodologia de desenvolvimento utilizada pela Vortal (MDA), de seguida foi

necessário perceber quais as soluções existentes para a integração de aplicações de terceiros

e respetivos trabalhos efetuados na área (casos de estudo), de maneira a escolher a solução

ideal no contexto Next>. Por último, foi feito o desenho arquitetural da solução recorrendo a

vários diagramas UML.

Model Driven Architeture

9

2 Model Driven Architeture

Este capítulo tem como intuito apresentar os conceitos fundamentais relacionados com a

Model Driven Architecture, quais as suas vantagens e desvantagens e apresentar o leque de

soluções e ferramentas existentes.

Método de desenvolvimento tradicional

A evolução no desenvolvimento de software é muitas vezes comparada à evolução no

desenvolvimento de hardware. Enquanto as evoluções no mundo do hardware são muito

significativas (processadores mais rápidos, discos rígidos/externos com mais capacidade de

armazenamento e mais compactos, etc.), no mundo do software os métodos de programação

e desenvolvimento são iguais ao que eram há 20/30 anos atrás (Figura 2). Todavia, o

progresso no desenvolvimento de software é evidente e é um facto que é possível construir

sistemas cada vez maiores e mais complexos de forma cada vez mais rápida (através de

ferramentas que auxiliam o desenvolvimento).

Criam-se, de ano para ano, novas tecnologias e linguagens com regras, nomes e processos

distintos de forma a simplificar e agilizar o processo de desenvolvimento, mas ainda não existe

nenhuma que consiga eliminar os diferentes problemas que esta área enfrenta. O

desenvolvimento de software é um trabalho intensivo, onde normalmente é preciso integrar

várias linguagens e sistemas e onde existe sempre o problema da alteração contínua de

requisitos [5].

Figura 2 – Processo de desenvolvimento tradicional [5]

Os principais problemas que o desenvolvimento de software enfrenta, na atualidade, estão

relacionados com produtividade, portabilidade e interoperabilidade [6]. O problema da

produtividade está interligado com o facto de se dispender uma grande parte do tempo de

desenvolvimento a recolher e transformar requisitos em diagramas (tipicamente UML) que, na


10

sua maioria, são ignorados na fase de programação. Por este facto, usualmente, o que é

produzido não coincide com o que foi inicialmente especificado o que obriga os

programadores a corrigir/remodelar funcionalidades (mais uma vez esta fase é, tipicamente,

realizada sem recurso a documentação).

Como já foi referido, na indústria de software, novas tecnologias e metodologias surgem com

frequência, o que leva a que muito software tenha de ser atualizado, ou até mesmo,

reformulado de forma a conseguir integrar e comunicar com os novos desenvolvimentos.

Como consequência e como, por norma, os sistemas de software não “vivem” isolados

(comunicam e utilizam outros sistemas) as questões de interoperabilidade revelam-se cada vez

mais complexas e apresentam cada vez mais um papel preponderante (p.e. desenvolvimento

web utiliza um grande leque de tecnologias).

A aproximação com base em MDA (Model Driven Architecture) tenta resolver estes e outros

problemas e apresenta-se como uma revolução no processo de desenvolvimento de software,

pelo facto de utilizar modelos e transformações para produzir sistemas de software complexos

[7].

Model Driven Architecture (MDA)

A Model Driven Architecture é uma metodologia de desenvolvimento, proposta pelo Object

Management Group (OMG), que dá enfâse e muita importância à utilização de modelos nos

processos de desenvolvimento de software. A MDA tem o objetivo de separar as

funcionalidades do sistema dos detalhes de implementação/plataforma e, através de

transformações com níveis de abstração cada vez mais específicos, gerar o sistema de

software final. Os modelos produzidos são extremamente formais e não devem conter

qualquer ambiguidade.

No fundo, é uma especificação para apoiar o desenvolvimento baseado em modelos,

designado de Model Driven Development (MDD). O MDD não é uma prática recente, mas

ganhou grande destaque e notoriedade depois do OMG propor a MDA em 2011 [8].

A MDA surge como um novo padrão que tenta elevar o processo de desenvolvimento para um

novo nível. As aplicações construídas utilizando este padrão englobam todas as áreas (desde o

sector dos transportes até ao sector da saúde), são produzidas de forma rápida e consistente

e podem ser implementadas em praticamente todas das tecnologias atuais (.NET, Java, etc.).


11

Modelos

Os modelos assumem um papel preponderante no processo de desenvolvimento através da

MDA, já que são um dos seus conceitos-chave. Um modelo é definido como uma

representação de uma parte da função, estrutura ou comportamento de um sistema (Figura 3)

e é escrito/definido através de uma linguagem de modelação bem definida e formal, que

tipicamente leva à escolha do UML. Porém esta ferramenta não é uma restrição e existe um

grande conjunto de outras possibilidades [9]. É importante que os modelos sejam completos,

consistentes e não ambíguos para garantir que a transformação dos mesmos em outros

modelos seja possível [5].

A linguagem de modelação UML é, tipicamente, escolhida para a escrita de modelos pois é a

ideal para definir os aspetos estruturais de um sistema [5] (p.e. diagramas de classe) e

quando utilizada em conjunto com Object Contraint Language (OCL) garante a definição de um

modelo consistente e preciso. Enquanto o UML garante a definção estrutural de um sistema, a

OCL permite definir e adicionar regras comportamentais que se aplicam aos diferentes

modelos [5].

Para um dado sistema podem existir vários tipos de modelos e é usual que esses modelos

possuam alguma relação entre si. Existem diversos tipos de relações, por exemplo, um modelo

pode descrever o sistema com mais detalhe que outro.

Figura 3 – Modelos em MDA

Processo de desenvolvimento

O processo de desenvolvimento através da MDA é em tudo semelhante ao processo de

desenvolvimento tradicional, atrás apresentado. As fases do processo são as mesmas e a

diferença reside na natureza dos artefactos que são criados durante cada uma das fases. Na

MDA, os artefactos são modelos formais que podem ser interpretados por um computador.

O conceito chave, por trás desta metodologia é a clara distinção entre a especificação da

funcionalidade e a especificação de como essa funcionalidade é implementada através de uma


12

determinada tecnologia. Esta distinção é atingida separando os modelos independentes da

plataforma (PIM) dos modelos dependentes da plataforma (PSM).

O processo de desenvolvimento (Figura 4) começa com a construção de um modelo com um

alto nível de abstração (independente de qualquer plataforma), designado de Platform

Independent Model (PIM). De seguida, o PIM é transformado num ou mais Platform Specific

Model (PSM). Por último, o PSM é transformado em código fonte [5].

Figura 4 – Processo de desenvolvimento da MDA

Platform Independent Model (PIM)

O primeiro modelo que resulta da utilização do processo de desenvolvimento da MDA, é um

modelo com um alto nível de abstração que representa o sistema de um ponto de vista

independente de qualquer tecnologia, ou seja, representa as partes da especificação do

sistema que não mudam de uma plataforma para outra. A este modelo dá-se o nome de

platform independet model (PIM).

Para o desenvolvimento de PIM’s é necessário uma linguagem de modelação formal e capaz

de representar as especificações pretendidas, como por exemplo o UML. Os PIM´s podem ser

utilizados em diversos níveis de abstração, nos níveis mais baixos representam apenas os

comportamentos de negócio e em níveis mais avançados podem exprimir funcionalidades

mais complexas do próprio sistema [5] [10].

A produção e o desenvolvimento dos PIM’s traz grandes vantagens, pois permite que a pessoa

responsável por definir as funcionalidades se concentre apenas nas regras de negócio e que

não tenha de ter em consideração nenhum detalhe tecnológico. Estes, permitem que a

funcionalidade seja completamente isolada dos detalhes de implementação, o que garante a

facilidade de migração para outras plataformas.


13

Platform Specific Model (PSM)

No próximo passo do desenvolvimento, o PIM é transformado num outro modelo designado de

platform specific model (PSM). O PSM é um modelo computacional que combina a

especificação do PIM em detalhes que descrevem como um sistema irá utilizar uma

determinada tecnologia.

A transformação de PIM para PSM (transformações Model-to-Model), normalmente origina

vários PSM’s que podem estar relacionados através de atributos, tipos, etc. (as relações entre

PSM’s, em MDA, designam-se por Bridges) (Figura 5). Quando, através de um PIM, se geram

PSM’s para tecnologias distintas, estes são completamente isolados e independentes (p.e. um

PIM pode ser utilizado para gerar a mesma funcionalidade para .NET e Java) (Figura 5) [10].

Figura 5 – Transformações PIM - PSM

Código Fonte

O último passo no desenvolvimento, consiste em receber os PSM’s como input e produzir o

código fonte (transformações Model-to-Text) para uma plataforma em particular. Pelo facto de

os PSM’s serem dependentes da tecnologia, esta transformação é feita de forma,

relativamente simples. De notar também que, a transformação final de um PSM pode originar

código fonte para diversas linguagens (semelhante ao que acontece na transformação de PIM

para PSM).

Domain Specific Language (DSL)

Como já foi referido em 2.3 os modelos (PIM’s) são definidos/desenhados recorrendo uma

linguagem formal que os permite ser suficientemente completos e consistentes para gerar

PSM’s e, mais tarde, código final. A linguagem normalmente escolhida para este efeito é UML

mas é possível utilizar outras linguagens ou até mesmo criar linguagens especificas para

determinados contextos, as chamadas Domain Specific Languages (DSL).


14

Uma DSL é uma linguagem de programação ou de especificação utilizada num domínio ou

problema em especifico que, normalmente, não pode ser utilizada fora desse contexto [11].

As DSL’s têm a vantagem de serem focadas num problema em especifico e de permitir

prototipar mais facilmente a aplicação final, mas têm a desvantagem de necessitarem de um

esforço de aprendizagem maior para a sua utilização [11].

Exemplo – Do PIM ao Código

Para esclarecer os conceitos de PIM e PSM e para dar a entender, um pouco, o processo de

desenvolvimento baseado em MDA irá ser apresentado um pequeno exemplo rascunho. No

exemplo existem duas entidades (Cliente e Encomenda) e o objetivo é fazer um PIM que

suporte a migração para qualquer tipo de SGBD existente. Foi utilizada a ferramenta de

modelação Visual Paradigm para o desenvolvimento do seguinte PIM.

Figura 6 – Exemplo de um PIM

Como podemos verificar, o PIM é completamente independente da plataforma (Diagrama de

Classes UML) e apenas representa os atributos e as relações das entidades. Através deste PIM

é então possível gerar vários PSM’s dependendo do SGBD que pretendemos. Os SGBD

escolhidos foram o MySQL e o PostgresSQL e assim foram obtidos os seguintes modelos de

dados.

Figura 7 – Exemplo de um PSM (PostgresSQL)

Figura 8 – Exemplo de um PSM (MySQL)


15

Como é possível observar, através de um único modelo conseguimos obter outros dois

dependentes da plataforma. O próximo passo é conseguir obter o código de implementação

das tabelas na respetiva linguagem, coisa que é possível devido às ferramentas do Visual

Paradigm. Assim, para cada PSM foi obtido o seguinte código.

Figura 9 – Exemplo de código PostgresSQL

Figura 10 – Exemplo de código MySQL

Tipos de Transformações

Como é possível observar na Figura 4, e como foi referido nos capítulos acima, existem

diferentes tipos de transformações no processo de desenvolvimento baseado em MDA. As

transformações que são responsáveis por transformar PIM’s em PSM’s, são designadas por

transformações Model-to-Model (M2M) e as que transforam PSM’s em código fonte são

designadas por transformações Model-to-Text (M2T). Estes dois tipos de transformações são

feitas através de ferramentas automáticas (como a ferramenta Visual Paradigm), que de forma

muito simplista, não são mais do que um conjunto de regras que, quando agrupadas, definem

como um modelo numa determinada linguagem pode ser transformado num outro modelo

numa linguagem destino.


16

Ferramentas existentes

A MDA depende muito do uso de ferramentas, já que estas desempenham o papel mais

importante de todo o processo, as transformações. Quando um PIM é produzido, é iniciado

um processo automático de transformação, responsável por transforma-lo num PSM e

consequentemente em código. Este processo de transformação é conseguido através da

utilização de ferramentas, que recebem o PIM como input e geram um PSM que mais tarde é

transformado em código (através da mesma ferramenta ou de uma outra auxiliar) [12].

Figura 11 – Ciclo de transformação através de ferramentas

A escolha da ferramenta é por isso, um passo determinante para o sucesso e para a qualidade

do desenvolvimento. Uma boa ferramenta de transformação deve [6]:

Suportar diferentes plataformas;

Fornecer flexibilidade suficiente para migrar entre plataformas;

Suportar linguagens de modelação distintas (UML incluído);

Integrar com outras ferramentas de desenvolvimento de software.

Devido ao facto de o processo de transformação apresentar grande complexidade e devido ao

facto de o desenvolvimento de uma ferramenta que suporte todos os pontos acima

apresentados ser muito complexo, existem ferramentas que apenas suportam a transformação

PIM/PSM, outras que suportam PIM/PSM/Código e como seria de esperar outras que

suportam PSM/Código (mais comuns).

Como exemplo de ferramentas que implementam transformações desde o PIM até ao código

final, temos algumas ferramentas CASE como o Visual Paradigm e o Enterprise Architect que

utilizam UML para definição dos modelos e permitem a geração de código para inúmeras

linguagens. Nestas ferramentas o processo de transformação é bidirecional, ou seja, as

alterações feitas num determinado PIM são refletidas num PSM, mas o contrário também se

verifica.


17

Vantagens e desvantagens

Como foi referido no capítulo 2.1, o processo de desenvolvimento de software tradicional tem

alguns problemas, problemas esses que a MDA tenta resolver da melhor maneira possível. É

sabido que não existem formas perfeitas para o desenvolvimento de software, cada

paradigma/metodologia tem as suas vantagens e desvantagens, cabendo à equipa de

desenvolvimento decidir qual a melhor aproximação a utilizar.

Uma das vantagens de salientar é a clara separação entre PIM’s, PSM’s e ferramentas

automáticas de transformação. Isto garante que os responsáveis pelo desenvolvimento dos

PIM´s, não necessitem de se preocupar com detalhes específicos das plataformas e podem

focar a sua atenção na especificação da funcionalidade que melhor se adequa aos utilizadores

finais. Por outro lado, ao nível dos PSM’s é produzido muito menos código, pelo facto de uma

grande porção deste ser automaticamente produzido [5].

Com a utilização do MDA, a questão da portabilidade é largamente simplificada. A

portabilidade é, facilmente, atingida pelo facto de o mesmo PIM poder gerar diferentes PSM’s

para diferentes plataformas e tecnologias.

Para além das vantagens a nível técnico, é também importante referir que através da

utilização de MDA é possível garantir a padronização de código fonte e é conseguida uma

agilização e flexibilidade no tempo de resposta a problemas.

Como todas as abordagens, existem problemas e desvantagens que têm de ser tidos em

conta. No que toca ao MDA, é de salientar o facto de ser introduzida alguma rigidez no

processo de desenvolvimento, ou seja, pelo facto de se programar menos e se gerar mais,

nem todos os pormenores podem ser alterados e manipulados (pelo menos sem alterar o

próprio gerador). Outro problema que é importante salientar, é a mudança dos papéis dos

elementos da equipa já que, a necessidade de programação é menor e a necessidade de

especificação do sistema é acrescida [13].

Arquitetura Vortal Next>

19

3 Arquitetura Vortal Next>

Este capítulo tem como intuito fazer uma breve abordagem da arquitetura da plataforma Vortal

Next>, explicando os principais conceitos internos e os componentes da mesma. Será

abordada e explicada a abordagem seguida pela empresa Vortal para implementar a

metodologia MDA em termos de inputs, outputs e das transformações desde o processo de

definição do PIM até ao código final.

Visão Geral da Arquitectura

A arquitetura da plataforma Next> foi pensada e desenhada de forma a ser possível atingir alta

escalabilidade e alta disponibilidade. A disponibilidade é um fator crucial devido ao facto de se

tratar de um serviço que lida com dados confidenciais e de alta responsabilidade social.

Na Figura 12, que ilustra a arquitetura geral do sistema, é possível observar que a plataforma

é constituída por diversos componentes abstractos com funções bastante distintas, os

Marketplaces, os Markets, o Community e os Portais. Os conceitos apresentados são de teor

conceptual, ou seja, não têm qualquer mapeamento físico na infraestrutura.

Figura 12 – Arquitetura Geral do Sistema

O Community tem a função de atuar como um centralizador do ecossistema Next> (união do

Community e de todos os Marketplaces), ou seja, tem o papel de funcionar como um gestor

de vários conteúdos que são comuns a todos os Marketplaces (p.e. identificação e gestão de

empresas e utilizadores, traduções, entre outros). De notar que na atual arquitetura apenas

pode existir um Community por ecossistema.


20

Os Portais, como é possível observar na figura, encontram-se divididos em Público e

Vortal/Corporativo. O Portal Público é o que é disponibilizado ao mercado e o Portal

Corporativo, neste momento, apenas é constituído por uma empresa, a Vortal. Os Portais não

existem fisicamente (apenas são representados logicamente) e funcionam como um agregador

de Marketplaces.

Os Marketplaces, de uma forma muito genérica, podem ser descritos como a área de trabalho

dos compradores e dos fornecedores e onde estes podem interagir de forma a concretizar o

melhor negócio possível. É no Marketplace que decorrem as diferentes interações presentes

no processo de contratação pública ou privada.

Por último é importante referir que, um conceito que não se encontra representado no

diagrama, é o conceito de Market. O Market encontra-se definido dentro de um Marketplace

(um Marketplace tem vários markets) e, como o nome indica, representa o mercado de

contratação (Construção Civil, Área da Saúde, Processos Públicos, entre outros).

Em suma, é possível concluir que a arquitetura Next> é construída por diferentes

componentes, que se encontram ligados entre si. O Community é um componente único no

ecossistema enquanto um Portal é constituído por um ou vários Marketplaces e estes, por sua

vez, são constituído por um ou vários Markets.

Arquitetura Aplicacional

A plataforma Vortal Next> é constituída por várias aplicações, que seguem o padrão

arquitetural Model View Controller (MVC) e onde a comunicação entre Front End e Back End é

concretizada através de Windows Communication Foundation (WCF é utilizado para a

construção de aplicações orientadas a serviços).

Estas aplicações foram desenvolvidas utilizando a metodologia de desenvolvimento Model

Driven Architecture. Pelo facto de a abordagem MDA utilizada ser bastante distinta da

abordagem convencional, foi feito um overview tanto da abordagem convencional e será,

agora, explicada a abordagem utilizada. Como o intuito da dissertação é a revisão e a

restruturação da arquitetura de forma a permitir o desenvolvimento de aplicações, numa

primeira fase, os conceitos relacionados com o MDA são muito importantes para alterações,

desenvolvimentos e revisões futuras.


21

Modelos existentes

Como já foi referido, a MDA é baseada em modelos especificados através de uma Domain

Specific Language e, no caso da Vortal, foram definidos vários tipos de modelos e vários tipos

de linguagens para cada um desses modelos. Os modelos definidos foram baseados em XML

e XSD (para validação de conteúdo), modelos estes que são interpretados por um motor Java

(aplicação MDAStudio desenvolvida para a Vortal Next>) que por sua vez é responsável por

gerar código .NET e SQL.

Em primeiro lugar, é importante referir quais os tipos de modelos existentes e quais as suas

funções no âmbito da plataforma Vortal Next>. Os tipos de modelos existentes são,

nomeadamente:

.mvc (Model View Controller) – Representam os componentes de View, Model e

Controller de uma determinada página

Figura 13 – Porção de XML de um .mvc

.bom (Business Object Model) – Representam uma entidade de negócio e todos os

seus atributos e relações


22

Figura 14 – Porção de XML de um .bom

.qry (Query) – Representam Stored Procedures em SQL Server

Figura 15 – Porção de XML de um .qry

.btm (Business Transaction Model) – Representam qualquer operação que altere uma

entidade de negócio

Figura 16 – Porção de XML de um .btm

.mvcman (MVC Management) – São uma abstração dos .mvc, funcionam como uma

página de gestão de entidades


23

Figura 17 – Porção de XML de um .mvcman

.rules – Representam restrições ao nível dos .bom

Figura 18 – Porção de XML de um .rules

.gg – Representam as expressões/palavras que devem estar no tradutor

Figura 19 – Porção de XML de um .gg

.cfgman (Configuration Management) – Representam as configurações das aplicações

e dos ambientes

Transformações entre modelos

Com os diferentes tipos de modelos em mente, é possível então perceber quais os tipos de

transformações que estes sofrem até ser gerado o código final da aplicação, transformações

essas que podem ser M2M (Model-to-Model) ou M2T (Model-to-Text). De notar, que devido ao

facto de a comunicação Front End/Back End ser feita através de WCF (Windows


24

Communication Foundation), em muitos dos processos de transformação são gerados serviços

para esse efeito. Assim, o workflow de transformações dos modelos (.bom, .qry e .btm) é o

seguinte:

Figura 20 – Transformações dos modelos .bom, .qry e .btm

O workflow de transformação dos modelos .mvc/.mvcman não é exemplificado, pois estes são

diretamente transformados em código .NET, ou seja, este modelos são recebidos como Input

pelo MDAStudio e automaticamente é gerado o código correspondente à View, ao Model e ao

Controller (este último necessita de ser implementado e modificado pelo programador).

Problemas da abordagem/ferramenta

A ferramenta de MDA da Vortal foi desenvolvida com o intuito de padronizar e agilizar o

desenvolvimento da plataforma, e de maneira a ser atingida uma maior qualidade e segurança

no desenvolvimento. A verdade é que a plataforma cresceu de tal forma, que as aplicações

atingiram um tamanho bastante considerável e as dependências entre aplicações causaram

uma perda de agilidade no desenvolvimento devido ao tempo de transformação/geração dos

modelos (processo que demora cerca de 30 minutos atualmente).

Para além do tempo de transformação/geração, a ferramenta atingiu tal dimensão que uma

mudança ao nível, por exemplo, da linguagem final que está a ser gerada exige um grande

esforço de programação e refactoring. Apesar de os modelos utilizados serem independentes

da plataforma, a sua transformação para código final (transformação M2T) apenas é possível

para uma linguagem especifica, ou seja, o conceito de um único modelo poder gerar código

fonte para linguagens e plataformas distintas (p.e. .NET e Java) é perdido.

Integração de Aplicações de Terceiros

25

4 Integração de Aplicações de Terceiros

Existem na literatura, diversas aproximações à forma de possibilitar extensibilidade a uma

plataforma, tendo cada uma as suas vantagens e desvantagens mediante os seus objetivos,

ambientes e tecnologias utilizadas.

As diferentes abordagens apresentadas, são utilizadas em contextos web distintos,

dependendo do público alvo e de quais os conteúdos a disponibilizar. É importante perceber e

estudar o porquê e quais os contextos em que as abordagens são mais utilizadas e quais as

razões que levam à sua escolha.

Nas secções abaixo, serão apresentadas diversas opções, avaliadas as suas capacidades e

impactos e selecionada qual a melhor opção para o contexto atual, tendo em conta não só as

opções tecnológicas como também o seu time to market.

Application Programming Interface

Uma Application Programming Interface (API) tem o intuito de disponibilizar a parceiros e

programadores externos (Third Party Developers), o acesso a componentes e serviços de

maneira a possibilitar o rápido e eficaz desenvolvimento de aplicações (p.e. API do Twitter e do

Facebook). Uma API é, essencialmente, um contrato entre a aplicação e o programador, que

garante a confiança e a eficiência da ligação (Figura 21) [14] [15].

Existem dois tipos distintos de API’s, as públicas e as privadas. Uma API pública é

disponibilizada livremente a todos os utilizadores, enquanto que uma API privada é utilizada no

contexto de uma entidade para o desenvolvimento da própria aplicação, sendo também

disponibilizada a parceiros mediante um acordo contratual (pode representar uma grande

fonte de receitas da organização) [14].

No contexto web, as API’s, são normalmente disponibilizadas através de Web Services REST

(Representation State Transfer). Este tipo de API’s, recebe pedidos HTTP do cliente e, através

da interpretação do seu conteúdo, são geradas as respostas adequadas (tipicamente em

formato JavaScript Object Notation, mais conhecido por JSON) [15] [16].


26

Figura 21 – Visão geral do funcionamento de uma API

Este tipo de API tem a vantagem de ser, relativamente, fácil de utilizar e desenvolver, mas

onde é necessário ponderar os riscos legais, técnicos e estratégicos associados. Ao

implementar uma API, cuidados especiais com a autenticação dos utilizadores e com a

segurança dos dados são importantes e é necessário garantir que o trafego direcionado à

mesma não afeta o correto funcionamento da plataforma [14].

Alguns dos perigos associados ao desenvolvimento de uma API, incluem [14]:

Violação de questões legais;

Ataques direcionados à API ou ao conteúdo disponibilizado;

Exposição do negócio aos concorrentes diretos;

Conseguir com que a infraestrutura seja capaz de suportar o tráfego gerado pelos

pedidos dos clientes e que consiga retornar a resposta adequada.

Atualmente, a internet é o difusor de informação mais utilizado a nível mundial devido ao

crescimento da utilização de redes sociais como o Twitter, o Facebook e o Google+. Pelo facto

de o leque de redes sociais ser muito alargado e de a quantidade de informação e utilizadores

ser enorme, é comum este tipo de plataforma disponibilizar uma API para o acesso a

informação e serviços. Inicialmente, as API’s eram disponibilizadas através de Web Services

SOAP, mas mais tarde surgiu a abordagem REST (Representational State Transfer) que levou à

migração de muitas API’s (p.e. Google) e afirma-se, atualmente, como a abordagem mais

utilizada e mais vantajosa (Figura 22) [17].

Como já foi referido, a API da Google era disponibilizada utilizando unicamente Web Services

SOAP mas, após o aparecimento do protocolo REST esta foi atualizada e disponibilizada

utilizando o mesmo. Esta mudança permitiu à Google reduzir, quase para metade, a largura

de banda utilizada no dia a dia.


27

Figura 22 – Distribuição dos diferentes tipos de API [18]

Representational State Transfer (REST), é um estilo arquitetural não padronizado baseado no

standard HTTP (Hypertext Transfer Protocol). Neste protocolo, tudo é modelado com base em

recursos tendo cada recurso tem um URI (Uniform Resource Identifier) único associado [19].

Serviços REST “puros” são completamente stateless (não guardam informação do cliente do

lado do servidor), o que faz com que sejam especialmente indicados para o desenvolvimento

de uma API pública focada em operações de Create-Update-Read-Delete (como é o caso das

redes sociais) [19].

Estas arquiteturas têm dois componentes essenciais: clientes e servidores. Os clientes fazem

pedidos a um determinado recurso localizado no servidor, onde estes são interpretados de

forma a gerar a resposta adequada. Os pedidos são efetuados utilizando os métodos:

GET é utilizado para obter informação de um recurso sem o modificar;

POST é utilizado para criar e editar informação;

PUT é utilizado para atualizar informação;

DELETE é usado para remover informação do servidor.

Um recurso é, essencialmente, qualquer conceito/informação que possa ser endereçada por

um URI [16].

REST suporta variados tipos de dados (p.e. JSON) e tem ganhos de performance e

escalabilidade em relação às soluções concorrentes, já que consegue transmitir o mesmo tipo

de informação utilizando menor largura de banda. A largura de banda é, neste momento, um

ponto fulcral a ter em conta no desenvolvimento de uma API devido ao constante crescimento

de utilização dos dispositivos móveis no dia a dia [15].


28

Os conceitos chave associados ao REST são [14]:

Interface de separação entre cliente e servidor;

Não é guardada qualquer informação do cliente no servidor (stateless);

Camadas intermédias que permitem aumentar a escalabilidade e a segurança (o

cliente não percebe se está ligado ao servidor principal ou a um intermédio);

Orientado a recursos.

Uma API REST é extremamente vantajosa, como já foi referido, quando o foco é a gestão de

dados (CRUD) garantindo o desenvolvimento de aplicações móveis com um consumo de

largura de banda reduzida e de performance elevada, podendo mesmo ser um fator

diferenciador dos concorrentes do mercado.

Software Development Kits

Um Software Development Kit (SDK) representa um conjunto de ferramentas de

desenvolvimento com uma estrutura bem definida, e permite o desenvolvimento de software

para um determinado sistema operativo, consola, dispositivo móvel, ou qualquer outra

plataforma similar. Um SDK, normalmente, tem um IDE (Integrated Development

Environment) associado que ajuda os programadores no desenvolvimento de software com

maior qualidade dado que inclui funcionalidades como debug e validação sintática e semântica

em tempo de desenvolvimento. As ferramentas incluídas num SDK devem ser suficientes para

permitir criar, depurar, manter, testar e suportar as aplicações desenvolvidas.

São, normalmente, produtos de software extremamente robustos e escaláveis compostos por

diferentes camadas de abstração. O número de camadas e a sua divisão depende muito do

contexto de desenvolvimento e do tipo de SDK. Tipicamente, existe uma camada de baixo nível

que funciona como elemento de ligação a diversos ambientes (p.e. base de dados), uma

camada responsável por conter todas as bibliotecas passíveis de serem utilizadas pelo mesmo

(p.e. JFace e SWT) e uma camada responsável por lidar com os eventos do utilizador e

produzir as respostas adequadas [20].

A maior parte das empresas disponibilizam os SDK’s de forma totalmente gratuita, já que o

grande objetivo é conseguir que programadores externos desenvolvam aplicações com

qualidade de forma a enriquecer a plataforma (p.e. Google PlayStore). Tendo em conta que


29

todos os SDK’s são diferentes, é importante garantir um repositório de documentação

alargado, bem como uma linguagem/metodologia de fácil aprendizagem e utilização.

Com o aparecimento dos smartphones (Android e iPhone), houve a necessidade de criar uma

comunidade de utilizadores de forma a que estes pudessem colmatar as suas necessidades

da melhor forma possível e partilhar essas soluções com o mundo. Esta proliferação de

aplicações e a sua consequente necessidade de distribuição levou à definição de novos

modelos de negócio materializados no conceito de loja online, como por exemplo, os

mercados aplicacionais da Apple (AppStore) e da Google (PlayStore) [17]. Ambas as entidades,

disponibilizaram um SDK que possibilita o desenvolvimento de aplicações que, para além de

potenciar o crescimento da comunidade, representa uma grande parte dos seus lucros.

A AppStore, por exemplo, iniciou a sua atividade em Julho de 2008 e em Janeiro de 2011

atingiu a marca de 10 biliões de aplicações descarregadas. Durante este período de tempo

houve inúmeras aplicações a surgir diariamente e muitas se afirmaram como necessárias,

fazendo agora parte do nosso quotidiano. A loja da Apple, é reconhecida e disponibilizada em

todo o mundo e a luta para o desenvolvimento de um aplicação inovadora e com sucesso é

tanta que no ano 2010 a Apple arrecadou cerca de 250 milhões de dólares com o seu

mercado virtual. A Google é outro caso de sucesso, com 300 milhões de dispositivos ativos e

mais de 450 000 aplicações disponíveis [17].

Estes números continuam a crescer e a procura de aplicações para satisfazer as necessidades

diárias é cada vez maior, o que leva a que muitas empresas se especializem no ramo do

desenvolvimento de aplicações para dispositivos móveis.

No caso da Apple e da Google, é necessário garantir que os utilizadores têm acesso a uma

ferramenta de desenvolvimento com uma linguagem definida (quando se refere a linguagem,

entende-se também padrões de desenvolvimento, como por exemplo o Model-View-Controller)

com uma arquitetura bastante robusta, onde todos os testes e desenvolvimentos podem ser

executados através de emuladores. O resultado destas ferramentas de desenvolvimento são

pacotes de software como jogos ou aplicações que, depois de validados, são integrados no

mercado e disponibilizados a todos os utilizadores de forma gratuita ou não. É neste casos que

os SDK’s se afirmam em relação às restantes abordagens como a grande opção de

desenvolvimento de aplicações por parte de terceiros.


30

Desenvolvimento baseado em Plug-Ins

Por último, existe também a possibilidade de o desenvolvimento das aplicações ser feito com

base em plug-ins, ou seja, os programadores desenvolvem software para adicionar funções

muito especificas a uma determinada plataforma. Os plug-ins são normalmente pacotes de

software pequenos e leves a nível computacional que são escolhidos e instalados pelos

utilizadores de forma a colmatar as suas necessidades e, normalmente, não requerem

qualquer tarefa de configuração [21].

Quando uma plataforma suporta o desenvolvimento baseado em plug-ins (host/core

application), esta fornece os serviços que podem ser utilizados pelo plug-in e garante um

mecanismo de gestão dos mesmos (Figura 23). Assim, um plug-in não é um componente

isolado e o seu ciclo de vida depende, inteiramente, da host application [21].

Figura 23 – Visão Geral de uma Arquitetura Orientada a Plug-Ins

Algumas das razões, mais fortes, que impulsionam o desenvolvimento de uma arquitetura

com suporte ao desenvolvimento de plug-ins são [22]:

A possibilidade de programadores externos aumentarem as funcionalidades da

aplicação;

Possibilidade de os programadores internos adicionarem funcionalidades ao core

aplicacional sem comprometer a plataforma já existente;

Fácil adição de funcionalidades e alta escalabilidade (facilidade de evolução);

Separar o core aplicacional de funcionalidades extra (diminuir o tamanho da

aplicação).


31

O desenvolvimento baseado em plug-ins é uma abordagem bastante comum no mundo da

informática. Foi utilizada pela primeira vez num editor de texto (EDT) e, atualmente, é utilizada

para as mais variadas operações (p.e. programas de edição gráfica, como o Photoshop,

utilizam plug-ins para suportar novos tipos de imagens e os browsers utilizam plug-ins para

disponibilizar novas funcionalidades aos seus utilizadores).

O Eclipse (IDE desenvolvido em Java) é uns dos mais interessantes casos de sucesso quando

se pensa no ramo de desenvolvimento baseado em plug-ins. Devido a um grande número de

programadores, o Eclipse oferece uma extensa biblioteca de plug-ins e suporta uma grande

variedade de linguagens de programação [23]. Devido a esta flexibilidade, e tendo em conta o

sucesso e crescimento atingido a nível mundial, o Eclipse será utilizado como objeto de estudo

de forma a serem entendidos os seus componentes e conceitos principais.

O principais componentes da arquitetura do Eclipse são o workbench e o workspace. O

workbench é a entidade responsável pela interface gráfica da ferramenta e pela gestão das

janelas [24]. O workspace funciona como um sistema de ficheiros responsável por criar,

guardar e editar ficheiros, diretórios e projetos (Figura 24) [23].

Os plug-ins, no contexto do Eclipse, são programas que são carregados e conectados através

de pontos de extensão (extension points) e expõem as funcionalidades do sistema [24]. É

possível que plug-ins distintos se conectem entre si para aumentar o leque de funcionalidades.

(Figura 24) [21].

Figura 24 – Visão Geral da Arquitetura do Eclipse [20]

Com a constante necessidade de as empresas exporem os seus serviços na web, novas

formas e metodologias foram pensadas e desenvolvidas de forma a permitir que pessoas com


32

poucos ou nenhuns conhecimentos técnicos conseguissem desenvolver um web site funcional

e apelativo com os conteúdos desejados. Existem na web diversas abordagens e soluções para

o fazer, cada uma delas com as suas vantagens e desvantagens. Uma das formas de

desenvolvimento que surgiu nesse contexto, foi o desenvolvimento baseado em plug-ins e

associado a Content Management Systems (CMS) (p.e. Wordpress, Joomla e DotNetNuke) [25]

[26].

O uso de CMS’s traz grandes vantagens pois permite a criação rápida e eficaz de um web site

completamente funcional. Os CMS’s possibilitam a fácil alteração de conteúdos, garantem um

nível de segurança relativamente elevado e disponibilizam, no seu core, funcionalidades base

muito utilizadas (p.e. sistema de gestão de mensagens e de utilizadores). São os chamados

sistemas “easy to use, hard to master” [25]. Em contrapartida, os CMS’s, são sistema

pesados que necessitam de bastantes recursos a nível de hardware e constantes upgrades ao

nível de software [27].

O desenvolvimento de plug-ins enquadra-se no contexto do desenvolvimento de CMS’s, pois

estes permitem acrescentar funcionalidades ao sistema base de forma a melhor corresponder

às necessidades dos utilizadores [27].

O Joomla!, em consistência com o Wordpress, é um dos CMS’s mais conhecidos e mais

utilizados a nível mundial, sendo constituído por dois conjuntos de librarias base: o primeiro

conjunto são as librarias mantidas por programadores do Joomla; o segundo são as librarias

mantidas por programadores externos (Third Party Developers). No topo das librarias base do

CMS existe uma camada de abstração, responsável por fazer a ponte entre os plug-ins

desenvolvidos (por terceiros ou até mesmo pelos próprios programadores do Joomla) e as

librarias acima apresentadas (Figura 25) [28].

Figura 25 – Arquitetura Geral da Plataforma Joomla [28]

O desenvolvimento baseado em plug-ins garante a extensibilidade da aplicação (constante

desenvolvimento de novas funcionalidades), permite o desenvolvimento em paralelo (os plug-


33

ins são componentes isolados) e, pelo facto de um plug-in normalmente representar uma

funcionalidade específica, o seu desenvolvimento é focado não existindo over-development

[25]. Apesar de ser uma abordagem extremamente flexível e que garante um alto nível de

escalabilidade é, de todas as abordagens apresentas, aquela que possivelmente traz mais

complexidade e riscos associados. A complexidade deste tipo de aplicação cresce

exponencialmente com o número de plug-ins desenvolvidos e, com isso, aumenta a dificuldade

de gestão e probabilidade de conflitos entre os mesmos. Uma das dificuldades associadas a

este tipo de abordagem é a de garantir a gestão e compatibilidade entre diferentes versões do

mesmo plug-in [22].

É ainda necessário que exista um mecanismo que valide o conteúdo dos plug-ins

desenvolvidos, para que estes não interfiram no bom funcionamento do core aplicacional e um

mecanismo que garanta a integração dos mesmos com o core aplicacional.

Avaliação das Possibilidades

35

5 Avaliação das Possibilidades

Derivado do estudo previamente efetuado e no sentido de identificar quais as abordagens mais

utilizadas de forma a permitir o desenvolvimento de Third Party Applications, é necessário

avaliar e mapear estas abordagens no contexto aplicacional e arquitetural da plataforma Vortal

Next>. Por cada abordagem, é avaliado o seu impacto na arquitetura atual e a facilidade de

desenvolvimento quer na perspetiva do utilizador final quer na perspectiva da complexidade da

solução. Questões relacionadas com a performance e interoperabilidade da solução serão

também avaliadas e, por último, será avaliada a abordagem a nível de time-to-market e

vantagem competitiva para o negócio atual da Vortal.

API’S baseadas em REST

No contexto Next>, uma API REST é um serviço que poderá trazer grandes vantagens, dado

que permite o desenvolvimento de diversas aplicações para uma gama de dispositivos mais

alargada. Sendo a Next> uma plataforma com o intuito de se tornar uma referência

internacional no mercado de contratação eletrónica, é essencial que acompanhe o avanço

tecnológico e proporcione diversas formas de integração com plataformas externas.

Arquitetura e Escalabilidade

Como já foi referido (3.1), no ecossistema Next> existem dois componentes principais: o

Marketplace e o Community. O Community funciona como um gestor de vários conteúdos

(p.e. informação de empresas) e o Marketplace representa a área de trabalho dos

compradores e dos fornecedores. Assim, é possível concluir que a informação com mais

relevância para o negócio do utilizador se encontra ao nível do Marketplace, ou seja, toda a

informação relacionada com as consultas da plataforma (respostas, avaliações, negociações,

etc. ). Devido a este facto, o Marketplace vai ser o foco de toda a dissertação e de todas as

soluções apresentadas, sem prejuízo de a arquitetura da solução apresentar flexibilidade

suficiente para a inclusão de informação derivada de outras fontes internas à plataforma.

Assim sendo, quando se pensa na disponibilização de uma API, é aconselhável que esta se

encontre ao nível do Marketplace, que seja acessível através de Web Services REST, que seja

responsável pela comunicação com a plataforma e pelo retorno dos dados no formato

adequado (Figura 26).

Avaliação das Possibilidades

36

Figura 26 – Visão geral da arquitetura Next> com uma API REST

Esta solução tem um impacto reduzido na arquitetura dado que apenas é necessário definir

camadas de acesso independentes da arquitetura atual que, por sua vez, possuam os

métodos necessários para aceder aos dados já existentes.

A escalabilidade é, muitas vezes, referida como a facilidade de um sistema ser modificado de

forma a responder a um determinado problema. Esta definição de escalabilidade é

suficientemente vaga para gerar confusão e diferentes opiniões relativamente ao assunto. A

es

Documents

Guião de Relatório de Projecto / Estágiorepositorium.sdum.uminho.pt/bitstream/1822/27908/1/...vii Abstract The technological evolution of the last decades, widespread the use of