Estudo Sobre os Scripts SQL Utilizados Para o Fechamento da Folha de Pagamento
| Data de elaboração | 23/08/2023 |
|---|---|
| Responsável pelo estudo |
Ádrian Rabelo Mendes (Assessor) |
| Equipe do estudo | CAOS |
|
Alvo |
Sistema Governa |
| Origem |
Scripts SQL utilizados pela SEGEP para o fechamento da folha de pagamento |
| Objetivo | Para verificar a possibilidade de implementação e execução automatizada desses scripts SQL em funcionalidades do Governa após processamento da folha de pagamento. |
Glossário
API - Application Programming Interface (em português Interface de Programação de Aplicação)
HTTP - Hypertext Transfer Protocol (em português Protocolo de Transferência de Hipertexto)
SQL - Structured Query Language (em português Linguagem de Consulta Estruturada)
1. Introdução
...
1.1 O Problema
...
2. Referencial Teórico
Este capítulo introduz a base teórica deste estudo. São brevemente descritos conceitos de arquitetura de software. Especificamente das arquiteturas monolítica e microsserviços, cujos conceitos forma a base estrutural do sistema Governa e tornar-se-á base da possível solução para o objeto do estudo, respectivamente. Por fim, também são apresentadas as ferramentas e tecnologias que podem ser utilizadas no desenvolvimento da aplicação solução do objeto do estudo.
2.1 Arquitetura de Software
A arquitetura de software especifica como um sistema deve ser organizado e estruturado, compreendendo o conjunto de componentes do sistema, suas relações entre si, relacionamento com outros softwares e os princípios que regem sua evolução. A arquitetura destaca uma série de decisões de projeto e fornece mecanismos para considerar os benefícios de estruturas alternativas do sistema.
Vários estilos de arquitetura encontram-se à disposição dos engenheiros de software que podem ser aplicadas à uma arquitetura específica para um software valendo destacar microsserviços e arquitetura monolítica em termos de desenvolvimento web.
2.1.1 Arquitetura Monolítica
Uma aplicação web típica é executada em um computador remoto, denominado servidor, cuja interface de usuário é acessada por meio de um navegador (browser) no computador cliente. A aplicação é dita ser monolítica (ou monólito), quando toda a sua lógica é executada em uma única máquina, compartilhando memória, arquivos e recursos de processamento.
Apesar das principais linguagens de desenvolvimento de aplicações oferecerem abstrações para fragmentar a complexidade dos sistemas em módulos, ainda são projetadas para a criação de um único executável, no qual toda a modularização utilizada é executada numa mesma máquina compartilhando seus recursos.
Uma aplicação em arquitetura monolítica típica pode ser representada pela Figura 1 a seguir, onde todas as suas funções estão implementadas e são executadas em um único processo.
Figura 1 – Representação de uma aplicação monolítica 
É este único executável lógico que manipula solicitações HTTP, executa lógicas de domínio, recupera e atualiza dados do banco de dados, e constrói visualizações HTML a serem enviadas ao navegador.
2.1.2 Arquitetura de Microsserviços
O termo "Arquitetura de Microsserviços" surgiu nos últimos anos para descrever uma maneira particular de projetar aplicativos de software como suítes de serviços independentemente implantáveis. Trata-se de uma abordagem para o desenvolvimento de aplicações através da decomposição de suas funcionalidades em serviços discretos, cada um executando em seu próprio processo e se comunicando com mecanismos leves, tal como uma API de recursos HTTP.
A proposta da arquitetura de microsserviços é possibilitar o desenvolvimento de aplicações de maneira mais flexível, escaláveis e com manutenção mais simples em relação às aplicações em arquiteturas monolíticas. Como a aplicação é criada com pequenos serviços independentes, cada serviço pode funcionar ou falhar individualmente sem comprometer os demais. A Figura 2 representa um esquema de uma aplicação em arquitetura de microsserviços.
Figura 2 – Representação de microsserviços em uma aplicação 
Um serviço é desenvolvido para solucionar um problema específico e pode ser implantado, atualizado e escalado de forma independente, mantendo sua disponibilidade e funcionamento. Como os processos da aplicação são executados como serviços que se comunicam por meio de APIs, estes não necessitam ser desenvolvidas em uma linguagem de programação específica.
2.2 Spring Framework
O Spring é um framework que facilita a criação de aplicativos corporativos. Fornece tudo o que o desenvolvedor necessita para adotar a linguagem de programação Java em um ambiente corporativo, e com a flexibilidade de criar muitas tipos de arquiteturas dependendo das necessidades de um aplicativo. É de código aberto e possui uma comunidade amplamente ativa que fornece feedback contínuo com base em uma gama diversificada de casos de uso do mundo real.
O Spring é dividido em módulos. Os aplicativos podem escolher quais módulos precisam. No centro estão os módulos do contêiner principal, incluindo um modelo de configuração e um mecanismo de injeção de dependência. Além disso, fornece suporte para diferentes arquiteturas de aplicativos, incluindo mensagens, dados transacionais e persistência e web.
3. Possível Solução
...
4. Conclusão
...Após análise básica dos scripts, observou-se uma premissa geral. Caso as consultas não retornem resultados significa que os dados estão corretos, havendo retorno, os registros devem sofrer alterações ou exclusão. No mínimo, as duas histórias a seguir serão necessárias para dar início aos trabalhos.
| História |
O quê: Implementar, no Governa, funcionalidade para chamada à API externa Por quê: Para possibilitar a comunicação entre o Governa e o microsserviço |
| Regras e Validações | -- |
| Pontuação |
| História |
O quê: Criar projeto do microsserviço, configurar e adicionar ao gitlab da SETIC Por quê: Para desenvolvimento, manutenção e versionamento do código-fonte |
| Regras e Validações |
|
| Pontuação | 5 |
Essas histórias possibilitarão que o Governa realize chamadas à APIs e ao início do desenvolvimento do microsserviço. Ainda será necessária a criação de uma história para cada script, visto que cada um possui suas particularidades e precisam ser compreendidos para correta implementação.
5. Referências
...