Una propuesta de cambios en el sistema actual de la colección de Suframa para una plataforma orientada a objetos utilizando los patrones de proyecto DDD y sólido.

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. Una propuesta de cambios en el sistema actual de la colección de Suframa para una plataforma orientada a objetos utilizando los patrones de proyecto DDD y sólido. Revista científica multidisciplinaria base de conocimiento. Edición 07. año 02 vol. 03. PP 36-43, octubre de 2017. ISSN: 0959-2448

Resumen

La recaudación de una Agencia Federal como Suframa es extremadamente compleja, ya que hay varios integración legal y normativo necesario para un buen funcionamiento. Por lo tanto, está justificado para utilizar un sistema robusto que cumple con las reglas de negocio y desarrollos necesarios en este proceso dinámico. Por esta razón, este artículo pretende ofrecer una propuesta viable desde el punto de vista de la arquitectura de software para el desarrollo de una solución con código de calidad utilizando los patrones sólidos y proyectos DDD.

1. Introducción

El software actual que administra la colección de la Suframa se desarrolló a mediados de 1990 con la plataforma Cobol lenguaje de programación y la base de datos SQL DBB, que es una versión anterior de DB2 de IBM. Según el equipo de autoridad de coordinación, este sistema funciona con plataforma baja, es decir, en un Mainframe IBM Z22.

Antes el software en funcionamiento en la institución, podemos destacar los siguientes problemas:

• No-relacional base de datos y datos limitación de almacenamiento;
• Lenguaje de programación estructurada;
• Falta de control de versiones de los códigos;
• Falta de pruebas integradas;
• Dificultad de mano de obra para realizar mantenimiento del sistema.

Como es sabido, un software de esta dimensión es un "vivo" que necesitan de constante evolución. En este sentido, se ha encontrado equipo coordinación de Suframa que dicho software no cumple con las necesidades de negocio más ni que las necesidades tecnológicas, entre las necesidades de las principales novedades son las siguientes:

• Integración con plataformas de web a través de servicios Web;
• Integración con plataformas y móviles
• Procesamiento, generación y exportación de informes en varios formatos.

Según el sitio electrónico de la institución, la Superintendencia de la zona franca de Manaos (Suframa) – es una autoridad local del Gobierno Federal dependiente del Ministerio de industria, comercio y servicios que pretende construir un modelo de desarrollo regional utilizar recursos naturales en forma sostenible, asegurar la viabilidad económica y mejorar la calidad de vida de la población. Actualmente la Suframa tiene como alcance los Estados de Amazonas, Acre, Rondônia, Roraima y Amapá.

Sobre la importancia del municipio para la región y el gran volumen de recursos recogidos, justifica el desarrollo de un nuevo sistema de recolección utilizado software modernos patrones de arquitectura y tecnologías. Por lo tanto, el curso de este artículo se propondrá una estrategia para el desarrollo del software mencionado en este artículo.

2. Patrones de arquitectura de software

Antes de definir patrones de que va a utilizar, es importante definir qué es un patrón de diseño de software, por lo tanto, según el estándar de diseño de Gamma (2000) son soluciones genéricas a los problemas más comunes y recurrentes en el desarrollo de software Orientada a objetos (OOP) por un equipo de desarrollo de software.

La intención principal del proyecto es reducir el riesgo de errores en el software mediante el uso de técnicas ampliamente probado y aprobado por la comunidad de desarrollo de software.

Segunda Gamma (2001), actualmente existen varios patrones de diseño y un montón de información para la investigación, entre estos patrones que podemos destacar:

• Inyección de dependencias o inyección de dependencia;
• Método de la fábrica;
• Bulder;
• Abstracty fábrica;
• Singleton;
• Prototipo de;
• Comando;
• Iterador;
• Estrategia;
• Visitantes entre otros;

En medio de la multitud de normas existentes, este artículo pretende dar a conocer los patrones sugeridos como base para el desarrollo del nuevo sistema de colección de la Superintendencia de la zona franca de Manaus que son: Domain-Driven diseño (DDD) y sólido, porque implica el uso de en el uso de diversas prácticas de desarrollo de Software.

De esta manera, no quiere decir que el curso del proyecto no se puede utilizar otras normas, sólo por enseñar cuestiones serán abordados estos dos patrones en este artículo. Así, en los capítulos siguientes abordaremos profundamente esas normas.

2.1. El diseño por defecto de basada en dominio (DDD)

Según Evans (2016) desarrollo impulsado por el dominio (DDD) es un enfoque disciplinado para el diseño de software que se ocupa de una serie de conceptos y técnicas centrándose siempre en el campo del software.

En este modelo, el foco del desarrollo es en el área del sistema, es decir, las reglas de la empresa de software.

Una gran ventaja de la DDD es que su enfoque está totalmente orientado a objetos, es decir, los desarrolladores deben construir el software con orientado al objeto programación, de esta manera, segundo Cukier (2010) los beneficios logrados son los siguientes:

