Uma Proposta de Evolução do Atual Sistema de Arrecadação da Suframa para uma Plataforma Orientada a Objetos Utilizando os Padrões de Projeto DDD e SOLID.

PERES, Paulo Júnior de Jesus [1]

PINTO, Aurílio Guimarães [2]

FREITAS, Caio Guimarães [3]

LEITE, Francisco Canindé da Silva [4]

SILVA, Francisco Eronildo da [5]

OLIVEIRA, Geveson de Souza [6]

RIBEIRO, Dallas dos Santos [7]

ALMEIDA, Cristiany Caliri de [8]

MORAIS, Gilvanete Melo de [9]

PERES, Paulo Júnior de Jesus; et.al. Uma Proposta de Evolução do Atual Sistema de Arrecadação da Suframa para uma Plataforma Orientada a Objetos Utilizando os Padrões de Projeto DDD e SOLID. Revista Científica Multidisciplinar Núcleo do Conhecimento. Edição 07. Ano 02, Vol. 03. pp 36-43, Outubro de 2017. ISSN:2448-0959

Resumo

A arrecadação de um Órgão Federal como a Suframa é extremamente complexa, pois há vários normativos legais e integrações necessárias para um bom funcionamento. Por isso, justifica-se que seja utilizado um sistema robusto que atenda as regras de negócio e as evoluções necessárias neste processo dinâmico. Por este motivo, este artigo busca oferecer uma proposta viável do ponto de vista da arquitetura de software para o desenvolvimento de uma solução com código de qualidade utilizando os padrões de projetos DDD e SOLID.

1. Introdução

O atual software que gerencia a arrecadação realizada pela Suframa foi desenvolvido em meados de 1990 tendo como plataforma a Linguagem de Programação Cobol e o banco de Dados SQL DBB, que é uma versão anterior ao DB2 da IBM. Segundo a Coordenação de Informática da autarquia, tal sistema opera em plataforma baixa, ou seja, em um Mainframe Z22 da IBM.

Diante do software em operação na instituição, pode-se destacar as seguintes problemáticas:

• Banco de dados não relacional e com limitação de dados para armazenamento;
• Linguagem de programação estruturada;
• Falta de versionamento dos códigos;
• Falta de testes integrados;
• Dificuldade de mão de obra para realizar a manutenção do sistema.

Como é sabido, um software desta dimensão é um “órgão vivo” necessitando de constantes evoluções. Neste prisma, foi constatado pela Coordenação de Informática da Suframa que tal software não atende mais as necessidades do negócio tampouco as necessidades tecnológicas, entre as necessidades de evolução as principais são as seguintes:

• Integração com plataformas web através de webservices;
• Integração com plataformas mobiles, e
• Processamento, geração e exportação de relatórios em diversos formatos.

Segundo o sitio eletrônico da Instituição, a Superintendência da Zona Franca de Manaus (Suframa) – é uma autarquia do governo Federal vinculada ao Ministério da Industria, Comércio Exterior e Serviços que tem como objetivo construir um modelo de desenvolvimento regional que utilize de forma sustentável os recursos naturais garantindo a viabilidade econômica e melhorando a qualidade de vida da população. Atualmente a Suframa tem como abrangência os Estados do Amazonas, Acre, Rondônia, Roraima e Amapá.

Diante da importância da autarquia para a região, e ao grande volume de recursos arrecadados, justifica-se o desenvolvimento de um novo sistema de arrecadação utilizado modernos padrões de arquitetura de software e tecnologias. Por isso, ao decorrer deste artigo será proposto uma estratégia para desenvolvimento do software aludido neste artigo.

2. Padrões de arquitetura de Software

Antes de definirmos quais padrões serão utilizando, é importante definir o que é um Padrão de projeto de software, destarte, segundo Gamma (2000) padrão de projeto são soluções genéricas para os problemas mais comuns e recorrentes no cotidiano do desenvolvimento de software Orientados a Objetos (POO) por uma equipe de desenvolvimento de Softwares.

