Introdução

Neste documento procuramos apresentar e justificar as escolhas técnicas realizadas durante a implementação da rotina SCANCREF. As escolhas podem ser agrupadas da seguinte maneira:

• Paradigma
• Arquitetura
• Linguagem

Paradigma

A decisão de utilizar a Orientação a Objetos em detrimento da programação estruturada é provavelmente a mudança mais significativa empregada no desenvolvimento desta rotina. 

Não chega a ser uma novidade na Squad a existência de rotinas utilizando este modelo, porém o que torna a nossa abordagem um tanto mais inovadora é o uso de padrões de arquitetura e recursos avançados da linguagem que potencializam o poder de abstração da orientação a objetos.

O porquê da escolha

A escolha do paradigma foi orientada pelas vantagens que o mesmo traz para o desenvolvimento:

• Reutilização de código: objetos podem ser reutilizados em diferentes partes do programa, o que economiza tempo e esforço de desenvolvimento.
• Modularidade: os objetos podem ser criados independentemente e depois integrados em um programa maior. Isso ajuda a separar as diferentes partes do programa em módulos lógicos, tornando o programa mais fácil de entender, manter e modificar.
• Abstração: objetos permitem que você abstraia conceitos e ideias em representações mais concretas e fáceis de entender. Isso torna o código mais legível e fácil de manter.
• Encapsulamento: a orientação a objetos permite que você esconda a complexidade interna de um objeto. Isso torna o objeto mais fácil de usar, porque o usuário só precisa conhecer as funções públicas disponíveis e não precisa se preocupar com detalhes internos.
• Herança: a orientação a objetos permite que você crie hierarquias de objetos, com objetos mais especializados derivados de objetos mais gerais. Isso economiza tempo e esforço de desenvolvimento, uma vez que você pode reutilizar e modificar objetos existentes em vez de criar novos a partir do zero.

Arquitetura

Desenvolvemos a rotina SCANCREF utilizando dois modelos arquiteturais:

1. Arquitetura em camadas (Layered Architecture)

O primeiro deles é um modelo em camadas. É importante lembrar que nesta parte da aplicação não há necessidade de persistência de dados, logo não foi necessário se preocupar com uma interface gráfica para entrada de informações por parte do usuário. As camadas criadas são resumidas abaixo:

• Model: a camada de modelo é a responsável por representar os objetos que estamos modelando na aplicação, neste caso são os registros ou quadros do arquivo Scanc Refinaria. Foi então criada uma classe para cada registro do arquivo, cada atributo da classe representa um campo do registro;
• Service: na camada de serviço, isolamos a lógica de acesso a dados. Aqui são obtidos os dados e instanciados os objetos da camada de modelo;
• File: esta camada funciona como uma camada de aplicação, isto é, ela não armazena regras de negócio, mas apenas coordena tarefas e delega trabalho para colaborações de objetos de domínio (camadas Model e Service). Aqui, a camada File é responsável pela montagem e escrita do objeto que representa o arquivo, em meio magnético.

O porquê da escolha

Escolhemos essa abordagem visando os seguintes motivos:

• Separação de responsabilidades: cada camada tem uma responsabilidade específica, tornando o código mais fácil de entender, alterar e depurar.
• Reutilização de código: as camadas são isoladas e independentes, permitindo que o código seja reutilizado em outros projetos ou partes do mesmo projeto. Isto se aplica, inclusive para os futuros projetos do TAF. Procuramos desenvolver artefatos backend agnósticos, que poderão, a princípio, ser reaproveitados em projetos REST e PO-UI.
• Melhor escalabilidade: como as camadas são independentes, é possível escalar apenas aquela que precisa ser escalada, sem afetar as demais camadas.
• Facilidade de manutenção: com a separação de responsabilidades, é mais fácil identificar onde estão os erros e realizar manutenções pontuais, sem afetar outras partes do sistema.
• Facilidade de testes: a separação de responsabilidades também facilita a criação de testes automatizados para cada camada.

2. Model-View-Controller ou MVC

Aqui foram desenvolvidas as tabelas e as respectivas telas para entrada de informações, utilizando as funções MVC disponibilizadas pelo Framework.

FISA309 - Cadastro dos Quadros - Scanc Refinaria do Anexo VI

FISA310

O porquê da escolha

Escolhemos essa abordagem devido ao domínio do time sobre a tecnologia.