• Código de alineación con el negocio: la participación de los desarrolladores de los amantes/expertos en el sector es de suma importancia cuando DDD, esta es una característica del desarrollo ágil;
• Fomentar la reutilización: los códigos desarrollados, pueden ser reutilizados de forma transparente.
• Enganche mínimo: después de modelado del modelo de datos bien desarrollado, organizado, las "capas" de software puedan comunicarse sin dependencia mediante el uso de interfaces;
• Independencia de la tecnología: DDD no se centra en la tecnología utilizada en el desarrollo del software, sino en reglas de negocio.

Sin embargo, su objetivo es llegar al código de área necesario para el software a ser desarrollado con una arquitectura que permite la aplicación de los conceptos de DDD, así que segundo Cukier (2010) el patrón sugiere el uso de cuatro capas principales son:

En la figura anterior, las siguientes son aclaraciones segunda Cukier (2010):

• Interfaz de usuario – es la capa responsable de la interacción directa con el usuario, como el software pantallas, Web Servicios SOA resto, aplicaciones móviles o computadoras de escritorio, entre otros;
• Funcionamiento de la aplicación directamente con la capa de dominio con el fin de aislar la zona de capa "Interfaz de usuario", es importante para los papeles distintos, por ejemplo: no hay ninguna necesidad de sabe que interfaz de la clase de dominio debe realizar cierta acción . De esta manera, la capa de aplicación es una especie de mediador entre el dominio y la interfaz;
• Dominio: es la capa que contiene todas las reglas de negocio de la aplicación, es decir, todo lo que refleja los requisitos funcionales, los cálculos se manejan en esta capa;
• Infraestructura – responsable de la interacción con la infraestructura técnica, por ejemplo, acceso a los datos, acceso a sistemas de archivos, las comunicaciones de correo electrónico, entre otros.

Estas capas no son obligatorias, dependiendo de la necesidad del proyecto se pueden quitar o añadir nuevas capas. Lo que se debe tener en cuenta es la necesidad de programación imperativa orientada al dominio.

Pero hay algo que señalar, según Pires DDD (2016) la programación no es una arquitectura en capas ni una receta lista para su uso en cualquier software a desarrollarse. La DDD se centra en el desarrollo orientado al dominio, este es el enfoque y no de sus capas.

Antes de tales conceptos, llegar a los principales beneficios obtenidos mediante el uso de la DDD eso segunda Cukier (2010) que es la inducción al desarrollo de software dentro del escenario de mejora continua, lo que es una herramienta extremadamente útil para desarrollar software para calidad y que satisfaga las necesidades del cliente.

Por lo tanto, aplicar el estándar de proyectos significa rescata DDD verdaderamente programación orientada a objetos, porque su aplicación al equipo de desarrollo es necesario aplicar otras normas tales como: repositorio, decorador, estrategia, estado entre otros.

2.2. SÓLIDO

Según Martin (2008), Robert c. Martin identificaron cinco principios de la programación orientada a objetos que buscan la mejora de los códigos, tales principios son SRP, OCP, LSP, ISP y DIP. Antes de estos principios, Michael plumas señaló que se pudo crear el acrónimo llamado sólido que contiene los cinco principios. En la siguiente imagen se muestra el significado de las siglas:

Sigue la definición de cada parte de la sigla según la publicación de Martín (2008):

• Única responsabilidad principio o principio de responsabilidad única: una clase debe tener una y sólo una razón para cambiar. Este principio de una clase debe tener sólo un único propósito, por ejemplo: cuando crear una calculadora si no hacen que las operaciones matemáticas de una clase y todas sus operaciones, sino más bien, hacen una clase para cada operación;
• Abrir principio cerrado o abierto-cerrado principio: uno debe estar siempre abierta a la extensión y cerrado para la implementación, es por eso, cuando usted hace cambios a un código ya existente corre el riesgo de un impacto de error de varios otros fragmentos de código;
• Principio de sustitución de Liskov o principio de sustitución de Liskov: bases de clases siempre deben ser reemplazables por sus bases, es decir, una clase B hereda un 1 de enero siempre puede ser reemplazado por clase en una aplicación de código;
• Principio de segregación de interfaz o principio de segregación de Interfaces: las interfaces específicas muchos son mejores que una sola interfaz, como esta práctica tiene como objetivo reducir el acoplamiento de los códigos;
• Principio de inversión de dependencia o principio de inversión de dependencia: uno debe depender siempre de una abstracción y no de una implementación.

Al aplicar el sólido, obtienes los siguientes beneficios a su proyecto: posibilidad de realizar desarrollos de proyecto y mantenimiento, facilidad de prueba automatizados, menos esfuerzo para el desarrollo y la máxima reutilización del código del código.

3. Propuesta nueva colección sistema

El propósito de este artículo es proporcionar la base de conocimientos para el desarrollo de nuevo software para la gestión de la colección en manos de la Superintendencia de la Manaos libre comercio zona-Suframa utilizando el paradigma de programación orientada a objetos mediante la aplicación de las normas de Proyectos de DDD y sólido en el desarrollo del proyecto.

En esta propuesta, un plan de acción basado en el modelo de administración de 5W1H, tendríamos la siguiente planificación para el desarrollo:

