guião de relatório de projecto / estágio · pim platform independent model psm platform specific...

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).


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

escalabilidade é, um conceito bastante simples que assenta em três princípios base [29]:

Capacidade de um sistema se adaptar ao aumento de utilização;

Capacidade de um sistema suportar um maior conjunto de dados;

O sistema ser de fácil manutenção.

Para uma API REST garantir alta escalabilidade é necessário uma arquitetura por camadas tal

como numa aplicação web, ou seja, pode existir uma camada responsável por receber pedidos

de clientes e uma outra para aceder a um ou vários recursos para fornecer a resposta

adequada (Figura 27) [30] . Se pensarmos numa API como uma aplicação web comum, a alta

escalabilidade pode ser garantida utilizando uma aproximação ao padrão arquitetural Model-

View-Controller.

Figura 27 – API REST com múltiplas camadas [30]


37

Facilidade de Desenvolvimento

Uma API REST deve ser sempre acompanhada de uma manual de utilização (i.e.

documentação), onde são explicados quais os métodos existentes e a forma de os invocar

(Figura 28). Assim, do ponto de vista dos utilizadores finais, a utilização de uma API é um

processo bastante simples e de fácil habituação que consiste na realização de pedidos HTTP e

interpretar/tratar as respostas do servidor.

Apesar de ser uma abordagem de fácil utilização, esta apenas fornece a possibilidade de

realização de operações de gestão sobre a informação (leituras e escritas), o que significa que

os restantes componentes aplicacionais, como a interface, têm de ser garantidos e preparados

pelos utilizadores.

Figura 28 – Documentação Típica de uma API REST (Twitter) [31]

A disponibilização da API REST é, sem dúvida, a mais simples das três abordagens

mencionadas. De uma forma muito genérica, para esta solução é necessário garantir uma

camada aplicacional de Web Services (Figura 26) responsáveis por receber pedidos HTTP,

comunicar com o servidor e gerar uma resposta adequada.

Performance e Interoperabilidade

Segundo a Yahoo [32], a melhor técnica para aumentar a performance web é minimizar o

número de pedidos HTTP. Pelo facto de a utilização das API’s REST ser baseada em

constantes pedidos HTTP ao servidor, rapidamente se conclui que este principio é perdido e

que a performance da plataforma é afetada.

Com o crescimento de utilização da API, o número de aplicações desenvolvidas através da

mesma irá, consequentemente, aumentar levando assim ao aumento do número de pedidos

diários recebidos (Figura 29).


38

Figura 29 – Exemplo de utilização de uma API REST [30]

Com o aumento do número de pedidos diários, a carga do servidor web e da Base de Dados

aumenta. Se nenhuma ação for tomada no sentido de balancear esta carga, o tempo de

resposta irá consequentemente crescer.

As API’s REST são muito utilizadas no contexto web, mas têm ganho muita popularidade no

desenvolvimento de aplicações para dispositivos móveis, pelo facto de os dados serem

passados em formatos leves com um baixo consumo de largura de banda (JSON). Das três

soluções apresentadas esta é, sem dúvida, aquela que garante uma maior interoperabilidade

por conseguir atingir um maior número de dispositivos, nomeadamente, os dispositivos

móveis.

Time to Market

O Time to Market (TTM) é o período de tempo entre a concepção de um produto e a sua

disponibilização no mercado para venda. É um fator muito importante para as empresas que

disponibilizam produtos e serviços pois, quanto mais pequeno for maior é a probabilidade de o

produto entrar no mercado antes dos concorrentes diretos e captar a atenção dos

consumidores finais.

Uma API REST, apenas é responsável por disponibilizar diferentes tipos de recursos para

gestão de dados, ou seja, os restantes componentes aplicacionais são garantidos pela

empresa ou pelo programador que a está a utilizar. Assim, no caso da API, cabe à empresa ou

ao programador garantir o TTM mais curto possível.

Vantagem Competitiva

As API’s públicas, quando suficientemente boas para atrair a atenção de vários

programadores, têm um impacto muito grande no negócio base de uma empresa [14]. Para

além de ser possível atingir um maior número de dispositivos, uma API pode ser verdadeira

vantagem competitiva.


39

Software Development Kits


Para o desenvolvimento de um SDK, é necessário criar pontos de extensibilidade na

plataforma atual para que sejam disponibilizados os componentes, os dados e as ferramentas

essenciais ao desenvolvimento. Estes pontos de extensibilidade seriam criados ao nível do

Marketplace, pelas mesmas razões referidas em 5.1.

O próximo passo seria disponibilizar o SDK como um componente isolado da arquitetura

Next>, um IDE (p.e. uma página web integrada na plataforma atual), ferramentas e

comportamento próprios (Figura 30). Pelo facto de o SDK ser focado no desenvolvimento para

a plataforma Web da Vortal, necessitaria de comunicar com esta utilizando os pontos de

extensibilidade acima referidos e, assim, garantir aos seus utilizadores toda a informação,

métodos e ferramentas necessárias.

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

Esta solução tem um impacto considerável na arquitetura atual pois, para o SDK garantir, por

exemplo, as ferramentas de compilação e teste das aplicações desenvolvidas necessita de as

conseguir integrar no ambiente aplicacional da Next>, sem por em causa o funcionamento e

performance da mesma (p.e. como acontece com os emuladores dos dispositivos móveis).

A arquitetura de um SDK, como já foi referido, tem de ser pensada e desenhada de forma a

contemplar vários componentes e garantir diferentes tipos de ferramentas. Um dos aspectos

fundamentais na arquitetura de um SDK, para além da facilidade de utilização e performance,

é garantir que este se consiga adaptar às constantes mudanças do negócio sem necessitar de

grandes alterações, ou seja, é importante que este apresente altos níveis de escalabilidade.

Um SDK apenas garante alta escalabilidade se esta for pensada desde o início do seu

desenvolvimento.


40


O objectivo principal de um SDK é fornecer, a um programador, as ferramentas necessárias

para o desenvolvimento completo de uma aplicação (interface, lógica e persistência de dados).

As aplicações desenvolvidas, tipicamente, são incorporadas num sistema computacional

superior (p.e. sistema operativo móvel) e, por isso mesmo, não é comum encontrar dois SDK’s

com os mesmos princípios e metodologias de desenvolvimento. Por este facto, o

desenvolvimento de aplicações utilizando SDK’s exige um esforço de aprendizagem inicial, que

passa por entender os seus componentes e arquitetura. É uma abordagem mais complexa

para os utilizadores (convém, por exemplo, que estes tenham bases de programação), mas

pode tornar-se uma experiência muito gratificante a nível técnico, levando mesmo ao

aparecimento de novos negócios, empresas e especialistas.

O desenvolvimento do SDK é um processo complexo, onde é necessário simplificar a sua

arquitetura e fornecer um conjunto de ferramentas adequadas para que a interação do

utilizador com o mesmo seja o mais simples e intuitiva possível.

Performance e Interoperabilidade

No que toca à performance, o SDK apresenta grandes vantagens relativamente às restantes

abordagens, dado que pode e deve existir uma metodologia de validação e teste das

aplicações desenvolvidas (como acontece com a AppStore e a Play Store), ou seja, permite

que o ambiente Next> seja controlado.

Depois de um utilizador desenvolver uma determinada aplicação, esta é submetida para

validação. Durante o processo de validação, uma equipa especializada no interior da empresa

(neste caso da Vortal) será responsável por testar e identificar os pontos de melhoria da

aplicação, para que o correto funcionamento da plataforma não seja posto em causa. De

notar, que os componentes do SDK disponibilizados para o desenvolvimento das aplicações,

encontrar-se-ão optimizados a nível de segurança e da performance de forma a minimizar o

impacto na plataforma atual.

O desenvolvimento de aplicações com base em SDK, é focado numa plataforma ou sistema

computacional em específico, por exemplo, o SDK de Android apenas permite o

desenvolvimento de aplicações para dispositivos móveis com este sistema operativo. No caso

da plataforma Vortal, o SDK permitiria o desenvolvimento de aplicações para integrar a


41

plataforma web (Vortal Next>) e, por isso, a interoperabilidade da solução é mais reduzida

quando comparada com as API’s REST.

Time to Market

O TTM das aplicações desenvolvidas utilizando o SDK é medido pelo tempo necessário para o

desenvolvimento da mesma (como acontece com a API), mas neste caso também é preciso

ter em conta o tempo de validação necessária para verificar se a aplicação está em condições

para integrar o ambiente aplicacional da Next>. É, talvez, a solução que tem um TTM mais

demorado mas, que pelo facto de compreender uma fase de validação das aplicações, garante

uma performance controlada da plataforma.

Numa segunda fase, como evolução da solução, é possível construir um motor de regras que

tenha a responsabilidade de avaliar a aplicação de forma automática em diferentes aspetos

(segurança, performance, etc.) e, por consequência, melhorar o TTM removendo toda e

qualquer intervenção humana do processo de validação e verificação do programa.


Para além de um SDK permitir o crescimento do leque de funcionalidades presentes na

plataforma, pode ser um aspecto diferenciador dos concorrentes do mercado e gerar uma

grande parte dos lucros da empresa.

Os SDK’s são, por norma, pacotes de software gratuitos sendo passível a implementação de

