tecnicas avançadas de modelaç´ ao e produç˜ ao˜ semi … · tecnicas avançadas de...

Técnicas Avançadas de Modelação e ProduçãoSemi-Automática de Aplicações Web Responsivas

Gonçalo Ribeiro Pereira

Dissertação para obtenção do Grau de Mestre em

Engenharia Informática e de Computadores

Orientador: Prof. Alberto Manuel Rodrigues da Silva

Júri

Presidente: Prof. Paolo RomanoOrientador: Prof. Alberto Manuel Rodrigues da Silva

Vogal: Prof. António Paulo Teles de Menezes Correia Leitão

Maio 2019

Agradecimentos

Com a finalização desta tese de mestrado, é fechado um ciclo do qual retive varias liçõ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 várias pessoas, a motivar, guiar e aconselhar,

que foram indispensáveis para encontrar o melhor rumo e seguir pelo melhor caminho. Serve então

estas palavras para lhes mostrar a minha gratidã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 lá tanto nos bons como nos maus momentos. Foram eles que

me providenciaram com todas as condições para que fosse possı́vel concluir esta etapa. Um obrigado

especial por tudo.

Quero deixar também uma palavra de apreç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 experiência foram um factor decisivo para que tudo corresse pelo melhor.

Por ultimo, mas nã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

Aplicações Web, RSL, Model Driven Engineering, Angular6, ASP.NET Core 2, Xtend, Xtext;

iii

Resumo

As facilidades que as aplicações web oferecem promovem o aumento da sua utilização e desenvol-

vimento. Exemplos destas facilidades são; interacções sociais, fácil acesso à informação ou mesmo

como ponto de negócio das empresas. Além destas facilidades, as aplicações desktop estão a ser pro-

gressivamente convertidas em aplicações web devido às vantagens que trazem como: custo reduzido;

suporte e manutenção mais fáceis compatibilidade com maior número de dispositivos (smartphone,

portátil, tablet), facilidade de actualização de conteúdos e etc. No entanto o seu desenvolvimento trás

dificuldades adjacentes nomeadamente: necessidade de conhecer várias linguagens e frameworks,

mecanismos de segurança, bases de dados e design responsivo entre outras. Esta dissertação tem

como objectivo desenvolver uma ferramenta ”RSL2WebApp” com intuito de gerar código fonte para

aplicações web necessitando apenas dum Documento de Especificação de Requisitos ( ou em inglês

Software Requirements Specification) (SRS) por parte do utilizador. Como linguagem de especificação

e requisitos é utilizada o RSL. O RSL é uma linguagem para especificação de requisitos de sistema ri-

gorosa, consistente e fácil de usar que visa a reduzir as inconsistências e reduzir a quantidade de erros

durante a especificação de um sistema. No capı́tulo Avaliação 5, pode ser observado que partindo de

poucas linhas de especificação de um sistema em RSL, é gerado código fonte de uma aplicação web

pronta a correr, transformando o processo de desenvolvimento web bastante mais fácil e rápido. Neste

relatório serão introduzidos vários tópicos relacionados com o desenvolvimento de aplicações web e

na automatização do mesmo. É também explicado em detalhe o funcionamento do RSL2WebApp e do

modo de como é feita uma especificação de requisitos em RSL.

Palavras Chave

Aplicações Web, RSL, Engenharia Derivada de Modelos,Angular6, ASP.NET Core 2, Xtend, Xtext;

v

Conteúdo

1 Introdução 1

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Contexto 7

2.1 aplicaçõ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 Modelação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.5.4 Transformação de Modelos e Geração de Có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 Programaçã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 Geração de Có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 Visão geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4 Abordagem RSL2WebApp 39

4.1 Aplicação Web de referência QuickApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.2 Especificaçã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 geração de código fonte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1 Entidades(tabelas) para base de dados DataEntities . . . . . . . . . . . . . . . . . 50

4.3.2 Papeis e permissões associadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.3.3 Controladores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.3.4 páginas do lado do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

4.3.5 Serviços lado do cliente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

5 Avaliação 63

5.1 Casos de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.3 Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

6 Conclusão 71

6.1 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

6.2 Trabalho futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

A Exemplos da tipificação do elemento UseCase 75

B Exemplo: Requisitos informais do Billing System 77

viii

Lista de Figuras

2.1 Modelo das aplicações Web Tradicional vs aplicações Web SPA . . . . . . . . . . . . . . 10

2.2 Diferenças entre XML, JSON e uma DSL especifica para leitura de informação sobre