Tabla 01-plan de acción para el desarrollo del nuevo sistema.

¿Qué hacer?	¿Por qué?	¿Cómo?	¿Donde?	¿Quién?	¿Cuando?
Definir el lenguaje de programación y tecnologías para el proyecto	Estandarizar el desarrollo de software.	Reuniones técnicas	En la coordinación de informática	Los directivos TIC, programadores y arquitectos de software	Primera semana
Preparar el entorno de desarrollo y aprobación	Crear mecanismos para el equipo a trabajar en el proyecto	Instalación de servidores, software y los marcos	En la estación de trabajo de los miembros del equipo de desarrollo y en los servidores.	Equipo Configuración y soporte de las TIC	Segunda semana
Recopilación de requisitos de software	Documentar la información para ser programado en el campo	Reuniones y entrevistas	Suframa	Analistas de requisitos	La semana 10 3.
Codificación de	Crear el software	Codificación y pruebas	En Suframa	Fábrica de software	De la semana 22 11.
Correcciones y aprobación	Averiguar si lo que se ha desarrollado realmente es lo que las necesidades de la Suframa y realizar correcciones	Realización de pruebas	Ambiente de aprobación	Expertos en el sector (empresarial)	De la semana 23 a 25.
Implementación	Que el sistema en la producción	Hacer la construcción en el entorno de producción	Los sistemas de hosting	Analista de configuración	Semana 26.

Fuente: Dibujado por el autor.

Como la tabla de arriba, parece que el proyecto tendrá unos seis y medio meses para completar, sin embargo cabe señalar que este plan de acción contiene macros, acciones serían necesarios otros planes al detalle cada acción en la ejecución de la macro.

En vista de la acción de "codificación" acentuado en la 01 tabla, el uso de DDD, esta propuesta se recomienda crear las siguientes capas:

• Capa capa-esta presentación será la visión del usuario y para marco Angular de web 2.0 se utilizan y a dispositivos móviles (Android/IOS) usando la estructura iónica;
• Capa de servicios, será responsable de proporcionar la capa de presentación todos los webservices en formato resto y tendrá la función de control mediante la inyección dependencia marco ninject;
• Capa de aplicación – responsable de implementaciones de aplicación, como registro encapsulado registro y dominio;
• Dominio de capa-contiene la aplicación de reglas de negocio, se las entidades, Interfaces y servicios de dominio;
• Nivel de infraestructura – responsable de los datos de acceso capa mediante una herramienta ORM, repositorios, enviando mensajes de correo electrónico y autenticación.

En todas las capas deben ser aplicación los principios de la sólida.

Conclusión

Este artículo técnico intentado elaborar simplemente una propuesta concreta de la migración de un sistema de herencia en el desarrollo de la plataforma baja para una plataforma moderna, utilizando como base las normas de desarrollo de proyectos de Software orientado al desarrollo Dominio (DDD) y sólido.

Se entiende que esta propuesta sirve como base no sólo para la colección de la Superintendencia de la zona franca de Manaus, pero también como base para otros proyectos de migración y evolución de software que se ejecuta en abierto para más ajustes y futuras reediciones por otros autores.

Referencias

Cuba de tintura de Kent. "Patrones de implementación". BOOKMAN. 2013. 168 p. ISBN 8565837971.

Gamma, Erich. "Patrones de diseño". BOOKMAN. 2000. 528p. ISBN 8573076100.

Evans, Eric. "Dominio por diseño 3ª edición". Libros alta. 2016. 528p. ISBN 8550800651.

Martin, Roberto. Codigo limpio: Un manual de la artesanía de Software ágil ". Prentice Hall PTR. 431p. ISBN 0132350882.

Disponible en: <http: cieam.com.br/?u="suframa-tenta-retomar-cobranca-da-taxa-de-servicos-administrativos_-suspensa-pelo-stf">consultado el 21 de abril de 2017.</http:>

Disponible en: <http: www.eduardopires.net.br/2012/06/ddd-tdd-bdd/="">consultado el 21 de abril de 2017.</http:>

Disponible en: <http: www.eduardopires.net.br/2016/08/ddd-nao-e-arquitetura-em-camadas/="">consultado el 21 de abril de 2017.</http:>

Disponible en: <http: www.agileandart.com/2010/07/16/ddd-introducao-a-domain-driven-design/="">consultado el 21 de abril de 2017.</http:>

[1] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te. Especialista en base de datos de ULBRA.

[2] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.

[3] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.

[4] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.

[5] Licenciado en Ciencias de la computación, actúa como un servidor público de la SUFRAMA, como analista administrativo-te.

[6] Licenciado en Ciencias de la computación, actúa como servidor de la SUFRAMA, analista administrativo-te.

[7] Licenciado en Ciencias de la computación, actúa como servidor de la SUFRAMA, analista administrativo-te.

[8] Se graduó en administración de empresas, actúa como servidor público de la SUFRAMA, como administrador.

[9] Licenciado en economía, actúa como servidor público de la SUFRAMA, como economista.