uma política de pay per use. Existe um SDK base com as funcionalidades essenciais para os

utilizadores, onde é possível comprar componentes adicionais que garantam funcionalidades e

melhorias em diversos aspectos.

A biblioteca de componentes do SDK é fundamental para o sucesso do mesmo pois, necessita

de garantir liberdade aos utilizadores para desenvolver as aplicações que melhor se adequam

às suas necessidades. Assim, é possível considerar a existência de um componente que

possibilite a disponibilização de uma API REST, por parte dos utilizadores, e garantir todas as

vantagens aplicacionais e competitivas descritas em 5.1.

Apesar de as aplicações desenvolvidas serem integradas na plataforma Next>, a sua execução

será realizada num ambiente estanque e bem definido que não compromete a performance e

a disponibilidade da plataforma. Para além de o bom funcionamento da plataforma atual ser


42

garantido, é garantida também a transversalidade das aplicações, ou seja, é possível que estas

migrem para outras plataformas desde que seja criada a interface com os serviços adequados.

Para além disto, é ainda possível cobrar aos utilizadores pela submissão das aplicações na

plataforma ou até mesmo haver um valor mensal/anual que estes necessitem de pagar para

desenvolver as aplicações.

Desenvolvimento baseado em Plug-ins


Para suportar o desenvolvimento baseado em plug-ins, é necessário que existam diversos serviços para o desenvolvimento

dos mesmos (extension points) e é necessário que exista um mecanismo de upload, validação e integração automático dos

plug-ins na plataforma atual (no componente representado como Plugin Engine).

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

É, sem dúvida, a abordagem que implica mais alterações na atual arquitetura da plataforma

Next> e a que surge com mais risco associado, pelo facto de poderem existir conflitos entre os

diferentes desenvolvimentos o que pode levar à indisponibilidade da plataforma.

Sendo o plug-in um componente de software que permite acrescentar e estender

funcionalidades a uma determinada plataforma, facilmente se conclui, que as arquiteturas que

os suportam implementam o conceito de escalabilidade em larga escala. Estas arquiteturas

possuem vários pontos de extensibilidade (Figura 23 e Figura 30) que funcionam como slots

onde os plug-ins são introduzidos e através dos quais o crescimento da plataforma é garantido.


Tal como acontece no SDK, o desenvolvimento baseado em plug-ins exige um esforço de

aprendizagem inicial que passa por entender os seus componentes, arquitetura e serviços,

surgindo assim como uma abordagem consideravelmente complexa para os seus utilizadores

quando comparada com as API’s REST.


43

No que toca ao desenvolvimento de uma arquitetura que suporte o desenvolvimento de plug-ins, esta é sem dúvida a

abordagem mais complexa e que apresenta mais riscos envolvidos.

Performance

Apesar de ser uma solução que garante o dinamismo e a escalabilidade da arquitetura é, de

todas as estudadas, aquela que pode causar mais problemas a nível de performance. Na API o

principal problema, a nível da performance, reside na quantidade de pedidos HTTP feitos ao

servidor e no SDK a performance é controlada pelo facto de as aplicações serem validadas por

uma equipa especializada no interior da empresa e por os componentes disponibilizados

serem otimizados quer a nível de performance quer a nível de segurança. Nesta solução, se

pensarmos que os plug-ins são integrados on the fly, ou seja, depois de desenvolvidos passam

por um mecanismo de validação e caso sejam válidos são automaticamente integrados na

plataforma (p.e. como acontece com os CMS’s), rapidamente concluímos que o correto

funcionamento da plataforma e o seu tempo de resposta é posto em causa.

Alguns dos riscos de desenvolvimento baseado em plug-ins:

Conflitos entre plug-ins (p.e. versões diferentes do mesmo plug-in);

Variáveis que ocupem demasiada memória e que nunca são libertadas (p.e. ciclos

infinitos, não limpar estruturas de dados depois da sua utilização, etc.)

Por muito robusto e complexo que seja o mecanismo de validação, existem sempre situações

(como as acima apresentas) que são muito complexas de serem detectadas de forma

automática e que podem trazer problemas para a host application.

Em consistência com o que acontece com o SDK, o desenvolvimento de aplicações baseadas

em Plug-ins é focado numa plataforma ou sistema computacional em especifico e, por esse

motivo, no contexto Vortal este tipo de abordagem permitiria apenas o desenvolvimento para a

plataforma Vortal Next>.

Time to Market

O desenvolvimento de aplicações baseadas em Plug-ins, garante um TTM em tudo semelhante

ao SDK. Nesta abordagem o TTM é medido, mais uma vez, pelo tempo necessário para o

desenvolvimento da aplicação e pelo tempo necessário para o upload, validação e integração

do mesmo na plataforma.


44


Do ponto de vista comercial esta solução aproxima-se do SDK, já que o intuito é a criação de

extensões para aumentar o leque de funcionalidades da plataforma base. A plataforma base

possui um conjunto de serviços de livre utilização para a construção de novas extensões e um

conjunto mais avançado que só pode ser utilizado mediante uma taxa de utilização.

Comparação das abordagens

Tendo em conta os pontos referidos em 5.1, 5.2 e 5.3 é possível fazer uma comparação das

três abordagens, classificando cada um desses pontos numa escala de 1 a 5, em que 1 é a

pontuação mais baixa e 5 a mais alta. Cada um dos pontos tem um peso relativo, obtido

através de uma reunião que envolveu a equipa de engenharia e de mercados da Vortal, tendo

em conta a importância para o negócio base da Vortal, o impacto na plataforma atual e a

utilidade para o grupo de utilizadores finais.

Em primeiro lugar surge a facilidade de desenvolvimento do ponto de vista dos utilizadores

finais. Tendo em conta que a solução a desenvolver será para utilização externa à Vortal e que

só terá sucesso se for o mais simples e intuitiva possível este é, de todos, o ponto com maior

importância, surgindo com um peso de 25% do total.

De seguida, temos a performance e a interoperabilidade com 20% do total. Sabendo que na

área do comércio electrónico todos os minutos são decisivos quer para o comprador quer para

o fornecedor, é importante que o tempo de resposta da plataforma seja adequado e não seja

afetado pela solução desenvolvida. Para além deste aspecto, é também muito importante a

disponibilização de aplicações móveis de forma a aproveitar o constante crescimento que se

tem vindo a sentir nesta área.

Com 15% do peso total encontram-se os pontos referentes à arquitetura e escalabilidade, à

facilidade de desenvolvimento do ponto de vista da Vortal e ao TTM. A arquitetura, apresenta-

se cada vez mais como um fator essencial no ciclo de vida de um produto de software. É

necessário que esta seja pensada e desenhada da melhor forma possível e que consiga

garantir alguns aspectos chave como a escalabilidade, disponibilidade, segurança, eficiência,

eficácia, etc. Assim, as diferentes abordagens são comparadas a nível de impacto na

arquitetura atual, a nível de desenho da solução e a nível da sua escalabilidade.


45

A solução a desenvolver tem custos quer a nível de TTM, quer a nível de recursos, sendo por

isso mesmo importante comparar o esforço necessário para desenvolver cada uma delas no

contexto da Vortal. A solução é direcionada para um grupo de utilizadores externos à Vortal e,

por isso, é importante que estes vejam os seus desenvolvimentos a serem disponibilizados o

mais depressa possível. A comparação dos diferentes TTM’s serve exatamente para avaliar

qual a solução mais vantajosa do ponto de vista do cliente. De notar, que o TTM avaliado tem

em conta o tempo de desenvolvimento da aplicação e o tempo de validação da mesma.

Por último e com 10% do peso total, temos a vantagem competitiva. Como em todas as áreas

de negócio é importante que o produto/serviço apresente vantagens em relação aos

concorrentes diretos e consiga arrecadar um maior número de utilizadores. Sendo a Vortal

uma empresa focada em se tornar uma referência internacional na área do comércio

eletrónico, este ponto apesar de menos importante que os anteriores faz todo o sentido de

equacionar e comparar.

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

Next>

Peso API Rest SDK Plug-in’s

Facilidade de Desenvolvimento (Utilizadores) 25% 4 4 2

Performance e Interoperabilidade 20% 3 4 2

Arquitetura e Escalabilidade 15% 4 4 4

Facilidade de Desenvolvimento (Vortal) 15% 5 3 3

Time to Market 15% 3 3 3

Vantagem Competitiva 10% 3 5 5

Total 100% 74% 77% 58%

Tendo em conta os resultados obtidos na comparação das diferentes abordagens, é possível

concluir que uma das soluções deve ser posta de lado (Plug-ins com 58% do total) e que as

restantes, que apresentam um total muito próximo, devem ser, novamente, avaliadas.

A API apresenta tem a vantagem de ser de fácil desenvolvimento e de atingir uma gama de

dispositivos mais alargada, enquanto que e o SDK tem a vantagem de permitir uma


46

performance controlada da plataforma e de garantir uma vantagem competitiva mais elevada

quando comparado com a API.

Tendo em conta que Vortal tem o intuito de se tornar um referência internacional da área do

comércio electrónico foi definido, em conjunto com a equipa de engenharia e de mercados,

que o SDK é a solução que se apresenta, neste momento, com mais vantagens ao nível

comercial, que permite à Vortal destacar-se dos seus concorrentes diretos e atingir uma maior

