felipe de souza tortato - ufsc
TRANSCRIPT
Felipe de Souza Tortato
DESENVOLVIMENTO DE SOFTWARE WEB PARA
DIMENSIONAMENTO DE CONDENSADORES DO TIPO WIRE-
ON-TUBE, PARA APLICAÇÃO NA INDÚSTRIA DE
REFRIGERAÇÃO
Trabalho de Conclusão de Curso
submetido ao Departamento de
Engenharia Elétrica e Eletrônica da
Universidade Federal de Santa Catarina
para a obtenção do título de Bacharel
em Engenharia Eletrônica
Orientador: Prof. Dr. Mauricio
Valencia Ferreira da Luz
Florianópolis
2019
Ficha de identificação da obra elaborada pelo autor
através do Programa de Geração Automática da Biblioteca Universitária
da UFSC.
Tortato, Felipe de Souza
Desenvolvimento de Software WEB para
Dimensionamento de Condensadores do Tipo Wire-On-
Tube, para Aplicação na Indústria de Refrigeração /
Felipe de Souza Tortato ; orientador, Mauricio
Valencia Ferreira da Luz, 2019.
128 p.
Trabalho de Conclusão de Curso (graduação) -
Universidade Federal de Santa Catarina, Centro
Tecnológico, Graduação em Engenharia Eletrônica,
Florianópolis, 2019.
Inclui referências.
1. Engenharia Eletrônica. 2. Programação WEB. 3.
Ferramenta de Engenharia. 4. Modelagem UML. I. Luz,
Mauricio Valencia Ferreira da. II. Universidade
Federal de Santa Catarina. Graduação em Engenharia
Eletrônica. III. Título.
Este trabalho é dedicado aos meus pais.
AGRADECIMENTOS
Agradeço primeiramente a Deus, pelo dom da vida, por ter
chegado até aqui e pelas pessoas que Ele coloca no meu caminho.
Aos meus pais, Gilberto e Sandra, por todo o carinho, suporte e
cobranças dados ao longo de toda a minha vida e formação, possibilitando
que eu me tornasse um engenheiro.
À minha amada, Amanda, que esteve do meu lado nos meus
últimos semestres no curso, por todo apoio, compreensão e por ser minha
parceira de todas as horas.
Aos amigos de curso, em especial Bruno, Ericson, Fernando, José,
Maicon e Túlio, com quem compartilhei momentos de dificuldade e
nervosismo, mas também de alegrias ao longo do curso.
Aos amigos de outros cursos que, mesmo não estudando o mesmo
conteúdo que o meu, me apoiaram de todas as maneiras possíveis, em
especial, os amigos com os quais passei muitas noites estudando junto,
Artur, Gustavo, José e Rodrigo.
Ao meu orientador, Mauricio Valencia Ferreira da Luz, pelas
discussões, indicações e apoio no desenvolvimento deste trabalho.
A todos os colegas de trabalho no NEO Empresarial, que
contribuíram para com o meu desenvolvimento profissional e pessoal,
durante os anos nos quais trabalhamos juntos. Se hoje me sinto um
profissional preparado para resolver problemas, devo isso a vocês.
Aos bons professores que tive, pelo profissionalismo, competência
e por sua dedicação e empenho em formar excelentes profissionais.
O sucesso nasce do querer, da determinação e
persistência em se chegar a um objetivo. Mesmo
não atingindo o alvo, quem busca e vence
obstáculos, no mínimo fará coisas admiráveis.
(José de Alencar)
RESUMO
As ferramentas disponíveis para simulação de sistemas térmicos
fornecem soluções não específicas para os usuários, adicionando assim
um passo extra de manipulação de dados, de modo a se obter os resultados
desejados. Além disso, essas ferramentas exigem uma versão desktop
instalada para a realização das simulações. Esse trabalho descreve os
passos de desenvolvimento para um aplicativo WEB customizado para
simulação de trocadores de calor do tipo arame sobre tubo. Os passos de
desenvolvimento consistem no entendimento do problema enfrentado
pelo usuário, a modelagem do software por meio de diagramas UML, o
desenvolvimento do algoritmo e a programação dos arquivos utilizando
as linguagens de programação e os frameworks WEB mais utilizados no
mercado. No final, mostram-se as capturas de tela da ferramenta
desenvolvida, como resultados deste trabalho.
Palavras-chave: Programação WEB. Ferramenta de Engenharia.
Modelagem UML.
ABSTRACT
Available tools for thermal systems simulation provide nonspecific
solutions for the users, adding an extra step of filtering data to reach the
desired outputs. Moreover, these tools require a desktop installed version
to perform the simulations. This work describes the development steps of
a of a custom heat exchanger simulation tool embedded in a WEB
application. The development steps comprise the understanding of the
problem faced by the user of the tool, the modelling of the software
through UML diagrams, the algorithm development and the programming
of files applying some of the most used WEB languages and frameworks.
In the end, screenshots of the developed application are shown as results
of this work.
Keywords: WEB Programming. Engineering Tool. UML Modeling.
LISTA DE FIGURAS
Figura 1 - Trocador de calor do tipo WOT. .......................................... 27 Figura 2 - Diagrama simples de interação entre cliente e servidor a partir
de uma requisição. ................................................................................. 34 Figura 3 - Divisão da página em 12 colunas com o Bootstrap. ............. 38 Figura 4 - Exemplo com duas colunas md-6, tela de largura 1000 pixels.
............................................................................................................... 39 Figura 5 - Exemplo com duas colunas md-6, tela de largura 900 pixels.
............................................................................................................... 40 Figura 6 - Model-View-Controller. ....................................................... 41 Figura 7 - Interesse no tópico AngularJS nas pesquisas do Google. ..... 42 Figura 8 - Pesquisa de frameworks preferidos pelos programadores WEB.
............................................................................................................... 43 Figura 9 - Diagrama de classes com baixo nível de detalhamento. ....... 47 Figura 10 - Diagrama de classes com alto nível de detalhamento. ........ 48 Figura 11 - Diagrama de caso de uso. ................................................... 51 Figura 12 - Diagrama de classes............................................................ 52 Figura 13 - Diagrama de objetos. .......................................................... 53 Figura 14 - Diagrama de pacotes. .......................................................... 54 Figura 15 - Diagrama de sequência. ...................................................... 55 Figura 16 - Diagrama de comunicação. ................................................. 56 Figura 17 - Diagrama de estados. .......................................................... 57 Figura 18 - Diagrama de atividades. ..................................................... 59 Figura 19 - Diagrama de componentes. ................................................. 60 Figura 20 - Diagrama de implementação. ............................................. 61 Figura 21 - Visão Geral de Uso do Sistema. ......................................... 65 Figura 22 - Captura de tela de um fragmento do aplicativo antigo. ...... 70 Figura 23 - Captura de tela da página de Login. ................................... 83 Figura 24 - Captura de tela da página do trocado WOT do usuário
especialista. ........................................................................................... 84 Figura 25 - Captura de tela da funcionalidade de visualização do objeto
em 3D. ................................................................................................... 85 Figura 26 - Captura de tela dos modos de inserção da ferramenta. ....... 86 Figura 27 - Captura de tela do auxílio visual dos parâmetros. .............. 87 Figura 28 - Captura de tela da função de salvamento de dados de cálculo. ............................................................................................................... 88 Figura 29 - Captura de tela do modo de inserção dos parâmetros para
cálculo multiparamétrico. ...................................................................... 89 Figura 30 - Captura de tela do modo de visualização dos resultados do
cálculo multiparamétrico. ...................................................................... 90
Figura 31 - Captura de tela da página de Documentação. ..................... 91 Figura 32 - Captura de tela da página de edição da Documentação. ..... 92 Figura 33 - Captura de tela da página de gerenciamento de usuários. .. 93 Figura 34 - Capturas de tela da view de dimensionamento de trocadores
WOT simuladas para um Samsung Galaxy S5. .................................... 94 Figura 35 - Capturas de telas de Documentação (a) e de expansão do menu
(b), simuladas para um Samsung Galaxy S5. ........................................ 95 Figura 36 - Captura de tela da página de Documentação, simulada para
um Ipad. ................................................................................................ 96 Figura 37 - Diagrama de atividades para o front-end: Login. ............. 105 Figura 38 - Diagrama de atividades para o front-end: Cálculo simples
(parte 1/2). ........................................................................................... 106 Figura 39 - Diagrama de atividades para o front-end: Cálculo simples
(parte 2/2). ........................................................................................... 107 Figura 40 - Diagrama de atividades para o front-end: Cálculo
multiparamétrico (parte 1/2). .............................................................. 108 Figura 41 - Diagrama de atividades para o front-end: Cálculo
multiparamétrico (parte 2/2). .............................................................. 109 Figura 42 - Diagrama de atividades para o back-end: Cálculo. .......... 110 Figura 43 - Diagrama de atividades para o back-end: Banco de dados
(parte 1/2). ........................................................................................... 111 Figura 44 - Diagrama de atividades para o back-end: Banco de dados
(parte 2/2). ........................................................................................... 112 Figura 45 - Diagrama de estados para um usuário comum no
dimensionamento de um trocador WOT. ............................................ 113 Figura 46 - Diagrama de caso de uso para o procedimento de login e
redirecionamento (parte 1/2). .............................................................. 114 Figura 47 - Diagrama de caso de uso para o procedimento de login e
redirecionamento (parte 2/2). .............................................................. 115 Figura 48 - Diagrama de caso de uso para navegação no menu do usuário
tipo Administrador. ............................................................................. 116 Figura 49 - Diagrama de caso de uso para navegação no menu do usuário
tipo Especialista ou Técnico. .............................................................. 117 Figura 50 - Diagrama de caso de uso para realização do cálculo........ 118 Figura 51 - Diagrama de classes do aplicativo. ................................... 119 Figura 52 - View de login do aplicativo.............................................. 120 Figura 53 - View de cálculo simples do aplicativo (antes do clique
indicado pelo ícone em amarelo). ....................................................... 121 Figura 54 - View de cálculo simples do aplicativo (após o clique indicado
pelo ícone em amarelo da Figura 53). ................................................. 122
Figura 55 - View de cálculo multiparamétrico do aplicativo (antes do
clique indicado pelo ícone em amarelo). ............................................. 123 Figura 56 - View de cálculo multiparamétrico do aplicativo (após o clique
indicado pelo ícone em amarelo da Figura 55). .................................. 124 Figura 57 - View de exportar dados para formato de texto e realização do
download. ............................................................................................ 125 Figura 58 - View de documentação para os usuários tipo Especialista e
Técnico. ............................................................................................... 126 Figura 59 - View de edição de documentação para o Administrador.. 127 Figura 60 - View de gerenciamento de usuários para o Administrador.
............................................................................................................. 128
LISTA DE QUADROS
Quadro 1 - Exemplo em HTML. ........................................................... 36 Quadro 2 - Exemplo em CSS. ............................................................... 37 Quadro 3 - Exemplo de notação em JSON. ........................................... 37 Quadro 4 - Classes para o sistema de grade com Bootstrap. ................. 39 Quadro 5 - Exemplo de uma tabela em um banco de dados.................. 44 Quadro 6 - Algoritmo do solver. ........................................................... 52 Quadro 7 - Algoritmo do solver. ........................................................... 75 Quadro 8 - Algoritmo do Sistema de Autenticação. .............................. 77 Quadro 9 - Algoritmo do Gerenciador do Banco de Dados. ................. 80 Quadro 10 - Tabela de Usuários no Banco de Dados. ........................... 82 Quadro 11 - Tabela de Documentação no Banco de Dados. ................. 82
LISTA DE ABREVIATURAS E SIGLAS
3D - 3 dimensões, tridimensional
AC - Access Level (Nível de Acesso)
API - Application Programming Interface (Interface de Programação de
Aplicativos)
CSS - Cascading Style Sheets (Folhas de Estilo em Cascata)
DNS - Domain Name System (Sistema de Nomes de Domínio)
HTML - Hypertext Markup Language (Linguagem de Marcação de
Hipertexto)
HTTP - Hypertext Transfer Protocol (Protocolo de Transferência de
Hipertexto)
IIS - Internet Information Services (Serviços de Informações da Internet)
IP - Internet Protocol (Protocolo de Internet)
JS - JavaScript
JSON - JavaScript Object Notation (Notação de Objeto JavaScript)
MPA - Multiple-Page Application (Aplicação de Múltiplas Páginas)
MVC - Model-View-Controller (Modelo-Visão-Controlador)
P&D - Pesquisa e Desenvolvimento
PHP - Hypertext Preprocessor (Pré-processador de Hipertexto)
SPA - Single-Page Application (Aplicação de Página Unica)
SQL - Structured Query Language (Linguagem de Consulta Estruturada)
UML - Unified Modeling Language (Linguagem de Modelagem
Unificada)
WOT - Wire-on-Tube (Arame sobre tubo)
LISTA DE SÍMBOLOS
{ Início de trecho de código de iteração ou
condição (algoritmo)
} Final de trecho de código de iteração ou
condição (algoritmo)
[ ] Acesso a índices de uma variável do tipo vetor
(algoritmo)
( ) Delimitador de parâmetros para as funções
(algoritmo)
-> Acesso a atributos ou métodos de um objeto
(algoritmo)
... Não repetição de sequência de operações
semelhantes (algoritmo)
< > Delimitador de tag em HTML
Ponto de decisão ou de mesclagem (diagrama
de atividades)
Ação (diagrama de atividades)
Nodo inicial (diagrama de atividades),
Estado inicial (diagrama de máquina de
estados)
Nodo final (diagrama de atividades), Estado final (diagrama de máquina de estados)
Nodo fork ou join (diagrama de atividades)
Conector de mesma página (diagrama de
atividades)
Conector de página diferente (diagrama de
atividades)
Classe (diagrama de classes)
Herança (diagrama de classes), Generalização
(diagrama de caso de uso)
Associação (diagrama de classes, diagrama de
caso de uso)
+ Visibilidade pública (diagrama de classes)
- Visibilidade privada (diagrama de classes)
# Visibilidade protegida (diagrama de classes)
~ Visibilidade no pacote (diagrama de classes)
Ator (diagrama de caso de uso)
Estado (diagrama de máquina de estados)
SUMÁRIO
1 INTRODUÇÃO ................................................................... 27 1.1 MOTIVAÇÃO ...................................................................... 27
1.2 OBJETIVOS ......................................................................... 28
1.2.1 Objetivo geral ...................................................................... 28
1.2.2 Objetivos específicos ........................................................... 28
2 FUNDAMENTAÇÃO TEÓRICA ..................................... 31 2.1 ORIENTAÇÃO A OBJETOS ............................................... 31
2.1.1 Definição .............................................................................. 31
2.1.2 Objetos ................................................................................. 32
2.1.3 Classes .................................................................................. 32
2.1.4 Herança ................................................................................ 32
2.2 PROGRAMAÇÃO WEB ...................................................... 33
2.2.1 Funcionamento da WEB..................................................... 33
2.2.2 Front-End ............................................................................ 35
2.2.2.1 Linguagens ............................................................................ 35
2.2.2.1.1 HTML .................................................................................... 35
2.2.2.1.2 CSS ........................................................................................ 36
2.2.2.1.3 JavaScript.............................................................................. 37
2.2.2.2 Frameworks ........................................................................... 38
2.2.2.2.1 Bootstrap ............................................................................... 38
2.2.2.2.2 AngularJS .............................................................................. 40
2.2.3 Back-End.............................................................................. 43
2.2.3.1 Linguagens ............................................................................ 43
2.2.3.1.1 PHP ....................................................................................... 43
2.2.3.1.2 SQL ....................................................................................... 44
2.2.3.2 Bibliotecas ............................................................................. 45
2.2.3.2.1 CoolProp ............................................................................... 45
2.3 MODELAGEM DO PROCESSO – UML ............................ 45
2.3.1 Detalhamento de Informações ........................................... 46
2.3.2 Tipos de Diagramas ............................................................ 48
2.3.2.1 Diagramas de Caso de Uso ................................................... 49
2.3.2.2 Diagramas de Classe ............................................................. 51
2.3.2.3 Diagramas de Objetos ........................................................... 52
2.3.2.4 Diagramas de Pacote ............................................................. 53
2.3.2.5 Diagramas de Sequência ....................................................... 54
2.3.2.6 Diagramas de Comunicação ................................................. 55
2.3.2.7 Diagramas de Máquina de Estados ....................................... 56
2.3.2.8 Diagramas de Atividades ...................................................... 58
2.3.2.9 Diagramas de Componentes ................................................. 59
2.3.2.10 Diagramas de Implementação ............................................... 60
3 METODOLOGIA ............................................................... 63 3.1 ANÁLISE DOS REQUISITOS ............................................ 63
3.2 MODELAGEM DO SOFTWARE ....................................... 64
3.2.1 Diagramas de Atividades .................................................... 65
3.2.2 Diagrama de Estados .......................................................... 66
3.2.3 Diagrama de Caso de Uso .................................................. 66
3.2.4 Diagrama de Classes ........................................................... 67
3.2.4.1 User ....................................................................................... 67
3.2.4.2 Admin ................................................................................... 67
3.2.4.3 Session Manager ................................................................... 68
3.2.4.4 Database ................................................................................ 68
3.2.4.5 Database Connection ............................................................ 68
3.2.4.6 UserInterface ......................................................................... 68
3.2.4.7 Solver .................................................................................... 69
3.3 DESIGN DA INTERFACE .................................................. 69
3.4 DESENVOLVIMENTO DO FRONT-END ......................... 69
3.4.1 Situação Inicial .................................................................... 69
3.4.2 Estruturação do front-end .................................................. 71
3.4.2.1 Estrutura mínima para o desenvolvimento ............................ 71
3.4.2.2 Linguagens ............................................................................ 71
3.4.2.3 Bibliotecas e Frameworks ..................................................... 72
3.5 DESENVOLVIMENTO DO BACK-END ........................... 73
3.5.1 Situação inicial ..................................................................... 73
3.5.2 Estruturação do back-end .................................................. 73
3.5.2.1 Estrutura mínima para o desenvolvimento ............................ 73
3.5.2.2 Linguagens ............................................................................ 73
3.5.2.3 Bibliotecas ............................................................................. 74
3.5.3 Algoritmo ............................................................................. 74
3.5.3.1 Solver .................................................................................... 75
3.5.3.2 Sistema de Autenticação ....................................................... 77
3.5.3.3 Gerenciador do Banco de Dados ........................................... 79
3.5.4 Banco de dados .................................................................... 81
3.5.4.1 Tabela de Usuários ................................................................ 81
3.5.4.2 Tabela de Documentação ...................................................... 82
4 RESULTADOS .................................................................... 83 4.1 CAPTURAS DE TELA DO APLICATIVO ......................... 83
4.1.1 Monitor com viewport de 1440 x 900 pixels ...................... 83
4.1.1.1 Login ..................................................................................... 83
4.1.1.2 Tela de Cálculo do Trocador WOT ....................................... 84
4.1.1.3 Tela de Documentação .......................................................... 90
4.1.1.4 Tela de Gerenciamento de Usuários...................................... 92
4.1.2 Dispositivos Móveis ............................................................. 93
5 CONCLUSÃO ..................................................................... 97 5.1 SUGESTÕES PARA TRABALHOS FUTUROS ................ 97
REFERÊNCIAS .................................................................. 99
APÊNDICE A - Diagramas de Atividades ...................... 105
APÊNDICE B - Diagramas de Estados ........................... 113
APÊNDICE C - Diagramas de Caso de Uso ................... 114
APÊNDICE D - Diagramas de Classes ........................... 119
APÊNDICE E - Mock-ups das views .............................. 120
27
1 INTRODUÇÃO
1.1 MOTIVAÇÃO
O consumo energético com refrigeradores domésticos e freezers
no Brasil, em média, chega a 27% do total residencial, correspondendo
também a cerca de 6% do consumo energético nacional (PROCEL;
ELETROBRÁS, 2007).
Por conta do relativo baixo custo de fabricação, aplicam-se,
amplamente, os condensadores do tipo arame sobre tubo (WOT, do inglês
Wire-on-Tube) em refrigeradores e freezers de uso doméstico (MELO e
HERMES, 2009).
Esse tipo de condensador é composto por um tubo de aço, para
transporte do fluido, e de múltiplos arames de aço, para aumentar a
transferência de calor com o ambiente externo. Esse tubo de aço é
curvado, obtendo-se um formato de uma serpentina, e os múltiplos arames
são soldados paralelamente um ao outro, em ambos os lados do tubo
curvado (AMEEN, MOLLIK, et al., 2006). Mostra-se um desenho desse
componente na Figura 1.
Figura 1 - Trocador de calor do tipo WOT.
Fonte: (BANSAL e CHIN, 2003).
Modelos matemáticos para trocadores de calor têm sido alvo de
estudo de diversos pesquisadores da área de ciências térmicas. Dado o
potencial retorno que melhoras nesse componente podem trazer, deseja-
se encontrar o melhor conjunto de parâmetros de projeto, para entregar os
28
melhores resultados em termos de eficiência de consumo de energia, de
material e de espaço físico (BANSAL e CHIN, 2003).
Nesse contexto, o desenvolvimento de softwares de modelagem e
otimização da configuração de componentes surge como um auxílio para
a melhoria dos produtos e redução dos custos associados a testes, pois
evita a necessidade inicial de montagem da configuração para realizá-los
(BANSAL e CHIN, 2003).
Além da real possibilidade de redução de custos para o consumidor
final, a melhoria da eficiência dos condensadores contribui na redução
global do consumo de energia, sendo, então, importante no contexto de
redução de potenciais impactos do aquecimento global (TAGLIAFICO e
TANDA, 1997).
Não se encontrou, nas pesquisas realizadas, um aplicativo WEB
para dimensionamento de condensadores do tipo WOT. A falta de uma
ferramenta WEB, para aplicações como essa, dificulta o repasse de
conhecimento entre a fabricante de um componente de refrigeração e a
equipe técnica que monta soluções a partir desse componente. Essa
brecha de aplicações nesse campo que abre a oportunidade de
contribuição deste trabalho.
1.2 OBJETIVOS
1.2.1 Objetivo geral
Este trabalho estende um projeto anterior desenvolvido para uma
empresa na indústria de refrigeração. Os pontos de partida deste trabalho
foram uma série de algoritmos implementados em PHP e uma interface
de usuário em uma página WEB, voltada a aplicações científicas e de
aprendizado, porém com algumas limitações (citadas no decorrer deste
trabalho).
O objetivo deste projeto foi programar um novo aplicativo WEB,
que resolvesse as limitações da ferramenta anterior, e possuísse uma
estrutura modular e expansível para possíveis futuras funcionalidades.
1.2.2 Objetivos específicos
• Desenvolver templates de páginas e menu de navegação, para o
aplicativo WEB, de maneira que se facilite futura expansão da
ferramenta;
29
• Criar a página do trocador WOT, utilizando os cálculos do
programa antigo;
• Criar uma página de documentação que ensine usuários acerca
dos cálculos envolvidos;
• Implementar um sistema de autenticação, com diferentes níveis
de acesso de usuários;
• Hospedar a ferramenta no servidor da empresa.
31
2 FUNDAMENTAÇÃO TEÓRICA
Nesta seção, dar-se-á a descrição teórica, não exaustiva, dos
elementos utilizados ao longo deste trabalho. Inicialmente, far-se-á a
introdução teórica de orientação a objetos, para compreensão das seções
seguintes, depois dos elementos de programação WEB utilizados neste
projeto. Após isso, explicar-se-ão os principais passos adotados como
metodologia para entendimento do problema que este projeto ataca e
definição do escopo de trabalho.
2.1 ORIENTAÇÃO A OBJETOS
Para a compreensão dos diagramas de modelagem do software,
faz-se essencial a compreensão do paradigma de orientação a objetos.
Nesta seção, dar-se-á uma breve introdução sobre orientação a objetos, de
maneira a facilitar a compreensão das seções seguintes.
2.1.1 Definição
A orientação a objetos tornou-se a principal abordagem para o
desenvolvimento dos softwares modernos. Essa preferência advém das
facilidades associadas à programação não mais de uma sequência de
passos para atingir o objetivo, mas sim, focada em imaginar que o
software modela uma série de objetos que possuem características e que
executam ações (LAFORE, 2002).
Tem-se que para programas pequenos, o procedimento estrutural
de programação, por meio de uma sequência de operações, é suficiente.
Não há necessidade de um paradigma de programação, ditando princípios
de organização para o código. Porém, à medida que os programas se
tornam maiores e mais complexos, o modelo de programação estruturada
apresenta mais limitações, principalmente, por não modelar o mundo real
de maneira lógica, visto que não se pode modelar objetos como dados ou
como funções; ao contrário do paradigma de orientação a objetos, no qual
faz-se a modelagem de objetos do mundo real por meio de atributos e
métodos (LAFORE, 2002).
Nas próximas seções, apresentar-se-ão três conceitos importantes de orientação a objetos, que auxiliam na compreensão do restante deste
trabalho.
32
2.1.2 Objetos
Partindo-se da definição formal, dada por (SYKES e
MCGREGOR, 2001), um objeto é “uma entidade operacional que
encapsula tanto os valores de dados específicos quanto o código para
manipulá-los”1. De maneira mais tangível, um objeto no programa,
representa um objeto da vida real, que possui características, chamadas
atributos, e ações para acessar suas características, chamadas métodos.
Tem-se que tratando os termos do código como objetos do mundo real,
facilita-se muito o desenvolvimento de programais mais complexos
(LAFORE, 2002).
Por exemplo, um objeto chamado “Fusca” pode possuir atributos
como: cor, ano, motor, entre outros. Seus métodos podem ser: acelerar,
frear, acender os faróis, entre outros.
2.1.3 Classes
Classes são descrições de objetos similares (LAFORE, 2002), ou
seja, um conjunto de objetos que compartilham de informações
semelhantes (SYKES e MCGREGOR, 2001). Aos objetos criados a partir
de uma determinada classe, dá-se o nome de instância da classe
(LAFORE, 2002).
Por exemplo, no caso do objeto da seção 2.1.2, o Fusca, poderia
ser um objeto da classe carros, a qual possui atributos como cor, ano e
motor; e métodos como acelerar, frear , acender os faróis. A partir da
classe carro, poder-se-ia criar outros objetos, por exemplo, “Gol”.
2.1.4 Herança
Através de heranças, pode-se aproveitar características de uma
classe existente para formar uma nova classe. Chama-se essa classe base
de classe pai, e a classe que herda suas características e ações, de classe
filha (LAFORE, 2002).
Utilizando-se do mesmo exemplo que anteriormente, poder-se-ia
dizer que um “carro” é uma classe herdada de uma classe “veículo”. Desse
modo, características e métodos comuns a todos os veículos seriam herdados pela classe filha “carro”. A classe “carro” por sua vez, teria suas
particularidades, que não seriam comuns a todos os veículos.
1 Tradução feita pelo autor deste trabalho.
33
2.2 PROGRAMAÇÃO WEB
O desenvolvimento de software mudou muito nos últimos anos,
evoluindo desde os programas estáticos, feitos para operar em apenas um
tipo de hardware, até atualmente, com conexão à Internet, e operação em
diversos tipos de dispositivos. Em meados de 1980, a maioria dos
softwares era desenvolvida para operar em apenas um computador, para
resolver um problema específico. A partir de 1990, começou-se uma
tendência ao uso de sistemas distribuídos, para processamento de dados
online. Além disso, iniciou-se a propagação de páginas WEB (WOODS,
2016).
Atualmente, a Internet popularizou-se e é disponível para uma
enorme quantidade de usuários. Nesse contexto de massivo uso de
Internet, o desenvolvimento de software também sofreu migração para
plataformas WEB. Constroem-se os programas nessa plataforma
combinando-se: 1) componentes de código aberto, ou seja, pedaços de
código disponíveis para serem utilizados gratuitamente; 2) serviços
remotos disponíveis na Internet; e 3) código personalizado para a
aplicação (WOODS, 2016).
Para seu funcionamento, muitos programas mais complexos
utilizam bibliotecas e frameworks disponíveis por meio de APIs –
Interface de Programação de Aplicativos, do inglês Application User
Interface (TREUDE e ANICHE, 2018), que se tratam de um conjunto de
classes, métodos (NGUYEN, NGUYEN, et al., 2017) e funcionalidades
fornecidos por um terceiro (SAWANT e BACCHELLI, 2015).
A principal vantagem de uma API é a capacidade de reuso de
bibliotecas e funções já existentes, evitando-se, assim, o retrabalho
(SAWANT e BACCHELLI, 2015). Geralmente, a API apresenta-se por
meio de uma documentação que descreve a sua estrutura e como usá-la
(TREUDE e ANICHE, 2018).
2.2.1 Funcionamento da WEB
Objetiva-se, nesta seção, mostrar uma visão geral de como
funciona a WEB, de modo a se entender a separação do código em front-
end e back-end, e como essas partes interagem. Pode-se separar os agentes conectados à rede como clientes e
servidores. Os clientes representam-se por qualquer programa de acesso
à Internet em um dispositivo, por exemplo, um navegador. Já, os
servidores são computadores que armazenam páginas da WEB, sites,
aplicativos, APIs, entre outros. Tem-se que essa relação se inicia quando
34
o cliente faz uma requisição ao servidor. O servidor, por sua vez, responde
à solicitação do cliente (MDN WEB DOCS, 2019). Mostra-se essa
relação na Figura 2.
Figura 2 - Diagrama simples de interação entre cliente e servidor a partir de uma
requisição.
Fonte: (MDN WEB DOCS, 2019).
Desse modo, então, ao se digitar o endereço de um site na barra do
navegador, por exemplo, “google.com”, um servidor de sistema de nomes
de domínio (DNS), do inglês Domain Name System, traduzirá esse
endereço digitado para o endereço do servidor no qual o site hospeda-se,
ou seja, o seu real endereço na Internet. Tal endereço de servidor é um
código numérico chamado de número de protocolo de Internet (IP), por
exemplo “172.217.12.206”. Realiza-se essa tradução, dada a maior
facilidade das pessoas em memorizarem um texto, ao invés do conjunto
de números (MDN WEB DOCS, 2019).
Após isso, o cliente, por exemplo o navegador, envia uma
requisição do tipo HTTP (Protocolo de Transferência de Hipertexto, do
inglês Hypertext Transfer Protocol) para o servidor. Esse protocolo é
importante, pois estabelece a linguagem de comunicação entre as duas
partes. O servidor, por sua vez, responde ao cliente com o conteúdo
requisitado, que pode ser a página da WEB, por exemplo, ou um conjunto
de dados, no caso de serviços ou APIs disponíveis pela WEB (MDN WEB
DOCS, 2019).
A programação WEB pode ser dividida em duas frentes: front-end
e back-end. O back-end responde a requisições solicitadas pelo front-end,
o qual possui capacidade computacional limitada (TECHOPEDIA). Em
outras palavras, o front-end responsabiliza-se pela exibição da interface
apresentada ao cliente e o back-end possui a função de processamento de
dados (YUNRUI, 2018). A divisão do código entre front-end e back-end
simplifica o processo de programação e a manutenção de código
(TECHOPEDIA), além de reduzir custos de comunicação e aumentar a
eficiência para produção de um software (YUNRUI, 2018).
35
2.2.2 Front-End
O desenvolvimento do front-end consiste na descrição e
programação da interface gráfica com o usuário. Desse modo, é a parte
de um programa WEB relacionada à interação com o usuário e envio de
requisições para o back-end (TECHOPEDIA).
2.2.2.1 Linguagens
Nesta seção, comentar-se-á sobre diversas linguagens utilizadas no
front-end, porém, não se dará foco na sintaxe da linguagem, mas sim, no
entendimento de sua importância.
O front-end de um site WEB é composto por diversas partes, como
arquivos de textos estático, código, folhas de estilos (do inglês stylesheet),
scripts, mídias, entre outros. Nesses arquivos, predominam três
linguagens que são a base para o desenvolvimento de qualquer página no
front-end: HTML, CSS e JavaScript (MDN WEB DOCS, 2019).
2.2.2.1.1 HTML
A HTML (Linguagem de Marcação de Hipertexto, do inglês
Hypertext Markup Language), como o nome diz, não é uma linguagem
de programação, mas sim, de marcação. Isso quer dizer que ela define a
estrutura do conteúdo a ser mostrado (MDN WEB DOCS, 2019).
Os elementos em HTML são representados por tags, que
representam partes de um conteúdo. Ao ler uma tag, o navegador
reconhece como o conteúdo marcado por essa tag deve ser renderizado
(W3SCHOOLS).
Esse conceito faz-se mais claro com o exemplo do Quadro 1.
36
Quadro 1 - Exemplo em HTML.
Código em HTML Visualização no Navegador
<h1>Isto é um título nível 1</h1> Isto é um título nível 1
<h4>Isto é um título nível 4</h4> Isto é um título nível 4
<p>Isto é um parágrafo</p> Isto é um parágrafo
Fonte: do Autor (2019).
Utilizam-se, geralmente, as tags em pares, como mostrado no
exemplo do Quadro 1. Como comentado anteriormente, nota-se que o uso
delas modela a estrutura do texto aparece para o usuário.
2.2.2.1.2 CSS
Outra linguagem importante para desenvolvimento do front-end é
o CSS (Folhas de Estilo em Cascata, do inglês Cascading Style Sheets).
Introduziu-se essa linguagem para que fosse possível formatar o conteúdo
de páginas em HTML, facilitando a adição de estilos em múltiplas
páginas de uma só vez. Descrição de estilos em CSS é algo essencial para
que qualquer página da WEB não seja apenas texto sem formatação, uma
vez que a HTML não deve ser utilizada como meio de formatar uma
página WEB, mas apenas descrevê-la (W3SCHOOLS).
Para utilizar o CSS, escolhe-se o elemento que se deseja estilizar,
por exemplo, um título de nível 1. Após isso, especifica-se qual a
propriedade que deve ser alterada, como, a cor do texto. Por fim, define-
se o valor a ser atribuído para essa propriedade (MDN WEB DOCS,
2019).
A aplicabilidade do CSS torna-se mais clara por meio do exemplo
do Quadro 2. Nota-se que o código no arquivo em CSS é capaz de alterar
propriedades de estilo de um conteúdo marcado em HTML.
37
Quadro 2 - Exemplo em CSS.
Código em CSS e HTML Visualização no Navegador
h1 {
color: red;
border: 3px solid black;
}
<h1>Isto é um título nível 1</h1>
Isto é um título nível 1
Fonte: do Autor (2019).
2.2.2.1.3 JavaScript
O JavaScript é a linguagem de programação que adiciona maior
interatividade à página WEB. Por exemplo, com essa linguagem,
descrevem-se funções para responder a um evento causado pelo usuário,
como o clique em um botão (MDN WEB DOCS, 2019). Com funções em
JavaScript, pode-se alterar, criar ou apagar o conteúdo, em HTML, e
estilos, em CSS (W3SCHOOLS), além de realizar requisições ao back-
end.
Uma notação importante em JavaScript e para a WEB, devido à
frequência de uso em armazenamento e transferência de dados entre
cliente e servidor, é o JSON (Notação de Objeto JavaScript, do inglês
JavaScript Object Notation). Apesar de utilizar o formato de objetos em
JavaScript, o JSON é um formato de texto (W3SCHOOLS). Dá-se um
exemplo da notação no Quadro 3.
Quadro 3 - Exemplo de notação em JSON.
Notação em JSON
{
"Carro": [
{“modelo”: “Fusca”, "cor":"Vermelho", "ano":"1960"},
{“modelo”: “Gol”, "cor":"Azul", "ano":"1965"}
]
}
Fonte: do Autor (2019).
Nota-se, no Quadro 3, que há um conjunto de objetos tipo “carro”,
cada um com suas características de modelo, cor e ano, descritos em um
padrão textual.
38
2.2.2.2 Frameworks
O propósito do uso de frameworks para programação é facilitar o
processo de desenvolvimento, fazendo com que o foco dos
programadores seja no ato de transformar requisitos de projeto em uma
solução para os clientes. Os frameworks possibilitam que o programador
gaste menos tempo em questões ligadas ao funcionamento e estrutura da
linguagem, e mais tempo melhorando a usabilidade do programa
desenvolvido, por exemplo (TECHNOPEDIA).
Por conta do uso neste projeto, destacar-se-ão, nesta seção, dois
frameworks: Bootstrap e AngularJS.
Há uma série de fatores que devem ser levados em conta na escolha
de um framework. Inicialmente, deve-se saber que tipo de aplicação
deseja-se desenvolver e o tipo de benefício que se quer obter com o
framework (DELčEV e DRAšKOVIć, 2018).
2.2.2.2.1 Bootstrap
O Bootstrap é o framework de construção de páginas WEB que
possibilita o desenvolvimento rápido de layouts responsivos, ou seja,
layouts que se adaptam para diferentes tamanhos de tela do dispositivo
(PERUMAL, TABASSUM, et al., 2018). Esse framework faz isso por
meio de um conjunto de classes em CSS e funções em JavaScript
(BALASUBRAMANEE, WIMALASENA, et al., 2013).
A maneira como o Bootstrap realiza isso é por meio do sistema de
grade. Esse sistema divide a página em até 12 colunas. Como o sistema
de grade do Bootstrap é responsivo, essas 12 colunas podem ser
rearranjadas para que a visualização fique melhor em dispositivos com
telas menores (W3SCHOOLS). Na Figura 3 mostra-se como funciona a
divisão da tela em colunas.
Figura 3 - Divisão da página em 12 colunas com o Bootstrap.
Fonte: (W3SCHOOLS).
39
Junto à dimensão dos elementos, define-se, também, para qual
tamanho de tela de dispositivo considera-se aquela dimensão. O Bootstrap
possui por padrão quatro classes para representar o tamanho dos
dispositivos, mostradas no Quadro 4.
Quadro 4 - Classes para o sistema de grade com Bootstrap.
Código Dispositivo alvo Tamanho da tela
xs (extra pequeno) Celulares < 768 pixels de largura
sm (pequeno) Tablets > 768 pixels de largura
md (médio) Pequenos laptops > 992 pixels de largura
lg (grande) Laptops e Desktops > 1200 pixels de largura
Fonte: (W3SCHOOLS).
O uso dessas classes define o comportamento dos elementos de
interface do Bootstrap quando a página é aberta em diferentes
dispositivos.
Na Figura 4, considerou-se uma página com dois blocos de
dimensão 6, no Boostrap, com código de tamanho de tela md. A tela na
qual o dispositivo é testado possui 1000 pixels de largura, ou seja, o
tamanho da tela é maior do que md (992 pixels).
Figura 4 - Exemplo com duas colunas md-6, tela de largura 1000 pixels.
Fonte: (W3SCHOOLS).
Nota-se que o Bootstrap posiciona os elementos,
independentemente do tamanho do texto que há dentro dele, conforme a
especificação da classe utilizada, de duas colunas de dimensão 6. Mostra-
se, na Figura 5, para o mesmo exemplo, o resultado em uma tela de 900
pixels.
40
Figura 5 - Exemplo com duas colunas md-6, tela de largura 900 pixels.
Fonte: (W3SCHOOLS).
No caso da na Figura 5, como a tela do dispositivo (900 pixels) é
menor do que o tamanho especificado md (992 pixels), os componentes
em Bootstrap se modificam para melhorar o layout de visualização para
o usuário. Desse modo, garante-se que, independentemente do tamanho
de tela, a página apresentar-se-á de maneira atraente.
2.2.2.2.2 AngularJS
Como visto na seção 2.2.2.1.3, o JavaScript é uma linguagem para
adicionar comportamento dinâmico a uma página WEB. Essa linguagem
possui suporte à arquitetura MVC (Modelo-Visão-Controlador, do inglês
Model-View-Controller), que se utiliza para separar partes do código do
programa, melhorando o entendimento do código, fundamental para
grandes projetos. Diversos frameworks para a linguagem JavaScript
baseiam-se nessa arquitetura (DELčEV e DRAšKOVIć, 2018).
Nessa arquitetura, o modelo é a parte responsável pelo
gerenciamento de dados; a visão, pela exibição de dados para o usuário;
e o Controlador, pela interação entre Modelo e Visão, além da parte lógica
da página (DELčEV e DRAšKOVIć, 2018). A Figura 6 mostra como
funciona a interação entre as partes dessa arquitetura.
41
Figura 6 - Model-View-Controller.
Fonte: (FAT, VUJOVIC, et al., 2016).
O AngularJS é um framework para programação no front-end,
baseado em uma arquitetura semelhante à MVC. Dentre as vantagens que
esse framework possui, tem-se a utilização do modelo de aplicação de
página única (SPA), do inglês Single-Page Application. Esse modelo
fornece uma alternativa ao modelo tradicional de páginas WEB, o de
aplicação de múltiplas páginas (MPA), do inglês Multiple-Page
Application (OH, AHN e KIM, 2017).
Em aplicações do tipo MPA, a cada nova requisição realizada, toda
a página é recarregada. Ou seja, ao se clicar em um botão, por exemplo,
a página é totalmente recarregada, mesmo que só tenha sido modificado
um campo dela. Isso causa o efeito de tela branca, enquanto a tela é
carregada. Por outro lado, em aplicações do tipo SPA, apenas parte da
página é recarregada a cada requisição, fazendo com que a atualização da
página não gere redundância de dados e evite o efeito de carregamento de
página mencionado acima (OH, AHN e KIM, 2017), tornando o
comportamento da aplicação WEB semelhante ao comportamento de um
aplicativo Desktop, por exemplo (CHANSUWATH e SENIVONGSE,
2016).
Esse comportamento é obtido, utilizando-se observadores de
eventos (Figura 6), que percorrem laços de verificação de mudanças nas
propriedades de elementos. Quando uma mudança é vista, notifica-se o controlador dessa alteração, iniciando-se um ciclo novo com os dados
atualizados, porém, sem atualizar a página toda (FAT, VUJOVIC, et al.,
2016).
42
Uma outra característica importante do AngularJS é a
bidirecionalidade da ligação de dados2, que faz com que mudanças de
dados no modelo sejam propagadas imediatamente na visão, e mudanças
na visão (mudanças causadas por interação na interface) sejam percebidas
imediatamente no modelo (CHANSUWATH e SENIVONGSE, 2016).
Isso ocorre diferentemente do modelo unidirecional, no qual mudanças
no modelo são percebidas pela visão, mas não o contrário (KEJKAR,
KHAN e SHARMA, 2017).
Entretanto, o AngularJS é um framework que vem sendo usado
cada vez menos nos últimos anos, como mostra a consulta realizada no
Google Trends (Figura 7) para o termo AngularJS, no período de
01/01/2016 e 31/05/2019. O valor é normalizado em relação ao período
com o maior número de buscas dentro do intervalo solicitado.
Figura 7 - Interesse no tópico AngularJS nas pesquisas do Google.
Fonte: (GOOGLE TRENDS, 2019).
O decaimento no interesse ocorre devido à finalização programada
do suporte a esse framework, por parte da empresa que o criou, a Google,
tendo em vista a migração para o framework Angular, da mesma empresa.
Apesar de possuírem nomes parecidos, são frameworks diferentes.
Apesar disso, nota-se que esse framework ainda é um dos mais
utilizados. De acordo com o ranking da (HOTFRAMEWORKS, 2019),
mostrado na Figura 8, o AngularJS, representado pela linha verde clara,
2 Tradução feita pelo autor deste trabalho.
43
situa-se como um dos frameworks preferidos pelos programadores,
utilizando-se como base pesquisas em plataformas comumente usadas por
eles, como o Github e o Stack Overflow.
Figura 8 - Pesquisa de frameworks preferidos pelos programadores WEB.
Fonte: (HOTFRAMEWORKS, 2019).
2.2.3 Back-End
De maneira geral, o back-end executa funções relacionadas a
operações, processamento e armazenamento de dados, solicitadas pelo
front-end (TECHOPEDIA).
2.2.3.1 Linguagens
Nesta seção, comentar-se-á sobre as duas linguagens utilizadas no
back-end. Da mesma maneira como na descrição do front-end, não dar-
se-á foco na sintaxe da linguagem, mas sim, no entendimento de sua
importância para este projeto. Utilizaram-se duas linguagens para o
desenvolvimento do back-end: PHP e SQL.
2.2.3.1.1 PHP
O PHP (Pré-processador de Hipertexto, do inglês Hypertext Preprocessor) é uma linguagem de scripts utilizada no back-end, ou seja,
no servidor (MDN WEB DOCS, 2019). Dentro de um arquivo do tipo
PHP, pode-se conter códigos de linguagens do front-end, como HTML,
CSS e JavaScript, de modo que uma página poderia ser toda construída
44
dentro de um arquivo do tipo PHP (W3SCHOOLS). Apesar disso, como
comentado na seção 2.2.1, recomenda-se a abordagem de separação do
código.
Em termos de uso, a linguagem PHP é a mais difundida no back-
end de páginas WEB, sendo utilizadas para programar desde páginas
simples, até soluções mais complexas (GOPE, SCHLAIS e LIPASTI,
2017).
Por conta da grande adesão dessa linguagem pela comunidade de
desenvolvedores, ela possui uma vasta quantidade de extensões e serviços
disponíveis para interação com outras aplicações, aumentando-se, assim,
a eficiência de programação e o número de funcionalidades (SANTOS,
MENDONCA e MARTINS, 2008). Outro aspecto relevante da
linguagem é a facilidade de instalação e compatibilidade em servidores
HTTP, como Apache e IIS (Internet Information Services), e o suporte a
vários tipos de bancos de dados (W3SCHOOLS).
2.2.3.1.2 SQL
O SQL (Linguagem de Consulta Estruturada, do inglês Structured
Query Language) é uma linguagem utilizada para acesso e manipulação
de bancos de dados. Para aplicação dessa linguagem em páginas WEB,
utiliza-se um sistema de gerenciamento de banco de dados
(W3SCHOOLS), como o SQL Server e o MySQL, que são alguns dos
principais sistemas de bancos de dados relacionais (GOMES, 2019).
O fato de basear-se a linguagem SQL em sistemas de bancos de
dados relacionais, faz com que os dados sejam armazenados em tabelas,
com dados em linhas (entradas) e colunas (campos). O Quadro 5 mostra
um exemplo de uma tabela em um banco de dados.
Quadro 5 - Exemplo de uma tabela em um banco de dados.
id nome_aluno nota
0 Felipe 8
1 Pedro 7
2 Gabriela 8.5
Fonte: do Autor (2019).
Para consultar dados da tabela, executa-se uma query no servidor.
Essas queries são simples em SQL, com linguagem semelhante à
descrição de uma ação com a tabela. Por exemplo, ter-se-ia, para realizar
a leitura da nota do aluno “Felipe”, uma query semelhante a:
45
“SELECIONE nota ONDE nome_aluno = “Felipe”. Ao se executar essa
consulta, o servidor retornaria o valor “8”.
2.2.3.2 Bibliotecas
2.2.3.2.1 CoolProp
O CoolProp é uma biblioteca de código aberto (ou seja, livre para
uso) que implementa funções para cálculos de propriedades termofísicas
de diversos fluidos, além de métodos de interpolação, para aumento de
eficiência computacional (BELL, WRONSKI, et al., 2014).
Essa biblioteca encontra-se disponível para uso com diversas
linguagens de programação, incluindo o PHP (BELL, WRONSKI, et al., 2014).
2.3 MODELAGEM DO PROCESSO – UML
Com o aumento contínuo da complexidade dos softwares ao longo
do tempo (FERNÁNDEZ-SÁEZ, GENERO e CHAUDRON, 2012),
aliada à necessidade de entendimento de projetos desenvolvidos há
bastante tempo, a compreensão do sistema sob diferentes perspectivas
torna-se um grande desafio para os engenheiros de software (TILLEY e
HUANG, 2003).
Softwares antigos podem ter sido escritos em linguagens de
programação obsoletas, ter sido desenvolvidos em plataformas não
suportadas atualmente, e até conter adaptações para garantir o
funcionamento, as quais não estavam previstas no planejamento deles.
Por outro lado, softwares modernos podem ser realizados em múltiplas
linguagens de programação e por diferentes equipes (TILLEY e HUANG,
2003).
Nesse contexto, a modelagem de software apresenta-se como um
meio de projetar soluções de maneira correta, garantindo-se que o sistema
passou por uma análise técnica antes de se começar a desenvolver ou
alterar o código (NUGROHO e CHAUDRON, 2009). Além disso, ela
facilita o alinhamento entre o usuário final, consumidor do software, e a
equipe de desenvolvimento (FERNÁNDEZ-SÁEZ, GENERO e CHAUDRON, 2012).
Por outro lado, sob o ponto de vista de documentação, a
modelagem visa garantir a realização dela, evitando-se a perda de
informações no decorrer do projeto (NUGROHO e CHAUDRON, 2009),
46
mas também no futuro, desse modo prevenindo-se o problema de
entendimento de projeto, como mencionado acima.
Entre as possibilidades para a modelagem de software, vê-se a
Linguagem de Modelagem Unificada (UML), do inglês, Unified
Modeling Language, como um padrão no desenvolvimento de softwares
modernos. Trata-se de uma linguagem visual para descrição de requisitos
de alto nível do sistema, por meio de diagramas, formas, setas
representando funcionalidades, blocos do código e relações, por exemplo
(TILLEY e HUANG, 2003).
Por conta disso, no processo de manutenção de softwares mais
complexos, os autores (ARISHOLM, BRIAND, et al., 2006) mostram
que o uso da UML tende a resultar em maior corretude funcional, ou seja,
aderência do resultado com a especificação; além da melhora de
qualidade do projeto.
2.3.1 Detalhamento de Informações
Em se tratando de UML, outro aspecto relevante a se levar em
consideração é o nível de detalhamento de informações nos diagramas. O
nível de detalhamento refere-se à quantidade de informação utilizada para
representar o elemento modelado e, portanto, impactam no entendimento
e na manutenibilidade do modelo pelos envolvidos (NUGROHO, 2009).
Por exemplo, para o diagrama de classes, explicado com mais detalhes na
seção 2.3.2.2, um modelo com nível de detalhamento baixo apresenta
apenas o nome da classe, sem especificar detalhes como métodos e
atributos (NUGROHO, 2009), como mostrado na Figura 9.
47
Figura 9 - Diagrama de classes com baixo nível de detalhamento.
Fonte: (NUGROHO, 2009).
Por outro lado, para diagramas de classes com níveis maiores de
detalhamento, mostram-se informações sobre os métodos e atributos da
classe, nome e direção das associações, entre outros (NUGROHO, 2009),
tal como na Figura 10.
48
Figura 10 - Diagrama de classes com alto nível de detalhamento.
Fonte: (NUGROHO, 2009).
Entretanto, ao se falar sobre documentação, sempre há o
compromisso entre o valor agregado por ela, em relação ao tempo
investido. Por conta disso, diversos estudos são guiados para buscar
entender a relação entre o nível de detalhamento da modelagem e o
retorno trazido por ela (ARISHOLM, BRIAND, et al., 2006).
(NUGROHO, 2009) mostra que os benefícios de um maior nível
de detalhamento dos modelos são percebidos quando se usam eles como
guias de implementação do software. Por outro lado, como análise de alto
nível do sistema, essa relação é pouco significativa.
Deve-se então, buscar-se um ponto ótimo para a modelagem UML,
que se encaixe dentro do que realmente é necessário em termos de
documentação do software, assumindo-se o compromisso entre o retorno
causado pela boa documentação e os custos associados a ela (BRIAND,
2003).
2.3.2 Tipos de Diagramas
Nesta seção, apresentar-se-ão os principais diagramas de UML. Os
diagramas apresentados nas seções 2.3.2.1, 2.3.2.2, 2.3.2.5 e 2.3.2.8
foram elaborados no contexto deste projeto e apresentar-se-ão na seção 3.
49
Dar-se-á a explicação dos diagramas, com maior ênfase nos
diagramas elaborados neste projeto. Utilizar-se-ão, como base, os
manuais: (FOWLER e SCOTT, 2000), (RUMBAUGH, JACOBSON e
BOOCH, 2005) e (AMBLER, 2005). O objetivo desta seção não é servir
como guia para implementação de diagramas UML, mas fornecer a base
teórica para a compreensão daqueles elaborados neste projeto. Para
utilização como guia, recomenda-se o uso do manual do autor (AMBLER,
2005).
2.3.2.1 Diagramas de Caso de Uso
Antes de iniciar a explicação do diagrama, necessita-se a
compreensão dos conceitos de ator e caso de uso.
Um ator é a idealização de alguém ou algo que utiliza o sistema
modelado. Ou seja, o ator pode ser uma pessoa, uma organização, um
sistema externo, entre outros. Durante a execução do software, um
usuário dele pode ser representado por vários atores, assim como vários
usuários podem ser representados pelo mesmo ator. Representam-se os
atores por bonecos “palito” no diagrama (RUMBAUGH, JACOBSON e
BOOCH, 2005).
Já, um caso de uso é uma funcionalidade vista externamente pelos
atores, representando um comportamento do sistema (RUMBAUGH,
JACOBSON e BOOCH, 2005). Também pode ser visto como uma
sequência de ações que geram valor a um ator. Representa-se um caso de
uso por uma elipse no diagrama (AMBLER, 2005).
Um diagrama de caso de uso é, então, segundo (RUMBAUGH,
JACOBSON e BOOCH, 2005), “um diagrama que mostra os
relacionamentos entre atores e casos de uso dentro de um sistema”3.
Os casos de uso podem participar de diversos tipos de
relacionamento: associação, generalização, inclusão e extensão.
Representam-se os relacionamentos por linhas no diagrama de caso de
uso (RUMBAUGH, JACOBSON e BOOCH, 2005).
A associação possui a função de conectar um caso de uso com um
ator que participa desse caso (RUMBAUGH, JACOBSON e BOOCH,
2005).
A generalização ocorre quando há um caso de uso, ou um ator, que é semelhante a um caso de uso base, ou um ator base, e herda
características do seu parente, além de possuir outras características
próprias (FOWLER e SCOTT, 2000).
3 Tradução feita pelo autor deste trabalho.
50
Em um relacionamento do tipo include, um caso de uso base pode
adicionar comportamentos de outro caso de uso (RUMBAUGH,
JACOBSON e BOOCH, 2005), e sabe-se quando esse novo caso de uso
será invocado, ou seja, sabe-se que em determinado momento, uma
função, por exemplo, será invocada no código (AMBLER, 2005).
Já, um relacionamento do tipo extend, ocorre quando se insere um
comportamento adicional em um caso de uso tido como base, dentro de
determinadas condições, chamadas de pontos de extensão (FOWLER e
SCOTT, 2000). Desse modo, não se sabe quando esse caso de uso pode
acontecer e nem se ele vai ou não acontecer (AMBLER, 2005).
Esses conceitos ficam mais claros com um exemplo de diagrama
de caso de uso, como o mostrado na Figura 11.
Primeiramente, nota-se a existência de dois atores: o estudante e o
estudante internacional. O estudante internacional herda diversas
características de um estudante regular, por isso, há uma seta, partindo do
estudante internacional, apontada para o estudante. Entre os casos de uso,
há generalização no de “matricular um membro da família na
universidade”, que é um caso específico de “matricular um estudante na
universidade”.
Além disso, nota-se que há uma extensão entre os casos de uso
“fazer a verificação de segurança” e “matricular o estudante na
universidade”. Isso ocorre, pois há uma sequência lógica entre esses dois
casos de uso, que podem fazer com que o segundo caso de uso seja, ou
não, executado.
Por fim, há uma inclusão entre “matricular o estudante na
universidade” e “matricular no seminário”, pois sabe-se que a matrícula
no seminário será realizada e sabe-se quando isso vai ocorrer.
51
Figura 11 - Diagrama de caso de uso.
Fonte: (AMBLER, 2005).
2.3.2.2 Diagramas de Classe
Utilizam-se os diagramas de classe para exibir as classes do
sistema, as relações entre elas e os principais atributos e métodos delas.
Esse tipo de diagrama auxilia na implementação de softwares com
orientação à objetos (AMBLER, 2005).
As associações são as linhas que conectam as diversas classes no
diagrama. Associações mais complexas, que possuem atributos e métodos
para representá-las, podem ser inseridas em um diagrama de classes por
meio de linhas tracejadas (AMBLER, 2005).
Uma associação também pode conter multiplicidade, indicando o
número de objetos (exemplares de uma classe) que podem conter naquela
associação. A multiplicidade é representada por números acima da linha
de associação. Por exemplo, uma associação do tipo 1:*, indica que há
uma instância da primeira classe, para múltiplas instâncias da segunda
classe (RUMBAUGH, JACOBSON e BOOCH, 2005).
Mostra-se um exemplo de diagrama de classes na Figura 12. Nota-
se que é possível, que nenhum estudante esteja relacionado a um curso,
mas um estudante pode estar relacionado a múltiplos (*) cursos. A relação
que une os estudantes e o curso é uma matrícula, que possui atributos e
métodos próprios.
52
Figura 12 - Diagrama de classes.
Fonte: (AMBLER, 2005).
Utiliza-se uma simbologia em diagramas de classes para indicar a
visibilidade de um atributo ou método, de acordo com o mostrado no
Quadro 6.
Quadro 6 - Algoritmo do solver.
Símbolo Descrição
+ Visibilidade pública, acessível a qualquer objeto no sistema
- Visibilidade privada, acessível à classe que o implementa
# Visibilidade protegida, acessível à classe que o implementa
e subclasses
~ Visibilidade no pacote, acessível à classes do mesmo pacote Fonte: (AMBLER, 2005).
2.3.2.3 Diagramas de Objetos
Utilizam-se diagramas de objetos para exibir instâncias, por
exemplo, de um diagrama de classes, em determinado período. Desse
modo, pode-se explorar situações reais de relacionamentos entre objetos
do sistema (AMBLER, 2005).
Utilizando-se como exemplo, novamente, o do estudante, nota-se
que no diagrama de objetos, dá-se nome às instâncias das classes, e criam-
se variações delas, simulando possibilidades de execução real, conforme
mostrado na Figura 13.
53
Figura 13 - Diagrama de objetos.
Fonte: (AMBLER, 2005).
2.3.2.4 Diagramas de Pacote
Pacotes de classes representam um conjunto de classes que
possuem algo em comum, por exemplo, funcionalidades semelhantes,
implementação conjunta, alta colaboração entre elas (AMBLER, 2005).
Não se dispõe de regras para a separação de pacotes, mas deve-se ter em
mente que esse procedimento visa facilitar a manutenção do modelo
(RUMBAUGH, JACOBSON e BOOCH, 2005).
Um diagrama de pacotes, então, simboliza a relação entre diversos
pacotes de um modelo. Dentro de cada pacote, podem conter classes,
relações entre elas, casos de uso, e tudo o que seja exclusivo para aquele
pacote (RUMBAUGH, JACOBSON e BOOCH, 2005).
Os pacotes são representados por desenhos semelhantes a uma
pasta e as relações, por linhas tracejadas com uma seta ao final
(RUMBAUGH, JACOBSON e BOOCH, 2005).
A Figura 14 mostra um exemplo de diagrama de pacotes para um
subsistema de compra de tickets. Nota-se que é possível haver pacotes
dentro de pacotes, no caso de esses pacotes possuírem características
semelhantes. Além disso, há a dependência de pacotes externos para o
funcionamento de classes dentro de um pacote, por exemplo, alguma
classe do pacote de “seleção de assento” necessita algum atributo ou
método de alguma classe do pacote de “banco de dados de assentos”.
54
Figura 14 - Diagrama de pacotes.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
Pode-se montar, também, diagramas de caso de uso para pacotes,
como uma forma de organizar requisitos de uso (AMBLER, 2005).
2.3.2.5 Diagramas de Sequência
No diagrama de sequência, representa-se uma série de interações
entre objetos, descrevendo-se a mensagem passada entre eles e a ordem
(no tempo) em que elas são enviadas. Para isso, utiliza-se a dimensão
vertical do diagrama para o tempo e a horizontal, para a participação dos
objetos na interação (RUMBAUGH, JACOBSON e BOOCH, 2005).
Na Figura 15 mostra-se um exemplo de diagrama de sequência,
novamente, para a compra de tickets. Nota-se a sequência de atividades
que ocorre para a compra. Inicia-se a sequência com a solicitação do
totem de atendimento, controlado por um usuário, passando-se a
responsabilidade para o caixa. Após isso, os assentos disponíveis são
mostrados e a responsabilidade retorna para o totem para a seleção. E
assim por diante, até a conclusão da compra.
55
Figura 15 - Diagrama de sequência.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
A linha pontilhada na vertical representa a lifeline do objeto ao
longo do tempo, ou seja, o que acontece durante a vida daquele objeto. A
quantidade de tempo aumenta no eixo vertical de cima para baixo
(RUMBAUGH, JACOBSON e BOOCH, 2005).
2.3.2.6 Diagramas de Comunicação
Assim como o diagrama de sequência, o diagrama de comunicação
também mostra a interação entre os objetos, mas de maneira mais
explícita (RUMBAUGH, JACOBSON e BOOCH, 2005), mostrando o
papel de cada um deles na colaboração para a execução de alguma
operação (AMBLER, 2005). Como não há uma dimensão de tempo, ao
56
contrário do diagrama de sequência, dá-se a noção de sequência
utilizando-se números sequenciais no diagrama (RUMBAUGH,
JACOBSON e BOOCH, 2005).
Utilizando-se o mesmo exemplo do diagrama de sequência, de
compra de tickets, mostra-se um exemplo de diagrama de comunicação
na Figura 16.
Figura 16 - Diagrama de comunicação.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
Nota-se, novamente, a existência de um totem de compras. A
primeira interação começa no ato de uma requisição desse totem, indicada
por um número 1, seguida por uma busca no banco de dados, número 2.
Assim por diante, até retornar ao totem, no número 4, apresentando-o a
oferta de assentos. A interação segue até a efetuação da compra.
2.3.2.7 Diagramas de Máquina de Estados
Por meio dos diagramas de máquina de estados, pode-se
representar o comportamento dinâmico do programa, a partir de certo
57
estado, provocado por eventos. Com isso, prevê-se os rumos do programa
quando esse é submetido a um evento (AMBLER, 2005).
Um estado pode ser definido por um conjunto de valores para os
objetos em determinado período, que possuem um comportamento
idêntico (RUMBAUGH, JACOBSON e BOOCH, 2005). Ou seja, para
determinado estado, por exemplo, um estado “A”, o comportamento dele
a um evento “X” será sempre igual.
No diagrama, desenha-se o estado em um retângulo com bordas
arredondadas. As transições entre estados representam-se por setas e as
condições de transição apresentam-se junto às setas (RUMBAUGH,
JACOBSON e BOOCH, 2005). Na Figura 17, mostra-se um exemplo de
diagrama de estados.
Figura 17 - Diagrama de estados.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
Nota-se, no exemplo, que há um estado inicial de “Aguardo”. Esse
estado aguarda um evento, que pode ser de valor da ordem recebida
“maior do que 25” ou “menor do que 25”. Para cada caso, ocorre a
transição para um estado diferente. Espera-se chegar ao estado de
“Processar Ordem”.
58
2.3.2.8 Diagramas de Atividades
Os diagramas de atividades mostram uma sequência de atividades
realizadas em um programa. Esses diagramas fornecem suporte para
ilustrar tanto comportamentos condicionais quanto paralelos das
atividades (FOWLER e SCOTT, 2000). Faz-se isso por meio de um grafo
de nodos e fluxos, mostrando o fluxo de controle no decorrer do programa
executado (RUMBAUGH, JACOBSON e BOOCH, 2005). Desse modo,
lendo-se o diagrama de cima para baixo, pode-se compreender os passos
de computação para atingir determinado resultado.
Nesse tipo de diagrama, representam-se as atividades por um
retângulo de bordas arredondadas e os fluxos de controle, por setas. Além
disso, pode-se haver pontos de sincronização, que podem ser do tipo join
ou fork, ambos representados por uma barra horizontal. Nos pontos do
tipo join, aguarda-se o encerramento das atividades que se conectam na
região superior da barra, antes de dar início à atividade conectada na
região inferior dela. O inverso dos pontos do tipo join são os do tipo fork,
nos quais, a partir de uma atividade conectada na parte superior da barra,
executam-se outras atividades em paralelo, conectadas na parte inferior
dela (RUMBAUGH, JACOBSON e BOOCH, 2005).
Na Figura 18 mostra-se um exemplo de um diagrama de atividades.
Além dos elementos citados anteriormente, há também um losango entre
algumas atividades. Essa forma indica que a passagem por aquela
atividade para a próxima é condicional, ou seja, há um ponto de decisão
do programa, que precisa respeitar as condições daquele ponto para ter
prosseguimento (AMBLER, 2005).
O exemplo da Figura 18 se trata do processamento de uma ordem.
O círculo preto preenchido representa o início do processo. Após a
configuração inicial da ordem, há um ponto de decisão, verificando se é
uma “ordem única” ou se é uma “inscrição”. Para cada caso, há um fluxo
de programa diferente. É importante ressaltar que, caso os dois fluxos de
código voltem a se cruzar novamente, um novo símbolo condicional deve
ser colocado para juntar os fluxos. Isso ocorre no segundo losango do
exemplo da Figura 18. O círculo preto preenchido com um círculo de raio
maior ao seu redor indica o fim do processo.
59
Figura 18 - Diagrama de atividades.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
2.3.2.9 Diagramas de Componentes
Um componente pode representar um sistema físico ou uma parte
de um sistema que possua uma lógica. Tem-se que o comportamento de
um componente pode ser descrito de maneira concisa e suas interfaces
com outros componentes também. Desse modo, por meio de um diagrama
de componentes, pode-se compreender o papel daquele componente no
sistema, suas interfaces com o mundo externo a ele, ou seja, com outros componentes e o sistema, mas não se compreende detalhes de sua
implementação. Desse modo, pensando-se num sistema como um todo,
poder-se-ia trocar um componente por outro que possua a mesma
60
funcionalidade e as mesmas interfaces (RUMBAUGH, JACOBSON e
BOOCH, 2005).
Os componentes podem possuir interfaces que eles suportam,
assim como eles necessitam de interfaces para poder funcionar. Pode-se
pensar nessas interfaces como uma relação de dependência entre
múltiplos componentes (RUMBAUGH, JACOBSON e BOOCH, 2005).
No diagrama, as interfaces suportadas representam-se por um
círculo fechado e as interfaces necessárias, por um círculo semiaberto.
Portas são representadas por um quadrado e as interfaces devem estar
atreladas a uma porta (RUMBAUGH, JACOBSON e BOOCH, 2005).
Mostra-se um exemplo de diagrama de componentes na Figura 19.
Figura 19 - Diagrama de componentes.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
Um componente pode ser feito de outros componentes, que
também possuem interfaces. Nota-se, no exemplo da Figura 19, que o
componente “Sistema de Viagens” é feito com diversos outros
componentes conectados internamente. Há um console com o usuário,
como entrada de dados, e como saída, tem-se a realização da reserva.
2.3.2.10 Diagramas de Implementação
O diagrama de implementação mostra uma visão do sistema como
um todo, em termos de componentes de hardware e software. Usa-se esse
tipo de diagrama para analisar dependências que o sistema possa possuir
61
e prever possíveis problemas de instalação, por exemplo, definindo uma
estratégia de implementação (AMBLER, 2005).
Nesse diagrama, pode-se ver o arranjo físico de nodos, ou seja,
recursos computacionais, representados por um paralelepípedo. Por
exemplo, no diagrama da Figura 20, mostra-se um nodo “servidor”, que
se comunica com o nodo “cliente”. Os nodos podem conter artefatos, que
são as entidades físicas, no caso do exemplo, um arquivo “.jar”. Porém,
podem ser artefatos do tipo banco de dados, páginas da WEB,
executáveis, entre outros (RUMBAUGH, JACOBSON e BOOCH, 2005).
Figura 20 - Diagrama de implementação.
Fonte: (RUMBAUGH, JACOBSON e BOOCH, 2005).
63
3 METODOLOGIA
No presente capítulo, descrever-se-á o desenvolvimento deste
trabalho, considerando-se as principais etapas da execução: análise de
requisitos, modelagem do software, definição de design e interações com
o usuário do software, desenvolvimento do front-end e do back-end.
Nas seções referentes ao desenvolvimento, apresentar-se-ão tanto
as condições do trabalho anteriormente elaborado, quanto as
contribuições deste trabalho.
3.1 ANÁLISE DOS REQUISITOS
Satisfazendo as metodologias de desenvolvimento de software
convencionais, inicialmente, buscou-se a compreensão do problema junto
aos potenciais clientes da ferramenta. Para isso, realizou-se uma reunião
para entendimento do problema do cliente e percepção sobre possíveis
soluções.
Nessa reunião, o cliente relatou as dificuldades encontradas no
dimensionamento de componentes de sistemas de refrigeração,
destacando, principalmente:
• a despadronização dos métodos de cálculos entre os diferentes
setores de P&D (Pesquisa e Desenvolvimento) dentro da
empresa, devido à falta de uma ferramenta unificada e utilizada
por todas as áreas;
• a dificuldade de repasse de informações aos parceiros de áreas
que não são de P&D, por conta do alto nível de complexidade da
linguagem utilizada nos softwares de engenharia disponíveis na
empresa.
Além disso, o vasto volume de conhecimento que a empresa
acumulou ao longo dos anos, através de P&D interno e de parcerias com
universidades, apresentou-se como uma possibilidade para expansão
futura da ferramenta.
Como resultado da etapa de análise dos requisitos, listaram-se os
necessários do software a ser desenvolvido:
1. Interface WEB, no padrão visual da empresa;
2. Menu de navegação;
3. Facilmente expansível;
4. Compatível com IIS e Microsoft SQL Server.
64
A partir desses requisitos, apresentou-se um conjunto de propostas
de componentes que poderiam ser integrados à ferramenta. Por decisão
do cliente, optou-se por fazer um aplicativo para dimensionamento de
trocadores de calor WOT. Desse modo, a ferramenta deveria, a partir de
parâmetros inseridos pelo usuário, calcular, utilizando propriedades
termodinâmicas, os resultados para o dado dimensionamento.
Com base na decisão supracitada, listaram-se novos requisitos para
a parte visual da ferramenta:
1. Campos de inserção para propriedades geométricas do trocador;
2. Campos de inserção para propriedades físicas do fluido utilizado;
3. Botões de cálculo para execução das funções do aplicativo;
4. Dados de entrada do usuário e resultados do cálculo aparecendo
na mesma tela;
5. Geração de gráficos;
6. Possibilidade de inserção de um conjunto de entradas para obter
um conjunto de saídas;
7. Possibilidade de exportação dos dados em formato de texto.
Nos itens 4 e 6 da lista de requisitos, destacam-se duas dificuldades
anteriormente enfrentadas pelo cliente: a primeira, pela impossibilidade,
no software anterior, de se comparar o valor colocado na entrada e o
resultado do cálculo; e a segunda, no processo de geração de curvas, no
qual se fazia necessária a repetição do cálculo diversas vezes, alterando-
se os parâmetros manualmente.
3.2 MODELAGEM DO SOFTWARE
Neste capítulo, como forma de modelagem do software
desenvolvido, apresentar-se-ão diagramas de UML, que se consideraram
relevantes para o procedimento do trabalho. Usaram-se os diagramas para
modelagem do sistema, com fim de entendimento do problema e
direcionamento para a solução. Não se esperava partir do diagrama UML
diretamente para um código.
Para compreensão do sistema como um todo, a Figura 21 mostra o
comportamento esperado para um usuário comum do software, ou seja,
um usuário não administrador. De maneira mais resumida, espera-se que o usuário logue no aplicativo, insira parâmetros para os cálculos e
visualize os resultados.
65
Figura 21 - Visão Geral de Uso do Sistema.
Fonte: do Autor (2019).
Descrever-se-ão, nas próximas seções, outras funcionalidades do
software, de maneira não exaustiva, buscando-se, primariamente, a
compreensão geral acerca do processo de desenvolvimento e
funcionamento do sistema. Nessa etapa, adotou-se um ponto
intermediário de detalhamento dos diagramas, tendo em vista a ideia de
entendimento do problema e não implementação da solução por terceiros.
Por conta disso, processos chave do software apresentam-se com maior
nível de detalhamento, ao passo em que outros possuem maior abstração.
3.2.1 Diagramas de Atividades
Desenharam-se os diagramas de atividades para diferentes usos do
aplicativo, separando-os entre back-end e front-end.
Entre os diagramas do front-end, descreveram-se a atividade de
login, a de cálculo simples, com um conjunto de parâmetros, e a de
cálculo multiparamétrico, com vários conjuntos de parâmetros. Entende-
InícioLogar no sistema
Navegar nos menus
Inserir parâmetros de
cálculo
Pressionar botão de cálculo
Aguardar resultados
Salvar resultados
Visualizar resultados
66
se um conjunto de parâmetros, como os parâmetros necessários para
chegar aos resultados para dada geometria e propriedades do fluido.
Múltiplos conjuntos, então, geram múltiplos resultados, podendo-se
traçar uma curva de comportamento de um resultado, com base na
variação de um parâmetro.
Também, nos diagramas do back-end, descreveram-se os fluxos de
atividades para a realização do cálculo e acesso ao banco de dados.
Por conta do tamanho dos diagramas, a fim de melhorar a
visualização deles, preferiu-se mostrá-los nas figuras do APÊNDICE A.
3.2.2 Diagrama de Estados
Desenhou-se um diagrama de estados para um usuário comum,
considerando-se a utilização para o cálculo do trocador WOT, conforme
especificado em 3.1.
Para facilitar a visualização do diagrama, desconsiderou-se alguns
estados possíveis não tão usuais e designou-se nomes arbitrários para os
botões que geram eventos na interface do aplicativo.
Os estados compreendidos neste diagrama representam os
templates das views que são mostradas ao usuário. Desse modo, o que o
usuário vê seria, por exemplo, a tela de login, a tela de cadastro, a tela de
recuperar senha, e assim por diante, conforme mostrado no APÊNDICE
B. Nas telas que possuem diferentes visualizações, que dependem do
nível de acesso do usuário (AL), adicionou-se uma barra vertical (“|”),
para representar um filtro de seleção de componentes na página.
3.2.3 Diagrama de Caso de Uso
Desenvolveu-se o diagrama de caso de uso para três níveis de
usuário do aplicativo: administrador do sistema, especialista e técnico.
O administrador é o usuário capaz de administrar o acesso de
usuários, cadastrando-os ou removendo-os no banco de dados; e o texto
presente na página de documentação, também salvo no banco de dados.
O especialista é o usuário que pode realizar dimensionamento de
trocadores WOT, possuindo acesso a mais parâmetros de inserção, antes
do cálculo; e mais campos de visualização, após o cálculo. Por fim, o técnico é o usuário que também pode realizar
dimensionamento de trocadores WOT, porém não possui acesso a
parâmetros mais específicos, facilitando o uso em atividades cotidianas.
Os diagramas de caso de uso, considerando os três possíveis níveis
supracitados, apresentam-se nas figuras do APÊNDICE C.
67
3.2.4 Diagrama de Classes
O diagrama de classes do aplicativo apresenta-se no APÊNDICE
D. Para sua construção, levou-se, em consideração, as seguintes classes:
3.2.4.1 User
Trata-se de um usuário do aplicativo que, portanto, pode ser tanto
de nível especialista, quanto de nível técnico.
Estes usuários são diferenciados pelos seus atributos: e-mail,
senha, nível de acesso e token. Os dois primeiros atributos são utilizados
para acessar o aplicativo, através da tela de login. Utiliza-se o nível de
acesso para classificar o usuário e mostrar a ele as informações adequadas
para a sua necessidade.
Ambos os níveis de usuário supracitados possuem acesso às
mesmas páginas. Porém, o usuário de nível técnico pode modificar apenas
alguns parâmetros de entrada, pelo fato dos outros serem padronizados
para a sua aplicação; bem como, não pode visualizar todos os resultados
do cálculo, visto que são irrelevantes para sua aplicação e tornariam a
ferramenta menos objetiva.
O token é um código aleatório gerado no primeiro acesso, ou
primeiro acesso após logout, do usuário em um dispositivo. Ele é utilizado
para manter a sessão do usuário ativa nesse dispositivo, a fim de evitar a
necessidade de se inserir usuário e senha sempre que o usuário acessar a
ferramenta.
Os métodos, que representam as ações executadas por esses
usuários, são: solicitar login ou logout para o gerenciador de sessão
(3.2.4.3), inscrever-se no aplicativo, ler seus próprios atributos, ler a
documentação do aplicativo, ler e modificar o token local (no dispositivo
em uso) e provocar eventos através da interface. Os usuários do aplicativo
não possuem autorização para alterar os dados previamente cadastrados
no momento da inscrição.
3.2.4.2 Admin
A classe Admin é herdada da classe User. Por conta disso, ela compartilha dos mesmos atributos e métodos citados em 3.2.4.1. Porém,
além dos métodos da classe pai, ela possui métodos próprios, para
possibilitá-la a modificar o nível de acesso de outros usuários,
determinando se os novos cadastros agrupar-se-ão na categoria de
especialista ou técnico; para permitir que o administrador remova
68
usuários; e, para permitir que a documentação acessível aos outros
usuários seja alterada.
3.2.4.3 Session Manager
Trata-se de um administrador virtual para gerenciar as sessões para
os usuários logados. Seus métodos são relacionados às rotinas de criação
e encerramento de sessão, quando solicitado pelos usuários da classe User
ou pelo administrador, através da geração de um token; e à rotina de
verificação da sessão ativa em determinado dispositivo, comparando-se o
token armazenado no banco de dados e o token armazenado no
dispositivo.
3.2.4.4 Database
Esta classe representa a base de dados do aplicativo, ou seja, as
tabelas que armazenam informações. Utilizam-se as tabelas desta base de
dados para armazenar os atributos da lista de usuários, citados em 3.2.4.1,
e para armazenar o texto editável que é exibido na aba de documentação.
O único método disponível para esta classe é o de executar uma
query no banco de dados para adicionar, atualizar ou remover
informações.
3.2.4.5 Database Connection
Esta classe representa a conexão com a base de dados do
aplicativo. Por conta disso, seus atributos são: nome de usuário e senha
para acesso à base de dados, nome do servidor utilizado e nome da base
de dados, para efetuar a conexão.
Os possíveis procedimentos para essa classe são: iniciar a conexão,
encerrar comunicação e verificar o status da conexão.
3.2.4.6 UserInterface
Essa classe representa o template de interface que é comum a todas
as views. Por conta disso, seus atributos são do tipo template (em HTML, CSS e JS), sendo eles: o menu de navegação superior, o rodapé (footer) e
o conteúdo das páginas.
Os métodos para essa classe relacionam-se à decodificação de
eventos gerados pelo usuário, como por exemplo, clicar um botão e
69
preencher um formulário; e o redirecionamento para outras páginas, na
navegação do usuário.
3.2.4.7 Solver
Refere-se à classe que executa os cálculos de dimensionamento de
componentes, com base nos parâmetros passados a ela através da
interface. Desse modo, cada tipo de componente possui um objeto dessa
classe, com os métodos para: decodificar a requisição feita ao servidor,
ler os parâmetros de cálculo, realizar os cálculos para o componente em
questão e retornar os resultados para a interface.
3.3 DESIGN DA INTERFACE
Seguindo-se os requisitos citados em 3.1, esboçou-se, uma
interface conceitual e apresentou-se ela em uma reunião. Nessa reunião,
fizeram-se presentes o responsável pelo projeto na empresa e outro
potencial usuário da ferramenta, que possuía grande experiência com
ferramentas de engenharia utilizadas na empresa.
Ambos trouxeram ideias para melhorar a usabilidade da interface
e uma segunda versão dela foi elaborada a partir dessa reunião. Os
formatos que se poderia esperar para as telas são mostrados no
APÊNDICE E.
Ao final do desenvolvimento, as telas ficaram semelhantes ao
projeto, com pequenas alterações. A explicação da funcionalidade de cada
uma delas, será dada no capítulo 4.
3.4 DESENVOLVIMENTO DO FRONT-END
3.4.1 Situação Inicial
Como comentado anteriormente, dispunha-se de uma ferramenta
semelhante para realizar dimensionamento de componentes de
engenharia. Entre os problemas relatados, pela empresa com essa
ferramenta, continham: o fato de ela não possuir um padrão de parâmetros
e resultados utilizados pela empresa no dia-a-dia, inviabilizando o seu uso pelos colaboradores; e dificuldades de visualização dos dados, por conta
do layout aplicado. A Figura 22 mostra uma captura de tela da ferramenta
antiga, com os campos de inserção, resultados e métodos dos cálculos
propositalmente borrados.
70
Em relação às dificuldades de visualização, citados pela empresa,
nota-se, pela marcação 1, que os campos de inserção de parâmetros e de
resultados não podem ser visualizados ao mesmo tempo, por limitações
de espaço, visto que são muitos campos. Pelo mesmo motivo, a marcação
3 mostra que os gráficos também não podem ser visualizados lado a lado
com os resultados ou com os parâmetros de entrada.
Já, a marcação 2 refere-se ao problema de quantidade de
informação, sem a passagem de um filtro por elas, por conta da
inexistência de diferentes níveis de acesso. Nesse quadro, mostra-se o
método de cálculo utilizado pela ferramenta, que é uma informação
irrelevante para alguns usuários da ferramenta.
Figura 22 - Captura de tela de um fragmento do aplicativo antigo.
Fonte: do Autor (2019).
Além disso, fez-se toda a renderização da interface no back-end,
misturando-se a parte de código e a parte visual no mesmo arquivo,
prejudicando a manutenibilidade da ferramenta e interpretação dos
códigos. Outro aspecto negativo em relação a isso, é o efeito de “página
branca”, enquanto a nova página é carregada, ao navegar pelo menu, por
exemplo, como comentado na seção 2.2.1. Entende-se que a renderização
no back-end pode possuir vantagens em outros tipos de projetos, nos quais
não há atualização de dados com a mesma frequência.
Por conta disso, propôs-se a separação entre front-end e back-end, atribuindo-se ao primeiro a renderização (parte visual) e, ao segundo, a
execução de requisições realizadas ao servidor (acesso à base de dados e
cálculos), como uma API.
71
3.4.2 Estruturação do front-end
Dividir-se-á a estruturação do front-end em quatro partes: as
ferramentas utilizadas para a construção do aplicativo, as linguagens, as
bibliotecas e os frameworks escolhidos.
3.4.2.1 Estrutura mínima para o desenvolvimento
Para visualização do aplicativo WEB, ao longo do
desenvolvimento, fez-se necessária a utilização de um servidor WEB. O
ambiente do servidor foi um computador com sistema operacional
Ubuntu 18.04 e o servidor Apache2. Como ambiente de desenvolvimento,
utilizou-se o Sublime 3.
3.4.2.2 Linguagens
Para descrição da parte visual do front-end, utilizaram-se
linguagens padrão para aplicativos e sites WEB: HTML e CSS. A
primeira, para a descrição dos elementos que apareceriam na interface; e
a segunda, para customização desses elementos.
Os principais elementos em HTML utilizados foram: <table> e
derivados, para a construção de tabelas de entrada do usuário e de
resultados; <input>, para inserção de dados por parte do usuário; <div>,
para divisão de seções na página; e <button>, para descrever botões
utilizáveis pelo usuário.
Utilizou-se a linguagem CSS para personalização dos elementos
em HTML. Desse modo, tendo em vista os requisitos visuais do projeto,
as propriedades mais utilizadas foram as de alteração de cor dos campos,
das bordas, e das fontes; preenchimento e margem, para melhor
distribuição e posicionamento dos elementos; e propriedades dinâmicas,
para criar destaque, por exemplo, quando um usuário passa o mouse sobre
um botão.
Já, para implementação de funções mais complexas à interface,
utilizou-se a linguagem JavaScript. Com isso, foi possível chamar
funções quando algum evento é disparado, por exemplo. No aplicativo,
programaram-se as funções em JavaScript para: gerar animações de auxílio ao uso do aplicativo, utilizar pop-ups para inserção de dados e
conectar-se com o back-end através de requisições HTTP.
72
3.4.2.3 Bibliotecas e Frameworks
As bibliotecas foram essenciais para acelerar o processo de
desenvolvimento do aplicativo, dada a possibilidade de reuso de código
já desenvolvido. Para o front-end desse aplicativo, utilizaram-se
bibliotecas em CSS e Javascript.
A principal biblioteca de CSS utilizada foi o Bootstrap, com o
intuito de tornar a interface responsiva, para diferentes tamanhos de tela,
através da utilização de sistema de grids. Além disso, essa biblioteca
proporcionou o uso de diversos componentes predefinidos, facilitando o
processo de criação da interface.
Em JavaScript, utilizou-se a biblioteca Chart.js para a plotagem
dos gráficos; a biblioteca Handsontable, para utilização de planilhas de
inserção de dados por células; e a biblioteca de JavaScript do Bootstrap,
para efeitos e animações que não seriam possíveis apenas com a
biblioteca de CSS.
Para a criação de um aplicativo WEB com experiência similar a
um aplicativo equivalente em Desktop (SPA), utilizou-se o framework de
JavaScript AngularJS. Com isso, foi possível atribuir controladores
(controllers) para cada página, de modo a controlar os dados delas; filtros
(filters), para formatação de dados; diretivas (directives), para a extensão
de templates em HTML; e serviços (services), para execução de diversas
funções na aplicação.
Como previamente comentado, utilizou-se um controlador por
página, para realizar operações sobre os dados. Qualquer alteração em
alguma variável realizada pelo controlador é vista imediatamente na
interface, e vice-e-versa, devido ao mecanismo de two-way data binding.
Utilizaram-se filtros para ordenação de dados em tabelas. Não se
criaram diretivas para este projeto, pois não se viu necessidade para tal.
Por outro lado, utilizaram-se amplamente os serviços na
construção do aplicativo. Os principais serviços utilizados do AngularJS
foram: $http, relacionado a requisições HTTP para o servidor; $location,
relacionado à localização das páginas; $window, relacionado à janela do
navegador; e $sanitize, relacionado à remoção de tags potencialmente
perigosas ao aplicativo.
73
3.5 DESENVOLVIMENTO DO BACK-END
3.5.1 Situação inicial
Como comentado em 3.4.1, não se dispunha de uma separação no
código entre as linguagens de back-end e de front-end, pois ambas
estavam presentes no mesmo arquivo, dificultando a leitura e manutenção
do código.
Além disso, por ter se tratado de um protótipo, a versão antiga do
back-end não continha mecanismos de verificação dos valores inseridos
pelo usuário e nem tratadores de erros para as funções implementadas. No
front-end, verificava-se para algumas inserções, por exemplo, para
valores fora dos limites possíveis. Quando isso acontecia, uma pop-up
aparecia avisando sobre o erro de inserção. Porém, caso ocorresse algum
erro de cálculo, ou caso algum recurso do back-end estivesse
indisponível, erros poderiam acontecer, sem ocorrer tratamento e/ou
envio de feedbacks ao usuário da ferramenta.
3.5.2 Estruturação do back-end
Dividir-se-á a estruturação do back-end em 3 partes: as ferramentas
utilizadas para a construção do aplicativo, as linguagens e as bibliotecas
escolhidas. Não se utilizaram frameworks no back-end, visto que não se
encontrou necessidade para tal, ao longo da programação dessa parte.
3.5.2.1 Estrutura mínima para o desenvolvimento
Para a visualização de resultados e testes ao longo do
desenvolvimento, utilizou-se o mesmo servidor Apache2, do front-end,
rodando em um computador com sistema operacional Ubuntu 18.04.
Além disso, instalou-se o PHP 5.6, para suportar a programação na
linguagem PHP; e o MySQL 5.7.26, para rodar o banco de dados para
testes. Como ambiente de desenvolvimento, utilizou-se também o
Sublime 3.
3.5.2.2 Linguagens
Como já se dispunha dos cálculos implementados em PHP,
escolheu-se por manter essa linguagem no back-end. Essa decisão evitou
a necessidade da tradução do código já disponível para uma nova
linguagem, e focou o trabalho nessa linguagem no provisionamento do
74
servidor. Além disso, fez-se a disponibilização das funções por meio de
uma API para transferência de parâmetros e acesso aos resultados, em
PHP.
Para acesso ao banco de dados, para as funções de controle de
acesso e armazenamento de informações de documentação, utilizou-se
um banco de dados de linguagem SQL. Para a versão inicial do aplicativo,
optou-se por MySQL, pela facilidade de uso junto ao PHP e fácil
gerenciamento de informações com a ferramenta phpMyAdmin.
Desse modo, separou-se o back-end: na parte matemática, com os
cálculos e o uso da biblioteca CoolProp, citada em 3.5.2.3; e na parte de
estrutura para funcionamento do aplicativo, com a estruturação do banco
de dados e a disponibilização de APIs.
3.5.2.3 Bibliotecas
Utilizou-se a biblioteca CoolProp, para PHP, para a realização de
cálculos envolvendo as propriedades de fluidos, essencial para que o
aplicativo pudesse dimensionar o trocador de calor.
Enfrentaram-se dificuldades na configuração dessa biblioteca para
o PHP na tentativa de sua instalação em um sistema operacional de 32
bits (Raspbian), no qual se tentava rodar o servidor. O problema
encontrado foi o da não possibilidade de se compilar a biblioteca em
sistema operacional de 32 bits, por conta de flags de compilação para 64
bits. Além disso, a biblioteca em versões mais antigas não funcionava
com as versões mais novas do PHP. Após inúmeras tentativas, optou-se
por rodar o servidor no sistema operacional Ubuntu 18.04, de 64 bits,
como comentado na seção 3.5.2.1, no qual não se encontraram mais
problemas para instalação.
3.5.3 Algoritmo
Nesta seção, descrever-se-ão os algoritmos base para as principais
funções adaptadas ou implementadas no PHP. Entende-se que todas as
rotinas implementadas se baseiam nesses algoritmos com poucas
mudanças.
As chaves “{“ e “}” indicam, respectivamente, o início e o final de um trecho de código de iteração ou de condição. Utilizou-se os colchetes
“[“ e “]” para acessar índices das variáveis tipo vetor, de uma dimensão,
ou matriz, de mais dimensões. Usou-se os parênteses “(“ e “)” para a
transferência de parâmetros para as funções. O símbolo de reticências “...”
indica que naquela parte do código ocorre uma sequência de operações
75
semelhantes. A seta “->” indica acesso a algum atributo ou método do
objeto. O texto entre “/* */” indica o comentário da função da linha.
3.5.3.1 Solver
Mostra-se o algoritmo do solver no Quadro 7. Esta parte do
aplicativo responsabiliza-se por realizar o dimensionamento, através da
resolução do problema térmico, com base nos parâmetros passados.
Quadro 7 - Algoritmo do solver.
Algoritmo
aguardar_requisicao_servidor() {} /* Arquivo aguarda requisição do
servidor */
se(recebeu_requisicao == true) { /* Evento de requisição do servidor */
parametros[] =
converter_json_para_vetor_objeto(ler_parametros_recebidos()) /* Lê os
parâmetros enviados junto à requisição, ou seja, os parâmetros de cálculo
*/
numero_de_sistemas = conta_tamanho(parametros[]) /* Verifica a
quantidade de objetos de parâmetros, ou seja, quantos sistemas devem ser
simulados */
iterar(de numero_iteracao_sistema = 1 ate numero_de_sistemas) { /*
Iterador para buscar a solução para cada sistema a ser simulado */
se(checa_validade_parametros(parametros[numero_iteracao_sistema])
== valido) { /* Verifica se os parâmetros estão íntegros e se são
compatíveis com o cálculo solicitado (API genérica) */
continua()
}
se_nao {
retorna_erro()
finaliza()
}
76
parametros_si =
converter_unidades(parametros[numero_iteracao_sistema]) /* Realiza
conversão dos parâmetros para o sistema internacional de medidas,
para uso nos cálculos */
iterar(de numero_iteracao_passo 1 ate numero_passos) { /* O número
de passos que serão dados no cálculo, o que define a precisão do
cálculo. Por exemplo, para um tubo de 1 metro, 10 passos, significaria
que os cálculos seriam realizados para 10 centímetros, 20 centímetros e
assim em diante até 1 metro */
se(parametros_si->parametro_1 == condicao_1) { /* Verificações e
cálculos: a partir desse trecho, o software faz verificações e direciona
os cálculos, salva os valores em variáveis e realiza todos os cálculos
para cada passo indicado */
variavel_1[numero_iteracao_passo] = calculo_CoolProp_caso_1()
}
se_nao {
variavel_1[numero_iteracao_passo] =
calculo_CoolProp_nao_caso_1()
}
...
se(parametros_si->parametro_N == condicao_N) { /* Por exemplo,
verifica se algum parâmetro é um valor ou outro, ou se está dentro de
um range de valores, para ver qual função utilizar. Como não há um
padrão de verificação, não se pôde utilizar outro loop */
variavel_N[numero_iteracao_passo] = calculo_CoolProp_caso_N()
/* Salva o valor de um resultado para aquele passo */
}
se_nao {
variavel_N[numero_iteracao_passo] =
calculo_CoolProp_nao_caso_N()
}
77
}
resultados_sistemas[numero_iteracao_sistema] =
criar_objeto(variavel_1[]..., variavel_N[]) /* Salva um objeto com os
resultados de cada passo para aquele sistema */
}
responder_para_servidor(converter_vetor_objeto_para_json(resultados_s
istemas[])) /* Retorna os resultados para o solicitante através do servidor
*/
}
Fonte: do Autor (2019).
3.5.3.2 Sistema de Autenticação
Mostra-se o algoritmo do Sistema de Autenticação no Quadro 8.
Programou-se esta parte do aplicativo para controlar os acessos ao
aplicativo, direcionar os usuários para as páginas corretas e gerenciar as
informações e permissões de usuários.
Quadro 8 - Algoritmo do Sistema de Autenticação.
Algoritmo
aguardar_requisicao_servidor() {} /* Arquivo aguarda requisição do
servidor */
se(recebeu_requisicao == true) { /* Evento de requisição do servidor */
parametros = converter_json_para_objeto(ler_parametros_recebidos()) /*
Lê os parâmetros enviados junto à requisição, ou seja, os parâmetros da
operação com usuários a ser realizada */
se(checa_validade_parametros(parametros == valido) { /* Verifica se os
parâmetros estão íntegros e se são compatíveis com a operação com
usuários solicitada (API genérica) */
continua()
}
se_nao {
78
retorna_erro()
finaliza()
}
seleciona(parametros->funcao_escolhida) { /* Um seletor para escolher,
dentre as funções escolhidas, qual será o direcionamento do código */
caso "login": /* Quando o usuário já é cadastrado e solicita um login */
se(checa_credenciais_usuario(parametros->username, parametros-
>senha) == "ativo") {
cria_token_usuario(parametros->username) /* Um token para
manter sua sessão ativa é criado */
redirecionar_usuario(parametros->nivel_acesso) /* Redireciona o
usuário para a página inicial do seu nível de acesso */
}
se_nao() {
retorna_erro()
}
caso "logout": /* Deleta o token e torna o usuário inativo naquele
dispositivo até um novo login */
deleta_token_usuario(parametros->username)
caso "novo_usuario": /* Quando o usuário se cadastra na ferramenta */
se(checa_informacoes(parametros) == "ok") {
solicita_insercao_usuario(parametros) /* O usuário é inserido na
base de dados, mas ainda não pode acessar antes da aprovação do
Administrador */
}
se_nao {
retorna_erro()
79
}
caso "modificar_acesso": /* Função disponível para o Administrador,
para alterar o status de algum usuário */
modificar_acesso(parametros->username, nivel)
caso "recuperar_senha": /* Quando o usuário perde a sua senha e deseja
recuperá-la */
enviar_codigo_recuperacao(parametros->username, parametros-
>informacoes_recuperacao)
caso "atualizar_senha": /* Quando o usuário pretende alterar a senha */
se(checa_informacoes(parametros) == "ok") {
atualiza_senha(parametros->username, parametros->senha)
}
se_nao {
retorna_erro()
}
}
responder_para_servidor(codigo_resposta) /* Retorna código de sucesso
ou erro para o servidor */
}
Fonte: do Autor (2019).
3.5.3.3 Gerenciador do Banco de Dados
Mostra-se o algoritmo do Gerenciador do Banco de Dados no
Quadro 9. Essa parte do código no back-end serve para executar queries
e acessar os dados salvos no banco de dados do aplicativo, tanto na base
de usuários quanto na base de documentação.
80
Quadro 9 - Algoritmo do Gerenciador do Banco de Dados.
Algoritmo
aguardar_requisicao_servidor() {} /* Arquivo aguarda requisição do servidor */
se(recebeu_requisicao == true) { /* Evento de requisição do servidor */
parametros = converter_json_para_objeto(ler_parametros_recebidos()) /* Lê
os parâmetros enviados junto à requisição, ou seja, os parâmetros da
operação com usuários a ser realizada */
se(checa_validade_parametros(parametros == valido) { /* Verifica se os
parâmetros estão íntegros e se são compatíveis com a operação de banco de
dados solicitada (API genérica) */
continua()
}
se_nao {
retorna_erro()
finaliza()
}
seleciona(parametros->funcao_escolhida) { /* Um seletor para escolher,
dentre as funções escolhidas, qual será a query executada no banco de dados
*/
caso "inserção": /* Quando se deseja inserir algo na tabela */
query = "INSERE NA tabela_1 (colunas) VALORES (parametros-
>valores)"
caso "remoção": /* Quando se deseja remover algo da tabela */
query = "DELETA DE tabela_1 ONDE coluna_1 = parametros-
>condicoes[1]"
caso "edição": /* Quando se deseja atualizar algo na tabela */
query = "ATUALIZA tabela_1 COLOQUE coluna_1 = parametros-
>valores[1] ONDE coluna_2 = parametros->condicoes[2]"
caso "consulta": /* Quando se deseja ler dados da tabela */
query = "SELECIONA DE tabela_1 ONDE coluna_1 = parametros-
>condicoes_1"
}
81
se(verifica_credenciais(parametros->usernameDB, parametros->senhaDB)
== "ok") { /* Se as credenciais do usuário estão de acordo para se conectar,
executa a query */
resultado = executar_query(parametros->query)
responder_para_servidor(converter_vetor_objeto_para_json(resultado)) /*
Retorna resultados da consulta */
}
se_nao {
retorna_erro()
}
}
Fonte: do Autor (2019).
3.5.4 Banco de dados
Como comentado anteriormente, necessitava-se a adição de níveis
de acesso para diferentes usuários castrados na ferramenta. Além disso,
precisava-se salvar informações de documentação.
3.5.4.1 Tabela de Usuários
Fez-se uma tabela para usuários com as seguintes colunas: “id”
(tipo número inteiro), “email” (tipo string “VARCHAR”), “password”
(tipo string “VARCHAR”), “access_level” (tipo número inteiro) e
“token” (tipo string “VARCHAR”). A coluna de “id” incrementa-se
automaticamente e serve como uma chave para cada linha da tabela,
facilitando-se o acesso de informações. Além disso, para manter a
segurança das senhas inseridas, armazenaram-se elas utilizando-se a
criptografia MD5.
No Quadro 10, mostra-se o formato dessa tabela no banco de
dados, populada com dados meramente ilustrativos.
82
Quadro 10 - Tabela de Usuários no Banco de Dados.
id email password access_level token
0 [email protected] 1e877f98d8b... 0 34vryr66
1 [email protected] 493e8f9a9c3... 1 53hg535
2 [email protected] 42354efaa44... 2 y34534g
3 [email protected] 65465efa841... 1 645huki
Fonte: do Autor (2019).
Cada entrada da tabela é representada por uma linha. Tem-se que
há apenas um usuário do tipo administrador, mas pode-se haver diferentes
usuários de outros tipos. Cada novo usuário é cadastrado nessa base.
3.5.4.2 Tabela de Documentação
Fez-se uma tabela para armazenar a documentação com as
seguintes colunas: “id” (tipo número inteiro) e “doc” (tipo string
“VARCHAR”). A coluna “doc” salva o texto da documentação, em
formato HTML.
No Quadro 11, mostra-se o formato dessa tabela no banco de
dados, populada com dados meramente ilustrativos.
Quadro 11 - Tabela de Documentação no Banco de Dados.
id doc
0 <p> Lorem ipsum dolor sit amet, consectetur … </p>
Fonte: do Autor (2019).
83
4 RESULTADOS
4.1 CAPTURAS DE TELA DO APLICATIVO
Nesta seção, apresentar-se-ão os resultados do desenvolvimento do
aplicativo. Por questões de confidencialidade de métodos de cálculo da
ferramenta, borraram-se alguns campos de inserção e de visualização.
Apresentaram-se os resultados em três modos de visualização
distintos. Descrever-se-á a funcionalidade de cada view do aplicativo com
capturas de tela com viewport de 1440 x 900 pixels. Após isso, mostram-
se as capturas de tela das versões móveis celular e tablet, mas sem
explicação de funcionamento, uma vez que essas visualizações
compartilham das mesmas funcionalidades (ou menos) que as do
aplicativo rodando em uma tela com maior viewport.
4.1.1 Monitor com viewport de 1440 x 900 pixels
4.1.1.1 Login
Desenvolveu-se a tela de login, de maneira semelhante à projetada
(Figura 52), utilizando-se cores e a imagem de acordo com a identidade
visual da empresa. O resultado é mostrado na Figura 23.
Figura 23 - Captura de tela da página de Login.
Fonte: do Autor (2019).
84
Conforme mostrado na Figura 23, há campos para a inserção de
nome de usuário e senha; uma checkbox, para que o usuário permaneça
logado; um botão principal para efetuar o login e dois botões do tipo link
abaixo do botão principal, para as opções de recuperação de senha e de
cadastro.
4.1.1.2 Tela de Cálculo do Trocador WOT
Ao conseguir realizar o login, o usuário do tipo especialista
visualiza a tela mostrada na Figura 24. Para a construção dessa tela,
baseou-se no projeto mostrado na Figura 54.
Figura 24 - Captura de tela da página do trocado WOT do usuário especialista.
Fonte: do Autor (2019).
Nota-se que a parte de conteúdo da tela divide-se em três colunas.
Na primeira coluna, apresentam-se dois modos de visualização. O modelo
mostrado na parte superior da primeira coluna é uma visualização 3D do
componente (uma funcionalidade adicionada ao longo da execução do
projeto), para que o usuário possa conferir a geometria do equipamento.
O modelo na parte inferior da primeira coluna mostra a vista frontal do
componente, com legenda que auxilia na identificação dos campos de
preenchimento.
Abaixo do objeto 3D, colocou-se um botão do tipo link, disponível
apenas na versão para telas com maior viewport, para que fosse possível
85
ampliar a visualização do objeto 3D, resultando na janela mostrada na
Figura 25.
Figura 25 - Captura de tela da funcionalidade de visualização do objeto em 3D.
Fonte: do Autor (2019).
Na segunda coluna, pode-se inserir os parâmetros para os cálculos.
Alguns deles devem ser inseridos com valores pré-estabelecidos, através
de um menu de seleção, como mostrado na Figura 26.
86
Figura 26 - Captura de tela dos modos de inserção da ferramenta.
Fonte: do Autor (2019).
Os parâmetros numéricos devem ser inseridos digitando-se o valor
no campo. Além disso, no campo de seleção mais à direita, pode-se
selecionar a unidade daquele valor inserido, por exemplo, metros ou
milímetros.
Além disso, ao se passar com o ponteiro do mouse, pelos
parâmetros geométricos, mostra-se um círculo em destaque sobre a
imagem do componente (Figura 27), com o intuito de facilitar o
entendimento do usuário sobre qual parâmetro deve ser inserido naquele
campo.
87
Figura 27 - Captura de tela do auxílio visual dos parâmetros.
Fonte: do Autor (2019).
Por fim, na terceira coluna mostram-se os resultados dos cálculos.
Na parte superior, o usuário visualiza os principais resultados, podendo
também alterar as unidades da visualização com os campos de seleção.
Logo abaixo, plotam-se gráficos para a visualização de parâmetros
dependentes do passo do cálculo.
Para salvar os resultados, ao se clicar no botão de salvar resultados
(segundo, da esquerda para a direita), o aplicativo gera um arquivo no
formato texto e disponibiliza-o para download, como mostrado na Figura
28, de acordo com o projeto da Figura 57. O arquivo gerado contém os
parâmetros inseridos pelo usuário e os resultados.
88
Figura 28 - Captura de tela da função de salvamento de dados de cálculo.
Fonte: do Autor (2019).
Ao se clicar no terceiro botão da esquerda para a direita, pode-se
também salvar os logs gerados pelo aplicativo. Mostram-se os logs na
parte mais inferior da tela. Eles indicam no caso de algum erro ter
acontecido por motivos comuns, como: falha de conexão, parâmetros
inválidos e indisponibilidade de serviços. Além disso, disponibiliza-se
status dos cálculos e pode-se mostrar informações sobre o método de
cálculo utilizado (não se implementou essa funcionalidade).
Por fim, ao se clicar no quarto botão da esquerda para a direita,
abre-se uma janela pop-up com uma tabela para inserção de dados do
cálculo multiparamétrico. Nessa janela, pode-se inserir os mesmos
parâmetros para até 10 configurações diferentes. Com base nisso, geram-
se, por exemplo, 10 pontos de operação diferentes que podem ser
comparados para escolher um dimensionamento ótimo para o
componente. Mostra-se o projeto dessa janela na Figura 55 e o resultado
do desenvolvimento na Figura 29.
Nota-se que o formato de inserção é bem simples e semelhante a
algum software de edição de planilhas. Desse modo, caso o usuário tenha
os seus parâmetros em uma tabela do Microsoft Excel ou do Google
Sheets, por exemplo, pode-se simplesmente copiar os parâmetros e colar
no aplicativo.
89
Figura 29 - Captura de tela do modo de inserção dos parâmetros para cálculo
multiparamétrico.
Fonte: do Autor (2019).
Ao se clicar no botão de calcular, enviam-se os parâmetros para o
solver no servidor e ele retorna os resultados para todas as diferentes
combinações de parâmetros enviados. Um bloco em verde indica que a
operação foi realizada com sucesso.
O formato de retorno é uma tabela semelhante à tabela de inserção
de parâmetros. Então, pode-se copiar os dados e colar em alguma outra
tabela, ou gerar um documento de texto de saída com esses novos valores.
Para gerar o arquivo de texto, basta clicar-se no botão de salvamento.
Mostra-se o projeto inicial da tela de resultados do cálculo
mutiparamétrico na Figura 56. Pode-se ver a página desenvolvida na
Figura 30.
A funcionalidade de cálculo multiparamétrico encontra-se
disponível apenas para o aplicativo na versão para telas com maior
viewport, uma vez que seu uso em um aplicativo móvel seria complicado,
por conta da alta quantidade de dados em uma tela muito pequena e maior
esforço no uso de funções de copiar e colar.
90
Figura 30 - Captura de tela do modo de visualização dos resultados do cálculo
multiparamétrico.
Fonte: do Autor (2019).
4.1.1.3 Tela de Documentação
Por meio da tela de Documentação, o usuário pode aprender a usar
a ferramenta e entender os cálculos envolvidos nela. Para usuários
comuns da ferramenta, essa página se apresenta como um texto estático.
Mostra-se o projeto dessa página na Figura 58. Como resultado do
desenvolvimento, tem-se a página de documentação com formato similar
a uma Wiki, como mostrado na Figura 31.
91
Figura 31 - Captura de tela da página de Documentação.
Fonte: do Autor (2019).
Para se alterar o conteúdo da página de Documentação, necessita-
se logar no aplicativo como Administrador e escolher, no menu, a opção
de documentação. Pode-se visualizar o projeto inicial da página de
Documentação na Figura 59. Seguindo-se o projeto, construiu-se a página
mostrada na Figura 32.
Na página de edição de documentação, o modo de inserção da
documentação é na linguagem HTML. Caso o editor já possua
familiaridade com a linguagem, pode-se inserir o código diretamente no
campo à esquerda (Figura 32). Já, à direita, visualiza-se,
instantaneamente, a maneira como a documentação aparecerá na tela de
Documentação para os usuários comuns da ferramenta.
Porém, caso o editor não possua conhecimento sobre a linguagem
HTML, adicionou-se um conjunto de botões na parte inferior da tela
(abaixo do campo de edição), para auxiliá-lo na inserção da
documentação. Por meio dos botões, o usuário pode inserir formatos de
texto pré-definidos, como:
• Quatro níveis de texto: <h1>, <h3>, <h5> e <p>, para os títulos
e subtítulos de textos e parágrafos;
• Quebra de linha, para separar parágrafos;
• Linha divisória, para separar índices;
• Deixar o texto negrito, itálico, sublinhado ou subscrito;
92
• Listagem de itens;
• Criar blocos de texto com linha ao redor (panel).
Figura 32 - Captura de tela da página de edição da Documentação.
Fonte: do Autor (2019).
4.1.1.4 Tela de Gerenciamento de Usuários
Desenvolveu-se, por último, a tela de gerenciamento de usuários.
Ela serve para que o Administrador possa aprovar ou reprovar as
solicitações de acesso à ferramenta, além de atribuir níveis de acesso aos
usuários. Para isso, o projeto da Figura 60 previa a listagem de todos os
usuários em uma tabela, possibilitando a seleção de múltiplos usuários
para realização de uma mesma operação.
Mostra-se o resultado do desenvolvimento dessa tela na Figura 33.
Diferentemente do projeto, fez-se uma tabela mais simples, apenas com a
possibilidade de aprovação ou recusa da solicitação. Além disso, colocou-
se um campo para filtro de busca de usuários, para o caso de múltiplos
usuários estarem cadastrados na ferramenta.
93
Figura 33 - Captura de tela da página de gerenciamento de usuários.
Fonte: do Autor (2019).
4.1.2 Dispositivos Móveis
Apesar de não ser um requisito do projeto, pelo uso da biblioteca
responsiva Bootstrap, a adaptação da parte visual do aplicativo WEB para
dispositivos móveis agradou o cliente e facilitou os testes do aplicativo
entre os envolvidos.
Visto que as funcionalidades do aplicativo já foram explicadas na
seção 4.1.1, nesta seção apresentar-se-ão apenas as capturas de tela em
celulares e tablets, de modo a evitar a repetição do conteúdo.
As capturas de tela foram realizadas utilizando-se o modo de
visualização do navegador, mudando-se o dispositivo para um Samsung
Galaxy S5, com tela de dimensões 360 x 640 pixels. Mostra-se, na Figura
34 (a) a parte superior da tela de dimensionamento dos trocadores de calor
WOT. Nota-se que ela possui os mesmos componentes da tela da versão
Desktop, mas empilhadas, de modo a caber em uma tela mais estreita.
Visualiza-se, na Figura 34 (b), a parte de gráficos para o mesmo
dispositivo.
94
Figura 34 - Capturas de tela da view de dimensionamento de trocadores WOT
simuladas para um Samsung Galaxy S5.
(a) (b)
Fonte: do Autor (2019).
Simulou-se também, a tela de documentação para a versão móvel,
mostrada na Figura 35 (a). Pela limitação de espaço, recolhe-se o menu
superior do aplicativo e ele permanece oculto até que se clique no botão
“hambúrguer” (com três linhas horizontais) que ativa a expansão do
menu, como na Figura 35 (b).
95
Figura 35 - Capturas de telas de Documentação (a) e de expansão do menu (b),
simuladas para um Samsung Galaxy S5.
(a) (b)
Fonte: do Autor (2019).
Além disso, simulou-se o uso para o modelo Ipad, com dimensões
1024 x 1366 pixels. Mostra-se, na Figura 36, a tela de Documentação
capturada na simulação do Ipad.
96
Figura 36 - Captura de tela da página de Documentação, simulada para um Ipad.
Fonte: do Autor (2019).
97
5 CONCLUSÃO
Neste trabalho apresentou-se o processo de criação de um
aplicativo WEB, passando-se pelas etapas iniciais de especificação do
problema e modelagem do software, e posterior programação.
Tinha-se como objetivo inicial o desenvolvimento de um
aplicativo que superasse as limitações da ferramenta já disponível, além
de apresentar-se de maneira expansível para futuras funcionalidades.
Com base nos resultados, pode-se afirmar que o objetivo geral do projeto
foi alcançado com sucesso, tendo o projeto recebido bons feedbacks na
sua entrega final.
Entretanto, não se cumpriram os dois últimos objetivos
específicos, que dizem respeito à implementação do nível de acesso aos
usuários e à hospedagem da ferramenta no servidor da empresa. Não se
cumpriu o primeiro por questões de priorização de atividades por parte da
empresa, que deu preferência para a realização de mudanças em outros
aspectos do aplicativo. Já, o segundo não se cumpriu por conta da demora
na aprovação de projeto do setor de TI (tecnologia da informação) da
empresa, inviabilizando a hospedagem em primeiro momento.
A entrega do aplicativo agradou os responsáveis na empresa e
resultou no interesse de outros que não estavam envolvidos,
originalmente, no desenvolvimento da ferramenta. Com isso, após a
entrega deste projeto, já se iniciou a expansão da ferramenta para
implementação de novas funcionalidades.
5.1 SUGESTÕES PARA TRABALHOS FUTUROS
Como comentado anteriormente na conclusão, sugere-se a
continuidade do uso da ferramenta e expansão para novas
funcionalidades.
Também, para garantia da segurança da aplicação, deve-se
despender maiores esforços na questão de segurança de software. Não se
deu foco nesse aspecto neste projeto, uma vez que se acreditava que ele
seria inserido na Intranet da empresa, tomando-se apenas o cuidado de
elaborar validações para os formulários.
Ressalta-se também que, dependendo do tipo de projeto, a escolha de um framework que poderia cair em desuso em poucos anos, como o
caso do AngularJS, não seria a recomendação. Por exemplo, no caso de
uma equipe de desenvolvimento maior, no qual poucos integrantes
possuíssem familiaridade com esse framework, dar-se-ia a preferência
para o aprendizado de um framework com suporte prolongado. Utilizou-
98
se, porém o AngularJS, por conta da maior familiaridade do autor deste
projeto com este framework. Além disso, caso se fizesse necessário o
aprendizado desde o começo de qualquer outro, possivelmente, não se
teriam resultados tão expressivos quanto os obtidos.
No caso do desenvolvimento do software do princípio, escolher-se
ia, para o back-end, o Python como linguagem de programação para
implementação dos métodos e o framework Flask-RESTful, para a
programação da API, dada a quantidade de documentação disponível. Já,
para o front-end, escolher-se iam as mesmas linguagens (HTML, CSS e
JavaScript) e, pelos motivos já comentados, além do Bootstrap, um
framework com suporte continuado e comum entre os programadores: o
Vue.js.
99
REFERÊNCIAS
AMBLER, S. W. The Elements of UML 2.0 Style. Cambridge:
Cambridge University Press, 2005.
AMEEN, A. et al. Numerical analysis and experimental investigation into
the performance of a wire-on-tube condenser of a retrofitted refrigerator.
International Journal of Refrigeration, v. 29, p. 495-504, 2006.
ARISHOLM, E. et al. The Impact of UML Documentation on Software
Maintenance: An Experimental Evaluation. IEEE Transactions on
Software Engineering, 32, 2006. 365 - 381.
BALASUBRAMANEE, V. et al. Twitter Bootstrap and AngularJS:
Frontend Frameworks to expedite Science Gateway development. 2013
IEEE International Conference on Cluster Computing (CLUSTER),
Indianapolis, 2013.
BANSAL, P. K.; CHIN, T. C. Modelling and optimisation of wire-and-
tube condenser. International Journal of Refrigeration, v. 26, p. 601-
613, 2003.
BELL, I. H. et al. Pure and Pseudo-pure Fluid Thermophysical Property
Evaluation and the Open-Source Thermophysical Property Library
CoolProp. Industrial & Engineering Chemistry Research, v. 53, p.
2498-2508, jan. 2014.
BRIAND, L. C. Software Documentation: How Much is Enough?
Seventh European Conference on Software Maintenance and
Reengineering, 2003. Proceedings., Benevento, 2003.
CHANSUWATH, W.; SENIVONGSE, T. A model-driven development
of web applications using AngularJS framework. 2016 IEEE/ACIS 15th
International Conference on Computer and Information Science
(ICIS), 2016.
DELčEV, S.; DRAšKOVIć, D. Modern JavaScript frameworks: A
Survey Study. Modern JavaScript frameworks: A Survey Study, p.
106-109, 2018.
100
FAT, N. et al. Comparison of AngularJS framework testing tools. 2016
Zooming Innovation in Consumer Electronics International
Conference (ZINC), p. 76-79, 2016.
FERNÁNDEZ-SÁEZ, A. M.; GENERO, M.; CHAUDRON, M. R. V.
Does the Level of Detail of UML Models Affect the Maintainability of
Source Code? In: Kienzle J. (eds) Models in Software Engineering.
MODELS 2011. Lecture Notes in Computer Science., Berlin,
Heidelberg, 7167, 2012. 134-148.
FOWLER, M.; SCOTT, K. UML Distilled: A Brief Guide to the
Standard Object. 2ª. ed. [S.l.]: Pearson Education, 2000.
GOMES, P. C. T. Quais os principais bancos de dados e quais suas
diferenças? OpServices, 2019. Disponivel em:
<https://www.opservices.com.br/banco-de-dados/>. Acesso em: 15 jul.
2019.
GOOGLE TRENDS, 2019. Disponivel em:
<https://trends.google.com.br/trends/explore?date=2016-01-
01%202019-05-31&q=%2Fm%2F0j45p7w>. Acesso em: 27 jun. 2019.
GOPE, D.; SCHLAIS, D. J.; LIPASTI, M. H. Architectural support for
server-side PHP processing. 2017 ACM/IEEE 44th Annual
International Symposium on Computer Architecture (ISCA), p. 507-
520, 2017.
HOTFRAMEWORKS. Find your new favorite web framework:
Measuring web framework popularity so you can find interesting
frameworks to check out, 2019. Disponivel em:
<https://hotframeworks.com/>. Acesso em: 27 jun. 2019.
KEJKAR, G.; KHAN, A.; SHARMA, R. An Enhancement for Candidate
Recruitment System using Angularjs. 2017 International Conference
on Innovations in Information, Embedded and Communication
Systems (ICIIECS), 2017.
LAFORE, R. Object-Oriented Programming in C++. 4ª. ed.
Indianapolis: Sams Publishing, 2002.
101
MDN WEB DOCS. CSS basics, 2019. Disponivel em:
<https://developer.mozilla.org/en-
US/docs/Learn/Getting_started_with_the_web/CSS_basics>. Acesso
em: 27 jun. 2019.
MDN WEB DOCS. Getting started with the Web, 2019. Disponivel em:
<https://developer.mozilla.org/en-
US/docs/Learn/Getting_started_with_the_web>. Acesso em: 26 jun.
2019.
MDN WEB DOCS. How the Web works, 2019. Disponivel em:
<https://developer.mozilla.org/en-US/docs/MDN/About>. Acesso em:
26 jun. 2019.
MDN WEB DOCS. HTML Basics, 2019. Disponivel em:
<https://developer.mozilla.org/en-
US/docs/Learn/Getting_started_with_the_web/HTML_basics>. Acesso
em: 26 jun. 2019.
MDN WEB DOCS. JavaScript basics, 2019. Disponivel em:
<https://developer.mozilla.org/en-
US/docs/Learn/Getting_started_with_the_web/JavaScript_basics>.
Acesso em: 27 jun. 2019.
MDN WEB DOCS. PHP, 2019. Disponivel em:
<https://developer.mozilla.org/en-US/docs/Glossary/PHP>. Acesso em:
27 jun. 2019.
MELO, C.; HERMES, C. J. L. A heat transfer correlation for natural draft
wire-and-tube condensers. International Journal of Refrigeration, v.
32, p. 546-555, 2009.
NGUYEN, T. D. et al. Exploring API Embedding for API Usages and
Applications. Buenos Aires: IEEE. 2017.
NUGROHO, A. Level of detail in UML models and its impact on model comprehension: A controlled experiment. Information and Software
Technology, 51, n. 12, 2009. 1670 - 1685.
NUGROHO, A.; CHAUDRON, M. R. V. Evaluating the Impact of UML
Modeling on Software Quality: An Industrial Case Study. In: Schürr A.,
102
Selic B. (eds) Model Driven Engineering Languages and Systems.
MODELS 2009. Lecture Notes in Computer Science, Berlin,
Heidelberg, 5795, 2009. 181-195.
OH, J.; AHN, W. H.; KIM, T. Web app restructuring based on shadow
DOMs to improve maintainability. 2017 8th IEEE International
Conference on Software Engineering and Service Science (ICSESS),
p. 118-122, 2017.
PERUMAL, S. A. et al. Development of an Efficient Timetable System
using AngularJS and Bootstrap 3. 2018 8th IEEE International
Conference on Control System, Computing and Engineering
(ICCSCE), p. 70-75, 2018.
PROCEL; ELETROBRÁS. Pesquisa de Posse de Equipamentos e
Hábitos de Uso - Classe Residencial. Rio de Janeiro. 2007.
RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling
Reference Manual. 2ª. ed. Boston: Pearson Education, 2005.
SANTOS, J.; MENDONCA, J.; MARTINS, J. C. Instrumentation
Remote Control through Internet with PHP. 2008 IEEE Conference on
Virtual Environments, Human-Computer Interfaces and
Measurement Systems, 2008.
SAWANT, A. A.; BACCHELLI, A. A Dataset For API Usage. 2015 12th
Working Conference on Mining Software Repositories, p. 506-509,
2015.
SYKES, D. A.; MCGREGOR, J. D. A practical guide to testing object-
oriented software. Upper Saddle River: Pearson Education, 2001.
TAGLIAFICO, L.; TANDA, G. Radiation and natural convection heat
transfer from wire-and-tube heat exchangers in refrigeration appliances.
International Journal of Refrigeration, v. 20, p. 461-469, 1997.
TECHNOPEDIA. What is Software Framework? Disponivel em:
<https://www.techopedia.com/definition/14384/software-framework>.
Acesso em: 27 jun. 2019.
103
TECHOPEDIA. What is a Back-End System? Disponivel em:
<https://www.techopedia.com/definition/1405/back-end-system>.
Acesso em: 26 jun. 2019.
TECHOPEDIA. What is a Front-End System? Disponivel em:
<https://www.techopedia.com/definition/3799/front-end-system>.
Acesso em: 26 jun. 2019.
TILLEY, S. R.; HUANG, S. A qualitative assessment of the efficacy of
UML diagrams as a form of graphical documentation in aiding program
understanding. Proceedings of the 21st annual international
conference on Documentation, SIGDOC 2003, San Francisco, 2003.
184-191.
TREUDE, C.; ANICHE, M. Where does Google find API
documentation? 2018 ACM/IEEE 2nd International Workshop on
API Usage and Evolution, p. 19-22, 2018.
W3SCHOOLS. Bootstrap Grids. Disponivel em:
<https://www.w3schools.com/bootstrap/bootstrap_grid_basic.asp>.
Acesso em: 27 jun. 2019.
W3SCHOOLS. CSS Introduction. Disponivel em:
<https://www.w3schools.com/css/css_intro.asp>. Acesso em: 27 jun.
2019.
W3SCHOOLS. HTML Introduction. Disponivel em:
<https://www.w3schools.com/html/html_intro.asp>. Acesso em: 26 jun.
2019.
W3SCHOOLS. Introduction to SQL. Disponivel em:
<https://www.w3schools.com/sql/sql_intro.asp>. Acesso em: 27 jun.
2019.
W3SCHOOLS. JavaScript Introduction. Disponivel em:
<https://www.w3schools.com/js/js_intro.asp>. Acesso em: 27 jun. 2019.
W3SCHOOLS. JavaScript JSON. Disponivel em:
<https://www.w3schools.com/js/js_json.asp>. Acesso em: 27 jun. 2019.
104
W3SCHOOLS. PHP 5 Introduction. Disponivel em:
<https://www.w3schools.com/php/php_intro.asp>. Acesso em: 27 jun.
2019.
WOODS, E. Software Architecture in a Changing World. IEEE
Software, v. 33, n. 6, p. 94-97, 2016.
YUNRUI, Q. Front-End and Back-End Separation for Warehouse
Management System. 2018 11th International Conference on
Intelligent Computation Technology and Automation, p. 204-208,
2018.
105
APÊNDICE A - Diagramas de Atividades
Figura 37 - Diagrama de atividades para o front-end: Login.
Fonte: do Autor (2019).
106
Figura 38 - Diagrama de atividades para o front-end: Cálculo simples (parte 1/2).
Fonte: do Autor (2019).
107
Figura 39 - Diagrama de atividades para o front-end: Cálculo simples (parte 2/2).
Fonte: do Autor (2019).
108
Figura 40 - Diagrama de atividades para o front-end: Cálculo multiparamétrico
(parte 1/2).
Fonte: do Autor (2019).
109
Figura 41 - Diagrama de atividades para o front-end: Cálculo multiparamétrico
(parte 2/2).
Fonte: do Autor (2019).
110
Figura 42 - Diagrama de atividades para o back-end: Cálculo.
Fonte: do Autor (2019).
111
Figura 43 - Diagrama de atividades para o back-end: Banco de dados (parte 1/2).
Fonte: do Autor (2019).
112
Figura 44 - Diagrama de atividades para o back-end: Banco de dados (parte 2/2).
Fonte: do Autor (2019).
113
APÊNDICE B - Diagramas de Estados
Figura 45 - Diagrama de estados para um usuário comum no dimensionamento
de um trocador WOT.
Fonte: do Autor (2019).
Login
Load page template
Recuperar
Load page template
Cadastrar
Load page template
Home | AL
Load page template
WOT | AL
Load page template
Calcular
Show Loading Info
Error
Show Error Info
114
APÊNDICE C - Diagramas de Caso de Uso
Figura 46 - Diagrama de caso de uso para o procedimento de login e redirecionamento (parte 1/2).
Fonte: do Autor (2019).
115
Figura 47 - Diagrama de caso de uso para o procedimento de login e redirecionamento (parte 2/2).
Fonte: do Autor (2019).
116
Figura 48 - Diagrama de caso de uso para navegação no menu do usuário tipo Administrador.
Fonte: do Autor (2019).
117
Figura 49 - Diagrama de caso de uso para navegação no menu do usuário tipo Especialista ou Técnico.
Fonte: do Autor (2019).
DimensionarVentiladores
Dimensionar Compressores
Visualizar Menu de Usuário
Usuário
DimensionarDispositivos de
Expansão
Dimensionar Condensadores
Selecionar Opção de Menu
DimensionarMicro-canal
DimensionarEvaporador No-frost
DimensionarCondensador Skin
DimensionarWire-on-Tube
Selecionar Opção de Sub-Menu
Inserir Parâmetros
<<extend>><<extend>>
<<extend>>
DimensionarEvaporadores
118
Figura 50 - Diagrama de caso de uso para realização do cálculo.
Fonte: do Autor (2019).
119
APÊNDICE D - Diagramas de Classes
Figura 51 - Diagrama de classes do aplicativo.
Fonte: do Autor (2019).
User
- tinyint accessLevel- String email- String password- String token
+ boolean User(String email, String password)+ tinyint getAccessLevel(String email)+ String getLocalToken()+ boolean setLocalToken(String)+ String getDocumentation()+ boolean askLogin(String email, String password)+ boolean askLogout(user.email)+ makeInterfaceEvent(event e)
SessionManager
+ boolean createSession(user)+ boolean checkSession(String localToken)+ boolean closeSession(user)- String generateToken()UserInterface
- element navigationMenu- element footer- element content
- decodeEvent (event e)- redirectUser()
*:1
Admin
+ boolean writeDocumentation(String documentation)+ boolean setAccessLevel(String email, tinyint accessLevel)+ boolean removeUser(String email)
DatabaseConnection
- String dbUser- String dbPassword- String dbServer- String dbName
+ boolean connectionOpen()+ boolean connectionClose()+ boolean checkConnectionStatus()1
:*
1:1
Database
- String documentation- User[] users
+ boolean executeQuery(String query)
1:1
Solver
+ decodeRequest(request r, params [])- readParametersFromServer(Parameter[] params)- writeResultsToServer(Parameter[] params)- String solveDesign()
*:*
*:*
*:1
*:1
120
APÊNDICE E - Mock-ups das views
Figura 52 - View de login do aplicativo.
Fonte: do Autor (2019).
121
Figura 53 - View de cálculo simples do aplicativo (antes do clique indicado pelo ícone em amarelo).
Fonte: do Autor (2019).
122
Figura 54 - View de cálculo simples do aplicativo (após o clique indicado pelo ícone em amarelo da Figura 53).
Fonte: do Autor (2019).
123
Figura 55 - View de cálculo multiparamétrico do aplicativo (antes do clique indicado pelo ícone em amarelo).
Fonte: do Autor (2019).
124
Figura 56 - View de cálculo multiparamétrico do aplicativo (após o clique indicado pelo ícone em amarelo da Figura 55).
Fonte: do Autor (2019).
125
Figura 57 - View de exportar dados para formato de texto e realização do download.
Fonte: do Autor (2019).
126
Figura 58 - View de documentação para os usuários tipo Especialista e Técnico.
Fonte: do Autor (2019).
127
Figura 59 - View de edição de documentação para o Administrador.
Fonte: do Autor (2019).
128
Figura 60 - View de gerenciamento de usuários para o Administrador.
Fonte: do Autor (2019).