pessoas [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3 Classificação dos dos elementos RSL [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.4 MDE transformação de modelos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1 Elementos utilizados para especificação RSL neste projecto, adaptado de [3]. . . . . . . . 35

3.2 Visão geral do fluxo do processo do RSL2WebApp. . . . . . . . . . . . . . . . . . . . . . 37

4.1 Login QuickApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2 Gestão de papeis QuickApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Repositório e unidade de trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.4 Exemplo de uma especificação em RSL para o elemento DataEntity . . . . . . . . . . . . 46

4.5 Exemplo de uma especificação em RSL para o elemento DataEntityCluster . . . . . . . . 47

4.6 Exemplo de uma especificação em RSL para o elemento Actor ”Operator” . . . . . . . . . 47

4.7 Exemplo de uma especificação em RSL para o elemento UseCase . . . . . . . . . . . . . 48

4.8 Método doGenerate Xtend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.9 Processo de geração . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.10 Arquitetura do RSL2WebApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.11 Classe dominio gerada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

4.12 Relações entre DataEntities RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

4.13 Relação um-para-zero-ou-um RSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.14 Relações um-para-muitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

4.15 DataEntity derivada . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4.16 Permissões geradas para a DataEntity e Vat . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.17 Geração de função/papel e utilizador . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

4.18 Pagina principal da e Vat DataEntity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

ix

4.19 Pagina de ediçã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 descrição do Billing System para para que diz respeito aos actores [3] . . . 66

5.2 Representação dos Actors em RSL para o Billing System . . . . . . . . . . . . . . . . . . 67

5.3 Representação das DataEntities em RSL para o Billing System . . . . . . . . . . . . . . . 69

x

Lista de Tabelas

3.1 Comparação Angular, React e Vue.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.2 Comparação ASP.NET Core, NodeJS e PHP . . . . . . . . . . . . . . . . . . . . . . . . . 33

xi

Acrónimos

SRS Documento de Especificação de Requisitos ( ou em inglês Software Requirements

Specification)

RSL Requirements Specification Language

DSL linguagem especı́fica de domı́nio (ou em inglês, Domain-Specific Language)

GPL linguagem de propósito geral (ou em inglês, General-purpose language)

SPA aplicação de página única (ou em inglês, Single-Page Application)

RE engenharia de requisitos (ou em inglês, Requirements engineering)

NL lı́ngua natural (ou em inglês, Natural Language)

CNL lı́ngua natural controlada (ou em inglês, Controlled Natural Language)

MDA arquitectura orientada por modelo (ou em inglês, Model-Driven Architecture)

MDE engenharia conduzida por modelos (ou em inglês, Model-Driven Engineering)

M2T modelo para texto (ou em inglês, Model-to-Text)

M2M modelo para modelo (ou em inglês, Model-to-Model)

xii

1Introdução

Conteúdo

1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1

Este capı́tulo descreve a motivação para o desenvolvimento deste projecto. Descreve também o ob-

jectivo principal, que será o desenvolvimento da ferramenta ”RSL2WebApp”, e estrutura do documento.

1.1 Motivação

O uso de aplicações web está presente no quotidiano, pois facilita várias tarefas tais como o acesso

ao correio electrónico, a interacção social com amigos, familiares ou mesmo para assuntos profissio-

nais através de redes sociais (Facebook, Instagram, Linkedin, etc.), e o acesso facilitado à informação

através de aplicações web de notı́cias relacionados com uma grande variedade de assuntos como me-

dicina, informática, nutrição, etc. Isto leva à necessidade de construir mais e melhores aplicações web.

No entanto, o desenvolvimento deste tipo de aplicações web pode ser um processo bastante desafiante

e demorado, pois é necessário reunir conhecimentos de várias áreas tecnológicas. Exemplos da difi-

culdade do desenvolvimento destas aplicações são as seguintes: grande diversidade de linguagens de

programaçã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; segurança; design responsivo, etc. Devido a todas estas

dificuldades envolvidas no desenvolvimento de aplicações web, fica claro que, uma ferramenta que seja

capaz de gerar código fonte para este tipo de aplicações web, baseado-se apenas em requisitos do

sistema, poderá ser de grande utilidade reduzindo a complexidade do desenvolvimento deste tipo de

aplicações web.

O desenvolvimento de um documento que descreve os requisitos e caracterı́sticas de um sistema é

chamado de Documento de Especificação de Requisitos ( ou em inglês Software Requirements Spe-

cification) (SRS), pois fornece uma visão partilhada entre todos os principais intervenientes durante a

concepção e implementação de um sistema [4]. No entanto, em geral, a forma mais comum e preferida

para representação dos requisitos do sistema é através do uso da lı́ngua natural (ou em inglês, Natural

Language) (NL), o que tem introduzido alguns problemas (conforme explicado mais à frente). Uma

solução para mitigar esses problemas é através da adopção da linguagem Requirements Specification

Language (RSL) [4] para especificação de requisitos, que também facilita a automatização de algumas

tarefas relacionadas com a análise e validação de requisitos (o RSL é descrito com maior detalhe mais

à frente na secção 2.4).

Com o RSL2WebApp, a complexidade do desenvolvimento de aplicações web é reduzida significa-

tivamente uma vez que é apenas necessário a especificação do sistema alvo utilizando o RSL, cuja

especificação é depois usada como fonte para a geração de tais aplicações web. Quando comparado

com todas as dificuldades adjacentes ao desenvolvimento web, fica claro que esta ferramenta pode

reduzir significativamente o tempo e esforço do seu desenvolvimento.

3

1.2 Objectivo

O objectivo principal deste projecto é conhecer e implementar uma ferramenta, designada por ”RSL2WebApp”,

que seja capaz de gerar código fonte para aplicações web a partir de especificações do sistema em

RSL. As aplicações web produzidas serão constituı́das por uma interface com a qual o utilizador poderá

interagir e um servidor que contém toda a lógica juntamente com a toda a estrutura de base de dados

que irá fornecer os dados relevantes. A interface será construı́da usando a framework Angular6 1 e

o servidor será construı́do com a framework ASP.NET Core 2. Para a geração de código e leitura da

especificação de requisitos é usada a linguagem Xtend 3.

A geração do código fonte para aplicação web requer, por parte do utilizador, uma SRS. Essa

especificação, que consiste basicamente num conjunto de funcionalidades e requisitos que a aplicação

deve satisfazer, é representada e definida usando a linguagem RSL. O RSL é uma linguagem que ajuda

a melhorar a produção de requisitos, descrita à frente em maior detalhe na secção 2.4.

Estes SRS serão processados pelo RSL2WebApp através das tecnologias Xtext/Xtend, que irá gerar

o có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 avaliação, é verificada a percentagem coberta pelo RSL2WebApp em relação ao SRS em

RSL desenvolvido pelo utilizador. Isto é, se todos elemento definido no RSL juntamente com o seus

atributos foram ”lidos” pelo RSL2WebApp e gerado o código fonte esperado.

Para uma avaliação inicial, são usados dois sistemas. Um sistema fictı́cio chamado ”Billing Sys-

tem”descrito na secção 5.1 que já possui uma especificação bem definida para ser usada nos testes

de geração de código. E outro sistema editado por mim, que representa uma loja online designada

de ”MyStore”, onde será possı́vel criar um carrinho de compras com o intuito de verificar a generali-

dade de especificações e evitar dependências do sistema ”Billing System”. Tendo em conta o que foi

mencionado acima, os objectivos desta dissertação são os seguintes:

- Investigação e aprendizagem em conhecimentos gerais de tecnologias de suporte para desenvol-

vimento de aplicações Web; Aprendizagem da linguagem Requirements Specification Language

(RSL) e Aprendizagem das tecnologias Xtext and Xtend.

- Definição e implementação de modelos para geração de código para as tecnologias Angular6(interface)

e ASP.NET Core(servidor), usando as tecnologias Xtext e Xtend, a partir das especificações em

RSL (RSL2WebApp).

- Validação e avaliação dos resultados obtidos, com base em cená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 relatório é composto por seis capı́tulos e está organizado da seguinte maneira.

O capı́tulo 1 Introdução, introduz a motivação e os objectivos principais deste projecto e ainda a

organização deste documento.

O capı́tulo 2 Contexto, contextualiza o âmbito da investigação onde são adoptados e introduzidos

alguns conceitos tais aplicaçõ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. Sã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 geração de código são também discutidas neste capı́tulo. Poste-

riormente, são explicadas as escolhas para as tecnologias usadas neste projecto, tendo em conta os

seus objectivos. Além disso, mostra uma visão geral da RSL2WebApp, com uma descrição detalhada

de como todas as peças estão ligadas, nomeadamente como é feita a transformação da especificação

RSL para código-fonte.

O capı́tulo 4, Abordagem RSL2WebApp, é apresentado o projecto template QuickApp que serve

como base para a construção do sistema RSL2WebApp. É explicado também de que forma o RSL2WebApp

faz a leitura da especificação do sistema em RSL e como é feita a geração de código fonte. Por fim é

explicado como é construı́da uma especificação de sistemas usando a linguagem RSL.

O capı́tulo 5, Avaliação, descreve como nomeadamente o trabalho realizado é testado e avaliado

em relação à sua capacidade de ler e interpretar a especificação gerada pelo utilizador e gerar código

correspondente.

Por último, o capı́tulo 6, Conclusão, apresenta a conclusão deste trabalho, com os pontos negativos

e positivos durante com todas as aprendizagens e visão geral de todo o processo, assim como as

vantagens e utilidade que esta ferramenta poderá ter.

5

2Contexto

Conteúdo

2.1 aplicaçõ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

Neste capı́tulo, são introduzidos assuntos relevantes dentro do contexto onde se encontra inserida

esta dissertação. É feita uma breve introdução aos conceitos relacionados com aplicações web, no-

meadamente a noção de aplicação de página única (ou em inglês, Single-Page Application) (SPA).

Descreve também a linguagem RSL e qual a necessidade e vantagens da sua utilização, que inclui

tópicos como: engenharia de requisitos (ou em inglês, Requirements engineering) (RE), linguagem es-

pecı́fica de domı́nio (ou em inglês, Domain-Specific Language) (DSL). É também introduzido o conceito

de engenharia conduzida por modelos.

2.1 aplicações Web

No desenvolvimento de websites têm sido usadas as seguintes linguagens: HTML, que permite definir

a estrutura e o conteúdo (como textos, imagens, tabelas, etc); e CSS, que permite definir o estilo

e apresentação dos elementos desses websites (como fontes, cores, margens, etc.). Contudo, com

estas duas tecnologias, é apenas possı́vel criar um website estático que não possibilita a interacção

com o utilizador.

Por outro lado, uma aplicação web permite um maior nı́vel de interacção e tem como objectivo

oferecer uma experiência de utilização semelhante ao de uma aplicação desktop, incluindo conteúdos

dinâmicos. Para tal, é necessário usar JavaScript. O JavaScript (normalmente abreviado como JS),

é a linguagem de programação mais popular no contexto da web que permite que os scripts sejam

executados no lado do cliente (navegador). Com esses scripts JS as páginas web integram conteúdos

mais dinâmicos e interactivos, dando a sensação de uma aplicação desktop.

As aplicações web são facilmente acessı́veis a partir de qualquer dispositivo (tablet, smartphone,

laptop, etc.) com acesso à Internet usando um navegador web. Em contraste com as aplicações desk-

top tradicionais, que precisam ser previamente instaladas para poderem ser utilizadas, as aplicações

web podem ser acedidas a partir de qualquer dispositivo desde que tenha acesso à Internet e um na-

vegador web. Algumas das vantagens das aplicações web são as seguintes: maior disponibilidade;

acessibilidade por uma variedade diferente de dispositivos(smartphones, portáteis, tablets, etc); maior

facilidade de manutenção e suporte; credibilidade no ramo empresarial com um aplicação web oficial.

Uma SPA é uma aplicação web baseada no modelo ”página única web”, com o objectivo principal de

oferecer aos seus utilizadores uma experiência de interacção semelhante à das aplicações desktop [5].

Nas aplicações web tradicionais (aplicação de várias páginas) geralmente, quando o utilizador interage

com a aplicação, é enviado um pedido ao servidor, que tratará do pedido e enviará a resposta para o

cliente com o novo conteúdo HTML, e finalmente, renderizado pelo navegador do cliente para poder

ser visualizado. O problema com esta abordagem é que são enviados muitos pedidos para o servidor.

Sempre que seja necessário mudar o conteúdo HTML, o utilizador terá de esperar pelo ”download”da

9

nova página web, o que resulta numa experiência de utilização mais demorada e não tão natural como

desejado.

Por outro lado no modelo SPA, normalmente todo o código necessário (HTML, JavaScript, e CSS)

ou é obtido com um único carregamento da página, ou é carregado dinamicamente e adicionado con-

forme necessário. Isto faz com que, sempre que seja necessário alterar o conteúdo da página, o próprio

navegador irá tratar da nova renderização com JavaScript. Por conseguinte, o servidor não é ocupado

durante este processo o que torna a renderização muito mais rápida providenciando uma experiência

de utilização mais responsiva, ao nı́vel das aplicações desktop. No entanto, se forem precisos dados ou

realização de cálculos do servidor, o pedido dos dados será feito assincronamente, conforme mostrado

na figura 2.1 e a renderização será feita da mesma maneira.

Figura 2.1: Modelo das aplicações Web Tradicional vs aplicações Web SPA (extraı́do de1).

2.2 Engenharia de Requisitos

Ter uma ideia clara e concisa do domı́nio do problema é essencial para ter sucesso durante o desen-

volvimento de um projecto.

Antes de começar a desenvolver a solução, é necessário que haja uma documentaçã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 à área de RE. A área RE consiste

em várias tarefas/actividades para oferecer uma visão/ideia partilhada do sistema entre as partes inte-

ressadas do projecto [4]. Embora todas as actividades sejam importantes, neste projecto é dada uma

atenção especial à actividade SRS.

SRS é um documento que descreve várias preocupações técnicas de um sistema de software (como

requisitos de sistema e requisitos de utilizador) [4]. Neste contexto, um requisito é uma descrição do1https://msdn.microsoft.com/en-us/magazine/dn463786.aspx

10

https://msdn.microsoft.com/en-us/magazine/dn463786.aspx

que o sistema é capaz de fazer ou uma caracterı́stica do sistema. Este documento é usado durante

todo o processo de desenvolvimento para facilitar a comunicação entre todas as partes interessadas,

bem como uma visão partilhada do sistema. Um bom SRS é essencial em muitas aspectos, tais como;

- Estimativa de orçamento e cronograma.

- Base para futuras actividades de manutenção.

- Acordo entre cliente e empresa.

- Menos defeitos nos requisitos e no produto final.

- Mais certidão nas caracterı́sticas do sistema e consequentemente menos trabalho a corrigir as

caracterı́sticas desnecessárias/erradas.

- Maior satisfação dos clientes e dos membros da equipa.

Um dos procedimentos mais crı́ticos durante o desenvolvimento de software é o planeamento, e

o SRS tem um papel muito importante neste assunto, pois é a fonte de informação principal para os

requisitos funcionais e não funcionais do produto, que pode ser usado ao longo de todo o ciclo de vida do

projecto, facilitando a comunicação e gestão de projectos durante todo o processo de desenvolvimento.

O sucesso ou o fracasso do desenvolvimento de sistema é altamente dependente da qualidade do SRS

produzido.

No entanto, o estabelecimento de uma compreensão e comunicação partilhada entre todas as par-

tes interessadas pode dar origem a um problema. Para que a comunicação entre todas as partes

interessadas seja eficaz, deve haver uma linguagem comum compartilhada com todos os envolvidos. A

abordagem mais rápida e preferida por parte das empresas, ainda é a produção os requisitos usando

NL (como inglês). A NL é flexı́vel, universal e os humanos são proficientes ao usá-la para comunicar

entre si. Apesar disso, é bem sabido que esta abordagem é propensa ao aparecimento de defeitos

na produção dos requisitos [7] devido às caracterı́sticas intrı́nsecas de NL (como ambiguidade e incon-

sistência) [8], que eventualmente irá dificultar futuras acções sobre os requisitos [9].

2.3 Linguagens Especı́ficas de Domı́nio

Uma vez que a causa de produção de requisitos de má qualidade deriva de problemas, como ambigui-

dade, das NL, a solução é usar uma linguagem mais restrita e formal, denominadas por DSL.

As DSL são linguagens de programação ou linguagens de especificação, especializadas para um

problema de domı́nio especı́fico. Estas linguagens não podem ser aplicadas a todo o tipo de problemas,

ao contrário das linguagem de propósito geral (ou em inglês, General-purpose language) (GPL), que

são aplicá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 é resolvido de uma forma

mais fácil e eficaz. No contexto deste projecto, podemos imaginar que uma NL, por exemplo o inglês,

seja uma GPL que possa ser usada para qualquer problema, e um linguagem mais controlada e não tão

abrangente sendo uma DSL que resolva um problema especı́fico, neste caso a produção de requisitos.

Há uma grande variedade de DSLs. Alguns exemplos são: SQL (para consulta de bancos de dados

relacionais); UML (modelagem visual); HTML e muitos outros.

Já existem algumas DSLs que são boas para representar informação técnica para máquina num

formato legı́vel por pessoas, como XML ou JSON, no entanto não é uma tarefa fácil, produzir uma

especificaçã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 são uma forma viável para representar informação para ser processada nos computadores, mas

não é o mais apropriado para a comunicação e a compreensão entre pessoas, portanto, especificar o

SRS com estas linguagens não é o melhor caminho.

A seguinte figura 2.2 ilustra as dificuldades de ler uma descrição com informação de pessoas usando

DSLs como o XLM e JSON. Primeiro, temos uma especificação XML, que não é a maneira mais indi-

cada que permita que seja possı́vel reter informações sobre cada pessoa, devido a todas as tags.

Seguidamente vem uma especificação ad-hoc usando JSON, que é menos confuso do que XML e um

pouco mais fácil de ler. Porém, é possı́vel fazer melhor, como mostrado mais à direita na figura com a

utilização de uma especificação usando uma DSL mais compacta e restrita.

Figura 2.2: Diferenças entre XML, JSON e uma DSL especifica para leitura de informação sobre pessoas [1]

12

2.4 A iniciativa RSLingo

O ITLingo é uma iniciativa de longo prazo com o objectivo de pesquisar, desenvolver e aplicar lingua-

gens de especificação rigorosas [2] no contexto de IT. Para tal o ITLingo considera principalmente as

seguintes áreas: (i) Engenharia de Requisitos, com o RSL; (ii) Engenharia de Testes, com o TSL (Tes-

ting Specification Language); e (iii) Gestão de Projectos, com o PSL (Projects Specification Language).

Com o objectivo de melhorar o rigor no desenvolvimento de documentos técnicos (p.e, especificações

de requisitos, especificações de casos de teste ou planos de projecto), O ITLingo adopta uma aborda-

gem linguı́stica, o que também irá resultar num aumento da produtividade através de transformações

e reutilização de modelos, juntamente com um aumento na qualidade com validação semi-automática.

Numa fase inicial, o RSLingo, que acomodada a área de RE do ITlingo, que a utilização de linguagens

naturais era a forma preferida e comum na especificação de requisitos, no entanto estas são propicias

ao desenvolvimento de documentos ambı́guos inconsistentes que são difı́ceis de validar ou transformar

automaticamente. [2]

Para resolver os problemas de qualidade na produção de requisitos, e ao mesmo tempo oferecer

uma linguagem que acomode todas as partes interessadas, é utilizado o RSL, que ajuda a mitigar al-

guns dos problemas provenientes do uso de NL para a produção de requisitos, onde existe um controlo

rigoroso e uma maneira certa para escrever SRS, e oferece também, benefı́cios em relação ao desen-

volvimento de software.

O RSL é uma DSL com o objectivo principal de melhorar a produção de requisitos de forma mais

sistemática, rigorosa e consistente usando uma lı́ngua natural controlada (ou em inglês, Controlled

Natural Language) (CNL), que segue recomendações práticas para melhorar a escrita dos requisitos.

Actualmente encontra-se num estado avançado, tendo sofrido varias actualizações desde a sua criação

com o objectivo de desenvolver uma linguagem mais ampla e consistente (hoje denominada ”RSLingo’s

RSL”ou apenas ”RSL”).

O RSL fornece vários elementos organizados logicamente em duas perspectivas 2.3: nı́vel de

abstração e matérias especı́ficas. Os nı́veis de abstração são: nı́veis de negócios, aplicativos, software

e hardware. Por outro lado, as matérias especı́ficas são: estrutura activa (sujeitos), comportamento

(acções), estrutura passiva (objectos), requisitos, testes, outras matérias e relações e conjuntos.

Esta linguagem é composta por um conjunto elaborado de elementos organizadas logicamente de

acordo com duas perspectivas: nı́vel de abstração e conceitos especı́ficos.

Os elementos da linguagem RSL são definidas por padrões linguı́sticos e representadas textual-

mente de acordo com estilos linguı́sticos concretos. Estes estão organizadas de acordo com dois

pontos de vista 2.3: o nı́vel de abstração (Nı́veis) e preocupações especificas (Concerns). Os nı́veis de

abstração são: nı́veis de negócios, aplicativos, software e hardware. Por outro lado, as preocupações

13

especı́ficas são: estrutura activa (sujeitos), comportamento (acções), estrutura passiva (objectos), re-

quisitos, testes, outras matérias e relações e conjuntos.

Figura 2.3: Classificação dos dos elementos RSL [2]..

Do ponto de vista prático, qualquer elemento pode ser usado em qualquer tipo de sistema, indepen-

dentemente do seu nı́vel de abstracção. Isso significa, por exemplo, que é possı́vel usar um elemento

DataEntity nos nı́veis Aplicação ou software, mas também nos nı́veis negócio ou mesmo hardware. No

entanto, o uso de um DataEntity no nı́vel de negócio deve ser mais geral e incompleta (por exemplo, sem

especificação de atributos de dados) em comparação com seu uso nos nı́veis do software, que devem

ser mais detalhados (por exemplo, incluindo atributos de dados e referências de chaves estrangeiras

especificação). Além disso, enquanto alguns elementos (por exemplo, Stakeholder, ActiveElement,

GlossaryTerm, Risk ou Vulnerabilidade) são naturalmente aplicados a diferentes tipos de sistemas, ou-

tros elementos não são tão obviamente aplicadas (por exemplo, UseCase e Actor são melhor aplicados

apenas para aplicativos ou software) [2].

14

2.5 Engenharia Conduzida por Modelos

A engenharia conduzida por modelos (ou em inglês, Model-Driven Engineering) (MDE) é uma meto-

dologia de desenvolvimento de software que se concentra na criação de modelos abstratos que repre-

sentam uma visão parcial e simplificada de um sistema. Geralmente, é necessário criar vá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 é que os módulos orientem todo o processo

de desenvolvimento (design do sistema, geração de código), que traz vantagens como melhorias de

qualidade do produto, aumento da produtividade e melhor comunicação entre as partes interessadas.

2.5.1 Modelos e Metamodelos

Há várias de definições para o termo ”modelo”, algumas delas não são claras e consistentes, embora,

para todas essas definiçõ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 visão parcial e sim-

plificada de um sistema. A criação de múltiplos modelos é normalmente necessá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 comunicação

entre todas as partes interessadas, pois permite compartilhar uma visão e compreensão comum. Os

modelos também tornam o planeamento do projecto mais assertivo e eficiente ao fornecer visões mais

apropriadas do sistema.

Os modelos estão de acordo com Metamodelos. Um Metamodelo é um modelo que define a estrutura

de uma linguagem de modelação [10].

2.5.2 Aparecimento da Engenharia Conduzida por Modelos

Originalmente, inúmeras técnicas e linguagens de modelagem foram propostas essencialmente com o

objetivo principal de de obter uma compreensão e visão comum e coerente do sistema em estudo e,

consequentemente, facilitar a comunicação entre as partes interessadas [10].

No entanto, nos últimos anos surgiu uma nova metodologia, não considerando apenas modelos

como artefactos de documentação, mas como artefactos centrais no processo de engenharia de soft-

ware [10].

Esta nova tendência de abordagens trouxe mais benefı́cios além dos oferecidos por metodologias

propostas anteriormente, pois também permite a criação ou a execução automática de sistemas de soft-

ware com base em modelos que utilizam técnicas complexas, como meta-modelagem, transformação

15

de modelos, geração de código, ou interpretação de modelos [10]. Os novos benefı́cios são de grande

importância, pois o contexto deste projecto é criar uma aplicação web através da geração de código.

Etas propostas - como o arquitectura orientada por modelo (ou em inglês, Model-Driven Archi-

tecture) (MDA) [11, 12], Fabricas de Software (em inglês, Software Factories) [13], ou recentemente

Engenharia DSL [14] - foram classificadas genericamente como Engenharia Derivada de Modelos

(MDE) [10], mas també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 Modelação

Conforme anteriormente, uma linguagem de modelação é definida por um metamodelo e é um conjunto

de todos os modelos possı́veis que estão de acordo com seus respetivos metamodelos [10]. Uma lin-

guagem de modelação é qualquer linguagem artificial que possa ser usada para expressar informações

ou conhecimentos ou sistemas numa estrutura definida por um conjunto de regras. Estas regras são

usadas para facilitar a interpretação do significado de cada componentes na estrutura.

Uma linguagem de modelação pode ser classificada em duas categorias: linguagem de modelação

para uso geral (ou em inglês é GPML) ou linguagem de modelagem para domı́nio especı́fico (ou em

inglês é DSML) [20–24].

As GPMLs (UML ou SysML são exemplos de GPMLs) são caracterizados por ter um maior número

de construções genéricas. Por outro lado, os DSLs tendem a usar algumas construções ou conceitos

mais próximos do seu domı́nio de aplicação, podendo melhorar a produtividade, a confiabilidade, a

manutenção e a portabilidade. No entanto, o uso de DSL pode aumentar alguns problemas, como o

custo da aprendizagem, implementação e manutenção de uma nova linguagem, bem como as ferra-

mentas para a desenvolver. [10].

2.5.4 Transformação de Modelos e Geração de Código

Um aumento da automatização no desenvolvimento do programa é obtido através transformações do

modelos. Os modelos de nı́vel superior são transformados em modelos de nı́vel inferior até que o

modelo possa ser executado usando, por exemplo, geração de código como ilustrado na figura 2.4.

Transformar um modelo noutro modelo significa que, o modelo de origem é transformado num modelo

de destino baseado em algumas regras de transformação.

Na abordagem MDE dois tipos principais de transformações tendem a ser considerados. modelo

para texto (ou em inglês, Model-to-Text) (M2T) e modelo para modelo (ou em inglês, Model-to-Model)

16

(M2M). Por um lado, as transformações M2T geram ou produzem artefactos de software - geralmente

código fonte, XML e outros arquivos de texto - a partir de modelos. A técnica mais comum para esta

classe de transformações é conhecida como geração de código. Por outro lado, as transformações de

modelo para modelo (M2M) permitem a transformação de modelos para outro conjunto de modelos,

geralmente mais próximo do domı́nio da solução ou que satisfaçam as necessidades especı́ficas das

diferentes partes interessadas [10].

Naturalmente, é importante referir que, no contexto de MDE, os modelos devem ser definido de

forma consistente e rigorosa para ser efetivamente usado. Geralmente, é necessário um certo nı́vel de

qualidade para que esses modelos possam ser usados corretamente em cenários M2M ou M2T.

Figura 2.4: MDE transformação de modelos.extraı́do de 2

17

3Tecnologias de Suporte

Conteúdo

3.1 Frameworks para desenvolvimento do lado do cliente . . . . . . . . . . . . . . . . . . 21

3.2 Frameworks e Linguagens de Programação do lado do servidor . . . . . . . . . . . 27

3.3 Tecnologias para Geração de Código . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.4 Tecnologias utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.5 Visão geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

19

Neste capı́tulo são discutidas varias tecnologias relacionados com o desenvolvimento web, tanto

para o lado do servidor como para o lado do cliente onde é feita uma apresentação e comparação entre

as mesmas. Da mesma forma são apresentadas e comparadas tecnologias para geração de código. É

apresenta também a solução proposta para este projecto que inclui as tecnologias escolhidas e de que

modo serão utilizadas. Por fim é apresentada uma visão geral do sistema.

3.1 Frameworks para desenvolvimento do lado do cliente

A linguagem de programação JavaScript, normalmente denominada por ’JS’, tornou-se a linguagem de

programação mais popular no contexto web, e é imprescindı́vel a todas as aplicações web, isto porque

é o JS que dá dinamismo a uma aplicação web o que permite ao utilizador interagir com a mesma, o

que no fundo é o objetivo principal duma aplicação web. No entanto, criar uma aplicação web com uma

boa aparência e um bom design, fácil de manter, simples de usar, entre outras qualidades que uma

boa aplicaçã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 já existiam são atualização frequentemente tendo múltiplas versõ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 usá-las pode ser um processo demorado.

No que diz respeito ao desenvolvimento de aplicações web , a utilização de frameworks JS é o

método mais recomendável. As frameworks/bibliotecas (como Angular, Vue, React) oferecem uma es-

trutura que deve ser seguida o que irá ajudar a manter o código mais organizado, tornando as aplicações

web mais flexı́veis e escaláveis e o processo de desenvolvimento mais fá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 manutenção do código que influenciam diretamente o

custo do projecto e, deste modo, o sucesso do projecto. A escolha da framework mais indicada não é

feita tendo em conta só 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 área de informática é importante saber que não há uma solução perfeita para todos

os projecto, irá 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+), é uma nova versão construı́da de raiz, pela

mesma equipa que desenvolveu AngularJS ou ”AngularJS 1.X”. É uma framework de código aberto

suportada e mantida pela Google, para a desenvolvimento de aplicações web e móveis. Foi feita com

o objectivo principal de facilitar o desenvolvimento de SPA [25].

O Angular adoptou um metodologia em que vê uma aplicação como uma colecção de componentes

e, onde todos os elementos da página são componentes com um devido propósito que podem ser

reutilizados em diferentes partes, o que promove a reutilização dos mesmos.

O Angular recomenda a utilização da linguagem TypeScript da Microsoft durante o seu uso, apesar

de ser possı́vel usar o JavaScript. TypeScript é uma Superset de JavaScript, que força a escrever

um código melhor e mais organizado e oferece outras vantagens para a produção de código como a

programação orientada a objecto.

A utilização de Typescript com Angular tornou o código mais sustentável e legı́vel. Isto traz mais

simplicidade para o desenvolvimento, porem é mais uma linguagem que é necessária de aprender o

que irá resultar numa complexidade de aprendizagem da framework maior.

As principais vantagens do Angular são as seguintes:

- Typescript: TypeScript oferece muitas vantagens como: programação orientada para objec-

tos(classes, interfaces, etc.); validação de tipos; detecção de erros enquanto se escreve o código

com IDEs como Visual Studio. Ter tais ferramentas é quase um requisito obrigatório para desen-

volvimento de grandes projectos.

- Ligação de dados bidireccional: Angular usa Ligação de dados bidirecional. Isto permite que a

framework seja capaz de ligar o Modelo de Documento Objecto (ou em inglês, Document Object

Model (DOM)) ao modelo de dados (base de dados) através dum controlador. Resumidamente

isto é, quando os utilizadores interagem com novos inputs e dão um novo valor à aplicação, não

só a interface é alterada, mas também o Modelo (base de dados) automaticamente. Consequen-

temente, não é necessários arranjar um método ou escrever código para ter em conta todas estas

modificações.

- Model-View-Controller: O padrão Model-View-Controller permite dividir o código do projecto

em três componentes: modelo, vista e controlador, permitindo a separação de preocupações que

mantêm o código organizado, limpo permitindo que possı́veis alterações sejam mais fáceis. Desta

forma, a alteração de cada componente pode ser feita independentemente onde cada parte do

1https://angular.io/docs

22

https://angular.io/docs

código apenas serve para uma finalidade, não estando tudo misturado, aumentando a qualidade

do produto final.

- É uma framework : Uma vez que o Angular6 é uma framework, oferece uma solução mais com-

pleta com mais possibilidades e funcionalidades, o que ajuda a começar um projeto mais rapida-

mente sem necessitar de bibliotecas adicionais ou outras ferramentas framework.

- Suportado pela Google: O Angular foi criado e é suportado pela Google, isto oferece alguma

credibilidade e popularidade à framework, pois é uma das empresas mais conceituadas no ramo

da informática, e 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 são estudadas e implementadas, o que melhora qualidades como desem-

penho, escalabilidade, etc. A atualização da framework ocorre com alguma frequência com um

objectivo de produzir uma framework melhor e mais fácil de usar (ultima versão a 1 Nov 2017

Angular 5.0 2).

Por outro lado as suas desvantagens são as seguintes:

- Curva de aprendizagem: Para se utilizar o Angular6, não só é necessário aprender uma fra-

mework nova, como também é aconselhável perceber como funciona a configuração dos ficheiros

e a forma como o Angular6 funciona e aprender uma nova linguagem TypeScript. .

- Typescript: É possı́vel utilizar Angular com JavaScript, mas poderá ser trabalhoso e mais difı́cil

devido à falta de documentação e apoio neste assunto, pois o mais utilizado é TypeScript. A

maioria dos cursos e palestras em Angular são feitas com o uso de TypeScript. Isto faz com que

a aprendizagem desta linguagem seja quase obrigatória.

- Regular DOM: O Angular manipula diretamente DOM, isto faz com que seja mais lento em

comparação com o React que usa um DOM virtual que apenas faz alterações necessárias ao

DOM normal. Também devido ao uso LIGAÇÃO DE DADOS BIDIRECIONAL, faz com que haja

observadores em cada componente para alertar sempre que haja uma alteração, que também

afeta o desempenho.

3.1.2 React

O React 3 (normalmente denominado por React.js ou ReactJS) é uma biblioteca JavaScript para cons-

truir interfaces mais elaboradas. Permite aos programadores criarem aplicaçõ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 reutilização de componentes de interface que apresentam dados que são alterados frequen-

temente, sem ter que actualizar a página, seguindo um modelo de SPA. O seu principal objectivo é que

seja rápido, eficiente, simples e escalável. React é descrito como o ”V” relativamente ao modelo MVC.

Permite que seja criado componentes para interface reutilizáveis (barra de navegação (tabs), caixas de

comentários, modelos pop-up, listas, tabelas ordenáveis, etc.).

Normalmente, o aspecto de uma página da Web segue um padrão, contendo vários componentes,

estes componentes podem ser elementos como cabeçalho, área principal, barra lateral, lista, etc. O

React usa a ideia de dividir uma página web em componentes tornando-os reutilizáveis. Estes com-

ponentes contém o código HTML juntamente com o código JavaScript para exibir conteúdo dinamica-

mente.

A grande ideia por trás do React é a seguinte: possibilitar a criação de elementos HTML que tenham

funcionalidades personalizadas, por exemplo, construir um elemento que exiba uma

área de texto, faça as validações no texto escrito na área de texto, envie o formulário aquando da sua

submissão, etc, onde seria apenas necessário incluir uma linha de código com a TAG: .

As principais vantagens do React são as seguintes.

- Ligação de dados unidireccional: O fluxo de dados é direccionado apenas de uma maneira,

não sendo possı́vel, como por exemplo no angular, alterar o Modelo (base de dados) com inputs

pelo utilizador. Porém isto traz vantagens, é possı́vel saber sempre onde estamos a alterar os

dados. A abordagem do React é muito mais fácil de fazer debug quando se trata de aplicações

extensas.

- Virtual DOM: O React introduziu o conceito de DOM virtual que permite a criação duma árvore

DOM leve, guardando-a em memoria. Sempre que um utilizador interage com o site, por exemplo,

preenchendo um formulário, o React cria um novo DOM virtual para compara-lo com o DOM real e,

sempre que são encontradas alterações o DOM virtual é construı́do para que seja apenas alterado

o que é necessá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 função de renderização sem ter que concatenar strings ou outro método

para juntar HTML com JS.

- Fácil utilização e aprendizagem: Sendo apenas uma biblioteca, a complexidade de aprender

React com Angular é muito menor, havendo também boa documentação e muitas pessoas que

utilizam a livraria é fácil encontrar ajuda online.

24

- Suportado pelo Facebook: Á semelhança do Angular, React também é suportado e mantido por

uma grande empresa e excelentes engenheiros, o que só traz benefı́cios para a tecnologia.


- JSX: Apesar da ideia do JSX ser bastante útil, que é juntar HTML com JavaScript, pode-se tornar

num desafio para se dominar e habituar a usar, isto porque, é apenas uma maneira de facilitar

a utilização de HTML com JS, porém não podemos usar o HTML normal (classname em vez de

classe, se queremos atribuir uma classe css) e pode exigir um pequeno esforço para se habituar

a usar. Construir componentes com JSX pode não ser tão simples/intuitivo como HTML puro e o

JS.

- React é apenas uma biblioteca: Não sendo uma framework robusta e completa, Não há por

exemplo um router implementado, tendo por isso de se utilizar outras bibliotecas externas para

estea finalidade. Por isso, é necessário ter algum grau de experiência na escolha de bibliotecas

para completarem estas necessidades.

- React é apenas uma camada de visualização: Fácil integração num sistema que siga o modelo

MVC.

3.1.3 Vue.js

Vue.js 4 (normalmente referido como Vue) é uma framework JS de código aberto que se concentra na

construção de interfaces de usuá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 versão mais ”leve”sem os conceitos extras.

Vue faz parte da camada de visualização apenas, é muito fácil de integrar com outras bibliotecas ou

projectos existentes. No entanto, Vue é perfeitamente capaz de criar aplicações sofisticadas de uma

página única quando usados juntamente com outras ferramentas/tecnologias modernas e bibliotecas

de suporte.

Uma das razões pelas quais há muito entusiasmados com o Vue recentemente, é que é extremamente

fácil de adoptar quando se precisa apenas de adicionar algumas caracterı́sticas dinâmicas básicas

numa aplicação web. Não é precisa instalar nada nem configurar.

As principais vantagens do Vue são:

- Complexidade de introdução de uma nova famework pequena: O Vue.js possui uma documentação

muito completa e bem escrita. Para se construir uma primeira aplicação web, basta saber JS e

4https://vuejs.org/v2/guide/

25

https://vuejs.org/v2/guide/

HTML básicos para fazer metade do trabalho. De acordo com uma pesquisa de JavaScript de

2016, a Vue tem uma classificação de satisfação pelos programadores de 89 %.

- Fácil Legibilidade/Manutenção: Vue encontra o ponto ideal entre legibilidade e manutenção.

Vue de certa forma é baseado no que o React e o Angular tê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 ligação bidireccional quando se precisar (dentro de um único

componente).


- A framework ainda se está a desenvolver: A framework é muito nova. Não há componentes

estáveis da comunidade - muitos deles foram criados para o Vue.js 1 e, às vezes, não é fácil para

os iniciantes verem no repositório do github para qual versão do Vue uma biblioteca especifica foi

desenvolvida. Esta questão é mitigada pelo fato de que se pode fazer coisas complexas no Vue

sem bibliotecas adicionais. Além disso, uma vez que esta framework é principalmente conhecida

na China, há comentários chineses no código na maioria das bibliotecas públicas e ajudas online,

devido a ser maioritariamente usada na China(o autor fala chinês).

- Não é suportado por uma grande empresa como React ou Angular: Apesar do seu criador

ter pertencido a Google e ao projecto Angular, não sendo suportado/mantido por uma grande

empresa como Angular ou Reagente, pode influenciar seu popularidade e confiança.

A tabela 3.1 compara de uma forma resumida as três frameworks descritas acima.

Tabela 3.1: Comparação Angular, React e Vue.js

Atributo Angular6 React VueEmpresa/Criador Google Facebook Evan YouAno de criação 2016 2013 2014Linguagem Typescript JSX JavascriptMVC Yes View layer only View layer onlyDOM Regular DOM Virtual DOM Virtual DOMVel. desenvolvimento Médio/Alto Alto AltoPerformance Muito boa Muito Boa Muito boaCurva de aprendizagem Alto Médio BaixoComunidade Médio Alto Médio(Chinesa)

Outras frameworks e bibliotecas JS podem ainda ser mencionadas neste âmbito para criar aplicaçõ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 Programação do lado do servi-

dor

O lado do servidor (ou em inglês normalmente referido como backend), uma aplicação Web é cons-

tituı́do por todas as componentes responsáveis pela generalidade da lógica e regras de negócio do

sistema. O backend do sistema refere-se a tudo o que o utilizador não consegue ver no navegador,

como base de dados e regras de negócio. Algumas operações pelo qual o backend é responsável

são por exemplo armazenar ou fazer consultas na base de dados, cálculos, desempenho, segurança,

lógica etc. Isto acontece ”na parte de trás”, nos bastidores da aplicação sem o utilizador dar conta. Um

aplicação web apesar de poder parecer muito apelativa e bem desenhada na parte do cliente, se não

tiver um backend que seja robusto e funcione corretamente, pode vir a ser uma aplicação web sem

grande uso.

Apesar de não existir uma interação direta entre o utilizador e o backend, a aplicação está sempre

ligada ao backend visto que a sua intervenção pode ser precisa a qualquer momento, por exemplo para

oferecer algum funcionalidade especifica ou para fazer consultas à base de dados. O código backend

é executado no servidor, ao contrário ao lado do cliente que corre no browser, e inclui a maior parte

do código necessário para que a aplicação funcione. Podemos comparar uma aplicação Web com um

icebergue duma forma em que o utilizador vê apenas uma fração de toda a aplicação. Isto implica que

os programadores de backend, não só precisam compreender linguagens de programação e base de

dados, mas também devem ter uma compreensão da arquitetura do servidor. Se uma aplicação for

lenta ou constantemente lançar erros, é provável que seja devido a problemas de backend.

Uma vez que existe uma variedade de linguagens de programação e frameworks para o desenvol-

vimento de software para backend, os programadores devem conhecer as diferenças entre elas assim

como as vantagens e desvantagens para escolher corretamente a mais indicada. Normalmente é es-

colhida uma pilha de software durante o desenvolvimento uma aplicação web.

As pilhas de software sã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 programação do lado do servidor.

Existem muitas razõ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 programaçã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 são as seguintes: Existem

várias pilhas de software, porém normalmente as mais comuns são o LAMP e MEAN (que serão descri-

27

tas em maior detalhe a seguir). Porém há quase uma pilha de software para quase todas as linguagens

de programação.

• LAMP (Linux/Apache/MySQL/PHP) LAMP consiste em componentes de software de código

aberto gratuitos que funcionam bem para sites e aplicações web dinâmicos. É o modelo de

pilha mais tradicional, com algumas variações para diferentes sistemas operacionais, servidores

e opções de base de dados. Na pilha LAMP, o PHP é compatı́vel com as linguagens Python e Perl.

Benefı́cios do LAMP: flexı́vel, fácil de desenvolver, fácil de implantar, seguro e com uma enorme

comunidade de suporte, uma vez que é de código aberto.

O Facebook usa essa pilha de software.

• MEAN (MongoDB/Express.js/AngularJS/Node.js) O MEAN é uma opção viável para substituir

a pilha LAMP tradicional, e usa JS tanto para o lado do cliente como para o lado do servidor. É

uma boa escolha para as empresas que desejam ser ágeis e escaláveis, oferecendo flexibilidade

na base de dados com MongoDB que é baseada num documento, e muitos outras caracterı́sticas

que ajudam no desenvolvimento de aplicações Web de página única ou de várias páginas. Usar

JS tanto para o lado do cliente como para o lado do servidor pode trazer várias vantagens como

por exemplo, os programadores que trabalham no lado do cliente podem entender facilmente o

código do lado do servidor, o que levará a uma maior produtividade.

Benefı́cios do MEAN : JS para cliente e servidor, suporta o padrão MVC, usa JSON para trans-

ferência de dados, oferece acesso à biblioteca de módulos JS do Node.js e à estrutura Express.js,

é de código aberto.

• WISA (Windows/Internet Information Services/SQL Server/ASP.NET) Esta pilha permite a

utilização das poderosas ferramentas SQL Server e ASP.NET. C# é a linguagem de programação

do ASP.NET, que relativamente a questões de desempenho, pode ser considerada melhor do que

a dos três grandes P na pilha LAMP (Perl, PHP e Python), o SqlServer pode ser também consi-

derado melhor do que o sistemas de gestão de base de dados relacional (RDBMS) gratuitos.

A desvantagem da pilha WISA é que demasiado de sofisticado para tipos de projetos simples

que não necessite da robustez e dos recursos avançados da WISA. Normalmente este compo-

nentes de software não são gratuitos porque pode exigir licenças da Microsoft e també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”porém a fase de debug será

mais fácil. É comum a utilização da pilha WISA mais a nı́vel empresarial para desenvolver sites

28

complexos e robustos.

Seguidamente seguem-se algumas linguagens de programação e frameworks das mais populares para

o lado do servidor.

3.2.1 ASP.NET Core

ASP.NET Core 8 é uma nova framework de código aberto e multiplataforma para desenvolvimento de

aplicações modernas na nuvem, como aplicações web, aplicações IoT e servidores para mobile. As

aplicações do ASP.NET podem ser executados no .NET Core ou na framework .NET completa. É

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 aplicações. ASP.NET Core

suporta várias plataformas no Windows, Mac e Linux. O ASP.NET Core é de código aberto.

O ASP.NET foi lançado há mais de 15 anos e há uma larga comunidade que usa esta framework para

construção de aplicações web. O ASP.NET Core é uma nova versão redesenhada do antigo ASP.NET,

com mudanç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 único

modelo de programação.

ASP.NET Core já não é baseado em System.Web.dll, que costumava incluir todas as bibliotecas e

funções. É modular, o que significa que se pode adicionar e remover recursos conforme sejam ne-

cessários através do ”NuGet packages”. Este método traz uma grande vantagem de incluir apenas as

bibliotecas e funções necessárias à aplicação ao contrário do método antigo que incluı́a toda a fra-

mework no projeto aumentando a complexidade e tamanho. Os benefı́cios de uma aplicação menor

podem ser maior segurança, manutenção reduzida, melhoria no desempenho etc.

As principais vantagens do ASP.NET Core são as seguintes:

• Multiplataforma e código aberto: Pode correr em Windows, MacOS e Linux. Permitir que o

ASP.NET Core seja utilizado por mais pessoas e empresas, o que irá aumentar a sua comunidade

e enriquecer a framework.

• Supportada pela Microsoft: Como mencionado anteriormente, ser suportada por uma grande

empresa traz vários benefı́cios para a framework.

• É modular: É possı́vel adicionar e remover recursos conforme sejam necessários ao projeto

precisa, com ”NuGet packages”reduzindo a complexidade e sobrecarga da aplicação web onde

só 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 separação de preocupações o que oferece um

código mais organizado e de fácil manutenção entre com mais benefı́cios, como mencionado

anteriormente.

• Versatilidade: Uma das melhores coisas sobre C# e .NET é a sua versatilidade. Sendo possı́vel

desenvolver aplicações desktop, web, móveis, etc.


• ASP.NET Core ainda está numa fase recente: Poderá haver falhas na documentação, nomea-

damente quando se está a criar uma aplicação que siga o método MVC.

3.2.2 Node.js

Node.js 9 é uma plataforma construı́da sobre o motor V8 JS do Google Chrome para facilmente construir

aplicações de rede rápidas e escaláveis.

O Node.js usa um modelo de I/O de eventos não bloqueante que o torna leve e eficiente, indicado para

desenvolvimento de aplicações em tempo real várias trocas de mensagens entre vários dispositivos

distributivos. O ecossistema de pacotes Node.js, npm, é o maior ecossistema de bibliotecas de có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 aplicações

web se unisse em torno de uma única linguagem de programação, em vez ser preciso uma linguagem

diferente para o lado do servidor. O Node.js é código aberto e cross-platform.

Algumas das principais vantagens do Nodejs são as seguintes:

• Usa JavaScript: O JS é 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 có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 programaçã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

vários módulos de JS que simplifica o desenvolvimento de aplicativos da Web usando Node.js em

grande medida com base num gestor de pacotes só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 são assı́ncronas, isto é,

não bloqueantes. Significa essencialmente que o servidor não aguarda pela API retornar dados/-

resultados. O servidor passa para a próxima API, e posteriormente um mecanismo de notificação

de Eventos do Node.js ajuda o servidor a obter uma resposta da chamada da API anterior.

• Rápido e escalável: Node foi feito para ser rápido e escalável, sendo construı́do no mecanismo

de JS V8 do Google Chrome.

• Multiplataforma e Código aberto: Ser multi-plataforma e código aberto é sempre um benefı́cio

para a ferramenta, pois aumentará a comunidade e sua popularidade.


• Lidar com o base de dados relacionais pode ser complicado: O Nodejs é mais apropriado

para lidar com os base de dados nosql, no entanto, é possı́vel usar bases de dados racionais,

mas requer mais esforço e não é tão intuitivo.

• Não é adequado para aplicações com computação pesada: Node.js ainda não suporta programação

multi-threaded. É indicado para aplicações complexas, mas não é adequado para realizar cálculos

de longa duração. Os pedidos recebidos ficam à espera numa pilha e executados sequencial-

mente de maneira rápida. No entanto, cálculos pesados bloqueiam o ciclo do evento, o que pode

levar a uma diminuição do desempenho.

• ”Callback hell”: Callback hell é um código onde o uso de de funções callback se torna difı́cil de

seguir e perceber e de testar.

3.2.3 PHP

PHP 10, acrónimo de ”PHP: Hypertext Preprocessor”é uma linguagem de script de uso geral muito

utilizada que é especialmente adequada para desenvolvimento web e pode ser incorporada em HTML.

Sua sintaxe é baseada em C, Java e Perl, e é fácil de aprender. O objetivo principal da linguagem é

permitir que os programadores de Web criem páginas web rapidamente.

O PHP é largamente usado no lado do servidor, projetada para consultar e editar informações na

base de dados. É normalmente incluı́da em base de dados escritos em SQL. O PHP é único no sentido

em que foi construı́do para a web. Há algumas frameworks modernas que usam php como linguagem

de programação, como o conhecido Laravel.

PHP é usado pelo Facebook.

Algumas das vantagens do PHP são:10http://php.net/

31

http://php.net/

• Multiplataforma e Código aberto: Pode ser executado em várias plataformas, incluindo Win-

dows, Linux e Mac. Fácil para os utilizadores encontrarem serviços de hospedagem para os seus

sites. É de uso gratuito e é constantemente melhorada por um grande número de pessoas e não

por uma única empresa. Os programadores por trás do PHP criaram um extenso recurso on-line

de todas as funções da linguagem, incluindo exemplos de como usá-las, o que torna mais fácil

aprender e usar PHP.

• Curva de aprendizagem pequena e fácil de usar: Começar a programar com o PHP é relativa-

mente simples, bem como construir páginas web, o que era o objetivo inicial da linguagem.

• Popular com uma grande comunidade e amplamente utilizada: O PHP está em toda parte e é

usado na maioria das aplicações web. A maioria dos problemas de programação já tem soluções

feitas por outros utilizadores. Sendo um dos idiomas de script do lado do servidor mais populares

há també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 são:

• Baixa dificuldade para usar: Apesar da facilidade de aprendizagem e utilização possa ser um

beneficio, também pode criar problemas visto que há vários tutoriais ou ajudas online que não são

as mais corretas e podem levar iniciantes a desenvolver mau código.

• Normalmente não é adequado para aplicações extensas: Pode haver problemas com a es-

calabilidade com grandes aplicações com big data, o PHP é mais apropriado para aplicações

pequenas a médias. Quando se trata de aplicações com milhões de utilizadores e milhares de

páginas, dificulta a sua gestão por nã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 programação podem ainda ser mencionados neste âmbito para

o lado do servidor tais como: Python11; Ruby on Rails12.

3.3 Tecnologias para Geração de Código

Normalmente, a geração de código é um mecanismo para produzir código fonte (numa linguagem de

programaçã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: Comparação ASP.NET Core, NodeJS e PHP

Atributo ASP.NET Core Node.js PHPEmpresa/Criador Microsoft Ryan Dahl Rasmus LerdorfAno de lançamento 2002 2009 1995Ultima versão Nov 2016 Jun 2016 Dez 2016Tipo Web Framework JavaScript runtime Ling. de ProgramaçãoVel. desenvolvimento Média Média/Alta Alta

Performance Muito boaMuito boa(+ pedidos I/O,- proc. de CPU)

Boa

Curva de aprendizagem Alta Média BaixaComunidade Média Alta Muito alta

software em execução a partir de modelos), a geração de código também pode ser conhecida como

transformação M2T 13.

De seguida, serão apresentadas algumas das tecnologias mais populares para geração de código.

3.3.1 Acceleo

Acceleo 14 é um gerador de código aberto do Eclipse Foundation que permite usar uma abordagem

orientada por modelo para a construção de aplicações. O Acceleo é uma implementação pragmá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 código (Java, C#, PHP,

etc.) . No entanto, pode não ser a melhor solução para se obter uma estrutura e controlo durante a

geração de código.

3.3.2 Xtend

O Xtend [1] 15 é um dialeto flexı́vel e expressivo do Java, que compila para código fonte legı́vel e

compatı́vel com Java 5. Permite usar qualquer biblioteca Java existente. O resultado compilado é legı́vel

e bem indentado e tende a ser executado de uma maneira tão eficiente como o código equivalente em

Java.

Xtend é uma linguagem de propósito geral, tem uma sintaxe mais concisa do que Java e pode ser

vista como ”Java melhor”. O Xtend não é adaptado especificamente à geração de código, mas como

uma linguagem de propósito geral. No entanto, é possı́vel usá-la para geração de código, especialmente

para gerar código que requer que seja legı́vel e indentado graças a expressões de modelo de vá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 inglês, multi-line template expressions). O próprio Xtend é implementado no Xtext, que é

