ARQUITECTURA DE SOFTWARE BASADA EN EL SISTEMA DE MODULOS
←
→
Transcripción del contenido de la página
Si su navegador no muestra la página correctamente, lea el contenido de la página a continuación
Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
ARQUITECTURA DE SOFTWARE BASADA EN EL SISTEMA DE MODULOS
JAVA
Beverido Castellanos-Julio Andrés, † Juárez Martínez-Ulises, †
Reyes Hernández-Luis Ángel,† Abud Figueroa-María Antonieta, † Sánchez Cervantes-José Luis
ISC. Beverido Castellanos Julio Andrés
juabeca@hotmail.com, jsanchezc@ito-depi.edu.mx
___________________________________________________________________________________________________
___________________________________________________________________________________________________
Abstract
La complejidad de los sistemas de software se relaciona estrechamente con la falta de modularidad. Si bien
existen alternativas de solución por parte de los lenguajes de programación para resolver esta problemática,
resultan insuficientes dado que se limitan al nivel de código y únicamente cubren algunos puntos relacionados al
tema. Java en versiones previas al JDK 9 dependía de una estructura monolítica para ejecutar sus aplicaciones,
considerando dicha problemática Oracle implementó un sistema de módulos que permite a las aplicaciones
contener únicamente lo que requieren para su ejecución. Con la finalidad de ofrecer un diseño más apegado al
desarrollo modular siguiendo la organización del patrón arquitectónico MVC (Modelo-Vista-Controlador),
resolver los problemas de diseño que presenten los sistemas migrados a Java 9 , y dado que no se reporta en la
literatura una arquitectura basada en el sistema de módulos de Java 9, se propone una arquitectura considerando:
un enfoque de componentes, interfaces requeridas, exportación de interfaces, utilización de servicios y
protección de módulos.
Keywords
Java, Módulo, Arquitectura
Introducción contribuir al desarrollo modular y mejorar las
decisiones de diseño que presenten los sistemas
La modularidad es un tema importante en la migrados a Java 9. Cabe destacar que Java 9 fue
comunidad de software dado que permite el migrado rápidamente a Java 10 y posteriormente a
desarrollo de software de calidad y fácil de Java 11, pero las pruebas en su momento se
mantener. Sin embargo, la complejidad del mismo realizaron bajo Java 10.
radica en que no se suscita únicamente a nivel de
código, sino también a nivel de entorno de I. Trabajos relacionados
ejecución. Si bien existe el principio de separación
de asuntos, el cual permite la separación de un Erdweg, S., & Ostermann, K. (2017)
sistema en secciones que atienden diferentes establecieron como objetivo demostrar cómo las
responsabilidades y ayuda a llevar a cabo una características de un modelo son integradas en un
descomposición modular adecuada, las tecnologías
lenguaje de programación sin romper el
per se soportan parcialmente el desarrollo de
módulos ofreciendo soluciones basadas en modularidad. Para lograr dicho objetivo propusieron
interfaces, agrupamiento (ej. paquetes), por un sistema de módulos basado en SugarJ para el
consiguiente, no ofrecen un soporte modular desarrollo dirigido por modelos que integre
adecuado. Considerando esta problemática, se modelos, código convencional, metamodelos y
propone el desarrollo de una arquitectura que transformaciones como módulos en un marco de
aproveche el potencial modular que brinda el trabajo para manejar dependencias. El sistema de
sistema de módulos de Java 9 siguiendo la
módulos garantiza la ausencia de dependencias
organización del patrón MVC, considerando un
enfoque basado en componentes, con la finalidad de ocultas, es decir, todo lo requerido por un módulo
90
Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
para su ejecución debe ser declarado de manera composición avanzada para introspección y
explícita permitiendo así la compilación por composición de módulos. CORE (Concern-Oriented
separado de los módulos. Reuse, Reutilización Orientada a Asuntos) es un
nuevo paradigma de desarrollo de software
Kübler, F. et al. (2017) propusieron como objetivo inspirado por las ideas de separación
modularizar los análisis estáticos de programa con multidimensional de asuntos, las cuales permiten la
la finalidad de obtener reutilización. Para lograr correcta separación de conceptos de importancia
dicho objetivo se propuso el desarrollo de un marco dentro de un dominio. CORE construye de manera
de trabajo llamado SootKeeper, el cual utiliza utilizable representaciones de soluciones basadas en
modularidad de OSGi (Open Services Gateway las disciplinas de MDE (Model-Driven Engineering,
initiative, Iniciativa de Puerta de Enlace de Ingeniería Dirigida por Modelos), líneas de
Servicios Abiertos) el cual es un consorcio dedicado productos de software, modelado de objetivos, y
a la modularidad, con la finalidad de separar análisis técnicas de modularización avanzadas ofrecidas por
en pequeños compartimientos, los cuales se ejecutan la orientación a aspectos para definir módulos
de forma individual y en paralelo. flexibles de software que permiten la reutilización
Rentschler, A. et al. (2014) definieron el objetivo de de software basada en modelos de gran escala.
controlar las dependencias entre módulos, haciendo En la Tabla 1 se muestra un análisis comparativo
hincapié en que estas deben ser explícitas. Mucho entre las diferentes propuestas relacionadas a
del esfuerzo en entender las transformaciones de modularidad con respecto a la arquitectura
modelos se produce por la complejidad inducida por propuesta basada en el sistema de módulos de Java
el alto nivel de datos y control de dependencias. Se (ArqJ).
propuso un sistema de módulos basado en cQVTom
(Core QVT-Operational-Modular, Núcleo Tabla 1. Análisis comparativo entre propuestas de
Operacional Modular QVT) que incluya no solo el modularidad
control de dependencias como parte de sus contratos
Artículo A B C
de interfaz, sino también las dependencias de
información a nivel de clase de los modelos
Erdweg, S., & Sí
involucrados.
Ostermann, K. (2017).
Stiévenart, Q. et al. (2016) marcaron como objetivo Kübler, F., Müller, P., Sí
separar la definición de semánticas de lenguaje de la & Hermann, B. (2017).
abstracción de la máquina, con la finalidad de
Rentschler, A., Werle, Sí
obtener una modularidad alta. Se presentó SCALA-
D., Noorshams, Q.,
AM, un marco de trabajo para implementar análisis Happe, L., & Reussner,
estáticos como máquinas abstractas R. (2014)
sistemáticamente abstraídas. Los análisis
implementados en SCALA-AM separan la Stiévenart, Q., Nicolay, Sí
semántica operacional de los asuntos de abstracción
J., De Meuter, W., &
De Roover, C. (2016)
de la máquina abstracta. Este modularidad facilita
variar el lenguaje analizado y el método de Schöttle, M., Alam, O., Sí
abstracción aplicado en un análisis. Kienzle, J., &
Mussbacher, G. (2016).
Schöttle et al. (2016) establecieron como objetivo
Arquitectura de Sí Sí Sí
desarrollar un concepto de modularidad que permita
software basada en el
separar y empaquetar asuntos en una forma
reutilizable, y que permita el uso de mecanismos de Sistema de módulos de
91
Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
Java A pesar de la problemática que se suscita al
momento de la transformación modular del patrón
MVC. En el desarrollo de la arquitectura ArqJ no se
A) Investigación de propiedades modulares busca reemplazar ni presentar diferencias respecto
al patrón arquitectónico MVC, más bien, se busca
B) Desarrollo de un lenguaje y/o paradigma presentar en la arquitectura las distintas
con soporte de código características modulares que provee Java 9
utilizando el patrón arquitectónico MVC como base
C) Desarrollo de un lenguaje y/o paradigma central distribuida en módulos. Se consideró el
con soporte de entorno de ejecución patrón arquitectónico MVC como un patrón en el
cual las capas están conformadas de varios módulos
y no solo de macromódulos. Los módulos que, al
ser migrados generan muchas dependencias
modulares, deben ser subdivididos en módulos
Como se observa en la Tabla 1, las propuestas
siguiendo el principio de separación de asuntos sin
abordan conceptos particulares de modularidad en
romper con el patrón arquitectónico. De esta forma
diferentes áreas. ArqJ aprovecha las capacidades
se obtienen varias ventajas al aislar
modulares a nivel de código y entorno que brinda el
responsabilidades y resolver dependencias
sistema de módulos de Java 9. El contar con
modulares, entre ellas se encuentra la prevención
modularidad a nivel de entorno y código coadyuva a
del error de dependencia cíclica.
un mejor análisis y diseño arquitectónico.
El error de dependencia cíclica se suscita cuando
II. Metodología existe un módulo org.mod.a que tiene una
dependencia modular con org.mod.b, org.mod.b con
1) Revisión de lo reportado en la literatura respecto org.mod.c y su vez con org.mod.a, en el cual Java
a conceptos modulares y arquitecturas basadas en el no conoce el orden para resolver dichas
sistema de módulos de Java. dependencias.
2) Desarrollo de la arquitectura aprovechando las
características que brinda el sistema de módulos de Si bien existen soluciones a nivel de código como el
Java. patrón de diseño Observer, el cual permite notificar
3) Migración al sistema de módulos de Java del el estado de los objetos y de esta forma prevenir el
caso de estudio académico “Tabla periódica de error de dependencia cíclica, está solución
elementos químicos” utilizando ArqJ. implicaría una gran reestructuración a nivel de
código para todas las clases de los sistemas
III. Desarrollo de la arquitectura migrados a Java 9 involucradas en errores de
dependencia cíclica, generando un mal diseño a
Muchos de los sistemas migrados de Java 8 o futuro, además no alcanza a cubrir todos los
anteriores presentan problemas en materia de escenarios y problemas que presenta un sistema a
modularidad debido a que existe cierto grado de nivel modular. Por lo que la arquitectura ArqJ
acoplamiento que genera muchas dependencias presenta una solución a nivel arquitectónico
modulares innecesarias. A pesar de que existen siguiendo el patrón MVC, aplicando el principio de
patrones arquitectónicos como el MVC que permite separación de asuntos para solventar dichos
una organización adecuada del sistema problemas y no requiere la reestructuración de todas
arquitectónicamente hablando, brinda un diseño las clases.
modular limitado, por consecuencia, los módulos
del Modelo, la Vista y el Controlador se tornan En la Figura 1 se presenta la arquitectura ArqJ
robustos y con gran cantidad de dependencias planteada en este artículo:
modulares al ser migrados al sistema de módulos de
Java.
92Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
del módulo, por lo que, al ser una característica de
gran importancia, se manejó en ArqJ como el
estereotipo lo cual indica en la relación si
se trata de un acceso reflectivo o tradicional.
Otra característica que fue incorporada en los
descriptores de módulo fue el manejo de servicios y
proveedores. Dicha característica permite que un
módulo provea servicios a un módulo consumidor y
que uno o varios módulos proveedores ofrezcan
implementaciones del módulo de servicios. Al igual
que con la protección modular se optó por el manejo
de estereotipos en ArqJ indicando el perfil de los
módulos: de servicios, proveedores y consumidores.
Los proveedores deben indicar en su relación la
implementación que ofrecen de qué módulo de
servicios a que consumidor, así como los
consumidores deben indicar con una dependencia
qué módulo de servicios van a utilizar.
Fig. 1. Arquitectura ArqJ basada en el sistema de La Capa de Dependencias simboliza la arquitectura
módulos de Java. necesaria para que un módulo sea capaz de resolver
sus dependencias. En dicha capa se ubica el
Como se aprecia en la Figura 1, se consideran tres
descriptor de módulo, el cual, funge como
capas. En la Capa de Módulos se encuentran cuatro
manifiesto de un módulo de todos los
tipos de módulo: módulos de vista, módulos de
requerimientos que necesita para funcionar
controlador, módulos de modelo y módulos de
(módulos de Java y/o módulos creados) así como las
terceros. exportaciones en caso de ser necesario.
Como se mencionó anteriormente, el sistema de
Todo módulo en Java puede exponer y/o requerir
módulos de Java brinda modularidad no solo a nivel
interfaces hacia otros módulos, en el esquema
de código sino también a entorno de ejecución. Una
tradicional orientado a objetos se manejan
vez realizado el sistema es posible generar una
referencias hacia otras clases para consumir los
máquina virtual que contenga únicamente los
métodos que provee dicha clase (ej. Clase de vista a módulos necesarios para su funcionamiento por
clase de controlador). Considerando lo ya
medio de la herramienta JLINK, mejorando la
mencionado, las referencias bajo el paradigma OO
modularidad y escalabilidad del sistema. Tomando
generan dependencias modulares en el sistema de
en cuenta esa característica, la Capa de Entorno
módulos de Java
considera el módulo JLINK como el generador de la
que requieren ser especificadas explícitamente en máquina virtual personalizada utilizando las
los descriptores de módulo pertinentes. Por lo que
dependencias de la Capa de Dependencias, sobre la
ArqJ establece en la capa de módulo el manejo de
cual los módulos de la Capa de Módulos trabajarán.
interfaces expuestas y requeridas que permitan
clarificar las dependencias entre módulos. Las
IV. Experimentación
dependencias son indicadas mediante relaciones de
contrato especificando los módulos involucrados.
En esta sección se explica una transformación
modular al caso de estudio académico “Tabla
En versiones previas al sistema de módulos de Java
periódica de elementos químicos”, dicho caso de
no existía una encapsulación fuerte de los campos
estudio es un sistema que presenta problemas de
debido a que, utilizando mecanismos de reflexión
modularidad entre las clases que conforman el
era posible acceder los valores de los campos. En el
sistema. A continuación, se presenta en la Figura 2
sistema de módulos los módulos son capaces de
un análisis preliminar de dependencias modulares
especificar si permiten el manejo de mecanismos de
del caso de estudio:
reflexión en su totalidad o solo en algunos paquetes
93Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
Fig. 3. Solución al caso de estudio académico
“Tabla periódica de elementos químicos”
aplicando los lineamientos de ArqJ.
V. Resultados
La arquitectura presenta grandes ventajas en
términos de utilidad dado que permite al
desarrollador trabajar de manera natural con el
sistema de módulos de Java explotando las ventajas
Fig. 2. Análisis de dependencias modulares del que este ofrece.
caso de estudio académico “Tabla periódica de
elementos químicos”. Como se aprecia en la Figura 3, al realizar un
correcto análisis de dependencias modulares
Como se puede apreciar en la Figura 2, las legadas, es posible diseñar una solución que permita
dependencias legadas entre módulos del caso de migrar un sistema desarrollado previamente al
estudio presentan varios problemas de dependencia sistema de módulos y que se subdivida en módulos
cíclica aun considerando un patrón arquitectónico a modo que, los problemas de dependencia cíclica
como el MVC, para este caso existen muchas se solucionen.
dependencias entre el módulo del modelo debido a
las instancias de clases. Para este caso de estudio se Hay que considerar un correcto análisis de
suscita la problemática de muchas dependencias dependencias modulares del sistema que se busca
hacia dos clases que permiten anotar clases y anotar transformar al sistema de módulos de Java, así
métodos, dichas dependencias se presentan en las como identificar correctamente los módulos que
tres capas y son las causantes de los problemas de conforman el patrón arquitectónico MVC, con la
dependencia cíclica. finalidad de que las dependencias entre módulos
sean las adecuadas. La arquitectura presenta con
Siguiendo la subdivisión modular y los lineamientos claridad las interfaces que exponen y requieren los
que se proponen en la arquitectura ArqJ, en la módulos uno de otro, así como los mecanismos que
Figura 3 se muestra la arquitectura del caso de se ocupan para acceder a los mismos (ej. Modelo →
estudio: elementos), de manera que, es posible realizar la
transformación modular de un sistema con mayor
facilidad bajo la arquitectura ArqJ.
Conclusiones
El sistema de módulos es una característica sólida
que se mantendrá transparente a lo largo de las
versiones 9, 10 y 11 de Java, por lo que migrar los
sistemas al nuevo sistema de módulo permitirá una
mayor mantenibilidad a mediano y largo plazo. Las
transformaciones modulares implican un análisis
completo del sistema, lo cual se torna complejo si se
trata de un sistema conformado por un gran número
de paquetes y/o clases, sin embargo, una vez
realizada la transformación pertinente, es posible
extender la funcionalidad del sistema con mayor
facilidad aprovechando las ventajas modulares que
ofrece el sistema de módulos de Java.
94Número Especial de la Revista Aristas: Investigación Básica y Aplicada. *** ISSN 2007-9478. *** Vol.7, Núm. 14. *** Año 2019
Como trabajo a futuro, existe gran potencial para la Ritschel, N., & Erdweg, S. (2015). Modular Capture
arquitectura en cuestiones de modularidad si se Avoidance for Program Transformations. In
combina en conjunto con AspectJ, cabe destacar que Proceedings of the 2015 ACM SIGPLAN
AspectJ permite el trabajo con el sistema de International Conference on Software Language
módulos de Java pero aun no brinda un “corte” al Engineering (pp. 59–70).
descriptor de módulo, por lo que el soporte modular
queda limitado. Sin embargo, no se descarta que a Cazzola, W., & Shaqiri, A. (2016). Modularity and
mediano plazo AspectJ incorpore dicha Optimization in Synergy. In Proceedings of the 15th
característica, mejorando así la modularidad de la International Conference on Modularity (pp. 70–
arquitectura. 81).
Referencias
Erdweg, S., & Ostermann, K. (2017). A Module-
System Discipline for Model-Driven Software
Development. CoRR, 1(2), 1–28.
Kübler, F., Müller, P., & Hermann, B. (2017).
SootKeeper: Runtime Reusability for Modular
Static Analysis. In Proceedings of the 6th ACM
SIGPLAN International Workshop on State Of the
Art in Program Analysis (pp. 19–24).
Rentschler, A., Werle, D., Noorshams, Q., Happe,
L., & Reussner, R. (2014). Designing Information
Hiding Modularity for Model Transformation
Languages. In Proceedings of the 13th International
Conference on Modularity (pp. 217–228).
Stiévenart, Q., Nicolay, J., De Meuter, W., & De
Roover, C. (2016). Building a Modular Static
Analysis Framework in Scala (Tool Paper). In
Proceedings of the 2016 7th ACM SIGPLAN
Symposium on Scala (pp. 105–109).
Schöttle, M., Alam, O., Kienzle, J., & Mussbacher,
G. (2016). On the Modularization Provided by
Concern-oriented Reuse. In Companion
Proceedings of the 15th International Conference
on Modularity (pp. 184–189). New York, NY,
USA: ACM.
Figueroa, I., & Robbes, R. (2015). Is Functional
Programming Better for Modularity? In
Proceedings of the 6th Workshop on Evaluation and
Usability of Programming Languages and Tools
(pp. 49–52). New York, NY, USA: ACM.
95También puede leer