A intenção principal dos Padrões de projeto é diminuir o risco da ocorrência de erros em softwares através da utilização de técnicas amplamente testadas e aprovadas pela comunidade de desenvolvimento de software.

Segundo Gamma (2001), atualmente existem vários padrões de projetos, e muita literatura disponível para pesquisa, dentre esses padrões podemos destacar:

• Dependency Injection ou Injeção de dependência;
• Factory Method;
• Bulder;
• Abstracty Factory;
• Singleton;
• Prototype;
• Command;
• Iterator;
• Strategy;
• Visitor entre outros;

Em meio a imensidão de padrões existentes, este artigo busca evidenciar os padrões sugeridos como base para o desenvolvimento do novo sistema de Arrecadação da Superintendência da Zona Franca de Manaus que são: Domain-Driven Design (DDD) e o SOLID, pois a utilização de ambos implicam na utilização de diversas boas práticas de desenvolvimento de Software.

Neste prisma, não significa que ao decorrer do projeto não poderão ser utilizados outros padrões, apenas por questões didáticas serão abordados esses dois padrões neste artigo. Assim, nos capítulos seguintes iremos abordar profundamente tais padrões.

2.1. O Padrão Domain-Driven Design (DDD)

Segundo Evans (2016) Desenvolvimento orientado a Domínio (DDD) trata-se de uma abordagem disciplinada de design de software que aborda uma série de conceitos e técnicas sempre com foco no domínio do software.

Neste padrão de projetos, o foco do desenvolvimento está no Domínio do sistema, ou seja, nas regras de negócio do software.

Uma grande vantagem do DDD é que sua abordagem é totalmente Orientada a Objetos, ou seja, os desenvolvedores devem obrigatoriamente construir o software utilizando a programação orientada a objetos, desta forma, segundo Cukier (2010) os benefícios alcançados são os seguintes:

• Alinhamento do código com o negócio:o engajamento dos desenvolvedores com os conhecedores/especialistas do domínio é algo primordial quando se faz DDD, isso é uma característica do desenvolvimento Ágil;
• Favorecer reutilização:os códigos desenvolvidos, podem ser reutilizados de forma transparente.
• Mínimo de acoplamento:após uma modelagem do modelo de dados bem desenvolvida, organizada, as “camadas” do software podem se comunicar sem dependência através do uso das interfaces;
• Independência da Tecnologia:DDD não tem como foco a tecnologia empregada no desenvolvimento do software, mas sim nas regras de negócio.

Contudo, para que o DDD atinja seu objetivo é necessário que o software seja desenvolvido utilizando uma arquitetura que permita a aplicação dos conceitos do DDD, por isso, segundo Cukier (2010) o padrão sugere a utilização de quatro camadas principais que são:

Na Figura acima, seguem os esclarecimentos segundo Cukier (2010):

• Interface de Usuário – é a camada responsável pela interação direta com o usuário, como as telas do software, Webservices SOA ou REST, aplicativos mobiles ou desktops entre outros;
• Aplicação – trabalha diretamente com a camada de domínio de forma que isolar o domínio da camada “Interface de Usuário”, isso é importante para que os papéis fiquem distintos, por exemplo: não há a necessidade da interface conhecer qual classe do domínio deve executar determinada ação. Desta forma, a camada de aplicação é uma espécie de intermediadora entre o domínio e a interface;
• Domínio – é a camada que contém todas as regras de negócios da aplicação, ou seja, tudo que reflete aos requisitos funcionais, aos cálculos são tratadas nesta camada;
• Infraestrutura – responsável pela interação com as infraestruturas técnicas, por exemplo, acesso a dados, acesso a sistemas de arquivos, envios de e-mails, entre outros.

Estas camadas não são impositivas, dependendo da necessidade do projeto podem ser retiradas ou adicionadas novas camadas. O que deve-se ter em mente é a necessidade da imperativa programação voltada ao Domínio.