comunidade de utilizadores.

Assim, o intuito desta dissertação será desenhar e prototipar um SDK de desenvolvimento no

contexto Vortal Next> modelando um ou mais processos de negócio.

Vortal Development Software Kit

47

6 Vortal Development Software Kit

Tendo em consideração os resultados obtidos na secção 5.4, esta secção incide sobre o

desenho arquitetural de um SDK que permite a grupos especiais de utilizadores, desenvolver

as próprias aplicações de forma a integrar no ambiente aplicacional da plataforma Vortal

Next>.

A arquitetura é desenhada de forma a garantir que os utilizadores tenham acesso a uma

ferramenta simples e intuitiva que lhes permita desenvolver aplicações da forma mais eficaz e

eficiente possível. O SDK apresentado nesta dissertação é baseado em controlos gráficos e

containers (funcionalidade drag and drop disponibilizada pelo IDE do SDK), que permitem a

utilizadores sem qualquer experiência de programação o desenvolvimento das suas próprias

aplicações.

Visão Geral da Arquitetura

Antes de serem definidos os componentes da arquitetura e as suas relações, é importante a

definição dos mesmos a um alto nível de abstração de forma a entender qual o papel que

cada um desempenha na arquitetura.

Na Figura 32, podemos observar três componentes principais:

Controlos: diferentes componentes aos quais um utilizador tem acesso para a

construção gráfica das suas páginas, como por exemplo, botões e tabelas. Alguns dos

componentes, como as tabelas, podem ter fontes de informação (Datasources)

associadas e permitir ações sobre essa mesma informação;

Ferramentas: fornecer uma variada gama de serviços (possivelmente, Web Services

REST), que correspondem a extension points da plataforma, e que serão utilizados

pelos diversos componentes. É através deste, que a autenticidade dos utilizadores e a

segurança da ligação será garantida;

Motor Aplicacional: componente onde todos os processos de transformação,

compilação e integração serão tratados de forma completamente transparente para os

utilizadores.


48

Figura 32 – Arquitetura Macro da Solução

O utilizador tem acesso a um conjunto de controlos através dos quais a construção de páginas

web com todas as ações desejadas será possível. O utilizador não terá qualquer acesso a

código fonte, sendo tudo concretizado recorrendo a programação visual e através de uma

página web integrada na plataforma (i.e. o IDE do SDK).

A programação visual é definida, segundo [33], como sendo um conjunto de técnicas que

possibilitam a criação de programas através da manipulação de elementos gráficos em vez de

os especificar textualmente (código fonte).

Em paralelo com a construção da página, será gerado código XML que, no final da geração,

corresponderá a um ficheiro bem definido (p.e. um .MVC, um dos modelos utilizados pela

Vortal para o desenvolvimento, como demonstrado em 3.3). O ficheiro XML final terá todo o

mapeamento necessário para fazer corresponder os elementos, os estilos e os repositórios de

informação com o que, habitualmente, é utilizando na plataforma.

Esse ficheiro XML será recebido como input num compilador responsável por o interpretar e

gerar o código .NET MVC correspondente. Será neste processo que serão apresentados, caso

existam, todos os erros de construção.


49

Após a conclusão do processo sem qualquer erro, ou seja, quando o código final for

totalmente gerado e sem erros assinaláveis, é necessário um processo de integração com a

plataforma Next> que garanta o correto funcionamento da mesma com as novas

funcionalidades.

O processo de integração será garantido através da passagem do pacote final de software (p.e.

.jar no caso do Java e .dll no caso do .NET) para um application server dedicado ao

alojamento e execução das aplicações desenvolvidas. Este application server será

completamente isolado dos servidores responsáveis pela disponibilização da plataforma Vortal

Next>.

“4+1” View Model

A arquitetura de um sistema consiste no concepção e implementação da estrutura de alto

nível do sistema. É o resultado da combinação de vários elementos arquiteturais de forma a

satisfazer o maior número de requisitos funcionais e não funcionais. Para isso, e com o intuito

de construir arquiteturas estáveis e com altos níveis de confiabilidade e performance, são

utilizados modelos onde são apresentadas diferentes perspetivas do sistema [34] [35].

Para o processo de definição e desenho da arquitetura do SDK, será utilizada a abordagem

“4+1” View Model. Esta abordagem consiste na definição de um conjunto de “vistas” que

permitem representar o sistema na perspetiva dos diferentes stakeholder’s, como os

utilizadores finais, os programadores e os engenheiros de software [34].

As diferentes perspectivas definidas nesta abordagem são (Figura 33):

“Vista” Lógica: Focada na funcionalidade da aplicação em termos de elementos

estruturais e distribuição de responsabilidades. Esta perspetiva é utilizada pela equipa

de desenho técnico e arquitetura, de forma a ter diferentes níveis de abstração e é

representada utilizando diagramas de classe [35].

“Vista” de Processo: Considera aspetos não funcionais como a performance e a

escalabilidade e tem em conta problemas de concorrência, distribuição de carga e

tolerância a falhas. É utilizada para representar a perspetiva lógica através de

conjuntos de tarefas para atingir um determinado objetivo (diagramas de sequência)

[35].


50

“Vista” Física: Engloba os diferentes componentes do sistema de hardware, sobre os

quais a aplicação irá executar [35].

“Vista” de Desenvolvimento: Focada na organização em módulos do ambiente de

desenvolvimento, ou seja, a aplicação é dividida em pacotes (packages) que serão

desenvolvidos e testados pela equipa de desenvolvimento (diagramas de

componentes) [35].

Vista de Casos de Uso: Engloba os casos de uso que descrevem o comportamento do

sistema, na perspetiva dos utilizadores finais e outros stakeholder’s [35].

Figura 33 – “4+1” View Model Diagram

Vista de Casos de Uso

Como já foi referido, esta vista apresenta os casos de uso que descrevem as funcionalidades

do sistema na perspetiva dos utilizadores finais e permite a identificação das necessidades a

ter em conta aquando a definição das restantes perspetivas [35].

A representação dos casos de uso, tem dois propósitos principais [34]:

Impulsionar a descoberta dos elementos arquiteturais a definir nas restantes

perspetivas;

Validar e ilustrar a arquitetura definida.

Na Figura 34, é apresentado um diagrama geral de casos de uso, que representa a utilização

do SDK no ponto de vista do programador externo. Abaixo são explicados, com mais detalhe,


51

cada um dos casos de uso representados e no Anexo 1 é apresentado um diagrama de casos

de uso mais elaborado da utilização do SDK.

Figura 34 – Diagrama geral de Casos de Uso

Criar Aplicação: Caso de uso que permite, ao programador externo, o desenvolvimento da

aplicação no SDK. É neste processo que são definidos os atributos da aplicação, como o

nome, a visibilidade (pública ou privada), o tipo de aplicação a desenvolver (widget ou

aplicação com várias páginas e fluxo de navegação entre elas). Durante o processo de

desenvolvimento são criadas as diferentes páginas bem como o posicionamento dos

elementos nas mesmas.

Gerir Páginas: Caso de uso que permite, ao programador, fazer a gestão das páginas da

aplicação. É um caso de uso de alto nível que pode ser decomposto nas várias ações possíveis

de serem efetuadas sobre as páginas, nomeadamente, criar, atualizar, apagar, listar e

visualizar.

Gerir Elementos: Caso de uso que possibilita a gestão de todos os elementos presentes numa

página da aplicação. Ao passo do que acontece com o caso de uso “Gerir Páginas”, este é um

caso de uso de alto nível, que pode ser decomposto nas várias ações possíveis de serem

efetuadas sobre os elementos, nomeadamente, criar, atualizar, apagar, listar, visualizar,

associar ação e associar fonte de dados (datasource).

Validar Aplicação: Caso de uso que permite simular a utilização da aplicação desenvolvida (ou

parte dela) no contexto aplicacional da plataforma Next>.


52

Finalizar Aplicação: Caso de uso que permite finalizar o desenvolvimento da aplicação e o seu

envio para o servidor aplicacional responsável por garantir o seu funcionamento e a sua

integração com a plataforma Next>.

Perspetiva de Desenvolvimento

A perspetiva de desenvolvimento, tem como objetivo a divisão da aplicação em diferentes

componentes de software e a representação das suas relações e dependências [34]. Na

Figura 35 é ilustrado o diagrama de componentes que diz respeito ao ambiente aplicacional

do SDK a desenvolver.

É possível observar a divisão da aplicação em três packages principais, o SDKControls, o

SDKEngine e o VortalNext>InternalServices. O primeiro package contempla os componentes

que permitem a construção das aplicações, ou seja, são os componentes com os quais o

utilizador do SDK vai interagir (elementos gráficos, ações, páginas, etc.) para desenvolver as

aplicações de acordo com as suas necessidades. O package VortalNext>InternalServices é

responsável por encapsular todos os serviços da plataforma Next> passíveis de serem usados

para o acesso a informação e, por último, temos o package SDKEngine que contém os

componentes responsáveis pela geração e compilação de código final de forma transparente

para o utilizador. Este componente também é responsável por fazer o deploy das aplicações e

por configurar o ambiente de execução das mesmas no servidor aplicacional.

A divisão do SDK em diferentes packages permite acelerar o processo de desenvolvimento e

