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.
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)
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.
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.
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 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 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
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
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)
{
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 HTMLPonto 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)
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)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.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.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 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
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
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;
• 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;
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.
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.
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-front-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
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).
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).
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 define-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.
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.
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.
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.
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.
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).
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,
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
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, sback-endo 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:
“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),
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.
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.
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.
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).
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.
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.
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.
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”.
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.
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
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
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”.
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.
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
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
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.
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;
