TCC - Felipe Tortato

Prévia do material em texto

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 feitapelo 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 deuso 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 DiagramasNesta 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 essetipo 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ício
Logar 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