Mas há algo a ser observado, segundo Pires (2016) a programação DDD não é uma arquitetura em camadas nem tampouco uma receita pronta para ser utilizada em qualquer software a ser desenvolvido. O DDD foca no desenvolvimento orientado ao domínio, esse é o foco e não as camadas.

Diante de tais conceitos, chegamos aos principais benefícios ganhos ao utilizar o DDD que segundo Cukier (2010) é que a indução ao desenvolvimento de um software dentro do cenário de melhoria contínua, tornando-se uma ferramenta extremamente útil para se desenvolver softwares de qualidade e que atenda bem as necessidades do cliente.

Assim, aplicar o Padrão de Projetos DDD significa resgatar a programação verdadeiramente orientada a Objetos, pois em sua implementação a equipe de desenvolvimento é obrigada a aplicar diversos outros padrões como: Repository,  Decorator, Strategy, State entre outros.

2.2. SOLID

Segundo Martin (2008), Robert C. Martin identificou cinco princípios da programação orientada a objetos que buscam a melhoria de códigos, tais princípios são SRP, OCP, LSP, ISP e DIP. Diante de tais princípios, Michael Feathers observou que poderia ser criado o acrônimo chamado SOLID contendo os cinco princípios. A imagem a seguir demonstra o significado do acrônimo:

Segue a definição de cada parte do acrônimo segundo a publicação de Martin (2008):

• Single responsability Principle ou Princípio da Responsabilidade Única: uma classe deve ter um, e apenas um motivo para mudar. Neste princípio uma classe deve ter apenas uma única finalidade, por exemplo: ao se criar uma calculadora não devemos fazer uma classe Operações Matemáticas e colocar todas as operações nela, mas sim, fazer uma classe para cada operação;
• Open Closed Principle ou Principio Aberto-Fechado: deve-se estar sempre aberto para extensão e fechado para implementação, isso por que, quando se faz alterações em um código já existente corre-se o risco de um erro impactar em diversos outros fragmentos de códigos;
• Liskov Substitution Principle ou Princípio da Substituição de Liskov: as classes bases devem sempre ser substituíveis por suas classes bases, ou seja, uma classe B que Herda uma de uma Classe A pode sempre ser substituída pela classe A em um implementação de código;
• Interface Segregation Principle ou Princípio da Segregação de Interfaces: muitas interfaces específicas são melhores do que uma interface única, pois tal prática visa diminuir o acoplamento dos códigos;
• Dependency Inversion Principle ou Princípio da Inversão de Dependência: deve-se depender sempre de uma abstração e nunca de uma implementação.

Ao aplicar o SOLID, é possível obter os seguintes benefícios ao projeto: facilidade de realizar manutenções e evoluções do projeto, facilidade de realizar testes automatizados, menor esforço para evolução do código e um máximo reaproveitamento do código.

3. Proposta do novo Sistema de Arrecadação

A proposta deste artigo é fornecer base de conhecimento para o desenvolvimento de um novo software para gerenciamento da arrecadação realizada pela Superintendência da Zona Franca de Manaus – Suframa utilizando o paradigma da Programação Orientada a Objetos aplicando os padrões de projetos DDD e SOLID no desenvolver do projeto.

Nesta proposta, seguindo um plano de ação baseado no modelo da administração 5W1H, teríamos o seguinte planejamento para o novo desenvolvimento:

Tabela 01 – Plano de Ação para desenvolvimento do novo sistema.

