Upload
lamkhue
View
214
Download
0
Embed Size (px)
Citation preview
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
Arquitetura e Escalabilidade ................................................................................................. 39
Facilidade de Desenvolvimento ............................................................................................. 40
Performance e Interoperabilidade ......................................................................................... 40
Time to Market .................................................................................................................... 41
Vantagem Competitiva ......................................................................................................... 41
DESENVOLVIMENTO BASEADO EM PLUG-INS ............................................................................................ 42
Arquitetura e Escalabilidade ................................................................................................. 42
Facilidade de Desenvolvimento ............................................................................................. 42
Performance ....................................................................................................................... 43
Time to Market .................................................................................................................... 43
Vantagem Competitiva ......................................................................................................... 44
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
Model Driven Architeture
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.).
Model Driven Architeture
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
Model Driven Architeture
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.
Model Driven Architeture
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).
Model Driven Architeture
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)
Model Driven Architeture
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.
Model Driven Architeture
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.
Model Driven Architeture
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.
Arquitetura Vortal Next>
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.
Arquitetura Vortal Next>
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
Arquitetura Vortal Next>
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
Arquitetura Vortal Next>
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
Arquitetura Vortal Next>
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].
Integração de Aplicações de Terceiros
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.
Integração de Aplicações de Terceiros
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].
Integração de Aplicações de Terceiros
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
Integração de Aplicações de Terceiros
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.
Integração de Aplicações 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).
Integração de Aplicações de Terceiros
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
Integração de Aplicações de Terceiros
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-
Integração de Aplicações de Terceiros
33
ins são componentes isolados) e, pelo facto de um plug-in normalmente representar uma
funcionalidade específica, o seu desenvolvimento é focado não existindo over-development
[25]. Apesar de ser uma abordagem extremamente flexível e que garante um alto nível de
escalabilidade é, de todas as abordagens apresentas, aquela que possivelmente traz mais
complexidade e riscos associados. A complexidade deste tipo de aplicação cresce
exponencialmente com o número de plug-ins desenvolvidos e, com isso, aumenta a dificuldade
de gestão e probabilidade de conflitos entre os mesmos. Uma das dificuldades associadas a
este tipo de abordagem é a de garantir a gestão e compatibilidade entre diferentes versões do
mesmo plug-in [22].
É ainda necessário que exista um mecanismo que valide o conteúdo dos plug-ins
desenvolvidos, para que estes não interfiram no bom funcionamento do core aplicacional e um
mecanismo que garanta a integração dos mesmos com o core aplicacional.
Avaliação das Possibilidades
35
5 Avaliação das Possibilidades
Derivado do estudo previamente efetuado e no sentido de identificar quais as abordagens mais
utilizadas de forma a permitir o desenvolvimento de Third Party Applications, é necessário
avaliar e mapear estas abordagens no contexto aplicacional e arquitetural da plataforma Vortal
Next>. Por cada abordagem, é avaliado o seu impacto na arquitetura atual e a facilidade de
desenvolvimento quer na perspetiva do utilizador final quer na perspectiva da complexidade da
solução. Questões relacionadas com a performance e interoperabilidade da solução serão
também avaliadas e, por último, será avaliada a abordagem a nível de time-to-market e
vantagem competitiva para o negócio atual da Vortal.
API’S baseadas em REST
No contexto Next>, uma API REST é um serviço que poderá trazer grandes vantagens, dado
que permite o desenvolvimento de diversas aplicações para uma gama de dispositivos mais
alargada. Sendo a Next> uma plataforma com o intuito de se tornar uma referência
internacional no mercado de contratação eletrónica, é essencial que acompanhe o avanço
tecnológico e proporcione diversas formas de integração com plataformas externas.
Arquitetura e Escalabilidade
Como já foi referido (3.1), no ecossistema Next> existem dois componentes principais: o
Marketplace e o Community. O Community funciona como um gestor de vários conteúdos
(p.e. informação de empresas) e o Marketplace representa a área de trabalho dos
compradores e dos fornecedores. Assim, é possível concluir que a informação com mais
relevância para o negócio do utilizador se encontra ao nível do Marketplace, ou seja, toda a
informação relacionada com as consultas da plataforma (respostas, avaliações, negociações,
etc. ). Devido a este facto, o Marketplace vai ser o foco de toda a dissertação e de todas as
soluções apresentadas, sem prejuízo de a arquitetura da solução apresentar flexibilidade
suficiente para a inclusão de informação derivada de outras fontes internas à plataforma.
Assim sendo, quando se pensa na disponibilização de uma API, é aconselhável que esta se
encontre ao nível do Marketplace, que seja acessível através de Web Services REST, que seja
responsável pela comunicação com a plataforma e pelo retorno dos dados no formato
adequado (Figura 26).
Avaliação das Possibilidades
36
Figura 26 – Visão geral da arquitetura Next> com uma API REST
Esta solução tem um impacto reduzido na arquitetura dado que apenas é necessário definir
camadas de acesso independentes da arquitetura atual que, por sua vez, possuam os
métodos necessários para aceder aos dados já existentes.
A escalabilidade é, muitas vezes, referida como a facilidade de um sistema ser modificado de
forma a responder a um determinado problema. Esta definição de escalabilidade é
suficientemente vaga para gerar confusão e diferentes opiniões relativamente ao assunto. A
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]
Avaliação das Possibilidades
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).
Avaliação das Possibilidades
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.
Avaliação das Possibilidades
39
Software Development Kits
Arquitetura e Escalabilidade
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.
Avaliação das Possibilidades
40
Facilidade de Desenvolvimento
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
Avaliação das Possibilidades
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.
Vantagem Competitiva
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
Avaliação das Possibilidades
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
Arquitetura e Escalabilidade
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.
Facilidade de Desenvolvimento
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.
Avaliação das Possibilidades
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.
Avaliação das Possibilidades
44
Vantagem Competitiva
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.
Avaliação das Possibilidades
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
Avaliação das Possibilidades
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.
Vortal Development Software Kit
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.
Vortal Development Software Kit
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].
Vortal Development Software Kit
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,
Vortal Development Software Kit
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>.
Vortal Development Software Kit
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
Vortal Development Software Kit
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.
Vortal Development Software Kit
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.
Vortal Development Software Kit
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
Vortal Development Software Kit
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].
Vortal Development Software Kit
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
Vortal Development Software Kit
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
Vortal Development Software Kit
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
Vortal Development Software Kit
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.
Vortal Development Software Kit
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).
Vortal Development Software Kit
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.
Vortal Development Software Kit
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.
Vortal Development Software Kit
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
Vortal Development Software Kit
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.
Vortal Development Software Kit
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
Vortal Development Software Kit
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.
Vortal Development Software Kit
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
Vortal Development Software Kit
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.
Vortal Development Software Kit
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
Vortal Development Software Kit
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