uma ótima vantagem para este projeto, uma vez que o RSL também é definido no Xtext, o que nos

permite escrever todas as partes de uma implementação de DSL, especialmente a parte de geração

de código no mesmo programa.

Ser produtivo e escrever código bem indentado com macros poderosas e muitos outros recursos de

linguagem moderna é a principal vantagem desta linguagem idioma. Sintaticamente e semanticamente,

a Xtend tem raı́zes na linguagem de programação Java, mas melhora em muitos aspetos, tais como:

inferência de tipo; expressões Lambda; expressões template; métodos de extensão.

3.4 Tecnologias utilizadas

O objectivo principal do RSL2WebApp é gerar um código-fonte para aplicação web com base em requi-

sitos do sistema definidos com a linguagem RSL.

Para isso, várias tecnologias/frameworks foram estudadas nesta dissertação, onde se racionalizou

sobre as vantagens e desvantagens de cada uma. No contexto de engenheira informática, a escolha

das tecnologias/frameworks deverá levar em consideração muitos factores (por exemplo, competências

e experiência de equipa, contexto e requisitos do projecto, objectivos, etc.), pois o sucesso do desen-

volvimento de software é influenciado por esta escolha. Existem tecnologias que são melhores para

algumas coisas mas que são piores para outra, não existe uma que resolva todos os problemas e seja

