ARQUITECTURA DE REGLAS DE NEGOCIO BASADA EN MDA

1. Introducción

En el desarrollo de sistemas de información se han implementado los requisitos del mismo con métodos no estructurados. Este mecanismo deja de ser viable para sistemas de continuo cambio en las políticas del negocio. Sería más adecuado si se divide a los sistemas de información en tres componentes principales como ser: datos, procesos y reglas de negocio. En esta división, las reglas de negocio son una parte independiente de los requerimientos del sistema  necesitando un manejo especial [1].

Las reglas son ciudadanos de primera clase en el mundo de los requisitos. Estas pueden ser consideradas como sentencias que permiten a los usuarios expertos definir políticas, condiciones y conocimientos del negocio en unidades pequeñas y aisladas. Los requisitos, enfocados hoy como reglas de negocio (RDN), habitualmente se programan “a mano” por el desarrollador del sistema en el código fuente del front end, en los objetos de bases de datos de la aplicación (back end) o en ambos.

Pero que es una Regla de Negocio? Existen varias definiciones de reglas de negocio, algunas sencillas y compactas, otras más amplias y detalladas. Una regla de negocio según Ronald G. Ross es simplemente una regla que está bajo jurisdicción del negocio, lo cual significa que estas pueden ser creadas, revisadas y eliminadas cuando el negocio lo estime conveniente.

Tony Morgan por otra parte las define como una declaración compacta sobre un aspecto del negocio, usando un lenguaje simple, inequívoco, accesible a todas las partes interesadas: el dueño del negocio, el analista, el arquitecto técnico, y así sucesivamente [1].

Por qué modelar las Reglas de Negocio? resulta que por lo general, el área de negocios de una Organización conoce los procesos necesarios a implementar en los sistemas, pero dichos procesos carecen de documentación o es mínima la existente. Por lo que la documentación y programación de las reglas recaen por completo en el desarrollador del sistema y en el código fuente de la aplicación.

Pero que sucedería si estas reglas no se documentan bien?. Al momento de modificarlas y/o añadir nuevas reglas por otro desarrollador, este tendría que primeramente compenetrarse en el código fuente, con el peligro de alterar erróneamente la regla previamente programada.

Una forma de atenuar este problema seria modelar las Reglas de Negocio, de tal manera que se disponga de un lenguaje común de como estructurar las reglas para todos los desarrolladores. Por ello, la necesidad de modelar las reglas de manera fácil de entender e implementar, es lo más recomendable en sistemas de gran impacto.

Este articulo pretende mostrar una aplicación para modelar Reglas de Negocio basada en la Arquitectura Guiada por Modelos (MDA), como paradigma alternativo a la tradicional forma de desarrollo de aplicaciones, para ello primeramente se muestran definiciones de lo que es MDA y los elementos básicos para modelar reglas utilizando UML, diagramas de Maquinas de Estados y de Clases. Posteriormente se detalla el metamodelado de Reglas de Negocio que es considerada la parte central de la aplicación, luego se describe la construcción de la aplicación utilizando el IDE Eclipse, así como también la generación de código fuente Java que se estructuro en función de la tecnología Enterprise JavaBeans (EJB) , finalmente se muestran ejemplos del código generado con la aplicación.

2. Arquitectura Guiada por Modelos

La Arquitectura Dirigida por Modelos es una especificación detallada por el OMG (Object Management Group) que integra diferentes especificaciones y estándares definidos por dicha organización con la finalidad de ofrecer una solución a los problemas relacionados con los cambios en los modelos de negocio, la tecnología y la adaptación de los sistemas de información a los mismos [2].  

El MDA es un enfoque de desarrollo de software que define una nueva forma de construir software en la que se usan modelos a distintos niveles de abstracción, para guiar todo el proceso de desarrollo, así como la posibilidad de la generación automática de código a partir de los modelos definidos y de las reglas de transformación entre dichos modelos. El metamodelado es importante en MDA porque actúa como mecanismo para definir lenguajes de modelado, de forma que su definición no sea ambigua. Esta no ambigüedad permite que una herramienta pueda leer, escribir y entender modelos como los construidos con UML [3].

Para llevar a cabo su función, MDA se apoya en el estándar UML, que se lo describe a continuación brevemente.

3. UML

El lenguaje unificado de modelado (UML) es un lenguaje gráfico para el modelado de sistemas que permite modelar la arquitectura, los objetos, las interacciones entre objetos, datos y aspectos del ciclo de vida de una aplicación, así como otros aspectos más relacionados con el diseño de componentes incluyendo su construcción y despliegue [5]. 