facilitar a realização de testes, pelo facto de estes poderem ser tratados como componentes

independentes. Esta divisão apresenta, também, a vantagem de permitir a separação física de

componentes em servidores aplicacionais distintos [34] [35].

Figura 35 – Diagrama de Componentes


53

Perspectiva Lógica

A definição da perspetiva lógica do SDK foi concretizada recorrendo a diagramas de classe.

Para tal, foi necessário ter em conta o leque de funcionalidades a fornecer aos utilizadores

finais e, sempre que possível, foram utilizados padrões de desenho de software.

Design Patterns

Os padrões, representam soluções de software utilizadas para a resolução de um problema

recorrente, ou seja, representam o acumular de conhecimento de diferentes especialistas num

determinado contexto. Apresentam-se como soluções extremamente vantajosas, pois já foram

testadas e comprovadas em diversas aplicações e utilizadores [36] e pelo facto de

promoverem a reutilização e modularização do código. Estes podem ser divididos em três

categorias distintas, os padrões de criação, os padrões estruturais e os padrões

comportamentais [37] :

Padrões de criação caracterizam-se por adequar a instanciação de objetos a diferentes

tipos de situação. Representam uma forma de “esconder” a criação de classes

concretas e a forma como estas se relacionam. Exemplos deste tipo de padrão são:

factory, abstract factory e o singleton [37].

Padrões estruturais simplificam o desenho arquitetural pois definem formas mais

simples de relacionar as diferentes entidades. O adapter, composite e facade são

exemplos deste tipo de padrões [37].

Padrões comportamentais são utilizados de forma a identificar os diferentes processos

de comunicação de um programa de software. Ajudam a reduzir a complexidade e

quantidade de código para implementar uma determinada funcionalidade. Nesta

categoria inserem-se os padrões strategy e memento [37].

Durante a definição do SDK foram utilizados, sempre que possível, padrões de desenho para

garantir a qualidade e escalabilidade da solução (o motivo da utilização e os respetivos

padrões serão explicados no capítulo 6.5). É importante referir que, a utilização de padrões é

extremamente vantajosa pelo facto de permitir a resolução de problemas comuns no mundo

da engenharia de software, mas a utilização de padrões de forma excessiva (over engineering)

pode aumentar a complexidade da plataforma e, por consequência, prejudicar o seu

desempenho.


54

Controlos do SDK

Este package define os componentes aos quais o utilizador tem acesso para a criação das

suas aplicações, nos quais pode definir diferentes tipos de comportamentos e ações. Este

package é constituído pelas ações, pelos elementos gráficos, pelas fontes de informação e

pelas entidades responsáveis por agregar todos estes: a aplicação e as páginas da aplicação.

Os elementos representam os constituintes típicos de uma página web, como botões e tabelas

onde podem ser associadas ações/eventos e fontes de informação. As ações, como o nome

indica, representam interações do utilizador com a aplicação (p.e. carregar num link para abrir

uma nova página) e as fontes de informação ou datasources representam segmentos de

informação que podem ser apresentados em elementos de listagem como as tabelas (p.e. ter

uma tabela com todas as mensagens recebidas).

As páginas representam as entidades agregadoras de elementos, ou seja, uma página tem

diferentes tipos de containers (p.e. secção da esquerda e a secção central) que possuem, no

seu interior, um conjunto de elementos que representam a aplicação pretendida pelo cliente.

Por último existe a entidade aplicação, responsável por guardar todas as páginas e elementos

introduzidos pelo utilizador. É esta que guarda informação como o estado da aplicação

(Edição, Publicada, Em Aprovação e Rejeitada), a sua visibilidade (Pública ou Privada) e qual o

utilizador com acesso à sua modificação. Através dos métodos disponibilizados por esta

entidade, é possível aceder à hierarquia de elementos criada pelo utilizador e fazer a geração

de código intermédio e final.

De referir a existência de um package denominado de Common, onde são definidas todas as

classes utilizadas de forma global pelas entidade acima descritas. Neste package, são

definidos os enumerados do SDK (p.e. o enumerado que contém os diferentes tipos de

eventos do SDK e o que apresenta a lista de masterpages disponíveis para a criação de uma

aplicação) e é também definida a classe responsável pelo logging das diferentes ações

executadas pelo utilizador. O logging é um ponto bastante importante de uma aplicação pois

permite registar todos os eventos relevantes da mesma que, mais tarde, podem ser utilizados

para diagnosticar e resolver problemas graves. Para além deste facto, os logs podem também

ser utilizados para efeitos de auditoria e para a responsabilização dos autores de determinadas

ações.


55

Na Figura 36 é demonstrada a visão geral do package, com as relações entre os diferentes

tipos de entidades representadas. Cada um destes packages e entidades ilustradas são

explicados com mais detalhe e de forma mais aprofundada com o decorrer deste capítulo.

Figura 36 – Package de Controlos

Elementos gráficos

Como já referido, os elementos gráficos (ViewElements) representam os elementos utilizados

para a construção de uma página HTML típica. De todos os elementos existentes no contexto

web, são de salientar, os botões, as labels’s, os fieldset’s, as grid’s e os seus constituintes, as

textbox’s e os datepicker’s como os mais utilizados durante o desenvolvimento da plataforma

Next>. Estes elementos apresentam diversos atributos em comum e por isso mesmo na Figura

39 é possível observar a existência de uma classe “pai” (BaseViewElement) que contém todos

os atributos e métodos comuns e que cada elemento “filho” vai herdar e implementar.

Neste package é possível observar a existência de um classe abstrata (ViewElementCreator)

com um método abstracto denominado de CreateViewElement(). É também possível observar

a sua especialização em diferentes classes “filho” que são responsáveis por garantir a

implementação do método atrás referido. Este é um exemplo de implementação do padrão de

desenho Factory Method.

O padrão Factory é utilizado de forma a definir uma classe para a criação de um objeto, onde

as suas subclasses decidem qual a classe a instanciar [38]. Este padrão é, normalmente,

utilizado quando se quer dar suporte e extensibilidade a uma determinada entidade (p.e.

diferentes formatos de documentos), ou seja, quando se pretende encapsular o conhecimento

sobre qual o produto concreto a criar (ConcreteProduct) numa subclasse concreta


56

(ConcreteCreator) [38]. Na Figura 37 é apresentado um diagrama geral e simplificado do

padrão Factory.

Figura 37 – Diagrama geral do padrão Factory [37]

Quando se pensa num SDK baseado em programação visual, rapidamente se conclui que é

extremamente complexo antecipar todos os componentes que serão necessários. Para além

disto, com o aumento do número de elementos do SDK é importante que existam classes

especializadas na criação destes elementos (Concrete Factory), que saibam exatamente quais

os atributos e propriedades a preencher de forma a atingir o comportamento esperado.

Assim, a implementação de uma padrão Factory para a criação de elementos gráficos foi a

solução encontrada de forma a colmatar estes problemas.

É possível fazer a divisão dos diferentes elementos representados na Figura 36 em elementos

simples e elementos compostos. Os elementos simples são, como o nome indica, elementos

constituídos apenas pelos seus atributos e pelos seus métodos, enquanto os elementos

compostos são elementos que, no seu interior, podem ter um número indefinido de elementos

(simples ou compostos), ou seja, podem no seu interior possuir uma hierarquia de elementos.

No caso dos elementos representados os elementos compostos são os fieldset’s e as grid’s.

Apesar de os elementos serem diferentes, para o utilizador final não é necessária essa

separação de conceitos e, por isso, é necessário garantir um mecanismo que permita tratar de

forma uniforme os objetos simples e os objetos compostos. Este problema pode ser

endereçado através da utilização do padrão Composite.

O padrão estrutural Composite tem como objetivo compor objetos em estruturas de árvore

(hierarquias) de forma a ser possível representar objetos simples e compostos de forma

uniforme e transparente para o utilizador. Neste padrão os objetos simples não possuem

qualquer “filho” e definem o seu próprio comportamento enquanto os objetos compostos

garantem a lista de objetos simples e as operações relacionadas com os mesmos [38].


57

Figura 38 – Diagrama geral do padrão Composite [37]

Na Figura 39, existem duas aplicações do padrão Composite, uma no FieldsetViewElement e

outra no GridColumnViewElement. Estes elementos, são capazes de possuir um número

indefinido de elementos e é através do método WriteChildren() que a hierarquia de objetos é

criada e garantida.

Figura 39 – Package de ViewElements


58

Todos os elementos possuem a implementação dos métodos Write(), WriteAttributes() e

WriteActions(), sendo utilizados para a geração dos ficheiros XML finais que, mais tarde, dará

origem ao código final (como explicado em 6.1).

Na figura é representada uma classe [ElementName]Creator com o intuito tornar a

visualização e a compreensão do diagrama mais simples. Esta classe, representa os restantes

Concrete Factories utilizados para a criação do fieldset, da grid e do datepicker ou de qualquer

outro elemento que surja durante o ciclo de vida do SDK.

Ações

Os elementos gráficos de uma aplicação, não são componentes estanques, ou seja, são

componentes que podem sofrer modificações durante o ciclo de utilização da página e que

podem ter associados inúmeros eventos para, por exemplo, permitir a visualização de mais

informação. Assim, um elemento gráfico pode conter a implementação de um variado número

