On-line prognosis of sound Insulation laid out in EN-12354

(1)

Por

Jean Tharles Patrique Paiva

Orientador: Salviano Filipe Silva Pinto Soares

Co-orientador: Jorge Tiago Queir´os da Silva Pinto

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no DR – I s´erie– No

151, Decreto-Lei n.o

115/2013 de 7 de Agosto e no Regulamento de Estudos Conducente ao Grau de Mestre da UTAD

DR, 2.a

s´erie – No

(2)

(3)

Por

Jean Tharles Patrique Paiva

Orientador: Salviano Filipe Silva Pinto Soares

Co-orientador: Jorge Tiago Queir´os da Silva Pinto

Disserta¸c˜ao submetida `a

UNIVERSIDADE DE TR ´AS-OS-MONTES E ALTO DOURO para obten¸c˜ao do grau de

MESTRE

em Engenharia Electrot´ecnica e de Computadores, de acordo com o disposto no DR – I s´erie– No_{151, Decreto-Lei n.}o _{115/2013 de 7 de Agosto e no}

Regulamento de Estudos Conducente ao Grau de Mestre da UTAD DR, 2.a

s´erie – No

(4)

(5)

Salviano Filipe Silva Pinto Soares

Professor Auxiliar do Departamento de Engenharias

Universidade de Tr´as-os-Montes e Alto Douro

Jorge Tiago Queir´os da Silva Pinto

Professor Auxiliar do

Departamento de Engenharia Electrot´ecnica Universidade de Tr´as-os-Montes e Alto Douro

Acompanhamento do trabalho :

Lu´ıs Novo Pereira

MSc Engenharia Civil do Departamento de Civil

(6)

(7)

Os membros do Júri recomendam à Universidade de Trás-os-Montes e Alto Douro a aceita¸cão da disserta¸cão intitulada “On-line Prognosis of sound Insulation laid out in EN-12354” realizada por Jean Tharles Patrique Paiva para satisfa¸cão parcial dos requisitos do grau de Mestre.

Mar¸co 2019

Presidente: Jo˜ao Agostinho Batista de Lacerda Pav˜ao,

Professor Auxiliar da Escola de Ciˆencias e Tecnologia da Universidade de Tr´as-os-Montes e Alto Douro

Vogais do J´uri: Filipe dos Santos Neves,

Professor Adjunto da Escola Superior de Tecnologia e Gest˜ao do Instituto Polit´ecnico de Leiria

Salviano Filipe Silva Pinto Soares,

Professor Auxiliar do Departamento de Engenharias da Universidade de Tr´as-os-Montes e Alto Douro

(8)

(9)

Jean Tharles Patrique Paiva

Submetido na Universidade de Tr´as-os-Montes e Alto Douro para o preenchimento dos requisitos parciais para obten¸c˜ao do grau de

Mestre em Engenharia Electrot´ecnica e de Computadores

Resumo — A norma EN 12354:2000 define um método numérico detalhado baseado no desempenho de elementos de constru¸cão, permitindo estimar com precisão o desempenho acústico entre dois compartimentos. No entanto, projetar o isolamento acústico de edif´ıcios com dimensões consideráveis utilizando este método é muitas vezes uma tarefa dif´ıcil sem recurso à auxiliares tecnológicos. Seguindo este método, propomos uma aplica¸cão WEB, Sound Insulation Software (SIS), que permite projetar e simular o desempenho acústico automatizado e integrado de edif´ıcios.

Palavras Chave: Isolamento sonoro, EN-12354, Ac´ustica de Edif´ıcios, Arquitectura cliente/servidor e MVC

(10)

(11)

Jean Tharles Patrique Paiva

Submitted to the University of Tr´as-os-Montes and Alto Douro in partial fulfillment of the requirements for the degree of Master of Science in Electrical Engineering and Computers

Abstract —

The EN 12354 standard defines a detailed numerical method based on the performance of construction elements, allowing estimating accurately the acoustic performance between two compartments. However, designing the sound insulation of buildings with considerable dimensions using this method is often a difficult task that requires time to calculate. Following this method, we propose a WEB application that allows you to design automated and integrated acoustic performance of buildings.

Key Words: : Sound Insulation, EN-12354, Building Acoustic, slient/server Architecture e MVC

(12)

(13)

Os meus agradecimentos à todos que me ajudaram na conclusão desta etapa da vida. Em especial para o Professor Salviano Soares, Lu´ıs Pereira, José Barreiro, António Pereira, Jorge Gon¸calves, Stefan Vidal e Patrick Vidal.

Aos meus pais que sempre me apoiaram acima de tudo, parentes e namorada. A todos, obrigado.

UTAD/IPL, Jean Tharles Patrique Paiva

Vila Real, 24 de Setembro de 2018

(14)

(15)

Resumo ix

Abstract xi

Agradecimentos xiii

´Indice de tabelas xix

´Indice de figuras xxi

Gloss´ario, acr´onimos e abreviaturas xxv

1 Introdu¸c˜ao 1

1.1 Motiva¸c˜ao e objetivos . . . 2

1.2 Organiza¸c˜ao da disserta¸c˜ao. . . 3

2 As normas EN 12354:2000 5 2.1 Modelo de c´alculo . . . 6

3 Enquadramento te´orico das tecnologias utilizadas 11 3.1 Enquadramento Te´orico - Back-end . . . 12

3.1.1 Hypertext Transfer Protocol (HTTP) . . . 13

3.1.2 Web Services . . . 17

3.1.3 REpresentational State Transfer (REST) . . . 19

3.1.4 JavaScript Object Notation . . . 21 xv

(16)

3.2 Enquadramento Te´orico - Front-end . . . 32

3.2.1 Hypertext Markup Language (HTML) . . . 32

3.2.2 Cascading Style Sheets (CSS) . . . 33

3.2.3 Bootstrap . . . 34

3.2.4 Javascript - EMACScript . . . 35

3.2.5 AngularJS . . . 41

3.2.6 Tecnologias para ambiente 3D na WEB . . . 42

3.3 Algoritmos para reconhecimento de ciclos em grafos . . . 43

4 Conce¸c˜ao 47 4.1 Arquitectura da Aplica¸c˜ao . . . 47

4.2 Levantamento de Requisitos . . . 48

4.2.1 Requisitos Funcionais . . . 49

4.2.2 Requisitos n˜ao Funcionais . . . 50

4.3 Diagrama Entidades e Relacional . . . 52

4.4 Casos de Uso . . . 54

4.5 Modelo de Dados Complementar . . . 55

4.6 Diagrama de Classes . . . 57

5 Implementa¸c˜ao do Prot´otipo SIS 65 5.1 Tecnologias e Ferramentas Utilizadas . . . 65

5.2 Backend . . . 68 5.2.1 Autentica¸cão . . . 69 5.2.2 Autoriza¸cão . . . 70 5.2.3 Recursos . . . 71 5.3 Interface do Utilizador . . . 73 5.3.1 Barra de navega¸cão . . . 74 5.3.2 Home . . . 74 5.3.3 New Project . . . 75 5.3.4 My Projects . . . 77

5.3.5 My Materials - Insert New Materials . . . 79

5.3.6 My Materials - List All Materials . . . 82

5.3.7 My Materials - Edit/Remove Materials . . . 85

5.4 Caracter´ısticas 2D . . . 87

5.4.1 Renderiza¸c˜ao do cen´ario . . . 87

5.4.2 Desenho de uma linha . . . 92

5.4.3 Valida¸c˜ao de pol´ıgonos . . . 96 xvi

(17)

5.5.3 Fluxo de Dados . . . 109 5.5.4 Juntas El´asticas . . . 110 5.6 Reconhecimento de Sistemas . . . 112 5.6.1 Sistema Base . . . 113 5.6.2 Sistema Particular 1 . . . 114 5.6.3 Sistema Particular 2 . . . 115 5.7 Processo de C´alculo . . . 116

5.8 Cria¸c˜ao da Interface de Resultados . . . 118

6 Resultados e Discuss˜ao 123 6.1 Caso de Teste 1 . . . 123

6.2 Caso de Teste 2 . . . 126

6.3 Precis˜ao e Vis˜ao geral dos Resultados . . . 128

6.4 Geometrias irregulares suportadas . . . 128

7 Conclus˜ao e Trabalho Futuro 131 7.1 Conclus˜ao . . . 131

7.2 Trabalho Futuro. . . 132

Referˆencias bibliogr´aficas 133

(18)

(19)

4.1 Caracter´ısticas dos elementos. . . 59

5.1 (1) Nota da Figura 5.8. . . 84

5.2 (2) Funcionalidades ligadas aos eventos . . . 91

6.1 Vis˜ao geral dos resultados. . . 128

(20)

(21)

2.1 Caminhos de transmiss˜ao sonora (geometria regular) . . . 6

2.2 Processo para inicializar o cen´ario. . . 10

3.1 Sistema de trˆes camadas. . . 12

3.2 Comunica¸c˜ao entre cliente e servidor com o protocolo HTTP [1] . . . 14

3.3 Estrutura de uma mensagem HTTP. . . 15

3.4 Request Line [2]. . . 15

3.5 Status Line. . . 16

3.6 Exemplo de alguns status code e respectivas reason-phrases. . . 16

3.7 Web services atores e stack. . . 19

3.8 JSON exemplo de dados [3]. . . 22

3.9 JWT exemplo [4]. . . 23

3.10 JWT header [4].. . . 24

3.11 JWT playload [4]. . . 24

3.12 JWT signature [4]. . . 25

3.13 Java EE multicamada. . . 27

3.14 Servlet, esquema simplificado do seu funcionamento. . . 28

3.15 C´odigo Java em uma p´agina HTML (JSP), linha 15.. . . 29 xxi

(22)

3.17 Exemplo de uma p´agina HTML e c´odigo relativo [59]. . . 32

3.18 Canvas exemplo com manipula¸c˜ao Javascript [6].. . . 33

3.19 CSS e HTML exemplo [58]. . . 34

3.20 Sum´ario de como o Bootstrap funciona em m´ultiplas plataformas [57]. 35

3.21 CSS e HTML exemplo [58]. . . 35 3.22 Javascript documentos no HTML. . . 37 3.23 Javascript e DOM. . . 38 3.24 Javascript listener. . . 38 3.25 Javascript scope. . . 39 3.26 Javascript closures. . . 40 3.27 AngularJS exemplo. . . 42

3.28 Grafo sem direc¸c˜ao. Fonte: [7] . . . 44

3.29 Ciclo, denotado a vermelho. Fonte: [8] . . . 45

4.1 Arquitectuira MVC [9]. . . 49

4.2 Diagrama ER . . . 54

4.3 Diagrama de Casos de Uso. . . 56

4.4 Modelo Complementar dos dados presente na View. . . 58

4.5 Diagrama Classes parte 1, proveniente da DB. . . 60

4.6 Diagrama Classes parte 2. . . 61

4.7 Diagrama Classes parte 3. . . 63

5.1 Interface phpMyAdmin . . . 67

5.2 Diagrama de funcionamento da autentica¸c˜ao de utilizadores. . . 69

5.3 Diagrama de funcionamento da autoriza¸c˜ao de utilizadores. . . 70

5.4 Cria¸c˜ao de novos projetos. . . 76

5.5 Listagem de projectos. . . 78

5.6 Inser¸c˜ao de novos materiais. . . 81

5.7 Listagem de materiais. . . 83

5.8 Diagrama de funcionamento da p´agina de listagem de materiais. . . . 85 xxii

(23)

de todos os eventos associados na inicializa¸c˜ao. . . 88

5.11 Ilusta¸c˜ao do cen´ario 2D. . . 90

5.12 Processo de desenho de uma linha. . . 93

5.13 Compara¸c˜ao entre manter as linhas anteriores e n˜ao no estado 1. . . . 95

5.14 Processo de verifica¸c˜ao de novos poligonos. . . 97

5.15 Processo para inicializar o cen´ario. . . 99

5.16 Diferen¸c˜ao de reprodu¸c˜ao de imagem entre os renderizadores. . . 101

5.17 Exemplo da triangula¸c˜ao de um elemento horizontal. . . 103

5.18 Exemplo da triangula¸c˜ao de um elemento vertical. . . 104

5.19 Mapa de v´ertices de um elemento vertical com porta. . . 105

5.20 Mapa de v´ertices de um elemento vertical com janela. . . 106

5.21 Mapa de v´ertices de um elemento vertical com porta e janela. . . 107

5.22 M´odulos da interface de um elemento.. . . 109

5.23 Interface para atribui¸c˜ao de juntas el´asticas. . . 111

5.24 Sistema base. . . 114

5.25 Sistema particular 1. . . 115

5.26 Sistema particular 2. . . 116

5.27 Camadas da interface de resultados. . . 119

5.28 Exemplo da intera¸c˜ao do utilizador com a primeira camada. . . 120

5.29 Exemplo da intera¸c˜ao do utilizador com quarta camada. . . 121

6.1 Caso de Teste 1.. . . 124

6.2 Resultados Caso de Teste 1. . . 125

6.3 Caso de Teste 2.. . . 126

6.4 Resultados Caso de Teste 2. . . 127

6.5 Geometria 1 . . . 129

6.6 Geometria 2 . . . 130

(24)

(25)

abreviaturas

Lista de acr´

onimos

Sigla Expans˜ao

API Application Programming Interface

CSS Cascading Style Sheets

DAO Data Access Object

DFS Deepth Search First

DOM Document Object Model

EIS Enterprise Information System

ER Entidade e Relacionamento

HATEOAS Hypermedia As The Engine Of Application State HMAC Hash-based Message Authentication Code

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

JEE Java Enterprise Edition

JSE Java Standard Edition

JSON JavaScript Object Notation

(26)

JVM Java Virtual Machine

JWT JSON Web Token

MIME Multipurpose Internet Mail Extensions

MVC Model View Controller

OOP Object-Oriented Programming

OSI Open System Interconnection

POM Project Object Model

REST REpresentational State Transfer

RF Requisitos Funcionais

RNF Requisitos N˜ao Funcionais

RSA Rivest-Shamir-Adleman

SEA Statistical Energy Analysis

SIS Sound Insulation Software

SOAP Simple Object Access Protocol

SQL Structured Query Language

TCP-IP Transmission Control Protocol/Internet Protocol UDDI Universal Description, Discovery and Integration

UI User Interface

URI Uniform Resource Identifier

XML eXtensible Markup Language

WebGL Web Graphics Library

WSDL Web Services Description Language

WWW World Wide Web

(27)

Abreviatura Significado(s)

e.g. por exemplo

et al. e outros (autores)

etc. etecetera, outros

i.e. isto ´e, por conseguinte

vid. veja-se, ver

vs. versus, por compara¸c˜ao com

(28)

1

Introdu¸c˜

ao

A maioria dos pa´ıses da União Europeria (UE) têm legisla¸cão própria no que se refere aos requisitos m´ınimos de isolamento acústico dos edif´ıcios. Nas últimas duas décadas, alguns destes identificaram também a necessidade da cria¸cão e desenvolvimento cont´ınuo de um modelo de classifica¸cão acústica com classes correspondentes a diferentes n´ıveis de conforto. Ademais, a acústica de edif´ıcios tem de uma forma geral registado uma crescente importância a n´ıvel global sendo notáveis os esfor¸cos da comunidade cient´ıfica para se obter uma harmoniza¸cão dos descritores e da classifica¸cão acústica de edif´ıcios. O exemplo mais óbvio é o da norma ISO 19488, que está presentemente em desenvolvimento e cujo objectivo principal é especificar critérios de desempenho acústico para um modelo de classifica¸cão.

Em Portugal, o Regulamento dos Requisitos Acústicos dos Edif´ıcios (RRAE) que regula a vertente do conforto acústico no âmbito do regime da edifica¸cão, estabelece apenas valores m´ınimos de isolamento e no presente não existem modelos de classifica¸cão. Contudo, considera-se provável que estes venham a ser postos em prática no contexto Nacional ou Europeu.

Os métodos padronizados mais precisos para efectuar estimativas de isolamento acústico são aqueles especificados na série de normas EN 12354:2000. Estes têm

(29)

como base uma aproxima¸cão de primeira ordem do modelo matemático SEA (Statistical Energy Analysis) que é de substancial complexidade, pois requer uma análise das caracter´ısticas f´ısicas dos elementos construtivos ”envolvidos”na transmissão sonora e da forma como estes se conectam. Estas previsões tornam-se ainda mais complexas quando os espa¸cos em questão apresentam geometrias irregulares e quando os elementos construtivos usados são heterogéneos (i.e. elementos pesados e elementos leves). Assim, uma das práticas comuns entre os profissionais da acústica é considerar apenas os casos mais desfavoráveis, com a finalidade de garantir o cumprimento dos requisitos m´ınimos em questão.

´

E evidente que no caso de ser necessário avaliar um edif´ıcio de acordo com um modelo de classifica¸cão, dependendo dos critérios acústicos em prática, a quantidade de cálculos a efectuar aumenta significativamente e em alguns casos poderá ser mesmo necessário calcular a transmissão acústica entre todos os espa¸cos. Assim, o uso de um software com vista a automatizar parcialmente este processo seria de extrema utilidade não só por permitir identificar situa¸cões de risco como também determinar o desempenho acústico de um edif´ıcio completo, facilitando assim a sua classifica¸cão final em termos de n´ıveis de conforto acústico.

1.1 Motiva¸c˜

ao e objetivos

Os motivos principais para a realiza¸c˜ao desta disserta¸c˜ao foram:

• A identifica¸c˜ao de um problema para projetar o isolamento ac´ustico de edif´ıcios, como uma necessidade no seu trabalho no Reino Unido onde se utiliza normas com requisitos muito apertados identificado por Lu´ıs.

• A rápida expansão de modelos de classifica¸cão acústica ao n´ıvel dos pa´ıses da união europeia;

• A complexidade dos modelos de previs˜ao de isolamento existentes.

(30)

O principal objectivo consistiu em desenvolver uma aplica¸cão WEB, intitulada SIS (Sound Insulation Software), que permita o utilizador levar a cabo cálculos de isolamento acústicos a sons aéreos entre espa¸cos de acordo com o método detalhado especificado na norma EN 12354-1:2000.

1.2 Organiza¸c˜

ao da disserta¸c˜

ao

Esta disserta¸cão está subdividida em sensivelmente 5 partes. Das quais, a primeira é referente aos dois primeiros cap´ıtulos onde é introduzida toda a parte teórica por trás da aplica¸cão a desenvolver. Na segunda parte é demonstrada todo o aspecto lógico da concep¸cão de uma aplica¸cão. Esta parte refere-se ao quarto cap´ıtulo. Seguidamente, todo o processo lógico do cap´ıtulo anterior é desenvolvido no segmento a seguir que trata de explicar os aspectos mais importantes do desenvolvimento. De seguida, é exposto os resultados da implementa¸cão realizada e são evidenciados alguns casos reais. Por fim, a conclusão desta disserta¸cão e todos os aspectos a melhorar.

(31)

(32)

2

As normas EN-12354:2000

O desenvolvimento dos modelos de previsão acústica inclu´ıdos nas normas EN 12354 tiveram inicio há cerca de trinta anos e foram criados com o intuito de relacionar o desempenho acústico dos vários produtos e elementos com o desempenho de edifica¸cões e constru¸cões espec´ıficas.

A cria¸cão das normas surge de uma necessidade, ao n´ıvel Europeu, de estabelecer métodos de previsão por forma a minimizar os gastos substanciais que até a data a industria da constru¸cão necessitava sistematicamente para se adaptar a novos métodos e tecnologias.

As normas abrangem as seguintes disciplinas: isolamento a sons aéreos entre quartos, isolamento a sons de percussão (impacto) entre quartos, isolamento de fachada, transmissão de ru´ıdo para o ambiente, ru´ıdo de equipamentos e reverbera¸cão em espa¸cos fechados [48].

(33)

2.1 Modelo de c´

alculo

A norma EN 12354-1 estabelece um modelo de cálculo para a previsão do isolamento a sons aéreos entre quartos.

A transmissão total divide-se em múltiplas transmissões que ocorrem através de diferentes caminhos com uma determinada potência sonora (Figura 2.1). Esta abordagem é essencialmente equivalente a um modelo de transmissão SEA (Statistical Energy Analysis), mas utiliza quantidades f´ısicas conhecidas, como por exemplo o ´ındice de redu¸cão sonora (R) de todos os elementos envolvidos numa determinada transmissão, que pode ser determinado em laboratório de acordo com a norma ISO 10140-2:2010 [48].

Figura 2.1 – Caminhos de transmiss˜ao sonora (geometria regular)

Com base no método de cálculo detalhado da norma e na Figura2.1, a metodologia adoptada para determinar o isolamento acústico a sons aéreos entre dois quatros é a seguinte:

1. Cálculo e/ou teste laboratorial das seguintes quantidades acústicas: (a) ´ındice de redu¸cão sonora do elemento de separa¸cão: Rs;

(34)

(b) ´ındice de redu¸c˜ao sonora de cada elemento marginal no compartimento emissor: Ri;

(c) ´ındice de redu¸c˜ao sonora de cada elemento marginal no compartimento receptor: Rj;

(d) acréscimo de isolamento sonoro, por introdu¸cão de um revestimento adicional, colocado no elemento de separa¸cão no lado do espa¸co emissor e/ou espa¸co receptor: ∆RD, ∆Rd;

(e) acr´escimo de isolamento sonoro, por introdu¸c˜ao de um revestimento adicional, colocado no elemento marginal no lado do espa¸co emissor e/ou espa¸co receptor: ∆Ri, ∆Rj;

(f) tempo de reverbera¸cão estrutural em laboratório de cada elemento, Ts,lab; (g) ´ındice de redu¸cão de transmissão de vibra¸cões para cada caminho, Ki,j; (h) área do elemento separador Ss;

(i) área de cada elemento marginal no compartimento emissor: Si; (j) área de cada elemento marginal no compartimento receptor: Sj (k) comprimento da linha de jun¸cão entre cada elemento: lij

2. Transferência dos dados de laboratório para valores nas condi¸cões de aplica¸cão para cada elemento, acréscimo de isolamento e juntas de acordo com os seguintes princ´ıpios: Rsitu = R − 10 lg Ts,situ Ts,lab dB (2.1) onde:

Rsitu ´e o ´ındice de redu¸c˜ao de som de um elemento in situ;

Ts,situ é o tempo de reverbera¸cão estrutural do elemento nas actuais condi¸cões

de aplica¸c˜ao, em segundos;

Ts,lab é o tempo de reverbera¸cão estrutural do elemento em laboratório, em

(35)

∆Rsitu = ∆RdB (2.2)

onde:

∆Rsitu acréscimo de isolamento sonoro, por introdu¸cão de um revestimento adicional nas actuais condi¸cões de aplica¸cão;

∆R acréscimo de isolamento sonoro, por introdu¸cão de um revestimento adicional medido em laboratório. Dv,ij,situ = Kij − 10 lg lij √_a i,situaj,situ dB; Dv,ij,situ≥ 0dB (2.3) ai,situ = 2.2π2_S i C0Ts,i,situ . s fref f aj,situ= 2.2π2_S j C0Ts,j,situ . s fref f (2.4) onde:

Dv,ij,situ diferen¸ca de n´ıvel de velocidade de jun¸c˜ao entre o elemento excitado i e

o elemento receptor j;

Kij ´ındice de redu¸cão de vibra¸cão para cada caminho de transmissão ij numa junta;

ai,situ é o comprimento de absor¸cão equivalente do elemento i nas actuais condi¸cões

de aplica¸c˜ao, em metros;

aj,situ é o comprimento de absor¸cão equivalente do elemento j nas actuais condi¸cões

de aplica¸c˜ao, em metros;

f é a frequência central da banda em considera¸cão, em Hertz; fref é a frequência de referência, fref = 1000 Hz;

(36)

lij é o comprimento da jun¸cão entre os elementos i e j, em metros; Si é a área do elemento i, em metros quadrados;

Sj ´e a ´area do elemento j, em metros quadrados;

Ts,i,situ é o tempo de reverbera¸cão estrutural do elemento i, nas actuais condi¸cões

de aplica¸c˜ao;

Ts,j,situ é o tempo de reverbera¸cão estrutural do elemento j, nas actuais condi¸cões

de aplica¸c˜ao;

3. Determina¸cão da transmissão directa e marginal nas actuais condi¸cões de aplica¸cão de acordo com os seguintes princ´ıpios:

RDd = Rs,situ+ ∆RD,situ+ ∆Rd,situdB (2.5)

Ri,j = Ri,situ 2 + ∆Ri,situ+ Rj,situ 2 + ∆Rj,situ+ Dv,ij,situ+ 10lg Ss pSiSj dB (2.6) onde:

∆R melhoria do ´ındice de redu¸c˜ao de som ao adicionar camadas;

A norma inclui equa¸cões matemáticas para cálculo dos ´ındice de redu¸cão de transmissão de vibra¸cões para cada caminho em fun¸cão do tipo de elementos em causa.

A figura2.2ilustra um exemplo da informa¸cão que é disponibilizada para determinar o ´ındice de redu¸cão de transmissão de vibra¸cões (Kij) entre dois elementos, para um caminho espec´ıfico.

(37)

(38)

3

tecnologias utilizadas

Uma aplica¸cão Web esta sub-divida em três partes: a visualiza¸cão que o utilizador tem da aplica¸cão, a lógica associada e os seus dados. Do ponto de vista da implementa¸cão, atualmente são usados os termos back-end (ou back-office) e front-end para distinguir os processos de concep¸cão do servidor (lógica e dados) da interface do utilizador. Estes termos também são utilizados para assinalar o responsável pela concep¸cão destas partes, ou seja, o desenvolvedor back-end é o responsável por implementar a lógica da aplica¸cão e o acesso aos dados. Da mesma forma, o desenvolvedor front-end é responsável por implementar a interface gráfica da aplica¸cão e uma por¸cão lógica associada no lado do cliente.

Para estabelecer, de forma bem definida, todas as intera¸cões entre utilizadores e o servidor é necessário introduzir a arquitetura da aplica¸cão Figura 3.1. Nesta disserta¸cão foi abordada uma arquitetura de 3 camadas, das quais temos:

• Apresenta¸cão: interface do utilizador, todas as funcionalidades de uma aplica¸cão Web são apresentadas nesta;

• Lógica ou Business tier: esta controla todas as funcionalidades apresentadas na camada de Apresenta¸cão. Também controla o acesso aos dados e verifica a

(39)

permiss˜ao de utilizadores;

• Dados: base de dados, toda a forma de aloca¸c˜ao de dados.

Figura 3.1 – Sistema de trˆes camadas.

Nas próximas seçcões serão introduzidas todas as tecnologias associadas ao desenvolvimento de uma aplica¸cão Web que, como já foi referido anteriormente, pode ser dividida em termos de implementa¸cão, back-end e front-end.

3.1 Enquadramento Te´

orico - Back-end

O back-end é todo processo realizado por parte do servidor. Estes processos podem ser manipulados de várias formas, bem como através de inúmeras tecnologias e protocolos. Nesta subseçcão, serão descritas algumas tecnologias e protocolos subjacentes ao desenvolvimento do back-end.

Numa primeira fase, será discutido o meio de comunica¸cão entre duas partes (utilizadores e servidores) que, atualmente é maioritariamente composto pelo protocolo HTTP.

(40)

De seguida, serão expostos as tecnologias que atuam entre a interface do utilizador e a lógica da aplica¸cão, também chamadas de Web services e REST. Por fim, serão apresentadas as tecnologias referentes à lógica da aplica¸cão e dos dados.

3.1.1 Hypertext Transfer Protocol (HTTP)

HTTP é o protocolo ”standard”para comunica¸cão entre clientes e servidores que surgiu da necessidade de enviar informa¸cões através da Internet de forma a que todos os computadores fossem capazes de perceber. Este protocolo de comunica¸cão opera ao n´ıvel da aplica¸cão do modelo Open Systems Organization Interconnection (OSI ) utilizado para sistemas de informa¸cão distribu´ıdos, como por exemplo, a World Wide Web (WWW ) [31]. Este também implementa a arquitetura do modelo cliente/servidor (protocolo do tipo request-reply), utiliza como protocolo de transporte o Transmission Control Protocol /Internet Protocol (TCP-IP), caracterizando-se como [55]:

• connectionless: Após um cliente efetuar um pedido ao servidor, este irá desconectar-se enquanto aguarda por uma resposta, sendo da responsabilidade do servidor processar o pedido e re-estabelecer a conexão para o envio da respetiva resposta.

• independent: suporta a comunica¸c˜ao de qualquer tipo de dados.

• stataless: não guarda informa¸cões relativas aos pedidos já processados.

Figura 3.2 evidencia ilustrativamente o funcionamento do protocolo HTTP. No entanto, é necessário notar que na ilustra¸cão o cliente possa ser um servidor a comunicar com outro servidor.

(41)

Figura 3.2 – Comunica¸c˜ao entre cliente e servidor com o protocolo HTTP [1]

. Mensagens HTTP

Todas as as mensagens HTTP seguem o standard especificado pela RFC 2616. Estas podem ser de pedido ou de reposta entre duas partes. A ilustra¸c˜ao da figura 3.3

enumera todos os campos de uma mensagem HTTP, dos quais pode-se definir por [31, 25]:

(42)

Figura 3.3 – Estrutura de uma mensagem HTTP.

• Request line identifica o tipo de mensagem e o destinat´ario, constitu´ıda pelos seguintes elementos (Figura 3.4):

Figura 3.4 – Request Line [2].

– Request Method: indica o tipo de pedido a realizar no destinat´ario, podendo ser do tipo:

∗ GET: utilizado para leitura de dados;

∗ HEAD: ´e pedida uma resposta idˆentica a uma reposta com o pedido GET mas sem Entity Body;

(43)

∗ PUT: utilizado para modificar todos os dados do recurso acedido no destinat´ario;

∗ DELETE: apagar dados;

∗ OPTIONS: permite descrever as op¸c˜oes de comunica¸c˜ao entre as duas partes;

∗ PATCH: ´e utilizado para aplicar uma modifica¸c˜ao parcial ao dados do caminho especificado (URI);

– Uniform Resource Identifier (URI): localiza¸c˜ao do recurso; – HTTP version: vers˜ao do protocolo HTTP.

• Status line informa¸c˜ao do estado da resposta, constitu´ıdo pelos seguintes elementos (Figura 3.5):

Figura 3.5 – Status Line.

1. Status Code: ´e um valor constitu´ıdo por 3 d´ıgitos, onde o primeiro digito representa a classe da resposta (Figura3.6), e os outros diferenciam tipos de resposta associado a sua classe.

2. Reason-Phrase: informa¸c˜ao relativa ao status code.

(44)

• General Header: campos aplic´aveis a todas as resposta e pedidos; • Request Header: cabe¸calhos destinados aos pedidos realizados; • Response Header: cabe¸calhos relacionados as respostas;

• Entity Header: campos que definem as caracter´ısticas dos dados a serem transmitidos no Entity Body;

• Entity body: separado por um espa¸co do elementos anteriores, compõe muitas vezes os dados de uma mensagem HTTP. Também caracterizado por ser uma página em aplica¸cões Web.

3.1.2 Web services

Web service é um fragmento de software disponibilizado na internet que possibilita a comunica¸cão entre diferentes plataformas, por exemplo: um sistema programado em Java consegue comunicar com um outro sistema em PHP através de Web services. Esta interoperabilidade é conseguida através da utiliza¸cão de protocolos abertos e normas bem definidas para a troca de informa¸cões entre aplica¸cões.

Os Web services s˜ao compostos por SOAP (Simple Object Access Protocol), UDDI (Universal Description, Discovery and Integration), WSDL (Web Services Description Language) e XML + HTTP.

Existem duas formas de descrever a arquitetura de um Web service. A primeira é examinar os papéis de todos atores do web service. A segunda, é descrever a stack de protocolos contidos neste [41, 19].

Web Service Roles

Os atores de um Web services s˜ao (Figura 3.7):

(45)

• Service requestor: quem consome o servi¸co disponibilizado. Este, conecta-se e envia um pedido em XML (padrão de dados utilizado em Web services); • Service registry: diretório central de servi¸cos. Este contém todos os servi¸cos

publicados.

Web Service Protocol Stack

Sucintamente cada camada da stack de protocolos do Web services podem ser descritas como (Figura3.7):

• Service transport: respons´avel por transportar mensagens entre o Service provider e Service requestor. O protocolo mais utilizado para tal, ´e o HTTP mas podem ser utilizados outros como: FTP, SMTP etc;

• XML messaging: codifica as mensagem em formato XML para que sejam percept´ıveis entre as duas partes (SOAP e XML-RPC);

• Service description: responsável por descrever a interface pública de um Web service. Isto é realizado através da configura¸cão do WSDL (ficheiro XML); • Service discovery: responsável por centralizar todos os servi¸cos num registo

comum e fornecer uma forma fácil de publicar/encontrar servi¸cos. Isto é realizado através do ficheiro UDDI.

(46)

Figura 3.7 – Web services atores e stack.

3.1.3 REpresentational State Transfer (REST)

Criado por Roy Fieelding em 2000 na sua tese de doutoramento com o proposito de lidar com o problema de escalabilidade da web. REST é conhecido por ser um estilo de arquitetura, também chamado de Web’s architectural style por estar definido por seis restri¸cões [43, 49, 34, 32]: 1. Client-Server; 2. Uniform Interface; 3. Stateless; 4. Layered System; 5. Cacheable;

(47)

6. Code on Demand.

Uniform Interface

As intera¸cões entre os componentes Web - clientes, servidores ou intermediários - depende da uniformidade de suas interfaces. Se algum dos componentes não cumprirem o padrão de comunica¸cão estabelecido, a comunica¸cão não se verifica. Estes componentes Web interagem de forma consistente segundo quatro restri¸cões:

• Resource-Based: servi¸cos disponibilizados s˜ao chamados de recursos e s˜ao localizados a partir de um identificador, URI.

• Manipulation of Resources Through Representations: clientes podem manipular representa¸c˜oes de recursos de diferentes formas. Isto quer dizer que os dados podem ser representados em JSON, XML, HTML, etc;

• Self-descriptive Messages: todas as mensagens incluem informa¸c˜oes suficientes para processar a mensagem;

• Hypermedia as the Engine of Application State (HATEOAS): As representa¸cões de recursos obtidas em uma aplica¸cão REST devem possuir hiperlinks que permitam a navega¸cão do cliente pelos recursos. O estado da aplica¸cão muda apenas através de a¸cões identificados por estes hiperlinks.

Client-Server

Através da uniform interface é poss´ıvel separar fun¸cões de clientes e de servidores, ou seja, clientes são responsáveis por fazer pedidos e apresentar os dados e servidores responder aos pedidos dos clientes e manipular a informa¸cão de forma eficiente. Isto permite que ambos possam evoluir de forma independente;

(48)

Stateless

Esta restri¸cão enuncia que o web server não contém a obriga¸cão de guardar o estado do cliente na aplica¸cão. Com isso, todos os clientes devem conter toda a informa¸cão necessária para cada itera¸cão com o servidor.

Cacheable

Cacheable é uma restri¸cão em que os dados retornados pelo servidor poderão ser registados como cacheable (pass´ıveis de utiliza¸cão de cache), proporcionando maior desempenho do sistema;

Layered System

O sistema multi-camada possibilita a utiliza¸c˜ao de intermedi´arios tais como proxies e gateways. Estes podem ser utilizados para melhoria de seguran¸ca, cache de respostas, etc.

Code on Demand

Esta restri¸cão permite que servidores possam, temporariamente, transferir a lógica de uma funcionalidade para o cliente para que este possa executá-la.

3.1.4 JavaScript Object Notation

JSON é um formato padrão para transmissão de dados entre entidades/sistemas. Atualmente, tem sido muito utilizado em request/response de servidores, estruturamento de dados em plataformas estáticas, etc. Isto verifica-se uma vez que é de fácil leitura e manuseamento por humanos e computadores. JSON é um formato de texto completamente independente da linguagem, sendo originalmente derivado da linguagem de programa¸cão ECMAScript [27]. Os dados em JSON são representados

(49)

por um par key/value, em que a key deverá ser uma string responsável por identificar o respetivo value, podendo este ser do tipo primitivo (strings, números, booleans e null ) ou estruturado (objetos e arrays) figura 3.8 [22].

Figura 3.8 – JSON exemplo de dados [3].

3.1.5 JSON Web Token

JSON Web Token é um objeto JSON que é definido pela norma RFC 7519, como uma maneira compacta, autônoma e segura para transmissão de dados entre duas partes. As informa¸cões contidas neste objeto, podem ser consideradas confiáveis visto que são assinadas digitalmente por um segredo (com algoritmo HMAC) ou por um par chave pública/privada com RSA [4, 38].

Destacam-se as seguintes caracter´ısticas de um JWT mencionadas acima:

compacto pode ser facilmente enviado como parˆametro ou no cabe¸calho de um pedido HTTP;

(50)

O JWT é estruturado em três partes separadas por um “.” que são codificadas em base64, ilustrado na figura 3.9. Estas partes são designadas de header, playload e signature.

Figura 3.9 – JWT exemplo [4].

Header

Tipicamente no header esta tipo de token, neste caso JWT, e o algoritmo de hash utilizado para assinar, na ilustra¸c˜ao da figura3.10foi assinado com algoritmo HMAC SHA256.

(51)

Figura 3.10 – JWT header [4].

Playload

A segunda parte do token é o playload, que contém as claims. Claims são parâmetros que podem ser acerca do utilizador ou informa¸cões adicionais da autentica¸cão realizada pelo servidor (Figura 3.11). Existem três tipos de claims, das quais temos:

Registered são parâmetros predefinidos que definem, por exemplo: tempo de expira¸cão (exp), entidade que criou o token (iss), etc;

Public contém os parâmetros acerca do utilizador que utilizará o token; Private são utilizados para partilhar informa¸cões entre duas partes, que não são nem Public ou Registered

Figura 3.11 – JWT playload [4].

Signature

A assinatura é composto pelo header e playload codificados em base64 separados por um “.” e um segredo. Estas três partes posteriormente são assinadas utilizando

(52)

o algoritmo especificado (Figura 3.12).

Figura 3.12 – JWT signature [4].

3.1.6 Java

Java é uma linguagem de programa¸cão que foi originalmente desenvolvida pela Sun Microsystems que foi fundada por James Gosling em 1995, Java Standard Edition 1. Atualmente, a última versão do Java Standard Edition designa-se por 9 que foi lan¸cada em 2017. Com o avan¸co desta tecnologia e o aumento da sua popularidade, este foi distribu´ıdo em três edi¸cões [40,50]:

Java Standard Edition contém a sintaxe e o ambiente necessário para a compila¸cão de qualquer aplica¸cão;

Java Enterprise Edition plataforma destinada a cria¸cão de aplica¸cões Web e é implementada on top da JSE;

Java Mobile Edition plataforma destinada a cria¸cão de aplica¸cões móveis; Algumas das principais caracter´ısticas do Java são [16, 40]:

POO segue um modelo de programa¸c˜ao por objetos, ou seja, tudo no Java ´e um objecto;

Independente da plataforma é uma linguagem interpretada visto que código Java é compilado para bytecode, este por sua vez é independente da plataforma uma vez que é traduzido através da Java Virtual Machine (JVM). Isto também é conhecido por Code once, Run Everywhere.

(53)

Seguro visto que corre na JVM, esta cria uma sandbox, zona de mem´oria que ´e restrita (encapsulada), que dificulta ataques aos dispositivos;

Robusto uma das maiores vantagens do Java comparativamente a outras linguagem orientadas a objetos, é a preven¸cão de leaks de memória. O Java tem uma agente (Garbage Colector) que gere a memória automaticamente.

Java Enterprise Edition

Java EE é uma plataforma que fornece uma Interface de Programa¸cão de Aplica¸cões (API) para desenvolvimento e execu¸cão de software do quais se destacam: servi¸cos de rede e WEB. O Java EE utiliza um modelo de aplica¸cões distribu´ıdas em multicamadas de larga escala, escaláveis, confiáveis e seguras que é dividida em componentes com fun¸cões distintas e independentes [45].

Figura3.13mostra um esquema de aplica¸c˜oes Java EE dividida em camadas descritas abaixo [39]:

1. Client-tier - a camada do cliente consiste geralmente numa interface que permite acesso a um servidor Java EE que por norma est´a localizada em uma m´aquina diferente do servidor. Os clientes fazem pedidos ao servidor e este processa-os e retorna repostas correspondentes.

2. Web-tier - esta é composta por componentes que lidam com a intera¸cão entre clientes e a camada lógica ou Bussines-tier, tendo como principais fun¸cões:

(a) gerar conteúdo dinâmico em vários formatos para o cliente, JSP/Servlets. (b) adquirir dados de entrada da interface do cliente e retornar respostas

apropriadas criadas atrav´es da camada l´ogica.

(c) controlar o fluxo de intera¸cões do cliente com a interface. (d) executar lógica básica e guardar temporariamente dados.

3. Business-tier ou camada lógica - fornece todas as funcionalidades lógicas do sistema, como por exemplo: verifica¸cão dos dados do pedido do cliente.

(54)

4. Enterprise information system (EIS) - consiste em servidores de base de dados que podem estar localizados em uma m´aquina separada da aplica¸c˜ao Java EE.

Figura 3.13 – Java EE multicamada.

Servlet é um componente Web, gerido por um “container”, que fornece conteúdo dinâmico. As servlets são pequenas classes de Java independentes da plataforma,

compiladas para uma arquitetura neutra bytecode que podem ser executadas dinamicamente por um servidor web. Este servidor interage com clientes atrav´es do modelo

cliente-servidor que ´e fundamentado, principalmente, pelo protocolo HTTP.

O container da servlet, em conjunto com o servidor Web, fornecem servi¸cos de rede nos quais os pedidos e respostas s˜ao definidos, descodificados pedidos baseados em

(55)

MIME (Multipurpose Internet Mail Extensions) e formatadas as respostas baseadas em MIME. O container também contém e gere servlets através do seu ciclo de vida [21].

Para especificar o funcionarmento das tecnologias descritas anteriormente, recorre-se ao funcionamento básico da rela¸cão entre os sistemas Container - Servlet no qual tem-se, por exemplo, um utilizador a realizar um pedido HTTP ao servidor Web. Este pedido, posteriormente, é processado pelo servidor Web sendo transferido (em objeto que representa o pedido) para o container da servlet que por sua vez tem a habilidade de determinar a servlet (com base nas configura¸cões internas) encarregada do pedido. A servlet utiliza o objeto para identificar o utilizador e o formato HTML, bem como os parâmetros podem ter sido enviados como parte do pedido e outros dados relevantes para o processamento do pedido. Com isso, a servlet executa qualquer lógica na qual foi programada e gera dados e contrói a resposta para o cliente (Figura3.14).

Figura 3.14 – Servlet, esquema simplificado do seu funcionamento.

Java Server Pages é uma tecnologia para desenvolver páginas da Web dinâmicas, caracterizadas por serem também uma extensão das Servlets. Esta tecnologia auxilia os programadores a criar páginas dinâmicas através da inser¸cão de código Java em páginas HTML, sendo isto poss´ıvel ao utilizar caracteres especiais (Tags JSP). As tags JSP podem ser utilizadas para vários fins, como recuperar informa¸cões de uma

(56)

base de dados, controlo entre páginas, compartilha de informa¸cões entre pedidos e adquirir dados dos utilizadores através de formulários de páginas Web [54].

Figura 3.15 – C´odigo Java em uma p´agina HTML (JSP), linha 15.

Como já referido anteriormente as JSP’s são uma extensão das servlets, ou seja, os scriptlet JSP’s (código Java dentro das tags JSP) são traduzidos para servlet e compilados numa classe, podendo desta forma, ser consideradas uma abstra¸cão das mesmas [51]. Após a tradu¸cão e compila¸cão de uma JSP para uma servlet a sua gestão e funcionamento irá ser efetuada pelo container de forma semelhante a Servlet, subseçcão 3.1.6.

JAX-RS e Jersey

JAX-RS é uma API do Java desenhada para o desenvolvimento de aplica¸cões que utilizam a arquitetura REST. Esta API define um conjunto de anota¸cões que podem ser utilizadas ao longo de classes Java com o objetivo de controlar a¸cões de recursos REST [39]. Algumas destas anota¸cão são:

(57)

• @GET, @POST, @DELETE, @PUT correspondente ao método HTTP. O método Java que tiver uma destas anota¸cões irá proceder tal como a verbose HTTP;

• @PathParam é um tipo de parâmetro que pode ser extra´ıdo da URI; • @QueryParam é outro tipo de parâmetro que pode ser extra´ıdo da URI; • @Consumes utilizado para especificar o tipo de dados que o recurso aceita; • @Produces utilizado para especificar o tipo de dados que será produzido no

lado do recurso na resposta;

• @ApplicationPath utilizado para mapear a aplica¸c˜ao, ou seja, especificar o root da URI dos recursos.

Por outro lado, Jersey é uma framework que implementa as especifica¸cões da API JAX-RS para o concreto desenvolvimento de aplica¸cões em REST [30].

3.1.7 Base de Dados

As bases de dados e as suas tecnologias têm um grande impacto na crescente utiliza¸cão de computadores e tecnologia móvel. É justo dizer que as base de dados desempenham um papel cr´ıtico em todas as áreas em que exijam armazenamento de dados, incluindo, comércio eletrónico, engenharia, medicina, genética, direito e educa¸cão [29].

As bases de dados podem ser:

1. Relacionais: é uma cole¸cão de dados relacionados, ou seja, factos conhecidos que podem ser manipulados (com SQL - Structured Query Language) e que têm significado impl´ıcito [15]. MySQL é um exemplo de uma base de dados relacional.

(58)

2. Não relacionais: é uma cole¸cão de dados pouco consistente (dados estruturados ou não, geralmente estes não estão estruturados) mas com alta escalabilidade e alto desempenho para acesso de dados. Esta utiliza uma técnica de reperesenta¸cão par “key/value” semelhante a tecnologia JSON (seçcão 3.1.4) [56]. MongoDB é um exemplo de uma base de dados não relacional.

SQL é a linguagem padrão de uma base de dados relacional [53]. Esta linguagem abrange três principais tipos de instru¸cões:

1. SQL schema statements: s˜ao utilizadas para definir as estruturas de dados armazenada na base de dados.

2. SQL data statements: são utilizadas para manipular os dados, estruturas previamente definidas usando instru¸cões de esquema SQL (Figura 3.16). 3. SQL transaction statements: são utilizadas para manipular transa¸cões [14].

Figura 3.16 – Processo de execu¸c˜ao de uma query numa base de dados relacional. Fonte: [5]

(59)

3.2 Enquadramento Te´

orico - Front-end

Front-end esta por trás de todo o desenvolvimento gráfico de uma página Web que é composta principalmente por HTML, CSS e javascript. Nesta subseçcão serão apresentados todos os conceitos relativos a estas, bem como algumas frameworks que visam facilitar o processo de desenvolvimento.

3.2.1 Hypertext Markup Language (HTML)

O HTML é uma linguagem de marca¸cão simples utilizada para a cria¸cão de documentos hipertexto independentes da plataforma. Atualmente é a linguagem de marca¸cão padrão para desenvolvimento de páginas Web. Páginas em HTML são compostas por blocos, estes são também chamados de elementos que são representados por “tags” (Figura3.17) [20,59]. Estas, por sua vez indicam o tipo de elemento HTML, ou seja, se é um cabe¸calho (“heading”), parágrafo (“paragraph”), tabela (“table”), etc. Atualmente a versão mais recente do HTML é a 5, foi lan¸cada em 2014 e suporta novas caracter´ısticas tais como: elementos para cores, reprodu¸cão de som e v´ıdeo e desenhar gráficos interativos (canvas) [36].

(60)

HTML5 Canvas

O Canvas é um elemnto do HTML5 que permite uma renderiza¸cão dinâmica de formas 2D e imagens bitmap. É um modelo processual de baixo n´ıvel que atualiza um bitmap e não possui gráfico de cena embebido, ou seja, o canvas consiste em uma região desenhável definida em código HTML limitada a uma altura e largura, podendo ser manuseado por scripts em linguagem Javascript responsáveis por gerar desenhos dinâmicos [44].

Figura 3.18 – Canvas exemplo com manipula¸c˜ao Javascript [6].

3.2.2 Cascading Style Sheets (CSS)

CSS é utilizado para descrever como elementos HTML são renderizados numa página, ou seja, mudar a disposi¸cão, estilos e estados destes (Figura3.19) [58,24]. Todos os browsers compilam código CSS através de um número de regras que são aplicadas ao documento HTML, estas são constitu´ıdas por:

selector valor identificador do elemento selecionado a mudar as caracter´ısticas; property name nome da propriedade a mudar;

(61)

property value valor da propriedade;

Figura 3.19 – CSS e HTML exemplo [58].

3.2.3 Bootstrap

O Bootstrap é uma Framework desenvolvida pelo Twitter que utiliza HTML, CSS e Javascript para criar páginas Web responsivas. Com base em um sistema Flexbox grid, o Bootstrap implementa um layout de 12 colunas com múltiplo tamanhos com base na largura da janela de visualiza¸cão. Um elemento HTML pode ser associado ao Bootstrap, utilizando o nome da classe com o prefixo .col-. Como descri¸cão que se segue ao prefixo (Figura 3.20), o elemento terá uma largura m´ınima (ponto de interrup¸cão). Quando este valor for menor que tamanho da janela dispon´ıvel o elemento não é exibido [10, 57].

(62)

Figura 3.20 – Sum´ario de como o Bootstrap funciona em m´ultiplas plataformas [57].

Figura 3.21 ilustra como o documento HTML deve ser estruturado ao utilizar Bootstrap e a sua renderiza¸cão. O container (na imagem a rosa) envolve todos os elementos associados ao Boootstrap. Uma vez que esta framework baseada em grid’s, o primeiro elemento a ser declarado dentro do container é uma row (na imagem a vermelho), que pode conter até 12 colunas. Estas podem ser colocadas dentro das row (na imagem a verde) e ocupam uma percentagem do parente (row ) dependente do que se segue ao prefixo da classe utilizado.

Figura 3.21 – CSS e HTML exemplo [58].

3.2.4 Javascript - EMACScript

O JavaScript foi criado na Netscape nos primordios da Web, e tecnicamente, “Java-Script” ´e uma marca comercial licenciada pela Sun Microsystems (agora Oracle)

(63)

utilizada para descrever a implementa¸cão da Netscape (agora Mozilla) desta linguagem. Netscape submeteu a linguagem em vista a padronizá-la na ECMA, European Computer Manufacturer’s Association, e por questões de marca registrada, a versão padronizada da linguagem foi nomeada de “ECMAScript”. Pelos mesmos motivos de marca registrada, a versão desta linguagem da Microsoft é formalmente conhecida por ”JScript”. Na prática, a linguagem é conhecida por Javascript mundialmente [33, 47].

Na última década, todos os browsers implementaram a versão 5 do ECMAScript. Embora já exista a versão 8 do ECMAScript, a versão 5 é a “standard” [42, 28]. Javascript é utilizado para criar conteúdo dinâmico numa página HTML, isto é, em páginas HTML podem ser incluidos scripts para controlar a intera¸cões com o utilizador, controlar o browser ou até criar elementos HTML através da DOM, Document Object Model [42]. Esta é uma interface de aplica¸cão multi-plataforma e independente da linguagem que trata documentos HTML, XHTML e XML como uma árvore, onde cada objeto desta representa uma parte do documento [37]. Algumas das vantagens de utilizar esta tecnologia são:

Menos utiliza¸c˜ao do servidor para algumas tarefas validar os dados de um utilizador antes de envi´a-los para o servidor;

Experiência real-time com a página podem ser criadas interfaces de acordo com a¸cões do utilizador, rato ou teclado;

Interfaces mais ricas por exemplo drop-downs, menus parciais na barra de navega¸c˜ao de uma p´agina;

Frameworks existˆencia de um n´umero elevado de bibliotecas que facilitam o desenvolvimento de interfaces / funcionalidades.

Seguindo o paradigma da programa¸c˜ao orientada a objetos, prototypal inheritance do Javascript distingue-se de linguagens como Java, C++ ou C#, uma vez que o

(64)

conceito de classes e heran¸ca (introduzido no ECMAScript 2015) é baseado numa cadeia de objetos prototype, que permitem que as propriedades deste sejam herdadas diretamente um dos outros, em oposi¸cão aos métodos clássicos [11].

O Javascript pode ser ´ıncluido numa página HTML através de tags ou documentos externos com extensão “.js” (Figura 3.22).

Figura 3.22 – Javascript documentos no HTML.

DOM

Como foi referido anteriormente é poss´ıvel controlar aspectos da páginas com o javascript, estes podem ser pertencentes ao HTML bem como ao CSS. São necessários quatro campos para realizar a¸cões a DOM (Figura 3.23):

• método: tipo de selector que irá ser acedido ao elemento da DOM; • selector: identifica¸cão do elemento da DOM;

• propriedade: a¸c˜ao a realizar;

(65)

Figura 3.23 – Javascript e DOM.

Listener

Esta funcionalidade tem como objetivo “escutar” a¸cões efetuadas a um ou vários elementos da DOM. Para adicionar um listener a um elemento, é necessário especificar qual tipo de evento a ser manipulado, tipo de selector, o selector do elemento da DOM e a fun¸cão ou conjunto de instru¸cões a serem executadas.

Figura 3.24 – Javascript listener.

(66)

quando o utilizar clicar no elemento com o identificador “myBtn” as instru¸cões serão executadas (na figura: action), neste caso, a fun¸cão “displayDate(e)”.

Closures

Antes de descrever o que são closures é necessário definir o que é scope. Em qualquer linguagem de programa¸cão scope é o controlo de visibilidade e o ciclo de vida das variáveis ou constantes presentes no programa [47].

Figura 3.25 – Javascript scope.

Com base na ilustra¸c˜ao da figura 3.25, pode-se identificar trˆes tipos de scope, dos quais temos:

• block scope: a variável i só é vis´ıvel dentro deste. No entanto, a variável a e b são vis´ıveis dentro deste.

• function scope: as variáveis dentro deste scope só existem dentro do mesmo, ou seja, b e i não existem fora deste.

• global scope: todas as variáveis que pertencem a este estão vis´ıveis em qualquer parte da aplica¸cão.

(67)

Pode-se assumir que o ideal é declarar todas as variáveis da aplica¸cão no global scope uma vez que, desta forma, todas as variáveis estão sempre vis´ıveis para o cont´ınuo acesso da aplica¸cão. No entanto, esta prática pode causar intera¸cões indesejáveis entre outras variáveis existentes em outras aplica¸cões, frameworks, widgets ou até com o próprio navegador [47]. Deste modo, é boa prática utilizar closures para encapsular informa¸cões relativas da aplica¸cão.

Uma closure é a combina¸cão de uma fun¸cão e de todo o ambiente léxico que essa fun¸cão engloba. Em outras palavras, com uma closure é poss´ıvel ter acesso as caracter´ısticas de uma fun¸cão outer através de uma fun¸cão inner e guardar o seu estado através de uma referência, (Figura3.26) 1[23, 47].

(68)

3.2.5 AngularJS

AngularJS é uma framawork do Javascript baseada na arquitetura MVC para desenvolvimento de aplica¸cões Web dinâmicas. Atualmente, esta framework é open source mas

originalmente desenvolvida pela Google [52, 35].

Esta framework substitui atributos HTML por diretivas e vincula os dados ao HTML com express˜oes, estas podem ser criadas pelo programador ou utilizadas a partir de um conjunto de diretivas que s˜ao disponibilizadas pelo AngularJS, das quais temos:

• ng-app : vincula uma aplica¸cão AngularJS ao elemento div HTML; • ng-init : inicializa¸cão de dados da aplica¸cão;

• ng-controller : vincula um controlador a View da aplica¸c˜ao; • ng-model : vincula o valor de um input a aplica¸c˜ao;

• ng-bind : vincula os dados da aplica¸c˜ao a View ;

Na ilustra¸cão da Figura 3.27, o real¸cado a verde corresponde à vincula¸cão de uma aplica¸cão AngularJS a um elemento HTML, já a vermelho refere-se ao seu controlador. Por sua vez, os dados são vinculados no destacado a azul à aplica¸cão, isto é, ng-model (cor-de-rosa). O mesmo acontece no inverso, ou seja, os dados da aplica¸cão podem ser vinculados a partir do que se encontra a cor-de-rosa à View (ng-bind).

(69)

Figura 3.27 – AngularJS exemplo.

3.2.6 Tecnologias para ambiente 3D na WEB

Com WebGL sendo o novo padrão para gráficos 3D na Web, torna-se poss´ıvel aos programadores aproveitar todo o poder do hardware para renderiza¸cão de gráficos utilizando apenas JavaScript, um browser e uma cole¸cão de tecnologias Web padrão. A renderiza¸cão 3D no WebGL é análoga ao desenho 2D utilizando o elemento Canvas (seçcão3.2.1), na medida em que tudo é feito através de código JavaScript. Contudo, para aceder ao WebGL é fornecido ao consumir o elemento canvas existente e obter o seu contexto de desenho de forma espec´ıfica ao WebGL [46].

Uma parte desta disserta¸cão consiste em modela¸cão de ambientes 3D na Web e para isso como foi referido anteriormente esta modela¸cão assenta sobre o WebGL. Com isso foi utilizada uma framework de javascript com o objectivo de abstrair de técnicas puramente 3D e que utilize o padrão para desenho de modelos em 3D na web.

(70)

Babylon.js é uma motor para jogos 3D baseado em WebGL e javascript criado por David Catuhe e David Rousset. Babylon.js é uma framework nova e menos popular do que Three.js, embora mais acess´ıvel. É ainda open source e orientada para cria¸cão de jogos, com vários ferramentas/recursos desenvolvidos especificamente para jogos tais como: gamepad camera, instâncias acelera¸cão de hardware, e entre outras [18].

Three.js é uma framework JavaScript/API cross-browser utilizada para criar e exibir gráficos 3D animados em navegadores Web. Three.js utiliza WebGL e é opensource com mais de 650 contribuidores no total entretanto foi lan¸cada por [17].

PlayCanvas é um motor de jogo 3D / motor de aplica¸cões interativas 3D opensource, permite a edi¸cão simultânea de vários computadores na cloud através de uma interface no browser. Ela é executada em navegadores Web modernos que suportam o WebGL, dois quais Mozilla Firefox e Google Chrome [26].

3.3 Algoritmos para reconhecimento de ciclos em

grafos

Um grafo é uma estrutura que equivale a um conjunto de objetos em que alguns destes objetos estão, de certo modo, ”relacionados”. Os objetos correspondem a abstra¸cões matemáticas chamadas vértices (também chamados de nós ou pontos) e cada um dos pares de vértices relacionados é chamado de aresta (também chamado de arco ou linha). Normalmente, um grafo é representado em diagramas (Figura

3.28) por um conjunto de pontos, unidos por linhas ou curvas [60].

Relativamente aos grafos, um ciclo ou caminho fechado (Figura3.29) é um subgrafo de um grafo onde os seus vértices estão conectados em uma série fechada. Em vista a encontrar todos os ciclos de grafos podemos referir-nos ao DFS (Deepth Search First) que é um algoritmo de pesquisa que percorre um grafo em profundidade e

(71)

Figura 3.28 – Grafo sem direc¸c˜ao. Fonte: [7]

utiliza uma stack para ”lembrar”dos vétices que percorreu e saber qual o próximo vértice a percorrer, quando é encontrado um vértice ”sem sa´ıda”.

Este algoritmo funciona seguindo tres regras:

1. Regra 1: Visitar o v´ertice n˜ao visitado adjacente. Marcar como visitado. Colocar na stack.

2. Regra 2: Se nenhum vértice adjacente for encontrado o vértice atual é retirado da stack e continua o processo.

3. Regra 3: Repetir regra 1 e 2 at´e que a stack esteja vazia.

No entando, com as regras anteriormente descritas não é poss´ıvel encontrar ciclos diretamente mas se termos em conta o teorema que refere que “Um grafo tem ciclo se e somente se for exibida uma aresta já conhecida (presente na stack) durante o DFS. Com isto, podem-se executar DFS para o grafo e verificar as arestas anteriormente visitadas (também chamadas de back edges)”, é concreto afirmar que o algoritmo DFS tem a capacidade de encontrar os ciclos de um grafo.

(72)

(73)

(74)

4

Conce¸c˜

ao

A aplica¸cão web que se pretende implementar é designada por SIS (Sound Insulation Software), esta tem como fun¸cão realizar simula¸cões do isolamento sonoro de um piso inteiro. Para tal, é necessário projetar todos os conceitos lógicos a serem desenvolvidos.

Este cap´ıtulo tem como objectivo discriminar toda a parte conceptual utilizada para a implementa¸cão da aplica¸cão, sendo este um passo primordial para o desenvolvimento de um software de qualidade, fiável e eficiente. Com isso, todas as aplica¸cões devem respeitar os princ´ıpios da Engenharia do Software que estão representados nos subcap´ıtulos que se seguem.

4.1 Arquitectura da Aplica¸c˜

ao

A arquitetura que regirá a aplica¸cão é designada de MVC (Model View Controller), esta arquitectura divide a aplica¸cão em três partes que estão interconectadas, Figura

4.1.

Estas trˆes partes mais detalhadamente s˜ao descritas como: 47

(75)

1. Model : contém o núcleo funcional da aplica¸cão, responsável por encapsular os seus dados disponibilizando os métodos que podem ser usados no processamento dos mesmos. Este componente é independente dos componentes view e controller, permitindo que múltiplas views possam solicitar aos mesmos dados.

2. Controller : controla as intera¸cões entre a view e o model, uma vez que é da sua responsabilidade receber os pedidos dos utilizadores, traduzi-los em a¸cões que podem ser realizados pelo model e gerar as respetivas respostas com os dados que lhe forem retornados.

3. View: respons´avel por apresentar os dados ao utilizador.

Mais detalhadamente, todas as opera¸cões funcionais que o utilizador pode realizar na aplica¸cão estão dispon´ıveis na View (ou também User Interface UI). Estas opera¸cões são controladas pelo Controller que é responsável por invocar o Model para concretizar as opera¸cões e atualizar a View.

4.2 Levantamento de Requisitos

No decorrimento do subcap´ıtulo anterior foi definido o conceito de View (interface do utilizador), no que, atrav´es desta, o utilizador usa as funcionalidades do sistema. Com isso, para respeitar os bons princ´ıpios da Engenharia do Software o sistema tem de ser primeiramente especificado nos seus requisitos que ir˜ao ser compostos em funcionalidades.

O levamento de requisitos está dividido em funcionais e não funcionais. No que se refere aos requisitos funcionais, representam funcionalidades da aplica¸cão e as intera¸cões que os utilizadores possam ter. Já os requisitos não funcionais determinam caracter´ısticas do sistema.

(76)

Figura 4.1 – Arquitectuira MVC [9].

4.2.1 Requisitos Funcionais

Os requisitos funcionais do sistema que se pretende implementar s˜ao:

1. O sistema deverá ter um sistema de autoriza¸cão e autentica¸cão por token e login respectivamente;

2. O sistema dever´a permitir a utilizadores autenticados a consulta dos seus materiais;

(77)

3. O sistema deverá permitir a utilizadores autenticados a altera¸cão de materiais; 4. O sistema deverá permitir a utilizadores autenticados a cria¸cão de novos

materiais;

5. O sistema deverá permitir a utilizadores autenticados a remo¸cão de materiais; 6. O sistema deverá permitir a utilizadores autenticados a cria¸cão de novos

projetos e da sua caracteriza¸c˜ao;

7. O sistema dever´a permitir a utilizadores autenticados a remo¸c˜ao dos seus projetos;

8. O sistema dever´a permitir a utilizadores autenticados o desenho/manipula¸c˜ao de uma planta em 2D relativa a um projeto;

9. O sistema dever´a ser capaz de criar modelo 3D de plantas anteriormente desenhadas por utilizadores autenticados;

10. O sistema dever´a guardar periodicamente informa¸c˜oes do projeto no ato de desenho;

11. O sistema dever´a permitir a utilizadores autenticados atribuir materiais aos elementos do desenho;

12. O sistema dever´a permitir a utilizadores autenticados caracterizar todos os elementos do desenho;

13. O sistema dever´a permitir a utilizadores autenticados realizar simula¸c˜oes dos projetos;

14. O sistema dever´a permitir a utilizadores autenticados manusear dinamicamente resultados de simula¸c˜oes;

4.2.2 Requisitos n˜

ao Funcionais

(78)

1. O sistema dever´a estar online;

2. O sistema deverá ser acess´ıvel através de qualquer dispositivo que tenha acesso à Internet;

3. O sistema dever´a apenas ter conte´udos de natureza restrita;

4. O sistema deverá fazer a autentica¸cão através do email mais password com HASH e Salt;

5. O sistema deverá fazer a autoriza¸cão através de uma assinatura digital (token); 6. O sistema deverá permitir a filtragem de materiais por tipo (Associado a RF

no_2);

7. O sistema dever´a caracterizar os materiais nos seus respectivos grupos: (a) grupo 1: slab e ceiling;

(b) grupo 2: fa¸cade, wall e eco;

(c) grupo 3: door, window e glazed curtain; (d) grupo 4: Trickle Vent.

8. O sistema não deverá permitir a altera¸cão ou cria¸cão de materiais com parâmetros de distintos grupos (Associado a RF no_{3 e 4 e RNF n}o_7);

9. O sistema deverá processar toda a informa¸cão dos desenhos num modelo de dados leg´ıvel pela aplica¸cão (Associado ao RF no

8), mais informa¸cões na seçcão 4.5;

10. O sistema deverá verificar a validade e fazer reformula¸cão do modelo de dados relativo ao desenho (Associado ao RF no _{8 e 9), mais informa¸cões na seçcão} 4.5;

11. O sistema dever´a atualizar o projeto na base de dados num intervalo de 10 minutos (Associado ao RF no _10);

(79)

12. O sistema deverá inibir a utiliza¸cão da plataforma 3D a utilizadores que não tenham materiais suficientes;

13. O sistema deverá fazer a sele¸cão de materiais validos para atribui¸cão aos elementos de desenho (Associado ao RF no _{11 e RNF n}o _7);

14. O sistema dever´a permitir a atribui¸c˜ao de caracter´ısticas adicionais que respeitem o RNF no

7. (Associado ao RF no

12). Estas caracter´ısticas s˜ao evidenciadas mais nos subcap´ıtulos que se seguem;

15. O sistema deverá ser capaz de criar perfis automáticos (seçcão4.5) de caracteriza¸cão de elementos de desenho para habilitar as simula¸cões (Associado a RF no

13).

4.3 Diagrama Entidades e Relacional

O diagrama de Entidades e Relacionamento determina toda a l´ogica e descreve como as entidades ir˜ao se relacionar e quais as suas caracter´ısticas. Deste modo, pode-se definir os elementos principais de um diagrama ER como:

1. Entidate - representa um objecto que cont´em atributos que lhe s˜ao comuns, exemplo: pessoa e carro.

2. Atributo - representa propriedades dos Relacionamentos ou entidades, exemplo: nome da pessoa.

3. Relacionamento - representa a relac˜ao entre entidades. exemplo: uma pessoa tem um carro. Os relacionamentos podem ser tamb´em classificados quanto a sua multiplicidade:

(a) 1...1 (um para um); (b) 1...* (uma para muitos);

(80)

(d) X...Y (onde o valor de X representa o valor m´ınimo e o Y representa o valor m´aximo).

Quanto ao SIS temos o diagrama representado na Figura4.2podendo ser interpretado da seguinte forma:

1. Um utilizador tem 0 ou mais materiais;

2. Um material s´o pode pertencer a um e s´o um utilizador; 3. Um utilizador tem 0 ou mais projetos;

4. Um projeto só pode pertencer a um e só um utilizador; 5. Um projeto tem um e só um desenho;

6. Um desenho pertence a um e s´o um projeto;

Através da tabela Draw 2d é poss´ıvel identificar que esta é composta por todas as componentes do desenho que são Serializadas em JSON Strings. Esta caracter´ıstica é necessária para guardar o estado do desenho na View, sendo que estes atributos representam um modelo de dados complementar (subseçcão 4.5) ao modelo de base de dados representado nesta subseçcão.

(81)

Figura 4.2 – Diagrama ER

4.4 Diagrama Casos de Uso

O diagrama de Caso de Uso representa de forma simplificada todos as funcionalidades que os utilizadores (atores) do sistema podem efetuar. As suas componentes s˜ao:

1. Atores - algu´em ou algo que interage com o sistema;

2. Casos de uso - funcionalidades do sistema, descritas no Levantamento de requisitos;