Los elementos del modelado de UML, es decir, clases, interfaces, casos de uso, diagramas de actividad, etc. pueden además ser intercambiados entre herramientas del ciclo de vida utilizando el formato XMI. 

Los diferentes elementos del modelado UML permiten especificaciones estáticas y dinámicas de un sistema orientado a objetos. Los modelos estáticos incluyen la definición de clases, atributos, operaciones, interfaces y relaciones entre clases, como pueden ser la herencia, asociación, dependencia, etc. La semántica de comportamiento de un sistema puede representarse por medio del lenguaje UML gracias a sus diagramas de secuencia y colaboración. Para modelados más complejos, UML proporciona mecanismos para la representación de máquinas de estado. Por último UML también proporciona una notación para representar el agrupamiento del diseño lógico por medio de componentes y el despliegue y ubicación de esos componentes en nodos dentro de una arquitectura distribuida [5]. 

De los diferentes diagramas de Estructura disponibles en UML nos concentraremos en el Diagrama de Clases y en los Diagramas de Maquinas de Estado.

4. Diagramas de Maquinas de Estado

En UML, los diagramas de estado permiten describir el comportamiento de un objeto. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que llegan a él. En la mayor parte de las técnicas Orientadas a Objetos, los diagramas de estado se dibujan para una sola clase, mostrando el comportamiento de un solo objeto durante todo su ciclo de vida [6].

La manera más sencilla para definir una máquina de estado, seria a partir de los siguientes elementos:

• Estado: Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación o puede recibir cierto tipo de estímulos.
• Transición: Una transición es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones cuando ocurre un evento.
• Estado Inicial: Es el estado de un objeto antes de que los eventos en el diagrama han actuado en él.
• Estado Final: Es el estado en el que el objeto alcanza a finalizar su ciclo de vida.

Por ejemplo, el siguiente diagrama ilustra los estados posibles para el objeto Teléfono:

Figura 1.- Diagrama de Estados para representar objeto Teléfono.

Del diagrama se puede observar que: Al ejecutar la transición “descolgar”, se crea el objeto Teléfono y queda en el estado “Tono”. Desde el estado “Tono”, la única transición habilitada para el objeto es la de “marcar”, que al ejecutarse dejaría el objeto en el estado “Esperando”, al ejecutar  la transición “llamando” el objeto queda en estado “Tono Llamando” y así sucesivamente, el objeto podría ir cambiando de estado en estado, hasta ejecutarse la transición “colgar”, que haría que el ciclo de vida del objeto Teléfono termine.

Si aplicamos este mismo concepto a objetos encargados de manejar lógica de negocio y de persistir información en una Base de Datos relacional, tendríamos la posibilidad de construir diferentes modelos de máquinas de estado relacionadas a cada objeto de negocio es decir a cada tabla relacional de un sistema en particular.

Sin embargo, habrá que considerar los siguientes aspectos:

• Todo objeto de negocio sobre la cual se desea manejar una máquina de estados, deberá consignar dos atributos:
• ESTADO, que se encargara de almacenar el estado actual del objeto de negocio modelado.
• TRANSICION o TRANSACCION, que se encargara de almacenar la última transición ejecutada por el objeto debido a un estímulo del sistema.
• Los Estados INICIAL y FINAL son ficticios, es decir solo sirven para el modelado pero se interpretan de la siguiente manera:
• Al momento de crear el objeto de negocio, se asume que el estado del objeto es el INICIAL de tal manera que es incorporado al contenedor que lo administra, lo que significa que el objeto es persistido en la tabla transaccional.
• Si por alguna TRANSICION o TRANSACCION, el objeto alcanza el estado FINAL, esto significa que el objeto es eliminado del contenedor que lo administra, en otras palabras es eliminado de la tabla transaccional.
• Cualquier otro ESTADO alcanzado por el objeto al ejecutarse una TRANSICION, hará que los atributos del objeto se actualicen en el contenedor, es decir se actualizara el registro de la tabla transaccional asociada al objeto.
• Si hablamos en términos de sentencias DML, podríamos indicar que las TRANSICIONES tendrían los siguientes ámbitos de ejecución en la máquina de estados:
• INSERT: aplicado únicamente desde el estado INICIAL del objeto de negocio, este ámbito significaría que el objeto es creado.
• UPDATE: aplicado para cualquier TRANSICION que no alcance los estados INICIAL y FINAL, este ámbito significaría que el objeto es actualizado.
• DELETE: aplicado para cualquier TRANSICION que alcance el estado FINAL, esto significaría que el objeto es eliminado.
• Al ejecutarse una TRANSICION, esta podría disparar varios eventos u operaciones, siendo el lugar idóneo para modelar Lógica o Reglas de Negocio. Nuevamente si pensamos en términos de sentencias DML y considerando que una instrucción DML actúa sobre una fila (ROW) en la tabla relacional, podríamos indicar que los eventos u operaciones podrían ejecutarse como sigue:
• BEFORE ROW: Antes de la fila o registro actual que maneja el objeto, es decir la lógica de negocio se ejecuta antes de la sentencia DML.
• AFTER ROW: Después de la fila o registro actual, es decir la lógica de negocio se ejecuta después de la sentencia DML.