de eventos que, por sua vez, são responsáveis por originar uma ação.

A classe Events do package Actions é a classe que representa os eventos existentes e que

contém a lista de ações a despoletar. Nesta classe existe um enumerado designado de Type,

que é o atributo que identifica o tipo de evento a implementar (OnClick, OnMouseOver,

OnMouseDown, OnMouseUp, OnChange, entre outros).

Neste package foi utilizado, mais uma vez, e pela mesmas razões apresentas e explicadas em

6.5.2.1, o padrão Factory para a criação dos diferentes tipos de ações. É uma tarefa bastante

complexa antecipar todas as ações com necessidade de implementação e, por isso, existe

uma classe abstrata (ActionCreator) que delega a responsabilidade de implementar o método

de criação de ações com todos os atributos e propriedades necessárias às suas classes “filho”

(Concrete Creator’s).

No diagrama apenas são representadas três ações, a RedirectAction , a RefreshAction e a

ExecuteAction. A escolha das ações a representar foi feita depois de uma análise à plataforma

Next>, onde foi possível concluir que estas são, de entre as muitas ações existentes, as mais

utilizadas no contexto da plataforma.

A RedirectAction, permite que o utilizador introduza um fluxo de navegação nas suas

aplicações com links entre páginas da aplicação ou, até mesmo, com links para a plataforma

Next>. A RefreshAction permite a atualização de páginas ou de elementos mediante a ação


59

tomada pelo utilizador na interface. Por último temos a ExecuteAction, que permite a execução

de um serviço da plataforma Next>, por exemplo, para permitir o envio de mensagens ou para

a criação de tarefas.

Na Figura 40 é representado o package das Actions na sua totalidade com todos os aspetos

acima referidos.

Figura 40 – Package de Actions

Na figura é representada uma classe [ActionName]Creator com o intuito de tornar a

visualização e a compreensão do diagrama mais simples. Esta classe representa os restantes

Concrete Factories utilizados para a criação de qualquer outra ação que surja durante o ciclo

de vida do SDK.

Contrariamente ao que acontece com os ViewElements, todas as ações possuem a

implementação do método Write() para a geração dos ficheiros XML mais tarde utilizados na

geração do código final (como explicado em 6.1).

DataSources

No contexto de qualquer aplicação, a possibilidade de visualização de informação é

extremamente importante de forma a corresponder às necessidades dos utilizadores. Assim, é

importante que determinados conjuntos de elementos suportem a ligação a fontes de dados

(datasources) para a listagem e apresentação de informação.

O package de DataSources é constituído apenas pela entidade BaseDataSource, responsável

pelo mapeamento de entidades presentes na plataforma Next> com as entidades

disponibilizadas no contexto aplicacional do SDK. Esta classe é constituída por dois atributos


60

preenchidos através de dois enumerados existentes no package Common. O atributo Entity

representa a entidade pretendida (p.e. UserTasks) e assume um dos valores presentes no

enumerado Entities. O atributo Operation representa a operação a realizar sobre a entidade

escolhida (Create, Update, GetAll, Get, Delete, etc.) e é preenchido através de um dos valores

contidos no enumerado Operations da classe MappingEnums.

É através destes dois atributos que é conseguido o mapeamento dos Web Services da

plataforma Next> com a aplicação desenvolvida. Vejamos, por exemplo, o seguinte caso onde

a entidade BaseDataSource é instanciada da seguinte forma:

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

Mais tarde, durante a geração do código a entidade previamente instanciada, será convertida

numa chamada a um Web Service existente na plataforma Next> (como o exemplificado

abaixo).

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

Na Figura 43 é apresentado o package de Datasources em conjunto com a classe que contém

os atributos necessários para a realização do mapeamento entre a plataforma Vortal Next> e

as entidades disponibilizadas no contexto do SDK.

Figura 43 – Package de Datasources

Páginas

Já foram apresentados os componentes base que garantem a construção de uma aplicação

com diferentes comportamentos e diferentes tipos de ações. Falta apenas referir como é que

esses componentes são agrupados na aplicação de forma a ser criado um layout e um fluxo

de navegação.


61

O package de Windows é responsável por guardar todas as páginas da aplicação com os seus

respetivos componentes e, para cada uma delas, definir a sua estrutura em termos de

visualização (layout). Neste package existe uma classe “pai” denominada de Window, que

possui duas especializações, a Page e a DashBoardView. A Page representa uma página típica

da aplicação e é pelo facto de uma aplicação possuir várias instâncias desta, que é possível

criar o fluxo de navegação desejado. Por outro lado, quando uma aplicação implementa a

classe DashBoardView não existe qualquer fluxo de navegação, pois esta representa um widget

que poderá ser utilizado na página principal da Next> para consulta de informação. Em [39] é

explicado o dashboard Next> e introduzido o conceito de DashBoardView.

Por último, na Figura 44 é possível observar a classe Container que é a classe que permite a

divisão de uma Window em diferentes seções (p.e secção central, secção de topo, etc.) e, para

cada uma delas, guarda os elementos a serem disponibilizados.

Figura 44 – Package de Windows

Todas as classe representadas possuem a implementação dos métodos Write(),

WriteAttributes() e WriteChildren(), utilizados para a geração dos ficheiros XML mais tarde

utilizados para a geração do código final (como explicado em 6.1).


62

Vortal Development SDK

Como apresentado nos capítulos anteriores, as aplicações desenvolvidas através do SDK têm

acesso à informação guardada na plataforma Next> através dos serviços por esta

disponibilizados. A plataforma apresenta um package de serviços internos, responsável por

interpretar os pedidos do cliente e responder de forma adequada.

O número de entidades presentes na plataforma Vortal Next> é de grande dimensão, o que

torna as chamadas aos serviços um processo bastante complexo. Devido a este facto, houve a

necessidade de criar uma camada de abstração intermédia entre o SDK e o package de

serviços que o torna de mais fácil utilização. Neste ponto da arquitetura foi aplicado o padrão

estrutural Facade.

Este padrão garante a existência de uma interface simplificada para o acesso a um conjunto

de funcionalidades/métodos de um sistema [37] (Figura 45).

Figura 45 – Diagrama geral do padrão Facade [37]

A utilização deste padrão tem as seguintes vantagens [38]:

Tornar um sistema (neste caso um package de serviços) mais fácil de utilizar e

entender;

Reduzir as dependências do sistema, já que os clientes passam a utilizar a Facade

para comunicar.

Na Figura 46 é possível observar que o SDK não tem qualquer acesso ao package de serviços,

devido ao facto de a comunicação com o mesmo ser realizada através da classe

VortalServiceFacade. De notar que, tanto o Facade como o package de serviços, apenas

apresentam um pequeno conjunto das entidades e dos métodos a disponibilizar em cada uma

delas, de forma a facilitar a visualização e a interpretação do diagrama.


63

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

Motor do SDK

Quando uma aplicação se encontra totalmente desenvolvida ou num estado suficientemente

avançado para ser feita a sua compilação e validação, é utilizado o package SDKEngine. Este

package é completamente transparente para o utilizador e pode, inclusivamente, ser colocado

num ambiente físico distinto do package de controlos para, por exemplo, atingir melhores

níveis de performance e escalabilidade.

É neste ponto que é feita a geração e validação de código através da entidade Application (ver

Figura 36) para uma linguagem/modelo intermédio (neste caso XML) que, mais tarde, será

utilizada para gerar o código fonte final. Depois deste processo, é necessário encapsular o

resultado num pacote de software para integrar no servidor aplicacional de Thrid Party

Applications.

Na Figura 47 encontram-se representadas a classe Installer e a classe Tester que, apesar de

serem muito semelhantes, têm um comportamento bastante distinto. A classe Installer é a

classe que faz a geração e compilação de código final e que submete a aplicação para o

servidor aplicacional onde esta irá ser executada e a classe Tester faz a geração e compilação

de código para emular a utilização da aplicação no ambiente Next>. A grande diferença entre

estas duas classes, para além de a primeira enviar a aplicação para o servidor aplicacional,

reside no facto de a classe Installer fazer a optimização do código final gerado para melhorar

aspetos como a performance da aplicação.

É ainda de salientar, mais uma vez, a presença do package Common com mais duas classes

no seu interior, a classe SDKException e a classe Logger. A primeira é responsável por gerir os

erros que surgem durante o processo de geração e transformação de código e a segunda é a

classe responsável por registar todo o fluxo de execução do Motor do SDK.


64

Figura 47 – Diagrama geral do Motor do SDK

Gerador de Código

A geração de código do SDK é feita em duas fases, na primeira fase é feita uma transformação

M2M (entidade Application do package de controlos para ficheiro(s) XML) e na segunda é feita

uma transformação M2T (XML em código fonte de uma determinada linguagem).

No primeiro processo de transformação, a entidade Application é percorrida e transformada

num modelo XML através do seu método Write(). A escolha da transformação intermédia em

XML teve em conta o facto de ser extremamente simples fazer a validação do mesmo através

de XML Schema Definition (XSD). O XSD é uma linguagem baseada em XML que permite

definir regras de validação de ficheiros e, por isso, apresenta-se como uma solução simples

para a definição de uma Domain Specific Language (DSL). A validação do(s) ficheiro(s) XML

gerado(s) será feita na classe ModelValidator.