O que fazer?	Por que?	Como?	Onde?	Quem?	Quando?
Definir linguagem de programação e tecnologias para o projeto	Padronizar o desenvolvimento do software.	Realizando reuniões técnicas	Na coordenação de informática	Gestores de TIC, Programadores e arquitetos de softwares	Primeira semana
Preparar ambiente de desenvolvimento e homologação	Criar mecanismos para que a equipe trabalhe no projeto	Instalação de servidores, softwares e frameworks	Na estação de trabalho dos integrantes da equipe de desenvolvimento e nos servidores.	Equipe de configuração e suporte de TIC	Segunda semana
Coleta de Requisitos do Software	Documentar as informações a serem programadas no Domínio	Reuniões e entrevistas	Suframa	Analistas de Requisitos	Da semana 3 a semana 10.
Codificação	Criar o software	Codificando e testando	Na Suframa	Fábrica de Software	Da semana 11 a semana 22.
Homologação e correções	Averiguar se o que foi desenvolvido é realmente o que a Suframa necessita e realizar correções	Realizando testes	Ambiente de homologação	Especialistas do Domínio (Negócios)	Da semana 23 a 25.
Implantação	Disponibilizar o sistema na produção	Fazendo o build no ambiente de produção	Hosting dos sistemas	Analistas de configurações	Semana 26.

Fonte: Elaborado pelo Autor.

Conforme tabela acima, observa-se que o projeto deverá levar em torno de seis meses e meio para ser concluído, porém ressalta-se que esse plano de ação contém as ações macros, seriam necessários outros planos para detalhamento de cada ação macro em sua execução.

Tendo em vista a macro ação de “Codificação” apontada na tabela 01, destaca-se a utilização do DDD, esta proposta recomenda sejam criadas as seguintes camadas:

• Camada de Apresentação – nesta camada estarão os projetos de visão do usuário, sendo que para web será utilizado o framework Angular 2.0 e para dispositivos mobiles (Android/IOS) utilizando o framework Ionic;
• Camada de Serviços – será responsável por prover à camada de Apresentação todos os webservices em formato REST e terá o papel de controlar a injeção de dependência utilizando o framework ninject;
• Camada de Aplicação – Responsável pelas implementações de aplicação, como registro de log e encapsulamento do domínio;
• Camada de Domínio – conterá a implementação das regras de negócio, nela estarão as Entidades, Intefaces, e os serviços de domínio;
• Camada de Infra – camada responsável pelo acesso a dados utilizando uma ferramenta ORM, pelos repositórios, pelo envio de e-mails e autenticação.

Em todas as camadas deverão ser aplicados os princípios do SOLID.

Conclusão

Este artigo técnico buscou de forma simples elaborar uma proposta concreta de migração de um sistema legado desenvolvimento em plataforma baixa para uma plataforma moderna utilizando como base os Padrões de Projetos de desenvolvimento de Software o Desenvolvimento Orientado ao Domínio (DDD) e SOLID.

Entende-se que essa proposta serve como base não só para o software de arrecadação da Superintendência da Zona Franca de Manaus, mas também como base para outros projetos de migração e evolução de softwares ficando em aberta para posteriores adaptações e futuras republicações por outros autores.

Referências

Beck, Kent. “Padrões de Implementação”. Bookman. 2013. 168p. ISBN 8565837971.

Gamma, Erich. “Padrões de Projetos”. Bookman. 2000. 528p. ISBN 8573076100.

Evans, Eric. “Domain Driven Design 3ª Edição”. Alta Books. 2016. 528p. ISBN 8550800651.

Martin, Robert. “Clean Code: A Handbook of Agile Software Craftsmanship”. Prentice Hall PTR. 431p. ISBN 0132350882.

Disponível em : <http://cieam.com.br/?u=suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf> acesso em 21 de abril de 2017.

Disponível em: <http://www.eduardopires.net.br/2012/06/ddd-tdd-bdd/> acesso em 21 de abril de 2017.

Disponível em: <http://www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/> acesso em 21 de abril de 2017.

Disponível em : <http://www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/> acesso em 21 de abril de 2017.

[1] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI. Especialista em Banco de dados pela ULBRA.

[2] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[3] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[4] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[5] Graduado na área de computação, atua como servidor público na SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[6] Graduado na área de computação, atua como servidor SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[7] Graduado na área de computação, atua como servidor SUFRAMA, no cargo de Analista Técnico Administrativo – TI.

[8] Graduada em Administração, atua como servidora pública na SUFRAMA, no cargo Administradora.

[9] Graduada em Economia, atua como servidora pública na SUFRAMA, no cargo de Economista.