-
Técnicas Avançadas de Modelação e ProduçãoSemi-Automática
de Aplicações Web Responsivas
Gonçalo Ribeiro Pereira
Dissertação para obtenção do Grau de Mestre em
Engenharia Informática e de Computadores
Orientador: Prof. Alberto Manuel Rodrigues da Silva
Júri
Presidente: Prof. Paolo RomanoOrientador: Prof. Alberto Manuel
Rodrigues da Silva
Vogal: Prof. António Paulo Teles de Menezes Correia Leitão
Maio 2019
-
Agradecimentos
Com a finalização desta tese de mestrado, é fechado um ciclo
do qual retive varias lições e apren-
dizagens que levarei comigo. Apesar de ter demorado um pouco
mais do que o previsto, onde pelo
caminho encontrei imensos desafios, tristezas, incertezas e
alegrias que fazem parte do processo. Foi-
me possı́vel concluir este trabalho porque tive comigo várias
pessoas, a motivar, guiar e aconselhar,
que foram indispensáveis para encontrar o melhor rumo e seguir
pelo melhor caminho. Serve então
estas palavras para lhes mostrar a minha gratidão.
Gostaria de agradecer aos meus pais pela amizade, e pela coragem
que me deram ao longo de
todos estes anos, e por estarem sempre lá tanto nos bons como
nos maus momentos. Foram eles que
me providenciaram com todas as condições para que fosse
possı́vel concluir esta etapa. Um obrigado
especial por tudo.
Quero deixar também uma palavra de apreço aos meu orientador,
Professor Alberto Rodrigues da
Silva pelo excelente acompanhamento que me deu durante todo o
processo, mostrando-se sempre
disponı́vel para esclarecer a qualquer duvida durante todo o
processo tudo em prol do sucesso deste
projecto. Os seus conselhos e experiência foram um factor
decisivo para que tudo corresse pelo melhor.
Por ultimo, mas não menos importante, gostava de agradecer a
todos os meus amigos e colegas
por toda a amizade e apoio durante os bons e maus momentos.
A todos e a cada um em particular um grande Obrigado.
-
Abstract
Web applications are widely used due to the facilities they
offer such as social interactions, easy access
to information or even as enterprise business point. Along with
all these utilities, traditional desktop appli-
cations are being gradually converted into web applications as
it also brings advantages such as: easier
support and maintenance; compatibility with a greater number of
devices (smartphone, laptop, tablet),
ease update of content. However, there are adjoining
difficulties in web development, namely: need
to know several languages and frameworks, security mechanisms,
databases structure and responsive
design.
This dissertation aims to develop a ” RSL2WebApp ” tool in order
to generate source code for web
applications requiring only a System Requirement Specification
(SRS) from the user. For SRS it is used
RSL which is a strict, consistent, and easy-to-use language for
SRS that aims to reduce inconsistencies
and reduce the number of errors during system specification. In
the chapter Evaluation 5, it can be
observed that starting from a few lines of specification of a
system in RSL, it is generated a whole web
application ready to run , making the web development process
much easier and faster . In this report
will be introduced several topics related to the development of
web applications and the automation of it.
It also explains in detail the operation of RSL2WebApp and the
way in which a requirements specification
is made in RSL.
Keywords
Aplicações Web, RSL, Model Driven Engineering, Angular6,
ASP.NET Core 2, Xtend, Xtext;
iii
-
Resumo
As facilidades que as aplicações web oferecem promovem o
aumento da sua utilização e desenvol-
vimento. Exemplos destas facilidades são; interacções
sociais, fácil acesso à informação ou mesmo
como ponto de negócio das empresas. Além destas facilidades,
as aplicações desktop estão a ser pro-
gressivamente convertidas em aplicações web devido às
vantagens que trazem como: custo reduzido;
suporte e manutenção mais fáceis compatibilidade com maior
número de dispositivos (smartphone,
portátil, tablet), facilidade de actualização de conteúdos e
etc. No entanto o seu desenvolvimento trás
dificuldades adjacentes nomeadamente: necessidade de conhecer
várias linguagens e frameworks,
mecanismos de segurança, bases de dados e design responsivo
entre outras. Esta dissertação tem
como objectivo desenvolver uma ferramenta ”RSL2WebApp” com
intuito de gerar código fonte para
aplicações web necessitando apenas dum Documento de
Especificação de Requisitos ( ou em inglês
Software Requirements Specification) (SRS) por parte do
utilizador. Como linguagem de especificação
e requisitos é utilizada o RSL. O RSL é uma linguagem para
especificação de requisitos de sistema ri-
gorosa, consistente e fácil de usar que visa a reduzir as
inconsistências e reduzir a quantidade de erros
durante a especificação de um sistema. No capı́tulo
Avaliação 5, pode ser observado que partindo de
poucas linhas de especificação de um sistema em RSL, é gerado
código fonte de uma aplicação web
pronta a correr, transformando o processo de desenvolvimento web
bastante mais fácil e rápido. Neste
relatório serão introduzidos vários tópicos relacionados com
o desenvolvimento de aplicações web e
na automatização do mesmo. É também explicado em detalhe o
funcionamento do RSL2WebApp e do
modo de como é feita uma especificação de requisitos em
RSL.
Palavras Chave
Aplicações Web, RSL, Engenharia Derivada de Modelos,Angular6,
ASP.NET Core 2, Xtend, Xtext;
v
-
Conteúdo
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 4
1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 5
2 Contexto 7
2.1 aplicações Web . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 9
2.2 Engenharia de Requisitos . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 10
2.3 Linguagens Especı́ficas de Domı́nio . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 11
2.4 A iniciativa RSLingo . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 13
2.5 Engenharia Conduzida por Modelos . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 15
2.5.1 Modelos e Metamodelos . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 15
2.5.2 Aparecimento da Engenharia Conduzida por Modelos . . . . .
. . . . . . . . . . . 15
2.5.3 Linguagens de Modelação . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 16
2.5.4 Transformação de Modelos e Geração de Código . . . .
. . . . . . . . . . . . . . 16
3 Tecnologias de Suporte 19
3.1 Frameworks para desenvolvimento do lado do cliente . . . . .
. . . . . . . . . . . . . . . 21
3.1.1 Angular . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 22
3.1.2 React . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 23
3.1.3 Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 25
3.2 Frameworks e Linguagens de Programação do lado do servidor
. . . . . . . . . . . . . . 27
3.2.1 ASP.NET Core . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 29
3.2.2 Node.js . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 30
3.2.3 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 31
3.3 Tecnologias para Geração de Código . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 32
3.3.1 Acceleo . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 33
3.3.2 Xtend . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 33
3.4 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 34
vii
-
3.4.1 RSL . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 34
3.4.2 Angular6 . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 36
3.4.3 ASP.NET Core . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 36
3.4.4 Xtend . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 36
3.5 Visão geral do Sistema . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 37
4 Abordagem RSL2WebApp 39
4.1 Aplicação Web de referência QuickApp . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 41
4.2 Especificação RSL e keywords suportadas . . . . . . . . .
. . . . . . . . . . . . . . . . . 44
4.2.1 Elemento DataEntity . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 45
4.2.2 Elemento DataEntityCluster . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 46
4.2.3 Elemento Actors . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 47
4.2.4 Elemento UseCase . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 48
4.3 RSL2WebApp geração de código fonte . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 48
4.3.1 Entidades(tabelas) para base de dados DataEntities . . . .
. . . . . . . . . . . . . 50
4.3.2 Papeis e permissões associadas . . . . . . . . . . . . .
. . . . . . . . . . . . . . . 54
4.3.3 Controladores . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 57
4.3.4 páginas do lado do cliente . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 58
4.3.5 Serviços lado do cliente . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 60
5 Avaliação 63
5.1 Casos de estudo . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 65
5.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 68
5.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 68
6 Conclusão 71
6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 73
6.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 74
A Exemplos da tipificação do elemento UseCase 75
B Exemplo: Requisitos informais do Billing System 77
viii
-
Lista de Figuras
2.1 Modelo das aplicações Web Tradicional vs aplicações Web
SPA . . . . . . . . . . . . . . 10
2.2 Diferenças entre XML, JSON e uma DSL especifica para
leitura de informação sobre
pessoas [1] . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 12
2.3 Classificação dos dos elementos RSL [2]. . . . . . . . . .
. . . . . . . . . . . . . . . . . . 14
2.4 MDE transformação de modelos. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 17
3.1 Elementos utilizados para especificação RSL neste
projecto, adaptado de [3]. . . . . . . . 35
3.2 Visão geral do fluxo do processo do RSL2WebApp. . . . . . .
. . . . . . . . . . . . . . . 37
4.1 Login QuickApp . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 42
4.2 Gestão de papeis QuickApp . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 42
4.3 Repositório e unidade de trabalho . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 43
4.4 Exemplo de uma especificação em RSL para o elemento
DataEntity . . . . . . . . . . . . 46
4.5 Exemplo de uma especificação em RSL para o elemento
DataEntityCluster . . . . . . . . 47
4.6 Exemplo de uma especificação em RSL para o elemento Actor
”Operator” . . . . . . . . . 47
4.7 Exemplo de uma especificação em RSL para o elemento
UseCase . . . . . . . . . . . . . 48
4.8 Método doGenerate Xtend . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 49
4.9 Processo de geração . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 49
4.10 Arquitetura do RSL2WebApp . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 50
4.11 Classe dominio gerada . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 51
4.12 Relações entre DataEntities RSL . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 52
4.13 Relação um-para-zero-ou-um RSL . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 53
4.14 Relações um-para-muitos . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 54
4.15 DataEntity derivada . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 55
4.16 Permissões geradas para a DataEntity e Vat . . . . . . . .
. . . . . . . . . . . . . . . . . 56
4.17 Geração de função/papel e utilizador . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . 57
4.18 Pagina principal da e Vat DataEntity . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 58
ix
-
4.19 Pagina de edição de um registo da e Vat DataEntity . . .
. . . . . . . . . . . . . . . . . . 59
4.20 Pagina principal com detalhe da e Invoice DataEntity . . .
. . . . . . . . . . . . . . . . . . 60
4.21 Pagina principal com detalhe aberto da e Invoice DataEntity
. . . . . . . . . . . . . . . . 61
5.1 Fragmento da descrição do Billing System para para que diz
respeito aos actores [3] . . . 66
5.2 Representação dos Actors em RSL para o Billing System . .
. . . . . . . . . . . . . . . . 67
5.3 Representação das DataEntities em RSL para o Billing
System . . . . . . . . . . . . . . . 69
x
-
Lista de Tabelas
3.1 Comparação Angular, React e Vue.js . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 26
3.2 Comparação ASP.NET Core, NodeJS e PHP . . . . . . . . . .
. . . . . . . . . . . . . . . 33
xi
-
Acrónimos
SRS Documento de Especificação de Requisitos ( ou em inglês
Software Requirements
Specification)
RSL Requirements Specification Language
DSL linguagem especı́fica de domı́nio (ou em inglês,
Domain-Specific Language)
GPL linguagem de propósito geral (ou em inglês,
General-purpose language)
SPA aplicação de página única (ou em inglês, Single-Page
Application)
RE engenharia de requisitos (ou em inglês, Requirements
engineering)
NL lı́ngua natural (ou em inglês, Natural Language)
CNL lı́ngua natural controlada (ou em inglês, Controlled
Natural Language)
MDA arquitectura orientada por modelo (ou em inglês,
Model-Driven Architecture)
MDE engenharia conduzida por modelos (ou em inglês,
Model-Driven Engineering)
M2T modelo para texto (ou em inglês, Model-to-Text)
M2M modelo para modelo (ou em inglês, Model-to-Model)
xii
-
1Introdução
Conteúdo
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . 3
1.2 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . 4
1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 5
1
-
2
-
Este capı́tulo descreve a motivação para o desenvolvimento
deste projecto. Descreve também o ob-
jectivo principal, que será o desenvolvimento da ferramenta
”RSL2WebApp”, e estrutura do documento.
1.1 Motivação
O uso de aplicações web está presente no quotidiano, pois
facilita várias tarefas tais como o acesso
ao correio electrónico, a interacção social com amigos,
familiares ou mesmo para assuntos profissio-
nais através de redes sociais (Facebook, Instagram, Linkedin,
etc.), e o acesso facilitado à informação
através de aplicações web de notı́cias relacionados com uma
grande variedade de assuntos como me-
dicina, informática, nutrição, etc. Isto leva à necessidade
de construir mais e melhores aplicações web.
No entanto, o desenvolvimento deste tipo de aplicações web
pode ser um processo bastante desafiante
e demorado, pois é necessário reunir conhecimentos de várias
áreas tecnológicas. Exemplos da difi-
culdade do desenvolvimento destas aplicações são as
seguintes: grande diversidade de linguagens de
programação para o desenvolvimento no lado do servidor;
dominar o conhecimento de HTML CSS e
JavaScript para o lado do cliente; conhecer frameworks que
ajudam no desenvolvimento tanto no lado
do servidor como do cliente; base de dados; segurança; design
responsivo, etc. Devido a todas estas
dificuldades envolvidas no desenvolvimento de aplicações web,
fica claro que, uma ferramenta que seja
capaz de gerar código fonte para este tipo de aplicações web,
baseado-se apenas em requisitos do
sistema, poderá ser de grande utilidade reduzindo a
complexidade do desenvolvimento deste tipo de
aplicações web.
O desenvolvimento de um documento que descreve os requisitos e
caracterı́sticas de um sistema é
chamado de Documento de Especificação de Requisitos ( ou em
inglês Software Requirements Spe-
cification) (SRS), pois fornece uma visão partilhada entre
todos os principais intervenientes durante a
concepção e implementação de um sistema [4]. No entanto, em
geral, a forma mais comum e preferida
para representação dos requisitos do sistema é através do
uso da lı́ngua natural (ou em inglês, Natural
Language) (NL), o que tem introduzido alguns problemas (conforme
explicado mais à frente). Uma
solução para mitigar esses problemas é através da adopção
da linguagem Requirements Specification
Language (RSL) [4] para especificação de requisitos, que
também facilita a automatização de algumas
tarefas relacionadas com a análise e validação de requisitos
(o RSL é descrito com maior detalhe mais
à frente na secção 2.4).
Com o RSL2WebApp, a complexidade do desenvolvimento de
aplicações web é reduzida significa-
tivamente uma vez que é apenas necessário a especificação do
sistema alvo utilizando o RSL, cuja
especificação é depois usada como fonte para a geração de
tais aplicações web. Quando comparado
com todas as dificuldades adjacentes ao desenvolvimento web,
fica claro que esta ferramenta pode
reduzir significativamente o tempo e esforço do seu
desenvolvimento.
3
-
1.2 Objectivo
O objectivo principal deste projecto é conhecer e implementar
uma ferramenta, designada por ”RSL2WebApp”,
que seja capaz de gerar código fonte para aplicações web a
partir de especificações do sistema em
RSL. As aplicações web produzidas serão constituı́das por uma
interface com a qual o utilizador poderá
interagir e um servidor que contém toda a lógica juntamente
com a toda a estrutura de base de dados
que irá fornecer os dados relevantes. A interface será
construı́da usando a framework Angular6 1 e
o servidor será construı́do com a framework ASP.NET Core 2.
Para a geração de código e leitura da
especificação de requisitos é usada a linguagem Xtend 3.
A geração do código fonte para aplicação web requer, por
parte do utilizador, uma SRS. Essa
especificação, que consiste basicamente num conjunto de
funcionalidades e requisitos que a aplicação
deve satisfazer, é representada e definida usando a linguagem
RSL. O RSL é uma linguagem que ajuda
a melhorar a produção de requisitos, descrita à frente em
maior detalhe na secção 2.4.
Estes SRS serão processados pelo RSL2WebApp através das
tecnologias Xtext/Xtend, que irá gerar
o código final, tanto para o lado do cliente como para o lado
do servidor, de acordo com o que foi
especificado pelo utilizador.
Para a avaliação, é verificada a percentagem coberta pelo
RSL2WebApp em relação ao SRS em
RSL desenvolvido pelo utilizador. Isto é, se todos elemento
definido no RSL juntamente com o seus
atributos foram ”lidos” pelo RSL2WebApp e gerado o código fonte
esperado.
Para uma avaliação inicial, são usados dois sistemas. Um
sistema fictı́cio chamado ”Billing Sys-
tem”descrito na secção 5.1 que já possui uma especificação
bem definida para ser usada nos testes
de geração de código. E outro sistema editado por mim, que
representa uma loja online designada
de ”MyStore”, onde será possı́vel criar um carrinho de compras
com o intuito de verificar a generali-
dade de especificações e evitar dependências do sistema
”Billing System”. Tendo em conta o que foi
mencionado acima, os objectivos desta dissertação são os
seguintes:
- Investigação e aprendizagem em conhecimentos gerais de
tecnologias de suporte para desenvol-
vimento de aplicações Web; Aprendizagem da linguagem
Requirements Specification Language
(RSL) e Aprendizagem das tecnologias Xtext and Xtend.
- Definição e implementação de modelos para geração de
código para as tecnologias Angular6(interface)
e ASP.NET Core(servidor), usando as tecnologias Xtext e Xtend, a
partir das especificações em
RSL (RSL2WebApp).
- Validação e avaliação dos resultados obtidos, com base em
cenários concretos.
1https://angle.io/2https://docs.microsoft.com/en-us/aspnet/core/3http://www.eclipse.org/xtend/programming
4
https://angle.io/https://docs.microsoft.com/en-us/aspnet/core/http://www.eclipse.org/xtend/programming
-
1.3 Estrutura do documento
Este relatório é composto por seis capı́tulos e está
organizado da seguinte maneira.
O capı́tulo 1 Introdução, introduz a motivação e os
objectivos principais deste projecto e ainda a
organização deste documento.
O capı́tulo 2 Contexto, contextualiza o âmbito da
investigação onde são adoptados e introduzidos
alguns conceitos tais aplicações web, engenharia de
requisitos, linguagens especificas de domı́nio, a
iniciativa RSL e engenharia conduzida por modelos.
O capı́tulo 3, Tecnologias de Suporte, apresenta algumas das
tecnologias e ferramentas mais re-
levantes dentro do contexto deste projecto. São apresentadas e
discutidas algumas das ferramentas
mais populares para o desenvolvimento web, tanto para o lado do
cliente como para o lado servidor.
Da mesma forma, tecnologias para geração de código são
também discutidas neste capı́tulo. Poste-
riormente, são explicadas as escolhas para as tecnologias
usadas neste projecto, tendo em conta os
seus objectivos. Além disso, mostra uma visão geral da
RSL2WebApp, com uma descrição detalhada
de como todas as peças estão ligadas, nomeadamente como é
feita a transformação da especificação
RSL para código-fonte.
O capı́tulo 4, Abordagem RSL2WebApp, é apresentado o projecto
template QuickApp que serve
como base para a construção do sistema RSL2WebApp. É
explicado também de que forma o RSL2WebApp
faz a leitura da especificação do sistema em RSL e como é
feita a geração de código fonte. Por fim é
explicado como é construı́da uma especificação de sistemas
usando a linguagem RSL.
O capı́tulo 5, Avaliação, descreve como nomeadamente o
trabalho realizado é testado e avaliado
em relação à sua capacidade de ler e interpretar a
especificação gerada pelo utilizador e gerar código
correspondente.
Por último, o capı́tulo 6, Conclusão, apresenta a conclusão
deste trabalho, com os pontos negativos
e positivos durante com todas as aprendizagens e visão geral de
todo o processo, assim como as
vantagens e utilidade que esta ferramenta poderá ter.
5
-
6
-
2Contexto
Conteúdo
2.1 aplicações Web . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 9
2.2 Engenharia de Requisitos . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 10
2.3 Linguagens Especı́ficas de Domı́nio . . . . . . . . . . . .
. . . . . . . . . . . . . . . . 11
2.4 A iniciativa RSLingo . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 13
2.5 Engenharia Conduzida por Modelos . . . . . . . . . . . . . .
. . . . . . . . . . . . . . 15
7
-
8
-
Neste capı́tulo, são introduzidos assuntos relevantes dentro do
contexto onde se encontra inserida
esta dissertação. É feita uma breve introdução aos
conceitos relacionados com aplicações web, no-
meadamente a noção de aplicação de página única (ou em
inglês, Single-Page Application) (SPA).
Descreve também a linguagem RSL e qual a necessidade e
vantagens da sua utilização, que inclui
tópicos como: engenharia de requisitos (ou em inglês,
Requirements engineering) (RE), linguagem es-
pecı́fica de domı́nio (ou em inglês, Domain-Specific Language)
(DSL). É também introduzido o conceito
de engenharia conduzida por modelos.
2.1 aplicações Web
No desenvolvimento de websites têm sido usadas as seguintes
linguagens: HTML, que permite definir
a estrutura e o conteúdo (como textos, imagens, tabelas, etc);
e CSS, que permite definir o estilo
e apresentação dos elementos desses websites (como fontes,
cores, margens, etc.). Contudo, com
estas duas tecnologias, é apenas possı́vel criar um website
estático que não possibilita a interacção
com o utilizador.
Por outro lado, uma aplicação web permite um maior nı́vel de
interacção e tem como objectivo
oferecer uma experiência de utilização semelhante ao de uma
aplicação desktop, incluindo conteúdos
dinâmicos. Para tal, é necessário usar JavaScript. O
JavaScript (normalmente abreviado como JS),
é a linguagem de programação mais popular no contexto da web
que permite que os scripts sejam
executados no lado do cliente (navegador). Com esses scripts JS
as páginas web integram conteúdos
mais dinâmicos e interactivos, dando a sensação de uma
aplicação desktop.
As aplicações web são facilmente acessı́veis a partir de
qualquer dispositivo (tablet, smartphone,
laptop, etc.) com acesso à Internet usando um navegador web. Em
contraste com as aplicações desk-
top tradicionais, que precisam ser previamente instaladas para
poderem ser utilizadas, as aplicações
web podem ser acedidas a partir de qualquer dispositivo desde
que tenha acesso à Internet e um na-
vegador web. Algumas das vantagens das aplicações web são as
seguintes: maior disponibilidade;
acessibilidade por uma variedade diferente de
dispositivos(smartphones, portáteis, tablets, etc); maior
facilidade de manutenção e suporte; credibilidade no ramo
empresarial com um aplicação web oficial.
Uma SPA é uma aplicação web baseada no modelo ”página única
web”, com o objectivo principal de
oferecer aos seus utilizadores uma experiência de interacção
semelhante à das aplicações desktop [5].
Nas aplicações web tradicionais (aplicação de várias
páginas) geralmente, quando o utilizador interage
com a aplicação, é enviado um pedido ao servidor, que
tratará do pedido e enviará a resposta para o
cliente com o novo conteúdo HTML, e finalmente, renderizado
pelo navegador do cliente para poder
ser visualizado. O problema com esta abordagem é que são
enviados muitos pedidos para o servidor.
Sempre que seja necessário mudar o conteúdo HTML, o utilizador
terá de esperar pelo ”download”da
9
-
nova página web, o que resulta numa experiência de
utilização mais demorada e não tão natural como
desejado.
Por outro lado no modelo SPA, normalmente todo o código
necessário (HTML, JavaScript, e CSS)
ou é obtido com um único carregamento da página, ou é
carregado dinamicamente e adicionado con-
forme necessário. Isto faz com que, sempre que seja necessário
alterar o conteúdo da página, o próprio
navegador irá tratar da nova renderização com JavaScript. Por
conseguinte, o servidor não é ocupado
durante este processo o que torna a renderização muito mais
rápida providenciando uma experiência
de utilização mais responsiva, ao nı́vel das aplicações
desktop. No entanto, se forem precisos dados ou
realização de cálculos do servidor, o pedido dos dados será
feito assincronamente, conforme mostrado
na figura 2.1 e a renderização será feita da mesma
maneira.
Figura 2.1: Modelo das aplicações Web Tradicional vs
aplicações Web SPA (extraı́do de1).
2.2 Engenharia de Requisitos
Ter uma ideia clara e concisa do domı́nio do problema é
essencial para ter sucesso durante o desen-
volvimento de um projecto.
Antes de começar a desenvolver a solução, é necessário que
haja uma documentação adequada
e detalhada, pois o sucesso e o custo-benefı́cio de um
desenvolvimento de sistemas de software de-
pendem fortemente deste aspecto [6]. Esta actividade diz
respeito à área de RE. A área RE consiste
em várias tarefas/actividades para oferecer uma visão/ideia
partilhada do sistema entre as partes inte-
ressadas do projecto [4]. Embora todas as actividades sejam
importantes, neste projecto é dada uma
atenção especial à actividade SRS.
SRS é um documento que descreve várias preocupações
técnicas de um sistema de software (como
requisitos de sistema e requisitos de utilizador) [4]. Neste
contexto, um requisito é uma descrição
do1https://msdn.microsoft.com/en-us/magazine/dn463786.aspx
10
https://msdn.microsoft.com/en-us/magazine/dn463786.aspx
-
que o sistema é capaz de fazer ou uma caracterı́stica do
sistema. Este documento é usado durante
todo o processo de desenvolvimento para facilitar a
comunicação entre todas as partes interessadas,
bem como uma visão partilhada do sistema. Um bom SRS é
essencial em muitas aspectos, tais como;
- Estimativa de orçamento e cronograma.
- Base para futuras actividades de manutenção.
- Acordo entre cliente e empresa.
- Menos defeitos nos requisitos e no produto final.
- Mais certidão nas caracterı́sticas do sistema e
consequentemente menos trabalho a corrigir as
caracterı́sticas desnecessárias/erradas.
- Maior satisfação dos clientes e dos membros da equipa.
Um dos procedimentos mais crı́ticos durante o desenvolvimento de
software é o planeamento, e
o SRS tem um papel muito importante neste assunto, pois é a
fonte de informação principal para os
requisitos funcionais e não funcionais do produto, que pode ser
usado ao longo de todo o ciclo de vida do
projecto, facilitando a comunicação e gestão de projectos
durante todo o processo de desenvolvimento.
O sucesso ou o fracasso do desenvolvimento de sistema é
altamente dependente da qualidade do SRS
produzido.
No entanto, o estabelecimento de uma compreensão e
comunicação partilhada entre todas as par-
tes interessadas pode dar origem a um problema. Para que a
comunicação entre todas as partes
interessadas seja eficaz, deve haver uma linguagem comum
compartilhada com todos os envolvidos. A
abordagem mais rápida e preferida por parte das empresas, ainda
é a produção os requisitos usando
NL (como inglês). A NL é flexı́vel, universal e os humanos
são proficientes ao usá-la para comunicar
entre si. Apesar disso, é bem sabido que esta abordagem é
propensa ao aparecimento de defeitos
na produção dos requisitos [7] devido às caracterı́sticas
intrı́nsecas de NL (como ambiguidade e incon-
sistência) [8], que eventualmente irá dificultar futuras
acções sobre os requisitos [9].
2.3 Linguagens Especı́ficas de Domı́nio
Uma vez que a causa de produção de requisitos de má qualidade
deriva de problemas, como ambigui-
dade, das NL, a solução é usar uma linguagem mais restrita e
formal, denominadas por DSL.
As DSL são linguagens de programação ou linguagens de
especificação, especializadas para um
problema de domı́nio especı́fico. Estas linguagens não podem
ser aplicadas a todo o tipo de problemas,
ao contrário das linguagem de propósito geral (ou em inglês,
General-purpose language) (GPL), que
são aplicáveis em todos os domı́nios e conseguem resolver
qualquer tipo de problema. Por outro lado,
11
-
se o domı́nio do problema for abrangido por uma DSL especı́fica,
o problema é resolvido de uma forma
mais fácil e eficaz. No contexto deste projecto, podemos
imaginar que uma NL, por exemplo o inglês,
seja uma GPL que possa ser usada para qualquer problema, e um
linguagem mais controlada e não tão
abrangente sendo uma DSL que resolva um problema especı́fico,
neste caso a produção de requisitos.
Há uma grande variedade de DSLs. Alguns exemplos são: SQL
(para consulta de bancos de dados
relacionais); UML (modelagem visual); HTML e muitos outros.
Já existem algumas DSLs que são boas para representar
informação técnica para máquina num
formato legı́vel por pessoas, como XML ou JSON, no entanto não
é uma tarefa fácil, produzir uma
especificação em XML complexa e extensa dada a quantidade de
tags a que a linguagem obriga.
Escrever manualmente um ficheiro XML pode ser difı́cil, e a sua
leitura pode ser ainda pior [1]. Estas
DLSs são uma forma viável para representar informação para
ser processada nos computadores, mas
não é o mais apropriado para a comunicação e a compreensão
entre pessoas, portanto, especificar o
SRS com estas linguagens não é o melhor caminho.
A seguinte figura 2.2 ilustra as dificuldades de ler uma
descrição com informação de pessoas usando
DSLs como o XLM e JSON. Primeiro, temos uma especificação XML,
que não é a maneira mais indi-
cada que permita que seja possı́vel reter informações sobre
cada pessoa, devido a todas as tags.
Seguidamente vem uma especificação ad-hoc usando JSON, que é
menos confuso do que XML e um
pouco mais fácil de ler. Porém, é possı́vel fazer melhor,
como mostrado mais à direita na figura com a
utilização de uma especificação usando uma DSL mais compacta
e restrita.
Figura 2.2: Diferenças entre XML, JSON e uma DSL especifica
para leitura de informação sobre pessoas [1]
12
-
2.4 A iniciativa RSLingo
O ITLingo é uma iniciativa de longo prazo com o objectivo de
pesquisar, desenvolver e aplicar lingua-
gens de especificação rigorosas [2] no contexto de IT. Para
tal o ITLingo considera principalmente as
seguintes áreas: (i) Engenharia de Requisitos, com o RSL; (ii)
Engenharia de Testes, com o TSL (Tes-
ting Specification Language); e (iii) Gestão de Projectos, com
o PSL (Projects Specification Language).
Com o objectivo de melhorar o rigor no desenvolvimento de
documentos técnicos (p.e, especificações
de requisitos, especificações de casos de teste ou planos de
projecto), O ITLingo adopta uma aborda-
gem linguı́stica, o que também irá resultar num aumento da
produtividade através de transformações
e reutilização de modelos, juntamente com um aumento na
qualidade com validação semi-automática.
Numa fase inicial, o RSLingo, que acomodada a área de RE do
ITlingo, que a utilização de linguagens
naturais era a forma preferida e comum na especificação de
requisitos, no entanto estas são propicias
ao desenvolvimento de documentos ambı́guos inconsistentes que
são difı́ceis de validar ou transformar
automaticamente. [2]
Para resolver os problemas de qualidade na produção de
requisitos, e ao mesmo tempo oferecer
uma linguagem que acomode todas as partes interessadas, é
utilizado o RSL, que ajuda a mitigar al-
guns dos problemas provenientes do uso de NL para a produção
de requisitos, onde existe um controlo
rigoroso e uma maneira certa para escrever SRS, e oferece
também, benefı́cios em relação ao desen-
volvimento de software.
O RSL é uma DSL com o objectivo principal de melhorar a
produção de requisitos de forma mais
sistemática, rigorosa e consistente usando uma lı́ngua natural
controlada (ou em inglês, Controlled
Natural Language) (CNL), que segue recomendações práticas
para melhorar a escrita dos requisitos.
Actualmente encontra-se num estado avançado, tendo sofrido
varias actualizações desde a sua criação
com o objectivo de desenvolver uma linguagem mais ampla e
consistente (hoje denominada ”RSLingo’s
RSL”ou apenas ”RSL”).
O RSL fornece vários elementos organizados logicamente em duas
perspectivas 2.3: nı́vel de
abstração e matérias especı́ficas. Os nı́veis de abstração
são: nı́veis de negócios, aplicativos, software
e hardware. Por outro lado, as matérias especı́ficas são:
estrutura activa (sujeitos), comportamento
(acções), estrutura passiva (objectos), requisitos, testes,
outras matérias e relações e conjuntos.
Esta linguagem é composta por um conjunto elaborado de
elementos organizadas logicamente de
acordo com duas perspectivas: nı́vel de abstração e conceitos
especı́ficos.
Os elementos da linguagem RSL são definidas por padrões
linguı́sticos e representadas textual-
mente de acordo com estilos linguı́sticos concretos. Estes
estão organizadas de acordo com dois
pontos de vista 2.3: o nı́vel de abstração (Nı́veis) e
preocupações especificas (Concerns). Os nı́veis de
abstração são: nı́veis de negócios, aplicativos, software e
hardware. Por outro lado, as preocupações
13
-
especı́ficas são: estrutura activa (sujeitos), comportamento
(acções), estrutura passiva (objectos), re-
quisitos, testes, outras matérias e relações e conjuntos.
Figura 2.3: Classificação dos dos elementos RSL [2]..
Do ponto de vista prático, qualquer elemento pode ser usado em
qualquer tipo de sistema, indepen-
dentemente do seu nı́vel de abstracção. Isso significa, por
exemplo, que é possı́vel usar um elemento
DataEntity nos nı́veis Aplicação ou software, mas também nos
nı́veis negócio ou mesmo hardware. No
entanto, o uso de um DataEntity no nı́vel de negócio deve ser
mais geral e incompleta (por exemplo, sem
especificação de atributos de dados) em comparação com seu
uso nos nı́veis do software, que devem
ser mais detalhados (por exemplo, incluindo atributos de dados e
referências de chaves estrangeiras
especificação). Além disso, enquanto alguns elementos (por
exemplo, Stakeholder, ActiveElement,
GlossaryTerm, Risk ou Vulnerabilidade) são naturalmente
aplicados a diferentes tipos de sistemas, ou-
tros elementos não são tão obviamente aplicadas (por exemplo,
UseCase e Actor são melhor aplicados
apenas para aplicativos ou software) [2].
14
-
2.5 Engenharia Conduzida por Modelos
A engenharia conduzida por modelos (ou em inglês, Model-Driven
Engineering) (MDE) é uma meto-
dologia de desenvolvimento de software que se concentra na
criação de modelos abstratos que repre-
sentam uma visão parcial e simplificada de um sistema.
Geralmente, é necessário criar vários modelos
para representar e entender melhor o sistema em estudo. A MDE
considera os modelos de domı́nio
como entidades de primeira classe e seu objetivo principal é
que os módulos orientem todo o processo
de desenvolvimento (design do sistema, geração de código),
que traz vantagens como melhorias de
qualidade do produto, aumento da produtividade e melhor
comunicação entre as partes interessadas.
2.5.1 Modelos e Metamodelos
Há várias de definições para o termo ”modelo”, algumas delas
não são claras e consistentes, embora,
para todas essas definições, exista um consenso de que um
modelo define um sistema em estudo
(SUS) e vice-versa.
Duma forma resumida, definimos modelos como elementos que
representam uma visão parcial e sim-
plificada de um sistema. A criação de múltiplos modelos é
normalmente necessária para representar e
entender melhor o sistema em estudo [10].
Os modelos podem ter uma grande utilidade de muitas maneiras
diferentes, como facilitar a comunicação
entre todas as partes interessadas, pois permite compartilhar
uma visão e compreensão comum. Os
modelos também tornam o planeamento do projecto mais assertivo
e eficiente ao fornecer visões mais
apropriadas do sistema.
Os modelos estão de acordo com Metamodelos. Um Metamodelo é um
modelo que define a estrutura
de uma linguagem de modelação [10].
2.5.2 Aparecimento da Engenharia Conduzida por Modelos
Originalmente, inúmeras técnicas e linguagens de modelagem
foram propostas essencialmente com o
objetivo principal de de obter uma compreensão e visão comum e
coerente do sistema em estudo e,
consequentemente, facilitar a comunicação entre as partes
interessadas [10].
No entanto, nos últimos anos surgiu uma nova metodologia, não
considerando apenas modelos
como artefactos de documentação, mas como artefactos centrais
no processo de engenharia de soft-
ware [10].
Esta nova tendência de abordagens trouxe mais benefı́cios além
dos oferecidos por metodologias
propostas anteriormente, pois também permite a criação ou a
execução automática de sistemas de soft-
ware com base em modelos que utilizam técnicas complexas, como
meta-modelagem, transformação
15
-
de modelos, geração de código, ou interpretação de modelos
[10]. Os novos benefı́cios são de grande
importância, pois o contexto deste projecto é criar uma
aplicação web através da geração de código.
Etas propostas - como o arquitectura orientada por modelo (ou em
inglês, Model-Driven Archi-
tecture) (MDA) [11, 12], Fabricas de Software (em inglês,
Software Factories) [13], ou recentemente
Engenharia DSL [14] - foram classificadas genericamente como
Engenharia Derivada de Modelos
(MDE) [10], mas também por outros nomes relacionados, como a
engenharia baseada em modelos
(MBE), desenvolvimento orientado por modelo (MDD),
desenvolvimento de software orientado por mo-
delo (MDSD) [15–18], ou model-based testing (MBT) [19].
2.5.3 Linguagens de Modelação
Conforme anteriormente, uma linguagem de modelação é definida
por um metamodelo e é um conjunto
de todos os modelos possı́veis que estão de acordo com seus
respetivos metamodelos [10]. Uma lin-
guagem de modelação é qualquer linguagem artificial que possa
ser usada para expressar informações
ou conhecimentos ou sistemas numa estrutura definida por um
conjunto de regras. Estas regras são
usadas para facilitar a interpretação do significado de cada
componentes na estrutura.
Uma linguagem de modelação pode ser classificada em duas
categorias: linguagem de modelação
para uso geral (ou em inglês é GPML) ou linguagem de modelagem
para domı́nio especı́fico (ou em
inglês é DSML) [20–24].
As GPMLs (UML ou SysML são exemplos de GPMLs) são
caracterizados por ter um maior número
de construções genéricas. Por outro lado, os DSLs tendem a
usar algumas construções ou conceitos
mais próximos do seu domı́nio de aplicação, podendo melhorar
a produtividade, a confiabilidade, a
manutenção e a portabilidade. No entanto, o uso de DSL pode
aumentar alguns problemas, como o
custo da aprendizagem, implementação e manutenção de uma
nova linguagem, bem como as ferra-
mentas para a desenvolver. [10].
2.5.4 Transformação de Modelos e Geração de Código
Um aumento da automatização no desenvolvimento do programa é
obtido através transformações do
modelos. Os modelos de nı́vel superior são transformados em
modelos de nı́vel inferior até que o
modelo possa ser executado usando, por exemplo, geração de
código como ilustrado na figura 2.4.
Transformar um modelo noutro modelo significa que, o modelo de
origem é transformado num modelo
de destino baseado em algumas regras de transformação.
Na abordagem MDE dois tipos principais de transformações
tendem a ser considerados. modelo
para texto (ou em inglês, Model-to-Text) (M2T) e modelo para
modelo (ou em inglês, Model-to-Model)
16
-
(M2M). Por um lado, as transformações M2T geram ou produzem
artefactos de software - geralmente
código fonte, XML e outros arquivos de texto - a partir de
modelos. A técnica mais comum para esta
classe de transformações é conhecida como geração de
código. Por outro lado, as transformações de
modelo para modelo (M2M) permitem a transformação de modelos
para outro conjunto de modelos,
geralmente mais próximo do domı́nio da solução ou que
satisfaçam as necessidades especı́ficas das
diferentes partes interessadas [10].
Naturalmente, é importante referir que, no contexto de MDE, os
modelos devem ser definido de
forma consistente e rigorosa para ser efetivamente usado.
Geralmente, é necessário um certo nı́vel de
qualidade para que esses modelos possam ser usados corretamente
em cenários M2M ou M2T.
Figura 2.4: MDE transformação de modelos.extraı́do de 2
17
-
18
-
3Tecnologias de Suporte
Conteúdo
3.1 Frameworks para desenvolvimento do lado do cliente . . . . .
. . . . . . . . . . . . . 21
3.2 Frameworks e Linguagens de Programação do lado do servidor
. . . . . . . . . . . 27
3.3 Tecnologias para Geração de Código . . . . . . . . . . .
. . . . . . . . . . . . . . . . 32
3.4 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . 34
3.5 Visão geral do Sistema . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . 37
19
-
20
-
Neste capı́tulo são discutidas varias tecnologias relacionados
com o desenvolvimento web, tanto
para o lado do servidor como para o lado do cliente onde é
feita uma apresentação e comparação entre
as mesmas. Da mesma forma são apresentadas e comparadas
tecnologias para geração de código. É
apresenta também a solução proposta para este projecto que
inclui as tecnologias escolhidas e de que
modo serão utilizadas. Por fim é apresentada uma visão geral
do sistema.
3.1 Frameworks para desenvolvimento do lado do cliente
A linguagem de programação JavaScript, normalmente denominada
por ’JS’, tornou-se a linguagem de
programação mais popular no contexto web, e é imprescindı́vel
a todas as aplicações web, isto porque
é o JS que dá dinamismo a uma aplicação web o que permite ao
utilizador interagir com a mesma, o
que no fundo é o objetivo principal duma aplicação web. No
entanto, criar uma aplicação web com uma
boa aparência e um bom design, fácil de manter, simples de
usar, entre outras qualidades que uma
boa aplicação web deve ter, pode se uma tarefa complicada de
fazer manualmente. Para facilitar esta
tarefa, existem varias framework /bibliotecas para o
desenvolvimento do lado do cliente. A popularidade
do JS levou a um ecossistema muito vibrante de tecnologias,
framework e bibliotecas que mudou muito
o desenvolvimento web.
O aparecimento de framework JS para desenvolvimento web cresceu
a ritmo elevado, as fra-
meworks que já existiam são atualização frequentemente tendo
múltiplas versões. Apesar de trazer
algumas vantagens como diversidade, pode ter um lado negativo,
porque perceber os benefı́cios de
cada uma e ter que aprender a usá-las pode ser um processo
demorado.
No que diz respeito ao desenvolvimento de aplicações web , a
utilização de frameworks JS é o
método mais recomendável. As frameworks/bibliotecas (como
Angular, Vue, React) oferecem uma es-
trutura que deve ser seguida o que irá ajudar a manter o
código mais organizado, tornando as aplicações
web mais flexı́veis e escaláveis e o processo de
desenvolvimento mais fácil. O sucesso de um projecto
pode ser consideravelmente afectado pela escolha da framework
mais apropriada. Pode influenciar o
tempo de desenvolvimento e a capacidade de manutenção do
código que influenciam diretamente o
custo do projecto e, deste modo, o sucesso do projecto. A
escolha da framework mais indicada não é
feita tendo em conta só as vantagens e desvantagens que
oferecem. Depende dos objectivos iniciais
da empresa, dos requisitos do projecto, da funcionalidade geral
da framework, etc. Relativamente a
este assunto, na área de informática é importante saber que
não há uma solução perfeita para todos
os projecto, irá sempre haver vantagens e desvantagens.
Em baixo seguem-se algumas das frameworks JS mais populares e
relevantes hoje em dia para
desenvolvimento web do lado do cliente:
21
-
3.1.1 Angular
O Angular [25] 1 (normalmente denominado Angular 2+), é uma
nova versão construı́da de raiz, pela
mesma equipa que desenvolveu AngularJS ou ”AngularJS 1.X”. É
uma framework de código aberto
suportada e mantida pela Google, para a desenvolvimento de
aplicações web e móveis. Foi feita com
o objectivo principal de facilitar o desenvolvimento de SPA
[25].
O Angular adoptou um metodologia em que vê uma aplicação como
uma colecção de componentes
e, onde todos os elementos da página são componentes com um
devido propósito que podem ser
reutilizados em diferentes partes, o que promove a
reutilização dos mesmos.
O Angular recomenda a utilização da linguagem TypeScript da
Microsoft durante o seu uso, apesar
de ser possı́vel usar o JavaScript. TypeScript é uma Superset
de JavaScript, que força a escrever
um código melhor e mais organizado e oferece outras vantagens
para a produção de código como a
programação orientada a objecto.
A utilização de Typescript com Angular tornou o código mais
sustentável e legı́vel. Isto traz mais
simplicidade para o desenvolvimento, porem é mais uma linguagem
que é necessária de aprender o
que irá resultar numa complexidade de aprendizagem da framework
maior.
As principais vantagens do Angular são as seguintes:
- Typescript: TypeScript oferece muitas vantagens como:
programação orientada para objec-
tos(classes, interfaces, etc.); validação de tipos; detecção
de erros enquanto se escreve o código
com IDEs como Visual Studio. Ter tais ferramentas é quase um
requisito obrigatório para desen-
volvimento de grandes projectos.
- Ligação de dados bidireccional: Angular usa Ligação de
dados bidirecional. Isto permite que a
framework seja capaz de ligar o Modelo de Documento Objecto (ou
em inglês, Document Object
Model (DOM)) ao modelo de dados (base de dados) através dum
controlador. Resumidamente
isto é, quando os utilizadores interagem com novos inputs e
dão um novo valor à aplicação, não
só a interface é alterada, mas também o Modelo (base de
dados) automaticamente. Consequen-
temente, não é necessários arranjar um método ou escrever
código para ter em conta todas estas
modificações.
- Model-View-Controller: O padrão Model-View-Controller permite
dividir o código do projecto
em três componentes: modelo, vista e controlador, permitindo a
separação de preocupações que
mantêm o código organizado, limpo permitindo que possı́veis
alterações sejam mais fáceis. Desta
forma, a alteração de cada componente pode ser feita
independentemente onde cada parte do
1https://angular.io/docs
22
https://angular.io/docs
-
código apenas serve para uma finalidade, não estando tudo
misturado, aumentando a qualidade
do produto final.
- É uma framework : Uma vez que o Angular6 é uma framework,
oferece uma solução mais com-
pleta com mais possibilidades e funcionalidades, o que ajuda a
começar um projeto mais rapida-
mente sem necessitar de bibliotecas adicionais ou outras
ferramentas framework.
- Suportado pela Google: O Angular foi criado e é suportado
pela Google, isto oferece alguma
credibilidade e popularidade à framework, pois é uma das
empresas mais conceituadas no ramo
da informática, e é com certeza uma mais valia. O Google tem
uma equipa especializada com
grandes engenheiros focados na melhoria da framework, onde
tecnologias e abordagens mais
modernas e recentes são estudadas e implementadas, o que
melhora qualidades como desem-
penho, escalabilidade, etc. A atualização da framework ocorre
com alguma frequência com um
objectivo de produzir uma framework melhor e mais fácil de usar
(ultima versão a 1 Nov 2017
Angular 5.0 2).
Por outro lado as suas desvantagens são as seguintes:
- Curva de aprendizagem: Para se utilizar o Angular6, não só
é necessário aprender uma fra-
mework nova, como também é aconselhável perceber como
funciona a configuração dos ficheiros
e a forma como o Angular6 funciona e aprender uma nova linguagem
TypeScript. .
- Typescript: É possı́vel utilizar Angular com JavaScript, mas
poderá ser trabalhoso e mais difı́cil
devido à falta de documentação e apoio neste assunto, pois o
mais utilizado é TypeScript. A
maioria dos cursos e palestras em Angular são feitas com o uso
de TypeScript. Isto faz com que
a aprendizagem desta linguagem seja quase obrigatória.
- Regular DOM: O Angular manipula diretamente DOM, isto faz com
que seja mais lento em
comparação com o React que usa um DOM virtual que apenas faz
alterações necessárias ao
DOM normal. Também devido ao uso LIGAÇÃO DE DADOS
BIDIRECIONAL, faz com que haja
observadores em cada componente para alertar sempre que haja uma
alteração, que também
afeta o desempenho.
3.1.2 React
O React 3 (normalmente denominado por React.js ou ReactJS) é
uma biblioteca JavaScript para cons-
truir interfaces mais elaboradas. Permite aos programadores
criarem aplicações web complexas e
2https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935ced3https://facebook.github.io/react/docs/hello-world.html
23
https://blog.angular.io/version-5-0-0-of-angular-now-available-37e414935cedhttps://facebook.github.io/react/docs/hello-world.html
-
encoraja a reutilização de componentes de interface que
apresentam dados que são alterados frequen-
temente, sem ter que actualizar a página, seguindo um modelo de
SPA. O seu principal objectivo é que
seja rápido, eficiente, simples e escalável. React é descrito
como o ”V” relativamente ao modelo MVC.
Permite que seja criado componentes para interface
reutilizáveis (barra de navegação (tabs), caixas de
comentários, modelos pop-up, listas, tabelas ordenáveis,
etc.).
Normalmente, o aspecto de uma página da Web segue um padrão,
contendo vários componentes,
estes componentes podem ser elementos como cabeçalho, área
principal, barra lateral, lista, etc. O
React usa a ideia de dividir uma página web em componentes
tornando-os reutilizáveis. Estes com-
ponentes contém o código HTML juntamente com o código
JavaScript para exibir conteúdo dinamica-
mente.
A grande ideia por trás do React é a seguinte: possibilitar a
criação de elementos HTML que tenham
funcionalidades personalizadas, por exemplo, construir um
elemento que exiba uma
área de texto, faça as validações no texto escrito na área
de texto, envie o formulário aquando da sua
submissão, etc, onde seria apenas necessário incluir uma linha
de código com a TAG: .
As principais vantagens do React são as seguintes.
- Ligação de dados unidireccional: O fluxo de dados é
direccionado apenas de uma maneira,
não sendo possı́vel, como por exemplo no angular, alterar o
Modelo (base de dados) com inputs
pelo utilizador. Porém isto traz vantagens, é possı́vel saber
sempre onde estamos a alterar os
dados. A abordagem do React é muito mais fácil de fazer debug
quando se trata de aplicações
extensas.
- Virtual DOM: O React introduziu o conceito de DOM virtual que
permite a criação duma árvore
DOM leve, guardando-a em memoria. Sempre que um utilizador
interage com o site, por exemplo,
preenchendo um formulário, o React cria um novo DOM virtual
para compara-lo com o DOM real e,
sempre que são encontradas alterações o DOM virtual é
construı́do para que seja apenas alterado
o que é necessário da maneira mais eficiente. O desempenho do
ReactJS pode aumentar quando
se trata de grandes quantidades de dados/componentes quando
comparado ao Angular.
- JSX: React.js usa uma sintaxe especifica chamada JSX, que
permite juntar HTML com o JS.
Possibilita usar HTML na função de renderização sem ter que
concatenar strings ou outro método
para juntar HTML com JS.
- Fácil utilização e aprendizagem: Sendo apenas uma
biblioteca, a complexidade de aprender
React com Angular é muito menor, havendo também boa
documentação e muitas pessoas que
utilizam a livraria é fácil encontrar ajuda online.
24
-
- Suportado pelo Facebook: Á semelhança do Angular, React
também é suportado e mantido por
uma grande empresa e excelentes engenheiros, o que só traz
benefı́cios para a tecnologia.
Por outro lado as suas desvantagens são as seguintes:
- JSX: Apesar da ideia do JSX ser bastante útil, que é juntar
HTML com JavaScript, pode-se tornar
num desafio para se dominar e habituar a usar, isto porque, é
apenas uma maneira de facilitar
a utilização de HTML com JS, porém não podemos usar o HTML
normal (classname em vez de
classe, se queremos atribuir uma classe css) e pode exigir um
pequeno esforço para se habituar
a usar. Construir componentes com JSX pode não ser tão
simples/intuitivo como HTML puro e o
JS.
- React é apenas uma biblioteca: Não sendo uma framework
robusta e completa, Não há por
exemplo um router implementado, tendo por isso de se utilizar
outras bibliotecas externas para
estea finalidade. Por isso, é necessário ter algum grau de
experiência na escolha de bibliotecas
para completarem estas necessidades.
- React é apenas uma camada de visualização: Fácil
integração num sistema que siga o modelo
MVC.
3.1.3 Vue.js
Vue.js 4 (normalmente referido como Vue) é uma framework JS de
código aberto que se concentra na
construção de interfaces de usuário.
Foi criado pelo Evan You que trabalhou para o Google no projecto
Angular. Evan You tentou extrair
o que gostava mais no Angular e tentar criar uma versão mais
”leve”sem os conceitos extras.
Vue faz parte da camada de visualização apenas, é muito
fácil de integrar com outras bibliotecas ou
projectos existentes. No entanto, Vue é perfeitamente capaz de
criar aplicações sofisticadas de uma
página única quando usados juntamente com outras
ferramentas/tecnologias modernas e bibliotecas
de suporte.
Uma das razões pelas quais há muito entusiasmados com o Vue
recentemente, é que é extremamente
fácil de adoptar quando se precisa apenas de adicionar algumas
caracterı́sticas dinâmicas básicas
numa aplicação web. Não é precisa instalar nada nem
configurar.
As principais vantagens do Vue são:
- Complexidade de introdução de uma nova famework pequena: O
Vue.js possui uma documentação
muito completa e bem escrita. Para se construir uma primeira
aplicação web, basta saber JS e
4https://vuejs.org/v2/guide/
25
https://vuejs.org/v2/guide/
-
HTML básicos para fazer metade do trabalho. De acordo com uma
pesquisa de JavaScript de
2016, a Vue tem uma classificação de satisfação pelos
programadores de 89 %.
- Fácil Legibilidade/Manutenção: Vue encontra o ponto ideal
entre legibilidade e manutenção.
Vue de certa forma é baseado no que o React e o Angular têm de
melhor.
De React, baseou-se na abordagem baseada em componentes, fluxo
de dados unidireccional
para a hierarquia de componentes, desempenho com DOM virtual. Do
Angular, obteve modelos
semelhantes com boa sintaxe e ligação bidireccional quando se
precisar (dentro de um único
componente).
Por outro lado as suas desvantagens são as seguintes:
- A framework ainda se está a desenvolver: A framework é muito
nova. Não há componentes
estáveis da comunidade - muitos deles foram criados para o
Vue.js 1 e, às vezes, não é fácil para
os iniciantes verem no repositório do github para qual versão
do Vue uma biblioteca especifica foi
desenvolvida. Esta questão é mitigada pelo fato de que se pode
fazer coisas complexas no Vue
sem bibliotecas adicionais. Além disso, uma vez que esta
framework é principalmente conhecida
na China, há comentários chineses no código na maioria das
bibliotecas públicas e ajudas online,
devido a ser maioritariamente usada na China(o autor fala
chinês).
- Não é suportado por uma grande empresa como React ou
Angular: Apesar do seu criador
ter pertencido a Google e ao projecto Angular, não sendo
suportado/mantido por uma grande
empresa como Angular ou Reagente, pode influenciar seu
popularidade e confiança.
A tabela 3.1 compara de uma forma resumida as três frameworks
descritas acima.
Tabela 3.1: Comparação Angular, React e Vue.js
Atributo Angular6 React VueEmpresa/Criador Google Facebook Evan
YouAno de criação 2016 2013 2014Linguagem Typescript JSX
JavascriptMVC Yes View layer only View layer onlyDOM Regular DOM
Virtual DOM Virtual DOMVel. desenvolvimento Médio/Alto Alto
AltoPerformance Muito boa Muito Boa Muito boaCurva de aprendizagem
Alto Médio BaixoComunidade Médio Alto Médio(Chinesa)
Outras frameworks e bibliotecas JS podem ainda ser mencionadas
neste âmbito para criar aplicações
web tais como: JQuery 5; Backbone.js 6; Ember.js
7.5http://jquery.com/6http://backbonejs.org/7https://emberjs.com/
26
http://jquery.com/http://backbonejs.org/https://emberjs.com/
-
3.2 Frameworks e Linguagens de Programação do lado do
servi-
dor
O lado do servidor (ou em inglês normalmente referido como
backend), uma aplicação Web é cons-
tituı́do por todas as componentes responsáveis pela
generalidade da lógica e regras de negócio do
sistema. O backend do sistema refere-se a tudo o que o
utilizador não consegue ver no navegador,
como base de dados e regras de negócio. Algumas operações
pelo qual o backend é responsável
são por exemplo armazenar ou fazer consultas na base de dados,
cálculos, desempenho, segurança,
lógica etc. Isto acontece ”na parte de trás”, nos bastidores
da aplicação sem o utilizador dar conta. Um
aplicação web apesar de poder parecer muito apelativa e bem
desenhada na parte do cliente, se não
tiver um backend que seja robusto e funcione corretamente, pode
vir a ser uma aplicação web sem
grande uso.
Apesar de não existir uma interação direta entre o utilizador
e o backend, a aplicação está sempre
ligada ao backend visto que a sua intervenção pode ser precisa
a qualquer momento, por exemplo para
oferecer algum funcionalidade especifica ou para fazer consultas
à base de dados. O código backend
é executado no servidor, ao contrário ao lado do cliente que
corre no browser, e inclui a maior parte
do código necessário para que a aplicação funcione. Podemos
comparar uma aplicação Web com um
icebergue duma forma em que o utilizador vê apenas uma fração
de toda a aplicação. Isto implica que
os programadores de backend, não só precisam compreender
linguagens de programação e base de
dados, mas também devem ter uma compreensão da arquitetura do
servidor. Se uma aplicação for
lenta ou constantemente lançar erros, é provável que seja
devido a problemas de backend.
Uma vez que existe uma variedade de linguagens de programação
e frameworks para o desenvol-
vimento de software para backend, os programadores devem
conhecer as diferenças entre elas assim
como as vantagens e desvantagens para escolher corretamente a
mais indicada. Normalmente é es-
colhida uma pilha de software durante o desenvolvimento uma
aplicação web.
As pilhas de software são grupos de software para diferentes
aspetos do backend, que funcionam
em conjunto para cumprir um objetivo. Os componentes incluem um
sistema operacional, um servidor
web, uma base de dados e uma linguagem de programação do lado
do servidor.
Existem muitas razões pelas quais se pode escolher uma pilha
especı́fica. Por exemplo, se for pre-
visı́vel a necessidade de escalabilidade vertical, ou a equipa
de desenvolvimento estiver habituada com
alguma linguagem de programação especifica, que devem ser
tidas em conta para a escolha da pilha
de software para o desenvolvimento do projeto.
Algumas pilhas de software mais comuns para o lado do servidor
são as seguintes: Existem
várias pilhas de software, porém normalmente as mais comuns
são o LAMP e MEAN (que serão descri-
27
-
tas em maior detalhe a seguir). Porém há quase uma pilha de
software para quase todas as linguagens
de programação.
• LAMP (Linux/Apache/MySQL/PHP) LAMP consiste em componentes de
software de código
aberto gratuitos que funcionam bem para sites e aplicações web
dinâmicos. É o modelo de
pilha mais tradicional, com algumas variações para diferentes
sistemas operacionais, servidores
e opções de base de dados. Na pilha LAMP, o PHP é compatı́vel
com as linguagens Python e Perl.
Benefı́cios do LAMP: flexı́vel, fácil de desenvolver, fácil de
implantar, seguro e com uma enorme
comunidade de suporte, uma vez que é de código aberto.
O Facebook usa essa pilha de software.
• MEAN (MongoDB/Express.js/AngularJS/Node.js) O MEAN é uma
opção viável para substituir
a pilha LAMP tradicional, e usa JS tanto para o lado do cliente
como para o lado do servidor. É
uma boa escolha para as empresas que desejam ser ágeis e
escaláveis, oferecendo flexibilidade
na base de dados com MongoDB que é baseada num documento, e
muitos outras caracterı́sticas
que ajudam no desenvolvimento de aplicações Web de página
única ou de várias páginas. Usar
JS tanto para o lado do cliente como para o lado do servidor
pode trazer várias vantagens como
por exemplo, os programadores que trabalham no lado do cliente
podem entender facilmente o
código do lado do servidor, o que levará a uma maior
produtividade.
Benefı́cios do MEAN : JS para cliente e servidor, suporta o
padrão MVC, usa JSON para trans-
ferência de dados, oferece acesso à biblioteca de módulos JS
do Node.js e à estrutura Express.js,
é de código aberto.
• WISA (Windows/Internet Information Services/SQL
Server/ASP.NET) Esta pilha permite a
utilização das poderosas ferramentas SQL Server e ASP.NET. C#
é a linguagem de programação
do ASP.NET, que relativamente a questões de desempenho, pode
ser considerada melhor do que
a dos três grandes P na pilha LAMP (Perl, PHP e Python), o
SqlServer pode ser também consi-
derado melhor do que o sistemas de gestão de base de dados
relacional (RDBMS) gratuitos.
A desvantagem da pilha WISA é que demasiado de sofisticado para
tipos de projetos simples
que não necessite da robustez e dos recursos avançados da
WISA. Normalmente este compo-
nentes de software não são gratuitos porque pode exigir
licenças da Microsoft e também, o seu
desenvolvimento porque pode ser mais demorado quando comparado,
por exemplo, com a pilha
MEAN, devido a serem ferramentas mais completas e
”profissionais”porém a fase de debug será
mais fácil. É comum a utilização da pilha WISA mais a nı́vel
empresarial para desenvolver sites
28
-
complexos e robustos.
Seguidamente seguem-se algumas linguagens de programação e
frameworks das mais populares para
o lado do servidor.
3.2.1 ASP.NET Core
ASP.NET Core 8 é uma nova framework de código aberto e
multiplataforma para desenvolvimento de
aplicações modernas na nuvem, como aplicações web,
aplicações IoT e servidores para mobile. As
aplicações do ASP.NET podem ser executados no .NET Core ou na
framework .NET completa. É
constituı́do por componentes modulares, que se podem ir
adicionando, com sobrecarga mı́nima, para
que se mantenha flexibilidade e simplicidade durante o
desenvolvimento das aplicações. ASP.NET Core
suporta várias plataformas no Windows, Mac e Linux. O ASP.NET
Core é de código aberto.
O ASP.NET foi lançado há mais de 15 anos e há uma larga
comunidade que usa esta framework para
construção de aplicações web. O ASP.NET Core é uma nova
versão redesenhada do antigo ASP.NET,
com mudanças na arquitetura que resultam numa estrutura mais
simples e modular. A framework foi
construida de raiz e junta o ASP.NET MVC e Web API da Web
previamente separados num único
modelo de programação.
ASP.NET Core já não é baseado em System.Web.dll, que
costumava incluir todas as bibliotecas e
funções. É modular, o que significa que se pode adicionar e
remover recursos conforme sejam ne-
cessários através do ”NuGet packages”. Este método traz uma
grande vantagem de incluir apenas as
bibliotecas e funções necessárias à aplicação ao
contrário do método antigo que incluı́a toda a fra-
mework no projeto aumentando a complexidade e tamanho. Os
benefı́cios de uma aplicação menor
podem ser maior segurança, manutenção reduzida, melhoria no
desempenho etc.
As principais vantagens do ASP.NET Core são as seguintes:
• Multiplataforma e código aberto: Pode correr em Windows,
MacOS e Linux. Permitir que o
ASP.NET Core seja utilizado por mais pessoas e empresas, o que
irá aumentar a sua comunidade
e enriquecer a framework.
• Supportada pela Microsoft: Como mencionado anteriormente, ser
suportada por uma grande
empresa traz vários benefı́cios para a framework.
• É modular: É possı́vel adicionar e remover recursos conforme
sejam necessários ao projeto
precisa, com ”NuGet packages”reduzindo a complexidade e
sobrecarga da aplicação web onde
só se ”paga pelo que se usa”.
8https://docs.microsoft.com/en-us/aspnet/core/
29
https://docs.microsoft.com/en-us/aspnet/core/
-
• Segue o metodo de MVC: O MVC permite a separação de
preocupações o que oferece um
código mais organizado e de fácil manutenção entre com mais
benefı́cios, como mencionado
anteriormente.
• Versatilidade: Uma das melhores coisas sobre C# e .NET é a
sua versatilidade. Sendo possı́vel
desenvolver aplicações desktop, web, móveis, etc.
Por outro lado as suas desvantagens são as seguintes:
• ASP.NET Core ainda está numa fase recente: Poderá haver
falhas na documentação, nomea-
damente quando se está a criar uma aplicação que siga o
método MVC.
3.2.2 Node.js
Node.js 9 é uma plataforma construı́da sobre o motor V8 JS do
Google Chrome para facilmente construir
aplicações de rede rápidas e escaláveis.
O Node.js usa um modelo de I/O de eventos não bloqueante que o
torna leve e eficiente, indicado para
desenvolvimento de aplicações em tempo real várias trocas de
mensagens entre vários dispositivos
distributivos. O ecossistema de pacotes Node.js, npm, é o maior
ecossistema de bibliotecas de código
aberto do mundo.
O Node.js permite usar JS no lado do servidor. Consequentemente,
tornou-se um dos elementos
fundamentais do paradigma ”JavaScript everywhere”, permitindo
que o desenvolvimento de aplicações
web se unisse em torno de uma única linguagem de programação,
em vez ser preciso uma linguagem
diferente para o lado do servidor. O Node.js é código aberto e
cross-platform.
Algumas das principais vantagens do Nodejs são as
seguintes:
• Usa JavaScript: O JS é conhecido pela maioria das pessoas
dentro do desenvolvimento web,
e com a possibilidade de utilizar JS tanto para o lado do
cliente como para o lado do servidor
evita a necessidade de aprendizagem de uma nova linguagem e
permite que os programadores
percebam o código de ambos os lados. O uso de JavaScript num
servidor web, bem como o nave-
gador, reduz a incompatibilidade entre os dois ambientes de
programação que podem comunicar
estruturas de dados via JSON que funcionam da mesma forma em
ambos os lados.
• Grande comunidade: O Node.js possui uma enorme comunidade e
oferece uma biblioteca com
vários módulos de JS que simplifica o desenvolvimento de
aplicativos da Web usando Node.js em
grande medida com base num gestor de pacotes sólido (npm).
9https://nodejs.org/en/about/
30
https://nodejs.org/en/about/
-
• Baseado em eventos e assı́ncrono: Todas as APIs da biblioteca
Node.js são assı́ncronas, isto é,
não bloqueantes. Significa essencialmente que o servidor não
aguarda pela API retornar dados/-
resultados. O servidor passa para a próxima API, e
posteriormente um mecanismo de notificação
de Eventos do Node.js ajuda o servidor a obter uma resposta da
chamada da API anterior.
• Rápido e escalável: Node foi feito para ser rápido e
escalável, sendo construı́do no mecanismo
de JS V8 do Google Chrome.
• Multiplataforma e Código aberto: Ser multi-plataforma e
código aberto é sempre um benefı́cio
para a ferramenta, pois aumentará a comunidade e sua
popularidade.
Por outro lado as suas desvantagens são as seguintes:
• Lidar com o base de dados relacionais pode ser complicado: O
Nodejs é mais apropriado
para lidar com os base de dados nosql, no entanto, é possı́vel
usar bases de dados racionais,
mas requer mais esforço e não é tão intuitivo.
• Não é adequado para aplicações com computação pesada:
Node.js ainda não suporta programação
multi-threaded. É indicado para aplicações complexas, mas
não é adequado para realizar cálculos
de longa duração. Os pedidos recebidos ficam à espera numa
pilha e executados sequencial-
mente de maneira rápida. No entanto, cálculos pesados
bloqueiam o ciclo do evento, o que pode
levar a uma diminuição do desempenho.
• ”Callback hell”: Callback hell é um código onde o uso de de
funções callback se torna difı́cil de
seguir e perceber e de testar.
3.2.3 PHP
PHP 10, acrónimo de ”PHP: Hypertext Preprocessor”é uma
linguagem de script de uso geral muito
utilizada que é especialmente adequada para desenvolvimento web
e pode ser incorporada em HTML.
Sua sintaxe é baseada em C, Java e Perl, e é fácil de
aprender. O objetivo principal da linguagem é
permitir que os programadores de Web criem páginas web
rapidamente.
O PHP é largamente usado no lado do servidor, projetada para
consultar e editar informações na
base de dados. É normalmente incluı́da em base de dados
escritos em SQL. O PHP é único no sentido
em que foi construı́do para a web. Há algumas frameworks
modernas que usam php como linguagem
de programação, como o conhecido Laravel.
PHP é usado pelo Facebook.
Algumas das vantagens do PHP são:10http://php.net/
31
http://php.net/
-
• Multiplataforma e Código aberto: Pode ser executado em
várias plataformas, incluindo Win-
dows, Linux e Mac. Fácil para os utilizadores encontrarem
serviços de hospedagem para os seus
sites. É de uso gratuito e é constantemente melhorada por um
grande número de pessoas e não
por uma única empresa. Os programadores por trás do PHP
criaram um extenso recurso on-line
de todas as funções da linguagem, incluindo exemplos de como
usá-las, o que torna mais fácil
aprender e usar PHP.
• Curva de aprendizagem pequena e fácil de usar: Começar a
programar com o PHP é relativa-
mente simples, bem como construir páginas web, o que era o
objetivo inicial da linguagem.
• Popular com uma grande comunidade e amplamente utilizada: O
PHP está em toda parte e é
usado na maioria das aplicações web. A maioria dos problemas
de programação já tem soluções
feitas por outros utilizadores. Sendo um dos idiomas de script
do lado do servidor mais populares
há também muito suporte disponı́vel online.
• Funciona bem com base de dados: Suporta uma variedade
diferente de tipos de base de dados,
como base de dados sql e nosql, o que faz com que seja uma boa
escolha para aplicativos que
precisam se comunicar com base de dados.
Por outro lado as suas desvantagens são:
• Baixa dificuldade para usar: Apesar da facilidade de
aprendizagem e utilização possa ser um
beneficio, também pode criar problemas visto que há vários
tutoriais ou ajudas online que não são
as mais corretas e podem levar iniciantes a desenvolver mau
código.
• Normalmente não é adequado para aplicações extensas: Pode
haver problemas com a es-
calabilidade com grandes aplicações com big data, o PHP é
mais apropriado para aplicações
pequenas a médias. Quando se trata de aplicações com milhões
de utilizadores e milhares de
páginas, dificulta a sua gestão por não ser altamente
modular.
A tabela 3.2 compara de uma forma resumida o ASP.NET Core,
Node.js e PHP descritos acima.
Outros frameworks e Linguagens de programação podem ainda ser
mencionados neste âmbito para
o lado do servidor tais como: Python11; Ruby on Rails12.
3.3 Tecnologias para Geração de Código
Normalmente, a geração de código é um mecanismo para
produzir código fonte (numa linguagem de
programação como Java ou C #) derivada de um modelo. No MDD
(que pretende gerar um sistema
de11https://www.python.org/12http://rubyonrails.org/
32
https://www.python.org/http://rubyonrails.org/
-
Tabela 3.2: Comparação ASP.NET Core, NodeJS e PHP
Atributo ASP.NET Core Node.js PHPEmpresa/Criador Microsoft Ryan
Dahl Rasmus LerdorfAno de lançamento 2002 2009 1995Ultima versão
Nov 2016 Jun 2016 Dez 2016Tipo Web Framework JavaScript runtime
Ling. de ProgramaçãoVel. desenvolvimento Média Média/Alta
Alta
Performance Muito boaMuito boa(+ pedidos I/O,- proc. de CPU)
Boa
Curva de aprendizagem Alta Média BaixaComunidade Média Alta
Muito alta
software em execução a partir de modelos), a geração de
código também pode ser conhecida como
transformação M2T 13.
De seguida, serão apresentadas algumas das tecnologias mais
populares para geração de código.
3.3.1 Acceleo
Acceleo 14 é um gerador de código aberto do Eclipse Foundation
que permite usar uma abordagem
orientada por modelo para a construção de aplicações. O
Acceleo é uma implementação pragmática
do modelo MOF do Object Management Group (OMG) modelo para
linguagem de texto (MTL) que usa
qualquer modelo baseado em EMF (como UML) para gerar qualquer
tipo de código (Java, C#, PHP,
etc.) . No entanto, pode não ser a melhor solução para se
obter uma estrutura e controlo durante a
geração de código.
3.3.2 Xtend
O Xtend [1] 15 é um dialeto flexı́vel e expressivo do Java, que
compila para código fonte legı́vel e
compatı́vel com Java 5. Permite usar qualquer biblioteca Java
existente. O resultado compilado é legı́vel
e bem indentado e tende a ser executado de uma maneira tão
eficiente como o código equivalente em
Java.
Xtend é uma linguagem de propósito geral, tem uma sintaxe mais
concisa do que Java e pode ser
vista como ”Java melhor”. O Xtend não é adaptado
especificamente à geração de código, mas como
uma linguagem de propósito geral. No entanto, é possı́vel
usá-la para geração de código, especialmente
para gerar código que requer que seja legı́vel e indentado
graças a expressões de modelo de várias
13http://www.theenterprisearchitect.eu/blog/2009/01/15/mde-model-driven-engineering-reference-guide/14http://www.eclipse.org/acceleo/15https://eclipse.org/xtend/documentation/
33
http://www.theenterprisearchitect.eu/blog/2009/01/15/mde-model-driven-engineering-reference-guide/http://www.eclipse.org/acceleo/https://eclipse.org/xtend/documentation/
-
linhas (em inglês, multi-line template expressions). O próprio
Xtend é implementado no Xtext, que é
uma ótima vantagem para este projeto, uma vez que o RSL também
é definido no Xtext, o que nos
permite escrever todas as partes de uma implementação de DSL,
especialmente a parte de geração
de código no mesmo programa.
Ser produtivo e escrever código bem indentado com macros
poderosas e muitos outros recursos de
linguagem moderna é a principal vantagem desta linguagem
idioma. Sintaticamente e semanticamente,
a Xtend tem raı́zes na linguagem de programação Java, mas
melhora em muitos aspetos, tais como:
inferência de tipo; expressões Lambda; expressões template;
métodos de extensão.
3.4 Tecnologias utilizadas
O objectivo principal do RSL2WebApp é gerar um código-fonte
para aplicação web com base em requi-
sitos do sistema definidos com a linguagem RSL.
Para isso, várias tecnologias/frameworks foram estudadas nesta
dissertação, onde se racionalizou
sobre as vantagens e desvantagens de cada uma. No contexto de
engenheira informática, a escolha
das tecnologias/frameworks deverá levar em consideração
muitos factores (por exemplo, competências
e experiência de equipa, contexto e requisitos do projecto,
objectivos, etc.), pois o sucesso do desen-
volvimento de software é influenciado por esta escolha. Existem
tecnologias que são melhores para
algumas coisas mas que são piores para outra, não existe uma
que resolva todos os problemas e seja
perfeita, e cabe aos engenheiros reflectir e escolher o que é
mais apropriado para um determinado pro-
jecto. As tecnologias escolhidas para esta dissertação foram
baseadas em algumas vantagens tendo
em consideração o objectivo principal e o contexto deste
projecto.
3.4.1 RSL
RSL é o ponto de partida para o processo de geração de
código, uma vez que é exigido uma especificação
de requisitos consistente e rigorosa que a aplicação web deve
seguir. O RSL, como discutido antes,
apresenta muitos benefı́cios em relação ao SRS. Para além
disto, é essencial para este projecto porque
usa uma CNL com palavras-chave e padrões linguı́sticos bem
definidos para escrever os requisitos, evi-
tando o problema de uma NL onde há várias maneiras diferentes
de especificar o mesmo sistema, o que
torna uma especificação mais ambı́gua e menos consistente. Com
isto, a produção de uma aplicação
web baseada em especificações de sistema fica mais simples,
isto porque o RSL2WebApp precisa de
saber que código gerar a partir das especificações e era uma
tarefa muito mais difı́cil usando uma NL.
Para este projecto, o foco será apenas nos seguintes elementos
para a especificação de requisitos:
Actor, DataEntity e DataEntityClustere UseCase. A figura 3.1
mostra os elementos que serão usados
34
-
para este projecto. A área azul engloba todas os elementos
usados para a especificação de requisitos,
a área azul claro, que é a área StateMachine, representa um
trabalho avançado que não será utilizada
nesta dissertação. No entanto, a área azul no geral,
representa as construções que estão incluı́das
para a geração de código para a aplicação web, que
dependerá do que for especificado em cada uma
das construções, que será explicado mais à frente no
relatório.
Figura 3.1: Elementos utilizados para especificação RSL neste
projecto, adaptado de [3]..
Foram escolhidos estes elementos para a especificação do
sistema em RSL porque é neles que se
consegue representar duma melhor forma as funcionalidades da
aplicação web desejada. Por exemplo,