DDepois de todos os modelos serem validados com sucesso, é possível converte-los em código

fonte final (transformação PIM para PSM). Para isso, é necessário percorrer o(s) ficheiro(s)

XML gerado(s) e implementar a lógica associada à linguagem fonte pretendida. Ao desenhar a

arquitetura do SDK foi pensada a possibilidade de, no futuro, a linguagem pretendida para a

geração ser diferente da atual (C#) e nos impactos que essa mudança pode trazer para o bom

funcionamento do mesmo. Devido a esse facto, no package Code Generator existe a

implementação do padrão comportamental Strategy.

O padrão Strategy (Figura 48) define uma família de algoritmos e encapsula cada um deles

numa classe (ConcreteStrategy), ou seja, permite que uma classe (Strategy) tenha vários


65

comportamentos e se adapte a diferentes contextos. Este encapsulamento garante que os

algoritmos possam ser escolhidos em tempo de execução e garante a escalabilidade da

solução pela facilidade de acrescentar novos comportamentos sem afetar os já existentes [37]

[38].

Figura 48 – Diagrama geral do padrão Strategy [37]

Na Figura 49, a classe Generator é uma interface com dois métodos (GenerateXML() e

GenerateSourceCode()) que podem ter diferentes implementações dependendo da linguagem

fonte pretendida (p.e. implementação Java é diferente da implementação C#). Para isso,

existem as diferentes especializações da interface (C#Generator, JavaGenerator, etc.) onde as

considerações necessárias para cada linguagem são tidas em conta de forma a atingir geração

de código final.

Por último, existe a classe GeneratorContext onde é definido o contexto de utilização do

Generator, ou seja, é através desta que é escolhido qual o algoritmo a utilizar para a geração

do código final.

Figura 49 – Package do Code Generator

De notar que a classe [Language]Generator, representa a implementação dos dois métodos

definidos na interface Generator em qualquer outra linguagem fonte pretendida e que surja

durante o ciclo de vida do SDK.


66

Compilador

O último passo do processo de geração de código, passa por encapsular o código fonte final

em pacotes de software (p.e. no Java geram-se os jar’s e em .Net geram-se as dll’s). Este

processo denomina-se, por compilação.

Pelo facto de a geração de código final poder ser feita para diversas linguagens de

programação (processo garantido através do padrão Strategy), a sua compilação terá também

de contemplar diferentes implementações. Assim, o package Compiler (Figura 50) apresenta,

novamente, a implementação do padrão Strategy.

Existe uma interface (Compiler) com um método Compile() que é especializado tendo em

conta a linguagem alvo desejada (C#Compiler, JavaCompiler, etc). A classe CompilerContext é,

em consistência com o que acontecia no package CodeGenerator, a que define qual a

implementação do compilador a utilizar. De notar que, a implementação do compilador passa

por invocar os compiladores locais (p.e. invocar o compilador de C# ou o compilador de Java)

e não pelo desenvolvimento de um compilador de raiz.

Figura 50 – Package do Compiler

A classe [Language]Compiler, representa a implementação do método Compile() em qualquer

outra linguagem pretendida durante o ciclo de vida do SDK. É importante garantir a coerência

entre as linguagens disponibilizadas para a geração de código final e as linguagens passiveis

de serem compiladas. Se a linguagem a utilizar for uma linguagem interpretada, não existe a

necessidade de compilação e por isso este package deixará de ser utilizado.

Perspetiva de Processo

Esta secção representa a perspetiva lógica da arquitetura através de conjuntos de tarefas para

atingir um determinado objetivo. É uma forma de validar os padrões e os componentes


67

utilizados para a definição das classes do sistema e permite a simulação da utilização da

solução por parte de um determinado do utilizador.

Para a arquitetura definida nesta dissertação, são apresentados diagramas de sequência

relativos à criação de uma aplicação e à submissão da mesma para o servidor aplicacional

dedicado aos desenvolvimentos externos. Os diagramas desenhados apenas contemplam um

fluxo básico de mensagens de forma a facilitar a visualização dos mesmos, ou seja, apenas é

considerado o caminho ótimo, sem validações de formulários e ações, com interações

mínimas por parte de utilizador como prova da arquitetura desenhada.

A criação de uma aplicação pode ser explicada em duas fases. Numa primeira fase são

definidos os atributos macro da aplicação como o nome, o tipo e o layout. Numa segunda

fase, são posicionados os elementos na página e todo o comportamento associado aos

mesmos. A Figura 51 ilustra uma versão simplificada do processo acima descrito e na Figura

55 e Figura 56 do Anexo 2 encontram-se os diagramas de sequência mais detalhados.

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

A submissão da aplicação para o servidor aplicacional implica a utilização do objeto

Application previamente criado para a geração do código XML (Figura 58 do Anexo 2) e,

seguidamente, efetuar a geração de código final e respetiva compilação (Figura 57 e Figura 59

do Anexo 2). Na Figura 52 é apresentado um diagrama de sequência simplificado com o

intuito de esquematizar o processo acima descrito.


68

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

Perspetiva Fisica

Por último, temos a perspetiva que é utilizada para definir a infra estrutura de hardware

utilizada para suportar uma determinada aplicação e garantir requisitos não funcionais como a

segurança e escalabilidade [34]. Na Figura 53 é ilustrado o diagrama físico para deploy e

suporte das third party applications desenvolvidas no âmbito da plataforma Vortal Next>.

Figura 53 – Diagrama geral de deploy

As aplicações desenvolvidas através do SDK, dão origem a um pacote de software funcional

integrado na plataforma Next> e com acesso aos seus serviços. Este, será integrado num

cluster de servidores (Application Server Cluster), responsável por manter todas as aplicações

desenvolvidas. Através do clustering, é possível aumentar o número de servidores quando a


69

quantidade de third party applications o justificar, sem por em causa a disponibilização das

mesmas para os clientes e, assim, garantir a alta escalabilidade da solução.

As aplicações presentes no Application Server Cluster acedem, como já foi referido, aos

serviços da plataforma Vortal Next> para atingir o comportamento implementado pelo

utilizador. A Next> é responsável por interpretar os vários pedidos, por aceder e alterar a

informação necessária (maior parte das vezes, através de acesso à base de dados de SQL

Server) e retornar o resultado esperado.

A segurança de todas as comunicações é conseguida através da presença de firewall’s

intermediárias responsáveis pela implementação e execução das políticas de segurança

desejadas. Existe uma firewall entre os pedidos do cliente e o acesso às aplicações, outra

entre a comunicação das aplicações e da plataforma Next> e outra entre a Next> e o acesso à

base de dados. Ao nível dos dados, a segurança é mantida através da encriptação dos

mesmos através da utilizaçãoo do protocolo HTTPS.

Para além dos componentes acima mencionados existem, ainda, outros dois transversais a

todo o ambiente aplicacional, o Domain Controller e o Security Token Service (STS). O primeiro

é um servidor responsável por responder a pedidos de autenticação e conceder, ou não, o

acesso a um conjunto de recursos computacionais. O STS é o serviço de autenticação utilizado

para identificar os utilizadores da plataforma Next> com base em tokens e permitir que estes

naveguem entre as diferentes aplicações apenas com uma fase de login (single sign on/off).

Assim, sempre que uma aplicação é adicionada ao ambiente aplicacional da plataforma Next>

é necessário que seja adicionada ao domínio do STS de forma a garantir a autenticação e

autorização dos utilizadores à mesma. Em conjunto, o STS e o Domain Controller garantem a

segurança e confiabilidade da plataforma Next> e das aplicações desenvolvidas por terceiros,

no que toca à autenticação e autorização de utilizadores.

De salientar que todas as comunicações entre os diferentes componentes e o cliente são feitas

com base em HTTPS (segurança de dados), exceto a comunicação com a base de dados que

é feita utilizando o protocolo TCP/IP. A comunicação com a base de dados não se encontra

encriptada pelo facto de esta ser um componente interno de acesso muito restrito e, pelo facto

de todo o workflow de comunicação com o exterior ou com camadas de acesso superiores ser

realizado através de protocolos encriptados.


70

Modelo de Negócio

Na realidade empresarial atual, a evolução e disponibilização de novas funcionalidades é um

processo muito importante para garantir a vantagem competitiva. É importante para as

empresas, sempre que possível, elaborar estratégias de forma a aumentar a margem de lucro

e assim potenciar o seu negócio base.

O SDK, é direcionado aos utilizadores/empresas que utilizam a plataforma da Vortal e que

pretendem, de alguma forma, aumentar o leque de funcionalidades para garantir uma melhor

experiência de utilização. É um forma de colmatar as necessidades dos utilizadores, de

aumentar a comunidade da plataforma e de permitir o crescimento do mercado interno da

mesma. Neste, é possível a implementação de diversos tipos de estratégias de forma a

beneficiar, tanto a Vortal como os utilizadores responsáveis pelo desenvolvimento das

aplicações.

A primeira opção, tem em conta o facto de o SDK assentar sobre uma arquitetura baseada em

ViewElements que foram desenhados de forma a poderem ser adicionados ao SDK durante o

seu ciclo de vida, quer por necessidade dos utilizadores, quer por pedido destes à equipa de

desenvolvimento da Vortal. É possível definir elementos de livre utilização (que podem ser

utilizados por todos os utilizadores) e elementos que só podem ser utilizados mediante o

pagamento de um valor. A aliar a esta opção é ainda possível cobrar uma taxa de utilização

mensal, anual ou por número de aplicações (p.e. mediante uma valor, o utilizador tem a

possibilidade de submeter 3 aplicações) que oferecem um gama de componentes distintos

(p.e. a escolha da mensalidade possibilita o uso 10 componentes, enquanto que a anuidade

oferece uma gama de 20 componentes).

Como foi explicado durante a escrita da dissertação, as aplicações desenvolvidas pelos

utilizadores podem ser públicas ou privadas. As aplicações públicas podem ser utilizadas por

toda a comunidade Next> (i.e. estão disponíveis na Vortal Store) e as privadas apenas podem

ser utilizadas pela empresa que as desenvolveu. Por defeito, as aplicações são privadas e caso

o utilizador deseje a disponibilização das mesmas, tem de definir um valor de compra (para os

outros utilizadores), através do qual a Vortal arrecada 30% do total de transações.

Em conjunto com todas as opções apresentadas, é possível existir um serviço de apoio técnico

especializado por telefone, para os utilizadores menos experientes, que é assinado por um

determinado intervalo de tempo (escolhido pelo utilizador), mediante o pagamento de um


71

valor. De notar que indexado ao pacote base do SDK, já existe apoio técnico especializado mas

apenas através de troca de mensagens de e-mail.

Para a Vortal, os custos associados ao processo de disponibilizar um SDK de desenvolvimento

e de manter, em funcionamento, as aplicações desenvolvidas através do mesmo, estão

principalmente associados aos recursos a nível de hardware. Conforme o número de

aplicações aumenta é necessário aumentar, de igual forma, o número de servidores

aplicacionais que as suportam. É importante manter fatores chave como a performance e a

disponibilidade das aplicações e da plataforma Vortal Next>. O processo de desenvolvimento

do SDK, também se apresenta como um dos principais custos associados, pois é um processo

extremamente complexo e que necessita de uma equipa completamente dedicada ao seu

“fecho” dentro de um deadline definido.

Depois da sua disponibilização, é importante que exista uma equipa responsável por encontrar

pontos de melhoria da arquitetura, por aumentar o número de funcionalidades do SDK e por

garantir a sua evolução tecnológica.

É um processo extremamente complexo, que levará algum tempo a ficar completamente

funcional, mas que pode trazer inúmeras vantagens para a Vortal. Poderá ser um aspeto

diferenciador das restantes plataformas da área (concorrentes diretos) e é uma forma de

garantir novos processos de negócio que podem gerar receitas equivalentes ou superiores às

geradas através do negócio base. Para além da parte financeira, é uma funcionalidade que

pode atrair um grande número de utilizadores e, por consequência, permitir o crescimento da

plataforma a nível internacional.

Conclusões

73

7 Conclusões

Neste capítulo, é relembrado o trabalho realizado destacando as suas principais contribuições.

São respondidas as questões elaboradas no início da dissertação e, no final, descreve-se o

trabalho futuro a ser concretizado para a implementação e disponibilização da solução aos

clientes.

Trabalho Realizado e Conclusões

Esta dissertação propôs a elaboração de uma solução para permitir que um grupo especial de

utilizadores possa desenvolver as suas próprias aplicações e as integrar no ambiente

aplicacional da plataforma Vortal Next>. Foi necessário entender a arquitetura geral da

plataforma, os processos de negócio associados à mesma e a metodologia de

desenvolvimento utilizada (quais os seus conceitos principais e de que forma esta poderia

trazer benefícios para a solução a desenvolver).

Tendo em conta todas as características da plataforma (fluxos de negócio, metodologia de

desenvolvimento e arquitetura geral) foram encontradas, na literatura, três soluções

candidatas ao desenvolvimento de aplicações por parte de terceiros: a disponibilização de uma

API, a disponibilização de um SDK ou a implementação de um mecanismo baseado em plug-

ins. Para cada uma destas, foi realizado um estudo de quais as suas principais características,

dos conceitos teóricos associados, das principais vantagens e desvantagens e de quais os

contextos em que uma solução é escolhida em detrimento de outra (casos de estudo).

Pelo facto de a solução escolhida ter o intuito de ser disponibilizada em conjunto com a

plataforma Vortal Next>, foi feito um levantamento, no interior da empresa, de quais os pontos

mais importantes a ter em conta na solução a desenvolver. Esses pontos, foram usados como

comparação de cada uma das soluções e, no final, conclui-se que a disponibilização de um

SDK se apresentava como a solução com mais vantagens competitivas e aplicacionais para a

Vortal e para a plataforma já existente. O próximo passo, consistiu na definição do SDK

(utilizando “4+1” View Model) desenhando a sua arquitetura de software e de deploy nos

conformes da plataforma atual.

No início da dissertação, foram definidas quatro questões que, podem agora, ser discutidas.

As questões inicialmente propostas foram:

Conclusões

74

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? A resposta a esta pergunta surge com o levantamento das possíveis

soluções para o desenvolvimento de aplicações por parte de terceiros e com o estudo das

suas características ao longo do capítulos 4. Durante este capítulo, é demonstrado que as

três soluções (API,SDK e plug-in) são adequadas ao desenvolvimento de aplicações web,

dependendo de qual o contexto no qual são utilizadas. São soluções diferentes no que

toca à complexidade de implementação, aos recursos necessários, aos riscos envolvidos e

à simplicidade de utilização por parte do grupo de utilizadores finais.

A API é uma solução bastante fácil de desenvolver mas que não apresenta tanta

flexibilidade a nível de escalabilidade e evolução quando comparada com as outras. O SDK

é uma solução mais complexa mas que oferece aos seus utilizadores um leque de

funcionalidades mais alargado e garante as ferramentas necessárias para o bom

funcionamento da aplicação. Por último, o desenvolvimento baseado em plug-ins é uma

solução extremamente escalável e que oferece grandes vantagens para os utilizadores,

mas que em contrapartida é aquela que apresenta mais riscos envolvidos a nível

arquitetural e aplicacional.

No contexto da Vortal Next>, foi concluído (através da comparação feita no capítulo 1) que

o SDK é a solução que mais vantagens oferece ao negócio e à plataforma da Vortal. Esta

conclusão foi obtida, tendo por base vários pontos de avaliação, com diferentes pesos,

discutidos internamente pela equipa da Vortal (apresentados na Tabela 1).

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? Esta pergunta é respondida no decorrer no capítulo Erro! Fonte de

referência não encontrada., onde é apresentada a visão geral da solução, a sua respetiva

decomposição em diferentes módulos de software com detalhes específicos de

implementação e onde é provada a sua viabilidade através de casos de uso e diagramas

de sequência na perspetiva do utilizador final.

Nesta solução, o utilizador constrói as suas aplicações numa página web acessível apenas

se possuir credenciais de autenticação, recorrendo a programação visual. Desta forma, o

utilizador final apenas tem acesso ao conjunto de componentes desenvolvidos pela Vortal

Conclusões

75

o que garante a segurança, facilidade de desenvolvimento e grandes potencialidades do

ponto de vista comercial da solução.

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

ferramentas? A resposta a esta pergunta foi apresentada no capítulo 6.5.2, onde são

apresentados os diferentes constituintes do SDK, dando especial atenção aos

componentes gráficos (capítulo 6.5.2.1). Estes, podem ser considerados como a “base”

do SDK pois representam os diferentes componentes aos quais o utilizador tem acesso

para a construção das suas aplicações e aos quais pode adicionar diferentes tipos de

ações e comportamentos. Este package foi desenhado de forma a permitir que o leque de

componentes disponíveis pudesse crescer facilmente, dependendo das necessidades dos

utilizadores, alterando o mínimo possível a arquitetura e o código fonte já existente.

Assim, é possível considerar uma estratégia onde o utilizador tem acesso a um conjunto

de componentes básicos para a construção das suas aplicações (p.e. botões e caixas de

texto) e, mediante o pagamento de um valor (mais informações no capítulo 6.8), pode

aceder a outros componentes com funcionalidades mais avançadas e que possam trazer

valor acrescentado para as suas aplicações.

4. 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? Esta questão toca num ponto

extremamente sensível para o negócio base da Vortal. É uma área onde um minuto de

atraso pode ser a diferença entre um negócio bem-sucedido ou um negócio falhado e que

aglomera grandes comunidades de fornecedores e compradores. No capítulo 6.7 foi

apresentada a resposta a esta questão, com a definição da arquitetura para suportar as

aplicações desenvolvidas sem por em causa a plataforma atual e de forma a garantir a

escalabilidade, segurança e performance. As aplicações são mantidas num cluster de

servidores de forma a garantir a escalabilidade e a performance da solução e todas as

comunicações são salvaguardadas pela presença de firewall’s, pela utilização de

protocolos de encriptação de dados e pela presença do domain controller em conjunto

com o serviço de autenticação STS.

Em suma, esta dissertação fornece reposta às questões colocadas inicialmente, do ponto de

vista empresarial e aplicacional da plataforma Vortal Next>. É uma solução que pode trazer

Conclusões

76

imensas vantagens para a plataforma e que a pode destacar como uma das melhores

soluções existentes na área do comércio eletrónico.

Trabalho Futuro

O trabalho apresentado no âmbito desta dissertação é o embrião do futuro SDK de

desenvolvimento da Vortal já que apenas apresenta o desenho arquitetural da solução. Depois

do desenvolvimento do primeiro protótipo para testes com os utilizadores finais,

provavelmente, será necessário ajustar vários aspetos teóricos para melhor corresponder às

necessidades dos mesmos e permitir uma melhor experiência de utilização (não foi possível

desenvolver um protótipo aplicacional devido ao curto espaço de tempo da dissertação).

O SDK e os seus controlos, serão acessíveis através um IDE (uma página web integrada no

ambiente aplicacional Vortal Next>) responsável por garantir as funcionalidades de

programação visual (p.e. eventos drag and drop). O IDE e a sua respetiva interface gráfica são

aspetos fulcrais e decisivos para o sucesso da solução. Assim, outro dos pontos que

necessitará de especial atenção será a definição de uma interface simples de forma a garantir

um alto nível de usabilidade para os utilizadores finais (p.e. ser compatível com diversos tipos

de dispositivos e resoluções) e garantir a melhor experiência de utilização possível.

Há, sem dúvida, muito trabalho pela frente para concluir e disponibilizar a solução concebida

durante a dissertação. Os resultados e a arquitetura apresentada, representam um bom ponto

de partida para a implementação da solução (será necessário ajustar alguns conceitos

teóricos) e apresentam-se como um aspeto essencial para o sucesso da mesma.

Bibliografia

77

Bibliografia

1. CLEMENTS, P.; KEZMAN, R.; KLEIN, M. Evaluating a Software

Architecture. [S.l.]: InformIT, 206.

2. WILLIAMS, B. J.; CARVER, J. C. Characterizing software architecture

changes: A systematic review. Information and Software Technology, Julho

2009.

3. DUVANDER, A. 6,000 APIs: It’s Business, It’s Social and It’s Happening

Quickly. Programmable Web, 22 maio 2012. Disponivel em:

<http://blog.programmableweb.com/2012/05/22/6000-apis-its-business-its-

social-and-its-happening-quickly/>. Acesso em: fev. 2013.

4. AGUIAR, A. Framework Documentation. FEUP. Porto. 2003.

5. KLEPPE, A.; WARMER, ; BAST,. MDA Explained: The Model Driven

Architecture: Practice and Promise. [S.l.]: Addison Wesley, 2003.

6. MASHKOOR,. Investigating Model Driven Architecture. Department of

Computing Science. Sweden. 2004.

8. OMG. OMG Model Driven Architecture. OMG. Disponivel em:

<http://www.omg.org/mda/>. Acesso em: 2013.

7. BROWN, A. An introduction to Model Driven Architecture. IBM, 17 fev.

2004. Disponivel em:

<http://www.ibm.com/developerworks/rational/library/3100.html>. Acesso em:

19 fev. 2013.

9. J. MELLOR , et al. MDA Distilled: Principles of Model-Driven Architecture.

[S.l.]: Addison Wesley , 2004.

10. KALIAPPAN, P. S. Model Driven Architecture. Brandenburg Technical

University, Cottbus, Dezembro 2007. 1-17.

11. FOWLER, M.; PARSONS, R. Domain Specific Languages. [S.l.]: Addison-

Wesley Signature Series, v. 1, 2010.

Bibliografia

78

12. ALHIR, S. Methods and Tools. Understanding the Model Driven

Architecture (MDA), 2003. Disponivel em:

<http://www.methodsandtools.com/archive/archive.php?id=5>. Acesso em:

2013.

13. HAAN, J. D. 8 reasons why Model-Driven Development is dangerous. The

enterprise architect, 25 jun. 2009. Disponivel em:

<http://www.theenterprisearchitect.eu/archive/2009/06/25/8-reasons-why-

model-driven-development-is-dangerous>. Acesso em: 2013.

14. JACOBSON, D.; BRAIL, G.; WOODS, D. APIs: A Strategy Guide. [S.l.]:

O'Reilly, 2011.

15. YONGHONG, C.; XIWEI, X.; LIMING, Z. Web Platform API Design

Principles and Service Contract. Asia-Pacific Software Engineering

Conference. Australia: [s.n.]. 2012.

16. HEIDI-MARIA, R.; TOMAS, M.; MILJENKO, O. Design and

Implementation of a RESTful IMS API. Sixth International Conference on

Wireless and Mobile Communications. Finland : [s.n.]. 2010.

18. DUVANDER, A. New Job Requirement: Experience Building RESTful APIs.

Programmable Web, jun. 2010. Disponivel em:

<http://blog.programmableweb.com/2010/06/09/new-job-requirement-

experience-building-restful-apis/>. Acesso em: abr. 2012.

17. BLOEMENDAL, E. App stores for owners: a multiple-case study of app

stores. Utrecht University. [S.l.]. 2012.

19. FIELDING,. Architectural Styles and the Design of Network-based

Software Architectures. UNIVERSITY OF CALIFORNIA. IRVINE. 2000.

20. ECLIPSE Documentation. Eclipse. Disponivel em:

<http://help.eclipse.org/juno/index.jsp>. Acesso em: fev. 2013.

21. SCHLEINZER, B. et al. From Agents and Plugins to Plugin-Agents, Concepts

for Flexible Architectures. ESRGroups France, 2008.

Bibliografia

79

22. SAYFAN, G. Building Your Own Plugin Framework. Numenta. [S.l.]. 2007.

23. ROßLING, G.; SCHROEDER, P. Animalipse - An Eclipse Plugin for

AnimalScript. Electronic Notes in Theoretical Computer Science, 2009.

24. BOLOUR COMPUTING. Notes on the Eclipse Plug-in Architecture. Eclipse,

2003. Disponivel em: <http://www.eclipse.org/articles/Article-Plug-in-

architecture/plugin_architecture.html>. Acesso em: 2013.

25. RAINVILLE-PITT, S.; D’AMOUR, J.-M. Using a CMS to create fully

accessible websites. International cross-disciplinary conference on Web

accessibility, 2007.

26. LUST, G. et al. Content Management Systems: Enriched learning opportunities

for all? Computers in Human Behavior, 2012.

28. JOOMLA. Joomla! Framework vs Joomla! Platform. Joomla Documentation,

2012. Disponivel em:

<http://docs.joomla.org/Joomla!_Framework_vs_Joomla!_Platform>. Acesso

em: 2013.

27. SINGHAL, N.; MOHAN, T.; SARKAR, S. A COMPARATIVE STUDY

BASED ON OPEN SOURCE CONTENT MANAGEMENT SYSTEMS.

Indian Journal of Computer Science and Engineering, 2010.

29. HENDERSON, C. Building Scalable Web Sites. USA: O'Reilly, 2006.

30. ALLAMARAJU'S, S. Performance of RESTful Apps. subbu, 4 Março 2011.

Disponivel em: <http://www.subbu.org/blog/2011/03/performance-of-restful-

apps>. Acesso em: 18 Abril 2013.

31. TWITTER. Twitter Documentation. Twitter Documentation, 22 fev. 2013.

Disponivel em: <https://dev.twitter.com/docs/api/1.1>. Acesso em: mar. 2013.

32. YAHOO. Best Practices for Speeding Up Your Web Site. Yahoo, 2013.

Disponivel em:

<http://developer.yahoo.com/performance/rules.html#num_http>. Acesso em:

2013.

Bibliografia

80

33. BRAGG, S. D. AUTOTESTCON '94. IEEE Systems Readiness Technology

Conference. 'Cost Effective Support Into the Next Century', Conference

Proceedings. Anaheim, CA: [s.n.]. 1994. p. 211 - 220.

34. KRUCHTEN, P. Architectural Blueprints—The “4+1” View Model of

Software Architecture. IEEE Software 12 , 1995.

35. FCG SOFTWARE SERVICES. Applying 4+1 View Architecture with UML 2 ,

2007.

36. IBM. Benefits of using patterns. IBM, 2005. Disponivel em:

<http://publib.boulder.ibm.com/infocenter/rsdvhelp/v6r0m1/index.jsp?topic=%

2Fcom.ibm.xtools.pttrn.author.doc%2Ftopics%2Fc_benefits_ptrns.html>.

Acesso em: 18 maio 2013.

38. FREEMAN, E. et al. Head First Design Patterns. 1. ed. [S.l.]: O'REILLY,

2004.

37. DATA & OBJECT FACTORY. Design Patterns. Do Factory, 2001. Disponivel

em: <http://www.dofactory.com/Patterns/Patterns.aspx>. Acesso em: 12 mar.

2013.

39. SILVA, F. Improving the usability of web applications: more results with

less effort. Universidade do Minho. Braga. 2013.

81

Anexo 1 Diagrama de Casos de Uso

Na Figura 54, é apresentado o diagrama de casos de uso da utilização do SDK. De notar que

os casos de uso de gestão (p.e. Gerir Ações) compreendem as ações de criação, remoção,

visualização, edição e listagem (CRUD) que não foram representadas por questões de

visualização e simplificação do diagrama.

Figura 54 – Diagrama Detalhado de Casos de Uso

82

Anexo 2 Diagramas de Sequência

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

83

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

84

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

85

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

86

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

guião de relatório de projecto / estágio · pim platform independent model psm platform specific...

Documents