perfeita, e cabe aos engenheiros reflectir e escolher o que é mais apropriado para um determinado pro-

jecto. As tecnologias escolhidas para esta dissertação foram baseadas em algumas vantagens tendo

em consideração o objectivo principal e o contexto deste projecto.

3.4.1 RSL

RSL é o ponto de partida para o processo de geração de código, uma vez que é exigido uma especificação

de requisitos consistente e rigorosa que a aplicação web deve seguir. O RSL, como discutido antes,

apresenta muitos benefı́cios em relação ao SRS. Para além disto, é essencial para este projecto porque

usa uma CNL com palavras-chave e padrões linguı́sticos bem definidos para escrever os requisitos, evi-

tando o problema de uma NL onde há várias maneiras diferentes de especificar o mesmo sistema, o que

torna uma especificação mais ambı́gua e menos consistente. Com isto, a produção de uma aplicação

web baseada em especificações de sistema fica mais simples, isto porque o RSL2WebApp precisa de

saber que código gerar a partir das especificações e era uma tarefa muito mais difı́cil usando uma NL.

Para este projecto, o foco será apenas nos seguintes elementos para a especificação de requisitos:

Actor, DataEntity e DataEntityClustere UseCase. A figura 3.1 mostra os elementos que serão usados

34

para este projecto. A área azul engloba todas os elementos usados para a especificação de requisitos,

a área azul claro, que é a área StateMachine, representa um trabalho avançado que não será utilizada

nesta dissertação. No entanto, a área azul no geral, representa as construções que estão incluı́das

para a geração de código para a aplicação web, que dependerá do que for especificado em cada uma

das construções, que será explicado mais à frente no relatório.

Figura 3.1: Elementos utilizados para especificação RSL neste projecto, adaptado de [3]..

Foram escolhidos estes elementos para a especificação do sistema em RSL porque é neles que se

consegue representar duma melhor forma as funcionalidades da aplicação web desejada. Por exemplo,

tecnicas avançadas de modelaç´ ao e produç˜ ao˜ semi … · tecnicas avançadas de...

Documents