Por ejemplo, supongamos deseamos crear una máquina de estados para la tabla RECURSOS_CIP, que se encarga de registrar documentos de Ejecución de Recursos de un sistema financiero, el objeto de negocio relacionado a esta tabla podría denominarse RecursosCip. 

Se desea que la máquina de estados controle y modele la Creación, Modificación, Eliminación, Verificación, Desverificación y Aprobación de registros en dicha tabla. La máquina de estados podría modelarse como sigue:

Figura 2.- Diagrama de Estados para representar ciclo de vida del objeto de negocio RecursosCip. 

De manera análoga al anterior diagrama, podemos indicar que: al ejecutarse la transición “CREAR”, este creara un nuevo objeto RecursosCip dejándolo en estado “ELABORADO”, desde el estado “ELABORADO”, el sistema o usuario podría ejecutar la transacción “VERIFICAR”, dejando el objeto en estado “VERIFICADO” y así sucesivamente.

5. Diagramas de Clases UML

Un diagrama de clases en UML, es un tipo de diagrama de estructura estática que describe los tipos de objetos en el sistema, las relaciones que existen entre ellos, los atributos y métodos de las clases, las restricciones de las clases y sus asociaciones.

La forma de definir una clase es a partir de sus miembros, es decir sus atributos y métodos.  Para especificar la visibilidad de un miembro de la clase, se coloca uno de los siguientes signos delante de ese miembro:  (+) Publico, (-) Privado, (#) Protegido [7]. 

Una relación es un término general que abarca los tipos específicos de conexiones lógicas que se pueden encontrar en los diagramas de clases, se presentan las siguientes relaciones: Asociación, Composición, Agregación, Dependencia, Generalización.

La multiplicidad de una asociación es el número de posibles instancias de la clase asociada con una sola instancia, son números simples o un rango de números por ejemplo 0, 1, 0,..1, 0..*, 1..*.

Tomando en cuenta estas consideraciones, acerca de la definición de Diagramas de Clase en UML, las mismas se utilizaron como herramienta para el metamodelado de Reglas de Negocio.

6. Metamodelado de Reglas de Negocio

Para soportar el manejo y administración de Reglas de Negocio, para un entorno de desarrollo Java utilizando la tecnología EJB. Se propone la creación de los siguientes metamodelos:

• Metamodelo para representar Maquinas de Estado.
• Metamodelo para representar clases Java, que comprende la definición de atributos, métodos y anotaciones Java. Además de la representación de superclases e importaciones de clases.
• Metamodelo para representar clases EJB, como ser: Entity Beans, clases para Llaves Primarias, Session Beans, Interfaces Locales, Remotas y relaciones entre dichas clases.
• Metamodelado para representar la ejecución de Reglas de Negocio según las transiciones definidas en la máquina de estados para un objeto de negocio.

A continuación describimos los metamodelos mencionados.

6.1. Metamodelo de Maquinas de Estado

Este metamodelo permite definir una máquina de estado finita simple, según lo mencionado en el punto 5, los elementos que se modelan son:

• La máquina de estados podrá representar uno o más elementos declarativos (Declaration), como ser Transiciones y Estados.
• Los estados podrán ser declarados como: Inicial, Final o Normal.
• Una transición podrá relacionarse con un estado origen (source) y un estado destino (target). 
• Por cada transición se podrán definir un conjunto de Reglas o Lógica de negocio (rules), que se ejecutaran al momento de dispararse la transición.

Figura 3.- Metamodelo para Maquina de Estados simple.

6.2. Metamodelo de Clases Java

El objetivo de este metamodelo, consiste en modelar una clase Java, contemplando los siguientes elementos:

• Definición de clase Java incluyendo implementaciones y extensiones
• Súper Clases Java que permitan definir relaciones de implementación y extensión de la clase Java.
• Atributos de la clase, si la clase corresponde a un Objeto de Negocio se le adicionan atributos que correspondan a los campos de una tabla relacional como ser: nombre de columna, tipo de dato, longitud, etc.
• Métodos de la clase, incluyendo excepciones y parámetros.
• Anotaciones Java para la clase, atributos y métodos.
• Importaciones de la clase.
• Todos los elementos consideran modificadores de acceso.

Figura 4.- Metamodelo para representar Clases Java

6.3. Metamodelo de Clases EJB

Este metamodelo tendrá como objetivo, representar los elementos más importantes de la tecnología EJB, que es la que se utilizara como Back-End de la aplicación a desarrollar.

Consideramos a EJB como una tecnología idónea para programar Lógica y Reglas de Negocio en Java, de ahí que se modelaron los siguientes elementos:

• Los Objetos de Negocio (tablas relacionales) se representan como Entity Beans, adicionalmente se definen atributos que hagan referencia a la tabla relacional como ser: esquema, nombre de la tabla y tipo.
• Si un objeto de negocio tiene una llave compuesta, se crea una clase Primary Key y una relación con el Entity Bean.
• Si un Entity Bean requiere de una clase Listener, se crea una clase Entity Listener y una relación bidireccional con el Entity Bean.
• La Lógica de Negocio se representa mediante Session Beans que podrían ser de tipo Stateful, Stateless o MessageDriven.
• Los Session Beans podrían contener varios métodos, cada uno con su  código fuente asociado, adicionalmente se definirán métodos exclusivos para manejar operaciones DML del objeto de Negocio (clase MethodForDml).
• Todos los Session Beans podrán relacionarse a una clase Java que represente a la Maquina de Estados del objeto de negocio, creando la clase StateMachineClass mas una relación al Session Bean.
• Para la creación de interfaces locales y remotas asociadas a los Session Beans, se tienen las clases LocalInterface y RemoteInterface respectivamente. En estas interfaces se expondrán los métodos DML del objeto de negocio, para que sean accedidos desde cualquier cliente.

Figura 5.- Metamodelo para representar Clases EJB.

6.4. Metamodelo de Reglas de Negocio

Con este metamodelo se pretende representar  la lógica o reglas de negocio que se ejecutaran al dispararse cualquier transición de la máquina de estados. Las reglas se modelan de dos maneras, la primera forma es definir reglas de validación es decir cada regla está limitada a una estructura de validación predeterminada, en este caso el desarrollador tendrá la facultad de definir la regla con ciertos parámetros preestablecidos en el sistema que servirán para validar información. La segunda forma es la de definir la regla como un método es decir, el desarrollador podrá definir la regla de negocio de manera libre en un metodo, introduciendo código fuente al sistema o invocando la ejecución de un método de una determinada clase Java.

Cabe mencionar que el conjunto de reglas definido tendrá un orden de ejecución establecido, el cual el desarrollador podrá cambiar a conveniencia. Además, a cada regla se le asignara un ámbito de ejecución y una sentencia DML correspondiente.

Todas las reglas tendrán dos parámetros, el primero corresponde al objeto con los datos que se pretende actualizar y validar (precNew) y el segundo parámetro al objeto que contiene los datos previos a la actualización (precOld).

Tomando en cuenta estos detalles, el metamodelo de Reglas de Negocio se define de la siguiente manera:

• Las transiciones podrán tener un conjunto de reglas (rules).
• Cada regla (clase Rule) tendrá una descripción, una sentencia DML de ejecución, un ámbito de ejecución, un orden determinado y en caso de ejecución fallida un mensaje de error. Ya que esta clase hereda de la clase Method, la regla podrá ser implementada en un Session Bean.
• Se definen las siguientes reglas de validación:
• CompareRule, regla de comparación que permite validar por medio de un operador el contenido de un atributo del Entity Bean con un valor estático.
• ListRule, regla de tipo lista que permite validar el contenido de un atributo en una lista de valores estáticos.
• RangeRule, regla de tipo rango que permite validar el contenido de un atributo en un rango mínimo y máximo.
• UniqueKeyRule, regla de llave única que permite validar la existencia de una llave única en base a los atributos del Entity Bean.
• Se definen las siguientes reglas por método:
• MethodRule, regla donde se escribe un método de validación cualquiera, el desarrollador escribe el código fuente respectivo en el atributo “body”.
• CallMethodRule, regla que permite ejecutar un método de una clase Java definida en el modelo, para ejecutar el método indicado se deberá mapear los parámetros definidos en el método con los atributos del Entity Bean (CallMethodParameters).

Figura 6.- Metamodelo para representar Reglas de Negocio.

7. Aplicación para Administrar Reglas de Negocio

La aplicación que permite administrar las Reglas de Negocio la denominamos “RdnStatemachine”, está construida bajo estándares de modelado MDA y el Eclipse Modeling Framework (EMF) . Se utilizó el IDE Eclipse Modeling Tools versión Oxygen  y los frameworks Eclipse Sirius, Eclipse Acceleo  y Eclipse RCP. En el espacio de la aplicación, se integraron los siguientes proyectos:

• Proyecto EMF (org.eclipse.sirius.statemachine), permite definir el metamodelo de Reglas de Negocio, en base a los diseños presentados en el punto 6, generando el archivo “statemachine.ecore” y el archivo de generación de código fuente del metamodelo “statemachine.genmodel”.
• Proyecto de Editor Gráfico del metamodelo generado por EMF (org.eclipse.sirius.statemachine.design), construido en base a la tecnología Eclipse Sirius. En este proyecto se elaboró el archivo “statemachine.odesign” que representa al editor grafico del metamodelo “statemachine.ecore”, como resultado de la ejecución de este editor, los desarrolladores podrán elaborar diferentes modelos de Máquinas de Estado que se almacenan en archivos XMI, estos archivos tendrán extensión “.statemachine”. Adicionalmente se crearon comandos de Eclipse Plug-in Development que permitan ejecutar procesos de generación de código fuente e importación de elementos al modelo, estos comandos son:
• Comando para Generación de POJO’s o archivos de clases Java simples a partir de los Entity Beans, estos archivos solo contemplan atributos y métodos getters y setters.
• Comando de Generación de Entity Beans, permite generar archivos de clases Java de los Entity Beans en formato EJB, es decir  contemplan las anotaciones de Entity Beans para la clase, atributos y métodos.
• Comando de Generación de Session Beans, permite generar archivos de clases Java de tipo Session Bean en formato EJB, acá se contemplan métodos para administrar las reglas de negocio, métodos DML, métodos para administrar la máquina de estados y métodos propios.
• Comando para Importar una Tabla relacional al modelo.
• Comando para Importar una Clase Java al modelo.
• Cabe hacer notar que la generación de código fuente se la almacena en el directorio “src-gen” del proyecto de modelado.
• Proyecto de Interfaz de Usuario con Eclipse RCP (org.eclipse.sirius.statemachine.design.ui.wizards). En este proyecto se crearon interfaces de usuario de tipo Wizard para los siguientes procesos:
• Wizard para crear un nuevo proyecto de Reglas de Negocio que permite crear todos los artefactos necesarios para que el desarrollador comience con el modelado.
• Wizard para importar una tabla relacional de una Base de Datos como Entity Bean.
• Wizard para importar una clase Java a partir de código fuente (archivo .java) al modelo, esta importación permitirá habilitar a la clase Java en la definición de una Regla de Negocio de tipo CallMethodRule.
• Proyecto de Templetas Acceleo (org.eclipse.sirius.statemachine.template), utilizadas para la generación de código fuente Java, se programaron las siguientes templetas:
• Templeta para generación  de POJO’s (generatePojo.mtl)
• Templeta para generación de Entity Beans (generateEntityBean.mtl)
• Templeta para generación de Session Beans (generateSessionBean.mtl)
• Templeta para generación  de clases Java  (generateNormalClass.mtl)

A continuación se muestran algunas pantallas desarrolladas para esta aplicación.

Figura 7.- Ejemplo de editor gráfico para Maquina de Estados.

Figura 8.- Ejemplo de editor gráfico para Clases Java, Clases EJB, Super Clases, Interfaces EJB y sus relaciones.

Figura 9.- Ejemplo de editor gráfico para Reglas de Negocio (transición CREAR de la máquina de estados de RecursosCip).

8. Generación de Código Fuente

Como se indicó anteriormente la generación de código fuente se la realiza por medio de un proyecto de templetas que utiliza el framework Acceleo, este framework permite generar código a partir de un modelo, implementa la especificación M2T o ModelToText de la OMG y posee varias características como un editor que implementa un leguaje de manejo de templetas con resaltador de sintaxis, detección de errores, refactorización, etc.

Una templeta llegaría a ser la estructura sobra la cual Acceleo genera código, para generar código por medio de una templeta el framework genera una clase Java que permite ejecutar la templeta desde un proyecto integrado o ejecutarlo individualmente desde el IDE.

A continuación mostramos un ejemplo de una templeta Acceleo desarrollada.

Figura 10.- Templeta de generación de código Java para Session Beans.

Como indicamos anteriormente en el diagrama de clases de un proyecto de modelación se habilitaron 4 comandos para la generación de código fuente, para POJO’s, Entity Beans, Session Beans y clases Java comunes.

Figura 11.- Comandos habilitados para la generación de código fuente.

El código se almacena en la carpeta “src-gen” del proyecto y dependiendo de la definición de los artefactos, se genera también una estructura jerárquica de paquetes, es decir si por ejemplo un Entity Bean tiene definido el paquete bo.com.entities, la templeta Acceleo creara una estructura de paquetes o directorios dentro la carpeta src-gen, con los mismos nombres.

Figura 12.- Estructura jerárquica de paquetes generado por las templetas Acceleo.

A continuación se muestra ejemplos del código fuente generado para el objeto de negocios RecursosCip.

Figura 13.- Ejemplo de código fuente de Entity Bean (RecursosCip.java).

Figura 14.- Ejemplo de código fuente de Primary Key (RecursosCipPK.java).

Figura 15.- Ejemplo de código fuente de Session Bean (RecursosCipService.java).

Figura 16.- Ejemplo de código fuente de Interface Local para Session Bean (RecursosCipServiceLocal.java).

Figura 17.- Ejemplo de código fuente para definir Maquina de Estados (Statemachine.java).

9. Conclusiones y Recomendaciones

Del trabajo realizado se puede concluir lo siguiente:

• Es factible la utilización de tecnologías EMF y MDA para el modelado de Reglas de Negocio.
• Si bien la aplicación desarrollada “RdnStatemachine” es un prototipo, su funcionalidad permite administrar Lógica y/o Reglas de Negocio de manera visual y declarativa.
• El metamodelado de Reglas de Negocio, puede ser ampliado  a otros modelos, como por ejemplo: Arboles y Tablas de decisión.
• El trabajo realizado no está orientado a la creación de un BRMS (Bussiness Rules Management System), lo que pretende es modelar Lógica y Reglas de Negocio de manera visual, facilitando el trabajo de un desarrollador.

Como recomendaciones, se puede indicar que es necesario armar un proyecto piloto para analizar la implementación de este esquema en una aplicación donde las reglas son programadas en forma de paquetes y procedimientos almacenados en la Base de Datos por ejemplo.

10. Bibliografía

[1] Reglas de negocio en bases de datos relacionales, Alain Pérez Alonso. Extraído de: https://www.researchgate.net/publication/303859206_Reglas_de_negocio_en_bases_de_datos_relacionales (última fecha de acceso: Noviembre 14 del 2018).

[2] La Arquitectura Dirigida por Modelos (MDA). Extraído de: http://is3ados.blogspot.com/2008/12/la-arquitectura-dirigida-por-modelos.html (última fecha de acceso: Noviembre 14 del 2018).

[3] Arquitectura Dirigida por Modelos (MDA). Extraído de: https://ingenieriadelsoftwareuah2015.wordpress.com/2015/03/23/arquitectura-dirigida-por-modelos-mda/ (última fecha de acceso: Noviembre 14 del 2018).

[4] El Modelo de Proceso de Negocio. Extraído de: http://www.sparxsystems.com.ar/downloads/whitepapers/El_Modelo_de_Proceso_de_Negocio.pdf (última fecha de acceso Nov 15 del 2018).

[5] Definición de Lenguajes de Modelos MDA vs DSL. Extraído de: https://www.researchgate.net/publication/268373048_Definicion_de_Lenguajes_de_Modelos_MDA_vs_DSL (última fecha de acceso Noviembre 15 del 2018).

[6] Diagramas de Estado, Mareño Sanchez Ivan. Extraído de: http://virtual.usalesiana.edu.bo/web/practica/archiv/estados.doc (última fecha de acceso Noviembre 17 del 2018).

[7] Diagramas de Clases, Wikipedia. Extraído de: https://es.wikipedia.org/wiki/Diagrama_de_clases  (última fecha de acceso Noviembre 18 del 2018).