Embed Size (px)
Citation preview
Generación de Entregables de Arquitectura Empresarial Basada en Ingeniería de
Modelos
Trabajo de Tesis
Presentado al
Departamento de Ingeniería de Sistemas y Computación
Por
Giovanni Andrés Villegas Quimbaya
Asesor
Jorge Alberto Villalobos Salcedo Ph.D
Co-Asesor
Mario Eduardo Sánchez Puccini Ph.D
Para optar por el título de
Magíster en Ingeniería de Sistemas y Computación
Ingeniería de Sistemas y Computación
Universidad de los Andes
Enero de 2012
Contenido
Capítulo I – Introducción ........................................................................................................... 8
Capítulo II – Planteamiento del problema ........................................................................... 9
Capítulo III – Contexto del trabajo ....................................................................................... 11
1. Modelado de arquitectura empresarial .................................................................. 11
2. Entregables y artefactos de arquitectura empresarial ............................................ 12
3. Trabajo relacionado............................................................................................... 14
3.1. Lenguajes de plantilla ............................................................................................ 14
3.2. Herramientas......................................................................................................... 15
3.3. Propuestas de investigación .................................................................................. 16
Capítulo IV – Solución propuesta ......................................................................................... 19
1. Descripción general............................................................................................... 19
2. EnArDocs – Lenguaje de plantillas ........................................................................ 20
3. EnArAnalyse – Consultas y generación de artefactos ........................................... 31
4. Generador de documentos .................................................................................... 42
5. Catálogo de artefactos .......................................................................................... 44
Capítulo V – Experimentación ............................................................................................... 45
1. Descripción del escenario MDLA........................................................................... 45
2. Metamodelo y modelo unificado de MDLA ............................................................ 45
3. Personalización de artefactos ............................................................................... 53
4. Listado de artefactos generados ........................................................................... 57
5. Evaluación de resultados obtenidos ...................................................................... 63
Capítulo VI – Implementación ............................................................................................... 64
1. EnArDocs y EnArDocsFragments ......................................................................... 64
2. EnArAnalyse ......................................................................................................... 66
3. Generador de documentos .................................................................................... 68
Capítulo VII – Conclusiones .................................................................................................... 69
Bibliografía y referencias ....................................................................................................... 70
Apéndice A – Gramática de EnArDocs ................................................................................ 73
Apéndice B – Ejemplo de plantilla en EnArDocs ............................................................. 82
Apéndice C – Listado de funciones de EnArAnalyse ...................................................... 83
Índice de figuras
Figura 1 – Relaciones indirectas entre elementos como base de las matrices ................... 9
Figura 2 - Cambios en la organización implican cambios en el modelo y mantenimiento de
los entregables ......................................................................................................... 10
Figura 3 - Proceso de modelado al inicio de un proyecto de arquitectura empresarial -
Fuente [22] ............................................................................................................... 12
Figura 4 - Especificación del entregable de arquitectura empresarial .............................. 13
Figura 5 - Proceso de generación de documentación [7] ................................................. 16
Figura 6 - Esquema del proceso de generación de documentación - Fuente [19] ............ 17
Figura 7 – Estrategia de generación del entregable ......................................................... 20
Figura 8 - Sintaxis abstracta de EnArDocs ....................................................................... 22
Figura 9 - Ejemplo de creación de secciones en función de los elementos del modelo .... 31
Figura 10 - Representación utilizada por EnArAnalyse para el modelo, sus elementos y
relaciones ................................................................................................................. 32
Figura 11 - Sintaxis de la llamada a las funciones de EnArAnalyse dentro de EnArDocs 32
Figura 12 - Sintaxis alternativa para llamada de funciones anidadas ............................... 33
Figura 13 – Modelo de Archisurance - Fuente [11] .......................................................... 40
Figura 14 - Procesos de negocio vs aplicaciones para Archisurance ............................... 41
Figura 15 - Actores de negocio vs roles de negocio para Archisurance ........................... 41
Figura 16 - Catálogo de aplicaciones para Archisurance ................................................. 41
Figura 17 - Metamodelo del documento producido por el motor de plantillas de EnArDocs
................................................................................................................................. 43
Figura 18 - Metamodelo de aplicaciones.......................................................................... 45
Figura 19 - Metamodelo del Business Motivation Model (BMM) ....................................... 46
Figura 20 - Metamodelo de la arquitectura de procesos del negocio ............................... 46
Figura 21 - Metamodelo de aliados de negocio................................................................ 47
Figura 22 - Conceptos comunes para representar localización geográfica y de red ......... 47
Figura 23 - Metamodelo de la estructura financiera ......................................................... 48
Figura 24 - Metamodelo de recursos humanos ................................................................ 48
Figura 25 - Metamodelo de información ........................................................................... 49
Figura 26 - Metamodelo de infraestructura ...................................................................... 49
Figura 27 - Metamodelo de recursos de la organización .................................................. 50
Figura 28 - Metamodelo de la estructura organizacional .................................................. 51
Figura 29 - Metamodelo de productos ............................................................................. 51
Figura 30 - Metamodelo de servicios ............................................................................... 52
Figura 31 - Conceptos para representar componentes y estándares de tecnología ......... 52
Figura 32 - Visualización del modelo de MDLA ................................................................ 53
Figura 33 – MDLA - Application vs MDLAProcess ........................................................... 57
Figura 34 - MDLA - Data Objects vs Applications ............................................................ 57
Figura 35 - MDLA – Organizational Unit vs Role .............................................................. 58
Figura 36 - MDLA - Applications vs System Software ...................................................... 58
Figura 37 - MDLA – Applications vs Devices ................................................................... 59
Figura 38 - MDLA – Roles ............................................................................................... 59
Figura 39 - MDLA - Data Objects ..................................................................................... 60
Figura 40 - MDLA – Applications ..................................................................................... 60
Figura 41 - MDLA - Software Systems ............................................................................. 61
Figura 42 - MDLA - Infrastructure Services ...................................................................... 61
Figura 43 - MDLA - Infrastructure nodes .......................................................................... 62
Figura 44 - Esquema general de la implementación ........................................................ 64
Figura 45 - Proyectos XTEXT para los lenguajes implementados .................................... 65
Figura 46 - Gramática de EnArDocsFragments ............................................................... 65
Figura 47 – Modificación del script de generación de EnArDocsFragments ..................... 65
Figura 48 - Clases usadas para almacenar el modelo en memoria .................................. 66
Figura 49 - Conjunto de proyectos que conforman la librería EnArAnalyse ...................... 66
Figura 50 - Interfaz para implementar nuevas funciones dentro de EnArAnalyse ............ 67
Figura 51 – Ejemplo de archivo MANIFEST.MF con dependencias ................................. 68
Índice de tablas
Tabla 1 - Sintaxis concreta de EnArDocs ......................................................................... 30
Tabla 2 - Funciones básicas de consulta de EnArAnalyse ............................................... 35
Tabla 3 - Funciones básicas para generación de artefactos en EnArAnalyse .................. 38
Tabla 4 - Personalización de los artefactos TOGAF para el caso de estudio MDLA ........ 56
8
Capítulo I – Introducción
La arquitectura empresarial promueve el uso de los modelos, gracias a que proveen un
alto nivel de abstracción para estructurar y analizar la complejidad inherente a cada
organización. Por lo tanto, el proceso de modelado es una actividad indispensable dentro
de un proyecto de arquitectura empresarial. Sin embargo, durante el desarrollo de un
proyecto es necesario producir y consumir documentación que materialice el resultado de
los análisis sobre estos modelos. En el marco de arquitectura empresarial este tipo de
documentación recibe el nombre de entregables [23].
Los entregables suelen ser documentos con información de los modelos, cuya estructura
se ve afectada por factores como el alcance y los objetivos del proyecto, los lineamientos
de los frameworks de arquitectura empresarial y especialmente, por el contenido de los
modelos. Sin embargo, la empresa cambia constantemente e introduce nuevos elementos
que deben reflejarse en los modelos y la documentación que la describen. Generalmente,
la actualización de los entregables se realiza con un alto nivel de intervención humana, lo
que sumado a la complejidad de los modelos, probablemente introduce errores y hace
que se presenten problemas de ineficiencia e inconsistencia. Lo ideal sería que el
contenido y la estructura de los entregables se pudieran generar desde los modelos de
arquitectura empresarial.
La estrategia propuesta para ayudar a los usuarios durante este proceso de
documentación, se compone de un lenguaje de dominio específico (DSL) que permite
especificar la estructura y el contenido de los entregables, a través de un conjunto de
funciones para consultar y construir artefactos desde los modelos de arquitectura
empresarial. Por último, se proveen mecanismos de extensibilidad para adaptar las
funciones del lenguaje a las necesidades de cada organización, y obtener diferentes
formatos de salida para el entregable final.
Este documento está estructurado de la siguiente manera: En el capítulo dos se presenta
el planteamiento del problema; en el capítulo tres se presenta el contexto del trabajo, así
como el estado del arte relacionado; en el capítulo cuatro se describe la solución
propuesta y cada uno de sus componentes; en el capítulo cinco se presenta un escenario
de experimentación, con el objetivo de validar la propuesta; en el capítulo seis se describe
la implementación de los componentes de la solución; y por último, en el capítulo siete se
presentan las conclusiones del trabajo.
9
Capítulo II – Planteamiento del problema
Una organización posee un alto nivel de complejidad, que se ve reflejada en un modelo de
arquitectura empresarial igualmente complejo y de gran tamaño. Esto hace que la
producción de documentación derivada de estos modelos sea dispendiosa. En el caso
particular de los entregables de arquitectura empresarial, la construcción de artefactos
como las matrices [23] requiere un esfuerzo adicional porque es necesario encontrar las
relaciones entre elementos que muchas veces no están directamente relacionados
(Figura 1).
Figura 1 – Relaciones indirectas entre elementos como base de las matrices
Ahora bien, la organización cambia constantemente a través del tiempo: Se agregan
nuevos procesos de negocio, nuevas aplicaciones que los soporten, se adquieren
servidores para tener un mejor escalamiento, etc. Esta nueva información pasa a ser
parte del modelo de arquitectura empresarial, y por ende debe hacer parte de los
entregables. La actualización de esta información se hace con un alto nivel de
intervención humana, ya sea para revisar y extraer los nuevos datos desde el modelo, así
como para introducir los cambios en los entregables. El mantenimiento de los entregables
para conservar la consistencia con el modelo de arquitectura empresarial, es igual o más
dispendioso que la producción del entregable en primer lugar (Figura 2).
10
Figura 2 - Cambios en la organización implican cambios en el modelo y mantenimiento de los
entregables
Para abordar los problemas anteriores, se pretende cumplir con los siguientes objetivos:
1. Definir un lenguaje para la especificación de la estructura y el contenido de los
entregables en función del modelo de arquitectura empresarial
2. Definir una librería de funciones para consultar, analizar y generar los artefactos
arquitectura empresarial desde este modelo
3. Proponer una herramienta que incorpore estas soluciones, para generar los
entregables en base a uno o varios modelos de arquitectura empresarial de
manera semi-automatizada
11
Capítulo III – Contexto del trabajo
1. Modelado de arquitectura empresarial
El modelado es primordial para entender a la organización, ya sea durante el desarrollo
de un proyecto de arquitectura empresarial o para realizar un diagnóstico que requiera
tener una visión integral de sus dominios. Gracias a propuestas como [6][11][14] es
posible tener un lenguaje unificado de modelado para obtener un modelo que represente
esta visión integral de la organización. La importancia de este modelo unificado es que es
posible tener un mayor número de conceptos relacionados y sobretodo tener una mayor
capacidad de análisis transversal, para el soporte de la toma de decisiones al interior de la
organización.
Para construir este modelo unificado se inicia recopilando el conocimiento de los
stakeholders, los manuales y documentos informales que existen en la organización (t0).
Luego, un meta-modelador selecciona y ajusta los metamodelos tomados desde marcos
de referencia, que representan los dominios de interés para el proyecto de arquitectura
empresarial (t1). Los metamodelos se componen para obtener un lenguaje unificado de
modelado. Este lenguaje es usado por un modelador para construir el modelo de la
organización, en base al conocimiento recopilado inicialmente (t2). El modelo es luego
analizado por los expertos de dominio de la organización (t3), que construyen
documentación y artefactos para soportar la toma de decisiones (t4). A esta
documentación dentro del contexto de arquitectura empresarial se le denomina
entregables [22]. Las decisiones se materializarán en cambios y adiciones al modelo
durante una nueva iteración. El proceso se puede observar en la Figura 3.
12
Figura 3 - Proceso de modelado al inicio de un proyecto de arquitectura empresarial - Fuente [22]
Bajo este enfoque se asume que el metamodelo de arquitectura empresarial se mantiene
constante en el tiempo. Sin embargo, el modelo va a cambiar para ser consistente con la
realidad de la organización. Pero tal y como se puede observar en (t3) los entregables
soportan la toma de decisiones. Por lo tanto, esta documentación se debe actualizar a la
par que el modelo. En la siguiente sección se describe la relación entre los entregables y
artefactos de arquitectura empresarial con este modelo.
2. Entregables y artefactos de arquitectura empresarial
La estructura de un entregable se compone de capítulos y secciones, que a su vez
contienen artefactos tales como matrices, catálogos y diagramas [23]; junto con
descripciones textuales que los complementan. La especificación concreta de un
entregable está sujeta a los alcances y objetivos del proyecto de arquitectura empresarial
en el que se deban producir, a los marcos de referencia que se adopten, y sobre todo a la
estructura y contenido del modelo de arquitectura empresarial (Figura 4).
13
Figura 4 - Especificación del entregable de arquitectura empresarial
Un entregable con estas características es el Architecture Definition Document propuesto
por TOGAF para describir la arquitectura empresarial desde cuatro dominios: Negocio,
Aplicaciones, Información y tecnología. Cada uno de estos dominios puede estructurarse
como un capítulo dentro del entregable. Ya al interior de cada capítulo es común crear
secciones para cada conjunto de elementos por dominio. Por ejemplo, en el dominio de
negocio es común tener una sección con cada proceso de negocio, el diagrama que
describe sus actividades, y una descripción de cada una de ellas.
El contenido de los entregables, aparte del texto, lo constituyen artefactos de arquitectura
empresarial. Gran parte del razonamiento sobre el modelo se materializa a través de
estos: Las matrices ayudan a visualizar y razonar de forma simple las relaciones entre los
elementos; los catálogos contienen información relacionada con conjuntos de elementos.
Los diagramas se incluyen como imágenes que agrupan un determinado conjunto de
elementos y sus relaciones. Por ejemplo, en proyectos de arquitectura empresarial que
abarcan los cuatro dominios (Negocio, Aplicaciones, Información y Tecnología) es común
construir matrices para visualizar las relaciones entre los procesos de negocio y las
aplicaciones que los soportan, las entidades de datos que manipula cada aplicación, un
catálogo de las aplicaciones, los servidores que las soportan, un diagrama de entidades
de información y sus relaciones, etc.
14
Desde luego, el contenido y la estructura del modelo dependen del contexto donde se
construya y de las necesidades del proyecto que se quiera llevar a cabo. Sin embargo, las
necesidades para producir los entregables se pueden enmarcar dentro de:
Estructuración del entregable en base a los elementos del modelo
La construcción de las matrices requiere poder indagar sobre las relaciones entre
elementos indirectamente conexos
La construcción de los catálogos requiere filtrar elementos de acuerdo a criterios
específicos para cada dominio
Los diagramas pueden provenir de herramientas de modelado, pero esta
visualización puede aportar poco cuando el modelo es muy grande
A continuación se presenta el estado del arte relacionado con trabajos orientados a
generar documentación en base a fuentes de información estructurada (no
necesariamente modelos per se) y algunas herramientas de modelado que brindan
facilidades para estas tareas.
3. Trabajo relacionado
3.1. Lenguajes de plantilla
Los lenguajes de plantilla están diseñados para describir, en su mayoría, la lógica de
despliegue de datos desde un conjunto de fuentes de información. Se utilizan
generalmente para describir la capa de presentación en la Web, sin embargo son lo
suficientemente flexibles para generar documentos en aplicaciones que así lo requieran.
Velocity [24], FreeMarker [25] son lenguajes de plantilla muy utilizados para generar el
código de presentación en aplicaciones Web, pero se pueden usar igualmente para
generar cualquier texto de salida. Por otro lado, van en contra del patrón MVC [13] dado
que tienen efectos de borde, y además proveen instrucciones que los hacen muy
parecidos a un lenguaje de propósito general. La ventaja de este tipo de lenguajes es que
permiten tener instrucciones muy complejas y expresivas. Adicionalmente, son
extensibles, lo que los hace muy flexibles.
Los lenguajes de plantillas pueden ser de utilidad para desplegar y manipular POJOs
(Plain-Old-Java-Objects) y generar cualquier tipo de texto basada en la información que
15
estos contienen. Sin embargo, a menos que se usen para generar instrucciones en algún
lenguaje intermedio (HTML, XML) no es sencillo estructurar un documento y su
información de manera concreta.
3.2. Herramientas
Las herramientas de modelado, principalmente para el lenguaje UML, proveen algunas
capacidades para generar documentación en base a los modelos que permiten crear y
editar.
Agilian [26] es una herramienta comercial orientada al desarrollo de software, que provee
un entorno de modelado para UML, BPMN, diagramas Entidad-Relación (ERD) y
diagramas de flujo de datos (DFD). La herramienta contiene un editor para construir la
documentación desde los modelos construidos, haciendo uso de un editor WYSIWYG
(what you see is what you get) donde se arrastran los elementos y los diagramas hasta la
plantilla del documento. Esto hace más fácil la generación de la documentación, pero no
es posible ser más expresivo (por ejemplo para incluir resultados de consultas específicas
sobre los modelos) y los cambios del modelo no se reflejan automáticamente en la
documentación. Enterprise Architect [27] permite generar reportes de manera muy similar,
con la ventaja de que en cada ejecución de su generador es posible tener la información
actualizada desde los modelos. Esto, a cambio de menor expresividad para incluir la
información desde los modelos. BizzDesign Architect [28] es una herramienta de
modelado para el lenguaje Archimate [11], por lo tanto está más orientada al dominio de
arquitectura empresarial y posee funciones de reporte para generar la documentación de
los modelos construidos con ella. Sin embargo, la generación se hace a un alto nivel, lo
que no facilita la expresividad a la hora de especificar el documento final.
Aunque estas herramientas, todas comerciales, proveen facilidades para generar
documentación en base a modelos, están más orientadas al diseño y desarrollo de
software, con excepción de BizzDesign, que aunque ataca el problema, no es tan flexible
para extenderse a otros tipos de metamodelos diferentes a los propuestos por Archimate.
Por último, Gendoc2 [29] es una herramienta open-source que ofrece capacidades muy
similares a las propuestas en este trabajo. Gendoc2 hace parte del entorno de modelado
Top Cased basado en la plataforma eclipse. La herramienta permite construir plantillas de
documentos en formato MS Word 2007 u Open Office. Dentro de estas plantillas se
incluyen las referencias a los modelos y scripts de Acceleo [30] para consultarlos. Los
modelos pueden ser conformes a UML, EMF y Papyrus. Como elemento diferenciador de
16
esta herramienta, se proponen funciones concretas para construir artefactos de
arquitectura empresarial basados en los propuestos por TOGAF, de igual manera se
proveen mecanismos de extensión para incluir nuevas funciones (tal como lo hace
Gendoc2 a través de Acceleo) y se plantea un metamodelo que permite tener un modelo
del documento, lo que hace más flexible la generación del documento final en otro tipo de
formatos o estructuras (HTML, DocBook XML, PDF).
3.3. Propuestas de investigación
Las propuestas de investigación descritas a continuación, promueven la generación de la
documentación de un sistema, a partir de los modelos que especifican su diseño.
Sobresalen los sistemas embebidos, al parecer por la completitud de sus modelos
(estructura y comportamiento) a diferencia de los sistemas de propósito general.
MODDO [7] es una propuesta que permite generar documentación derivada de modelos
EMF. Utiliza el lenguaje de plantillas XPAND [31] para construir Information Objects (IO‘s)
desde el modelo. Los IO‘s son fragmentos XML que contienen la información de conjuntos
de elementos del modelo. Luego se usa una suite de edición para estos archivos, donde
se enriquece la información de los IO‘s. Una vez enriquecidos, estos fragmentos de
información se incrustan en una plantilla, de acuerdo al tipo de documento que se quiere
generar. Por último se utilizan transformaciones XML para generar la documentación final
en XHTML (Figura 5).
Figura 5 - Proceso de generación de documentación [7]
Este proceso presenta ventajas como la posibilidad de regenerar los IO‘s a medida que el
modelo cambia con el tiempo, lo que favorece también la reutilización de los fragmentos.
Sin embargo, los IO‘s sólo son el resultado de filtros aplicados al modelo, lo que hace
17
necesario que los usuarios utilicen un editor de archivos XML para agregar nueva
información o realicen análisis más complejos.
En [5] se aprovecha el formato XML en el que se almacenan los modelos de los sistemas
de automatización, diseñados con el soporte de una herramienta específica de este
dominio, para generar la documentación técnica. La propuesta plantea una serie de
transformaciones XSLT, que gracias a la completitud del modelado, permite tener una
documentación técnica muy elaborada del sistema final. Sin embargo, gracias a la
completitud de los modelos, la propuesta sólo se enfoca en extraer la información y
transformarla al formato del documento final. Esto, como ya se mencionó, puede ser
ventajoso en sistemas de este tipo, pero requiere de un uso extensivo de XSTL y de XML
para obtener resultados más elaborados.
La propuesta de [19] se enfoca en generar la documentación del software que se modela
con UML y SmartC, durante las etapas de levantamiento de requerimientos, diseño
preliminar y diseño detallado. Los autores definen un modelo para la documentación, que
a su vez se mapea a los modelos del sistema en cada una de las etapas de desarrollo de
software. El modelo de documentación especifica las instrucciones para extraer texto,
tablas y diagramas desde el modelo del sistema. Una vez que se han procesado estas
instrucciones, se combina el resultado con una plantilla que define el estilo del documento
final (Figura 6).
Figura 6 - Esquema del proceso de generación de documentación - Fuente [19]
18
La propuesta no es clara en profundidad sobre cada uno de los pasos que se llevan a
cabo. Sin embargo, una vez que se han procesado los modelos involucrados, se obtiene
un documento en formato MS Word, con la especificación del sistema. Al tratarse de un
proceso basado en este tipo de mapeo, es fácil obtener los mismos resultados tras cada
ejecución. Desde luego, no se obtiene tanta expresividad en los resultados ya que no hay
procesamiento de los elementos. Debido a las necesidades de análisis y expresividad
para poder tener artefactos de análisis, la propuesta no es flexible en este sentido.
Una propuesta más flexible es presentada en [9] a través de un perfil UML que se puede
extender y permite el uso de consultas y funciones para manipular los modelos. El modelo
del documento se estructura usando los elementos del perfil: sección y párrafo. Dentro de
cada sección o párrafo se incluyen los scripts para consultar el modelo. Terminado el
modelo del documento, se procede a procesarlo y validarlo. Si es válido, se ejecutan las
consultas sobre el modelo y se genera una representación intermedia en formato
DocBook XML. Desde este formato es posible generar la documentación en MS Word,
PDF y HTML, entre otros. La propuesta es flexible en cuanto a la extensibilidad de las
consultas, y a la portabilidad del perfil UML para ser usado en muchas herramientas de
modelado. Por otro lado, la estructura del modelo no es dinámica, ya que son los usuarios
los que definen directamente cada sección y párrafo. También es poco flexible en cuanto
a los tipos de modelos que puede aceptar, ya que se basa completamente en la
herramienta MagicDraw para acceder a los modelos.
19
Capítulo IV – Solución propuesta
En este capítulo se describe la propuesta para generar los entregables y artefactos de
arquitectura empresarial tomando como referencia las especificaciones del framework de
arquitectura empresarial TOGAF. Inicialmente se hace una descripción general de la
estrategia, para luego profundizar en cada uno de sus componentes.
La solución se ha definido en base a los siguientes requerimientos:
El conjunto de instrucciones del lenguaje para estructurar un entregable debe ser
mínimo y simple
Las funciones para consultar el modelo deben ser igualmente simples y mínimas
Si son necesarias nuevas funciones se deben proveer mecanismos de extensión
concretos para agregarlas
El proceso de generación del documento debe ser suficientemente flexible para
producir un documento en cualquier formato, no necesariamente MS Word
No se considera dentro del alcance:
La generación de diagramas desde los modelos. Para hacer frente a esta
necesidad se proveen instrucciones para incluir imágenes, e inicialmente un
conector para importar los diagramas de editores generados con GMF o Eugenia
[40].
1. Descripción general
Tal y como se mencionó anteriormente, un modelo unificado de arquitectura empresarial
provee una visión integrada de la organización. Se asume que este modelo se ha
construido en base a un metamodelo que permanece constante durante todo el proceso.
Inicialmente, el meta-modelador (encargado de construir el metamodelo) escribe las
funciones de consulta y análisis necesarias para extraer la información desde el modelo
(1). Estas funciones se importan en las plantillas que escribe el arquitecto empresarial,
encargado de especificar la estructura y el contenido de los entregables (2). El motor de
plantillas recibe como entrada: la plantilla del entregable, las funciones de análisis, el
modelo y los archivos externos referenciados dentro de la plantilla (archivos de texto e
imágenes) (3). Estos archivos permiten la inclusión de información que no está contenida
20
o no se puede generar en base al modelo. Una vez se han procesado las funciones y la
plantilla del entregable, se genera un modelo del documento que contiene toda la
información estructurada en capítulos, secciones, tablas, listados, imágenes y texto (4).
Este modelo ingresa a alguno de los generadores implementados, de cada generador
depende el formato de salida (5) (Figura 7).
Figura 7 – Estrategia de generación del entregable
2. EnArDocs – Lenguaje de plantillas
El lenguaje de plantillas diseñado para esta propuesta, con el objeto de estructurar el
entregable, se denomina EnArDocs (ENterprise ARchitecture DOCumentS). La intención
con EnArDocs no es proveer generación de texto en general, como lo hacen los lenguajes
de plantilla revisados en la sección de trabajo relacionado. En lugar de esto, está
orientado a proveer instrucciones para simplificar la estructuración de un entregable sin
21
necesidad de utilizar una notación adicional (XML), y además permitir que el contenido del
modelo se pueda integrar a la estructura del entregable a través de funciones de consulta.
EnArDocs cuenta con las siguientes características:
Definición de estructura del entregable a través de capítulos y secciones
Definición de elementos contenedores de información: tablas, listas, texto
Directivas para inclusión de archivos externos: texto e imágenes
Directivas para inclusión de fragmentos de plantilla (EnArDocs y Velocity) para
facilitar la reutilización
Directivas para control de flujo
Funciones de consulta y análisis sobre los modelos
Directivas para construir artefactos concretos de arquitectura empresarial: matrices,
catálogos y diagramas. Estos últimos a través de conectores con herramientas de
modelado
La sintaxis abstracta del lenguaje se puede observar en la Figura 8. Inicialmente, una
plantilla debe importar el conjunto de modelos que se van a utilizar como fuente de
información. Luego, se deben importar las funciones que sean necesarias para consultar y
analizar estos modelos. Los contenedores estructurales de información se pueden
clasificar en primarios y secundarios. Los contenedores primarios le dan la estructura al
documento en términos de capítulos y secciones. Los contenedores secundarios se
clasifican en tablas y listas. Estos dos tipos de contenedor conformarán la estructura del
entregable. Para el procesamiento de los elementos del modelo, se proponen dos
directivas concretas para el control del flujo: condicionales y ciclos. Luego, para agregar
contenido se proveen directivas para insertar texto, imágenes, fragmentos de plantillas de
EnArDocs, y procesamiento e inserción de plantillas Velocity. Por último, y para facilitar la
inserción de artefactos de arquitectura empresarial, se incluyen 3 directivas: matrix,
catalog y diagram. La sintaxis concreta del lenguaje se puede observar en la Tabla 1.
22
Figura 8 - Sintaxis abstracta de EnArDocs
23
Instrucción Descripción Ejemplo
importModel
‗modelLocationURI’
as $mAlias conformTo
‗mmLocationURI’
Importa el modelo localizado en (*.ecore)
modelLocationURI, que es conforme al
metamodelo localizado en mmLocationURI.
El modelo se puede referenciar luego a
través del alias $mAlias como una variable
más.
importModel ‗c:/mm.ea‘ conformTo
‗c:/eamm.ecore‘ as $model
importFunctionLibrary
‗locationURI‘
as $fAlias
Importa la librería de funciones (*.jar) para
ser referenciada con el alias $fAlias. Las
funciones contenidas dentro de la librería
se invocan usando este alias seguido de un
punto, seguido del nombre de la función y
sus parámetros entre paréntesis, separados
por coma: $fAlias.functionName(params)
importFunctionLibrary ‗c:/functions.jar‘ as
$functions
template {params}
Esta instrucción permite establecer los
siguientes parámetros:
name: Nombre de archivo del
documento generado
output_dir: Directorio de salida el
documento generado
template {
name: ―Architecture Definition Document‖,
output_dir: ―c:/documentation‖
}
chapter {params}
Agrega un capítulo a la estructura del
documento. Los capítulos pueden anidar
otros contenedores, más no otros capítulos.
chapter {
id: ―chapt_1‖,
title: ―Business Architecture‖
24
Parámetros:
id: Identificador único del capítulo
title: Título del capítulo
}
section {params}
Agrega una sección a la estructura del
documento. Las secciones pueden anidar
otros contenedores, incluyendo otras
secciones, más no capítulos. Parámetros:
id: Identificador único de la sección
title: Título de la sección
parent: (opcional) Identificador del
capítulo o la sección que contiene
esta sección
section {
id: ―sect_BP‖,
title: ―Business Processes‖,
parent: ―chapt_1‖
}
table {params}
tr
th header /th
/tr
tr
td data /td
/tr
/table
Agrega una tabla a la estructura del
documento. Los encabezados de la tabla
pueden contener cadenas de caracteres o
expresiones que den como resultado una
cadena. El contenido de las celdas puede
ser otros elementos, incluso otras tablas.
Sin embargo el documento de salida puede
no soportar este tipo de jerarquía.
Parámetros:
id: Identificador único de la tabla
table {
id: ―tbl_apps‖,
title: ―Application Inventory‖
}
tr
th
text { contents: ―Name‖ }
/th
th
text { contents: ―Description‖ }
25
title: Título de la tabla
parent: (opcional) Identificador del
capítulo o la sección que debe
contener al elemento
/th
/tr
tr
td
text { contents: ―CRM‖ }
/td
td
text { contents: ―Customer Relationship
Management Application‖ }
/td
/tr
/table
list {params}
item data /item
/list
Agrega una lista a la estructura del
documento. El contenido de los ítems de la
lista pueden ser otros elementos,
incluyendo otras listas. Sin embargo el
documento de salida puede no soportar
este tipo de jerarquía. Parámetros:
id: Identificador único de la lista
title: Título de la lista
parent: (opcional) Identificador del
capítulo o la sección que debe
list {
id: ―list_apps‖,
title: ―Applications supporting process‖,
type: ―unordered‖
}
26
contener al elemento.
type: (opcional) Tipo de lista:
ordered ó unordered (por defecto)
text {params}
Agrega un párrafo de texto al documento.
Parámetros:
id: Identificador único del párrafo
contents: Texto del párrafo
parent: (opcional) Identificador del
capítulo o sección que debe
contener al elemento
isExternal: Permite indicar (true ó
false) que el texto proviene de un
archivo externo, que se debe
resolver cuando se vaya a procesar
la plantilla
uri: Ruta absoluta del archivo
externo de texto (*.txt).
description: Agrega una
descripción para facilitar la
resolución en el momento de
resolver el archivo
text {
contents: ―Description‖
}
text {
isExternal: true,
uri: ―c:/appends/server_descr.txt‖,
description: ―File with application interfaces
description ‖
}
t{contents} Agrega un parráfo de texto al documento. t{―Description of the business process‖}
27
Es una forma abreviada de la instrucción
text{}. Facilita la inserción de texto cuando
no es necesario especificar más que el
contenido.
image {params}
Agrega una imagen al documento.
Parámetros:
id: Identificador único de la imagen
title: Título de la imagen
uri: Ruta absoluta del archivo
parent: (opcional) Identificador del
capítulo o la sección que debe
contener al elemento.
width: Ancho de la imagen
height: Altura de la imagen
image {
id: ―img_bp_bpmn‖,
uri: ―c:/business_process_bpmn.png‖,
title: ―Business Process Diagram‖
}
include „locationURI‘
(params)
Procesa un fragmento de plantilla e incluye
el resultado del procesamiento en el
documento. Los parámetros que recibe
corresponden a variables referenciadas
dentro del fragmento de plantilla a incluir.
La extensión de las plantillas de EnArDocs
es ―.eadf‖.
include ―c:/templates/information_arch.eadf‖
( model: $model )
processExternal ‗locationURI‘ Procesa una plantilla Velocity (*.vm) e processExternal
28
(params) incluye el resultado del procesamiento en el
documento. Los parámetros que recibe
corresponden a variables referenciadas
dentro de la plantilla a incluir.
―c:/templates/vt/numbered_table.vm‖
( processes: $businessProcess )
matrix {params}
Agrega una tabla que contiene la estructura
de un matriz típica de arquitectura
empresarial. Parámetros:
id: Identificador único de la matriz
title: Título de la matriz
parent: (opcional) Identificador del
capítulo o la sección que debe
contener al elemento
function: Función utilizada para
construir la matriz.
matrix {
id: ―mtx_1‖,
title: ―business process vs applications‖,
function:
$functions.simpleMatrix ( ―BusinessProcess‖,
“Application”, $functions.areRelated(), ―X‖ )
}
catalog {params}
Agrega un catálogo de elementos que
pueden representarse como una tabla o
una lista, dependiendo del número de
propiedades que se quieran mostrar,
asociadas al elemento. Parámetros:
id: Identificador único del catálogo
title: Título del catálogo
parent: (opcional) Identificador del
catalog {
id: ―cat_data_entities‖,
title: ―Data entities catalog‖,
function: $functions.dataEntitiesCatalog()
}
29
capítulo o la sección que debe
contener al elemento
function: Función utilizada para
construir el catálogo
diagram {params}
Agrega un diagrama del modelo
(actualmente en un editor generado sobre
GMF) como una imagen al documento.
Parámetros:
id: Identificador único del diagrama
title: Título del diagrama
parent: Identificador del capítulo o
la sección que debe contener al
elemento
uri: Ruta absoluta del archivo que
contiene el diagrama
diagram {
id: ―diag_goals‖,
title: ―Goals supported‖,
uri: ―c:/diagrams/goals_model.ecorediag‖
}
If (ifCondition) :
Expression
elseIf (elseCondition):
Expression
else:
Expression
/if
Instrucción condicional para controlar el
flujo de ejecución. La condición debe
corresponder a una expresión que dé como
resultado un booleano (true ó false).
if ( $process.name == ―Register‖ ) :
//instructions
elseIf ( $process.name == ―Pay‖ ) :
//instructions
else:
//instructions
/if
30
forEach iterable as $iterator :
Expression
/forEach
Ejecuta el conjunto de instrucciones
contenidas dentro de Expression por cada
elemento contenido dentro de Iterable
(Objeto que implemente la interfaz Iterable
de Java) y accede a cada elemento con la
variable $iterator.
forEach $functions.filterByElementType( $model,
―BusinessProcess‖ ) as $process:
text { contents: $process.name }
/forEach
Tabla 1 - Sintaxis concreta de EnArDocs
31
El lenguaje está diseñado para combinar el resultado de las consultas con la estructura
del entregable. Por ejemplo, el listado de entidades de datos filtradas desde el modelo se
puede recorrer una a una, crear una sección para cada entidad y dentro de ella agregar
una descripción de sus propiedades (Figura 9).
Figura 9 - Ejemplo de creación de secciones en función de los elementos del modelo
La gramática completa de EnArDocs implementada se puede ver en el Apéndice A del
documento. En la siguiente sección se presentarán las funciones de análisis que
complementan el alcance del lenguaje y permiten generar los artefactos de arquitectura
empresarial.
3. EnArAnalyse – Consultas y generación de artefactos
Tal como se mencionó anteriormente, el uso de una librería personalizada parte de la
necesidad de recorrer el grafo del modelo de una manera flexible. La librería se ha
denominado EnArAnalyse, y está orientada principalmente a brindar funciones que
faciliten la construcción de los artefactos de arquitectura empresarial, desde elementos
filtrados del modelo.
Para que las funciones se puedan ejecutar sobre el modelo, es necesario que éste se
transforme a una representación de grafo. Este grafo representa los conceptos del modelo
como Element, y a sus relaciones como Relation (Figura 10). A su vez, cada uno de ellos
contiene los atributos del concepto del modelo que le corresponden.
32
Figura 10 - Representación utilizada por EnArAnalyse para el modelo, sus elementos y relaciones
Una vez que se tiene esta representación del modelo, es posible usar algoritmos clásicos
de grafos para recorrerlo y encontrar caminos entre elementos que están indirectamente
relacionados. Por ejemplo, los procesos de negocio soportados por los diferentes nodos
de infraestructura, las aplicaciones que soportan la labor de un actor de negocio a través
de los procesos de negocio asignados a su rol de negocio, etc.
La sintaxis de las funciones cuando se invocan desde EnArDocs se puede observar en la
Figura 11. Cada llamada debe incluir el alias de la librería, además debe incluir un
elemento base para ejecutar la función y un conjunto de parámetros. El elemento base
suele corresponder a una referencia del modelo o un elemento de éste. Los parámetros
pueden corresponder a booleanos, cadenas de caracteres, números enteros y flotantes,
referencias a variables iterador dentro de un ciclo, o incluso el resultado de otras
funciones.
Figura 11 - Sintaxis de la llamada a las funciones de EnArAnalyse dentro de EnArDocs
Existen 2 maneras de ejecutar funciones anidadas. La primera es la más convencional
donde cada función se ejecuta y el resultado sirve como parámetro de la siguiente
función. La segunda manera es encadenar las funciones, de modo que el resultado de la
función se pasa a la siguiente como parámetro base. En la Figura 12 se puede observar la
manera de ejecutar la misma serie de funciones. En este caso debido a que todas las
33
funciones pertenecen a la misma librería, se puede obviar el nombre de la librería en la
forma encadenada. De lo contrario se antepone el nombre de la librería al nombre de la
función.
Figura 12 - Sintaxis alternativa para llamada de funciones anidadas
Las funciones de consulta a la fecha sirven para filtrar elementos en base a su tipo, su
nombre, y los valores de sus atributos. Sin embargo, gracias a los mecanismos de
extensión se pueden agregar nuevas funciones para consultar usando patrones de
búsqueda (por ejemplo, patrones en los caminos entre dos elementos, como se hace
ilustra en los ejemplos más adelante) expresiones regulares (por ejemplo, expresiones
regulares sobre los nombres de los atributos de los elementos) entre otras. Las funciones
de consulta básicas se pueden observar en la Tabla 2.
34
Función Descripción Ejemplo
filterByElementType ($model,
―ElementType1‖, “ElementType2”, …)
Retorna el conjunto de elementos que
corresponden a los tipos especificados,
desde el modelo $model.
//retorna los procesos de negocio
filterByElementType ($model,
―BusinessProcess‖)
filterByElementName ($model,
―ElementName1‖, ―ElementName2‖, …)
Retorna el conjunto de elementos que
corresponden a los nombres especificados,
desde el modelo $model. Requiere que los
elementos tengan un atributo ―name‖
definido.
//retorna los roles de aseguradora y
asegurado
filterByElementName ($model,
―Insurer‖, ―Insured‖)
FilterByElementAttributes ($model,
attOperator1(“att1Name”, att1Val),
attOperator2(“att2Name”, att2Val), …)
Retorna el conjunto de elementos desde el
modelo $model, cuyos atributos
corresponden a los especificados por cada
operador. Los operadores son los siguientes:
attEq(“attName”, attVal): operador
de igualdad entre el valor del atributo
con nombre attName y el valor attVal.
attGEt(“attName”, attVal): operador
―igual o mayor que‖, entre el valor del
atributo con nombre attName y el
valor attVal.
attGt(“attName”, attVal): operador
―mayor que‖, entre el valor del
atributo con nombre attName y el
//retorna los procesos de negocio cuyo
tiempo de respuesta sea menor a 50
milisegundos
FilterByElementAttributes ($model,
$f.attEq(―type_‖, ―BusinessProcess‖),
$f.attLt(―responseTime‖, 50))
35
valor attVal.
attLEt(“attName”, attVal): operador
―menor o igual que‖, entre el valor del
atributo con nombre attName y el
valor attVal.
attLt(“attName”, attVal): operador
―menor que‖, entre el valor del
atributo con nombre attName y el
valor attVal.
filterRelatedElements (Element,
―relationName‖)
Retorna el conjunto de elementos
relacionados, desde el element Element, a
través de la relación con nombre
relationName.
//retorna los roles de negocio asociados
al actor
filterRelatedElements ($businessActor,
―assignedBusinessRoles‖)
Tabla 2 - Funciones básicas de consulta de EnArAnalyse
36
Las funciones para construir artefactos usan la información de los elementos del modelo y
de sus relaciones. En el caso de las matrices, lo que se busca es visualizar las relaciones
entre 2 conjuntos de elementos, generalmente cada conjunto corresponde a un tipo
determinado (Procesos de negocio, aplicaciones, entidades de datos, nodos de
infraestructura, etc.). Para determinar si existe una relación entre dos elementos de cada
conjunto se puede aplicar una función que verifique si el camino que existe entre ellos es
válido. Por ejemplo, si un proceso de negocio X en realidad si es soportado por un nodo
de infraestructura Y. En el caso de los catálogos, generalmente se requiere filtrar un
conjunto de elementos, junto con algunas de sus propiedades o elementos relacionados.
Por ejemplo el inventario de aplicaciones de la organización puede contener las
propiedades: nombre, versión, interfaces expuestas, etc. El conjunto de instrucciones
básicas para generar artefactos se puede observar en la Tabla 3.
37
Función Descripción Ejemplo
simpleMatrix ( $model,
“ElementType1”, “ElementType2”,
“cellContent”, [showEmptyRowsCols] )
: MatrixArtifact
Retorna una matriz cuyas filas
corresponden a elementos de tipo
ElementType1, y sus columnas
corresponden a elementos del tipo
ElementType2. La función evalúa los
caminos entre cada par de elementos
de cada tipo, y si encuentra un camino
donde no se repitan los tipos
especificados, entonces establece el
valor de esa celda a cellValue. El
parámetro opcional boolean
showEmptyRowsCols establece si se
muestran filas y columnas vacías
(falso, por defecto).
//retorna la matríz de aplicaciones vs procesos de
negocio
simpleMatrix ($model, ―BusinessProcess‖,
―ApplicationComponent‖, ―X‖)
customMatrix ( $model,
fFilterElements1(), fFilterElements2(),
fAreRelated(),fValue() | ―Value‖,
[showEmptyRowsCols] )
Esta función ayuda a crear matrices
más personalizadas. Primero que todo
permite filtrar los elementos que se
quiere cruzar, usando las funciones
fFilterElement1 y fFilterElement2.
Los dos conjuntos de elementos se
//retorna una matriz entre aplicaciones y nodos de
infraestructura
customMatrix ($model, $f.filterByElementType (
―ApplicationComponent‖ ),
$f.filterByElementType(―Node‖),
$fx.areAppNodeRelated(),
38
filtrarán, para luego ser evaluados por
la función fAreRelated, que debe
retornar un valor verdadero o falso
para cada par de elementos,
dependiendo de si están relacionados
o no. La función fValue recibe como
parámetros los dos elementos, y
extrae el valor que se debe mostrar en
la intersección, si están relacionados.
En este último caso es posible pasar
una cadena de caracteres. El
parámetro opcional boolean
showEmptyRowsCols aplica igual que
en la función anterior.
$fx.extractAppNodeValue() )
simpleCatalog (
$model,”ElementType”, “attrName1”,
“attrName2”, …)
Retorna una tabla con las propiedades
del conjunto de elementos que
corresponden al tipo especificado.
//retorna el inventario de nodos de infraestructura
simpleCatalog ($model, ―Node‖, ―name‖,
―operativeSystem‖, ―speed‖, ―cores‖ )
customCatalog ( $model,
fFilterElements(), fExtractAttributes() )
Retorna una tabla con las propiedades
extraídas usando la función
fExtractAttributes, desde los
elementos filtrados por la función
fFilterElements.
customCatalog ( $model,
$f.filterByElementType(―DataObject‖),
$fx.extractDataObjectProperties() )
Tabla 3 - Funciones básicas para generación de artefactos en EnArAnalyse
39
Para ilustrar algunas de las funciones se utiliza un modelo derivado del metamodelo de
Archimate [11] (Figura 13). Este modelo contiene elementos representativos para cada
dominio de arquitectura: Negocio, aplicaciones e infraestructura, para una compañía
aseguradora con el nombre de Archisurance. La empresa cuenta con varios procesos,
pero el que aquí se presenta está relacionado con el reclamo de un seguro por parte de
un cliente. A continuación se presentan 3 artefactos básicos para este modelo. Se puede
observar el soporte de las aplicaciones (ApplicationComponent) hacia los procesos de
negocio (BusinessProcess) usando una matriz simple. También, los roles (BusinessRole)
que tiene asignado cada actor del negocio (BusinessActor). Por último se muestra un
catálogo básico con las aplicaciones existentes en el modelo. Esta corta personalización,
como se puede observar, permite generar los artefactos básicos de manera sencilla.
40
Figura 13 – Modelo de Archisurance - Fuente [11]
41
Procesos de negocio soportados por cada aplicación (aplicaciones que proveen un
servicio que es usado por un proceso de negocio)
Figura 14 - Procesos de negocio vs aplicaciones para Archisurance
Actores de negocio con los roles que tienen asignados
Figura 15 - Actores de negocio vs roles de negocio para Archisurance
Catálogo de aplicaciones
Figura 16 - Catálogo de aplicaciones para Archisurance
42
4. Generador de documentos
Una vez que se procesa una plantilla, junto con sus funciones y archivos externos, el
motor de plantillas produce un modelo del documento que es conforme al metamodelo de
la Figura 17. Este modelo contiene toda la información extraída desde los modelos que se
usaron como fuente de información. Permite asignar un conjunto de atributos (cadenas,
números enteros, números reales y booleanos) tanto al documento, como a los
contenedores de alto nivel: capítulo y sección. Estos contenedores anidan a los elementos
de contenido: tablas, listas, imágenes y texto. Las tablas están compuestas por filas, y
estas a su vez por celdas. Las celdas pueden contener a otros elementos de contenido.
Las listas están compuestas por ítems contenedores, al igual que las celdas de las tablas.
Las imágenes poseen un título y la ubicación del archivo. Los contenedores de texto
poseen un atributo para identificar si el texto se encuentra en un archivo externo, la
ubicación del archivo y su descripción. Cada elemento (contenedor o de contenido) puede
tener un identificador único, lo que podría permitir que los generadores puedan
implementar referencias cruzadas en el formato de salida.
El modelo del documento se puede procesar de manera independiente por parte del
generador que se quiera implementar. No es necesario procesar ni la plantilla, ni las
librerías de función utilizadas, ni los modelos que se hayan importado. Esto agrega
flexibilidad al tipo de salida que se puede generar.
El generador de documentos debe encargarse de asignar los estilos que considere
necesarios para cada uno de los elementos del modelo del documento. Como trabajo
futuro se planea implementar un modelo de estilos, que se pueda integrar al modelo del
documento en esta etapa y permita personalizar la estética del documento final.
43
Figura 17 - Metamodelo del documento producido por el motor de plantillas de EnArDocs
44
5. Catálogo de artefactos
Los artefactos caracterizados y adaptados desde el framework de arquitectura
empresarial TOGAF (tomando los elementos concretos de Archimate) son los siguientes:
Matrices
o System / Function (Application Components / Business Process)
o Data Entity / Data Component (Data Objects / Application Components)
o Actor / Role (Business Actors / Business Roles)
o System / Technology (Application Components / Software Systems)
o System / Technology (Application Components / Nodes)
Catálogos
o Role (Business Actors)
o Data Entity (Data Objects)
o Data Entity (Artifacts)
o Application portfolio (Application Components)
o Application portfolio (Software Systems)
o Technology portfolio (Infrastructure services)
o Technology portfolio (Infrastructure nodes)
En el capítulo de experimentación se utiliza una adaptación de estos artefactos y se crean
unos nuevos. Estos nuevos artefactos siguen basándose en matrices y catálogos, pero
están diseñados para el dominio del caso.
45
Capítulo V – Experimentación
1. Descripción del escenario MDLA
Como caso de estudio se utiliza el modelo de arquitectura empresarial de la empresa
Muebles de los Alpes S.A. (MDLA). Esta empresa es uno de los escenarios en el
laboratorio de arquitectura empresarial de la Universidad de los Andes [32]. MDLA se
dedica a la producción y comercialización de muebles para oficina y hogar. Cuenta con
gran reputación entre sus clientes, gracias a la calidad que tienen sus productos y a su
capacidad de innovación. Actualmente posee 3 puntos de fábrica y 10 salas de venta a lo
largo del país, pero los productos también se pueden adquirir a través de su portal web.
2. Metamodelo y modelo unificado de MDLA
El metamodelo de MDLA se compone de 14 dominios. A continuación se describe cada
uno de los dominios por separado.
2.1. Aplicaciones
Figura 18 - Metamodelo de aplicaciones
Contiene los conceptos para representar una aplicación, los servicios que provee, sus
instancias, las interfaces expuestas y las relaciones de consumo o integración entre estas
instancias.
46
2.2. Modelo de motivación del negocio (BMM)
Figura 19 - Metamodelo del Business Motivation Model (BMM)
Este dominio incluye los conceptos del Business Motivation Model [15]. Principalmente,
sirve para representar la motivación de la organización a través de su visión, metas,
estrategias, entre muchas otras.
2.3. Arquitectura de procesos de negocio (BPA)
Figura 20 - Metamodelo de la arquitectura de procesos del negocio
47
Permite modelar la jerarquía de procesos de la organización: la cadena de valor, sus
macro procesos, subprocesos y actividades. Estas últimas realizadas por un actor.
2.4. Aliados de negocio
Figura 21 - Metamodelo de aliados de negocio
Contiene los conceptos para modelar los aliados del negocio como: proveedores,
distribuidores, clientes. Igualmente, permite modelar los servicios que estos brindan, así
como el tipo de orden con la que cada uno de ellos interactúa: compra, entrega, venta.
2.5. Conceptos comunes
Figura 22 - Conceptos comunes para representar localización geográfica y de red
48
Estos conceptos se relacionan con el dominio Servicios, a través de las instancias de los
servicios. Sirve para describir la ubicación geográfica y de red, para cada una de las
instancias de un servicio.
2.6. Estructura financiera
Figura 23 - Metamodelo de la estructura financiera
Permite modelar de manera básica los pagos, asociados a una cuenta y entidad bancaria.
A su vez, cada pago puede ser realizado o recibido, y tiene una clasificación, una
condición, e impuestos asociados.
2.7. Recursos humanos
Figura 24 - Metamodelo de recursos humanos
Permite modelar a los empleados, su desempeño, salario, capacidades, competencias,
conocimiento y el equipo de personas al cual pertenece.
49
2.8. Información
Figura 25 - Metamodelo de información
Permite modelar las entidades de información, sus atributos, y las posibles
transformaciones necesarias para obtener una entidad canónica dentro del dominio de la
organización.
2.9. Infraestructura
Figura 26 - Metamodelo de infraestructura
Contiene los conceptos para representar los nodos, dispositivos, servicios ofrecidos por
estos elementos, y las redes de comunicación que los conectan.
50
2.10. Recursos de la organización
Figura 27 - Metamodelo de recursos de la organización
Contiene los conceptos para representar los activos fijos: bodega, planta de manufactura,
locaciones administrativas, tiendas y equipos. Cada producto puede hacer uso de alguno
de estos recursos.
51
2.11. Estructura organizacional
Figura 28 - Metamodelo de la estructura organizacional
Este dominio permite modelar la jerarquía organizacional, donde cada elemento en la
jerarquía supervisa y responde ante otro elemento organizacional, y es representado por
varios roles.
2.12. Productos
Figura 29 - Metamodelo de productos
Contiene los conceptos para modelar los muebles y su lista de materiales. Los materiales,
a su vez son una especialización de los productos, clasificados en varias categorías.
52
2.13. Servicios
Figura 30 - Metamodelo de servicios
Contiene los conceptos para modelar los servicios, sus instancias, interfaces y métodos.
Además, a cada servicio concreto se le pueden asociar requisitos de calidad como
disponibilidad y tiempo de respuesta.
2.14. Tecnología
Figura 31 - Conceptos para representar componentes y estándares de tecnología
Estos conceptos permiten representar componentes de tecnología como servidores de
aplicación, motores de bases de datos, middleware, entre otros. Además, estándares de
tecnología como protocolos de comunicación, seguridad, etc.
El modelo de MDLA contiene más de 1000 elementos y alrededor de 1500 relaciones.
Este modelo refleja en una buena escala la dificultad para extraer, de manera manual,
53
conjuntos de elementos, así como sus relaciones. Una visualización del modelo utilizado
VizGraph [33] se puede observar en la Figura 32.
Figura 32 - Visualización del modelo de MDLA
En la próxima sección se describe la personalización de los artefactos base de TOGAF
para el modelo de MDLA. Luego, se presentan los artefactos que se construyeron, su
caracterización, y por último se hace una evaluación de los resultados obtenidos.
3. Personalización de artefactos
Con el fin de generar el catálogo de artefactos propuesto por TOGAF, es necesario
personalizar la invocación de los métodos. Luego, es necesario mapear cada los
conceptos al dominio de MDLA. Este mapeo se puede observar en la Tabla 4.
Matrices
TOGAF MDLA Descripción
System / Function Application vs
MDLAProcess
El concepto más ajustado
para los procesos de
negocio es el
"MDLAProcess", mientras
que para las aplicaciones se
usa el concepto
"Application". Y lo que se
quiere observar es
precisamente las
aplicaciones que soportan
54
estos procesos. Se usa el
valor "supportedBY" para la
intersección entre estos dos
elementos.
Data Entity / Data
Component
Data Objects vs
Applications
Para las entidades de datos
se utiliza el concepto
"DataObject", sin embargo
la manipulación de objetos
de datos se hace por parte
de las actividades, por lo
tanto es necesario
identificar los servicios
(ApplicationService) que
provee cada aplicación y
establecer la relación. Se
usa el valor
"manipulatedBy" para la
intersección entre estos dos
elementos.
Actor / Role Organizational Unit vs Role
En este caso, debido a que
no existe la relación entre
los actores del negocio que
permita conocer sus roles,
se optó por mostrar la
relación de representación
que existe entre las
unidades organizacionales
"OrganizationalUnit" y los
roles de negocio "Role". Se
usa el valor "represents"
para la intersección entre
estos dos elementos.
System / Technology
(Application domain)
Applications vs System
Softwares
Aquí los conceptos
relacionados que se quieren
55
visualizar corresponden a
aplicaciones, cuyas
instancias
(ApplicationInstance) están
desplegadas en algún
sistema (SystemSoftware)
dentro del dominio de
infraestructura. Se usa el
valor "hostedBy" para
establecer la intersección
entre estos dos elementos.
System / Technology
(Infrastructure domain) Applications vs Devices
Los conceptos para esta
matriz pretenden ilustrar los
dispositivos "Device" donde
se alojan las instancias de
las aplicaciones. Se usa el
valor "supports" para
establecer la intersección
entre estos elementos.
Catálogos
TOGAF MDLA Descripción
Role Roles
Se consultan los conceptos
"Role" junto con su nombre
y descripción.
Data Entity (Application
domain) Data Objects
Se consultan los conceptos
"Data Object" junto con su
nombre y descripción.
Data Entity (Infrastructure
domain) N/A
Este artefacto no se puede
generar debido a que no
hay un concepto similar a
un "Artifact" (por ejemplo
una tabla dentro de una
base de datos) que realice a
los "Data Object" dentro del
56
modelo de MDLA.
Application portfolio
(Application domain) Applications
Se consultan los conceptos
"Application" junto con su
nombre y descripción.
Application portfolio
(Infrastructure domain) Software Systems
Se consultan los conceptos
"SystemSoftware" junto con
su nombre y descripción.
Technology portfolio
(Services) Infrastructure Services
Se consultan los conceptos
"Infrastructure" junto con su
nombre y descripción.
Technology portfolio
(Nodes) Infrastructure nodes/devices
Se consultan los conceptos
"Node" y "Device" junto con
su nombre y descripción.
Tabla 4 - Personalización de los artefactos TOGAF para el caso de estudio MDLA
La experimentación para el caso de estudio no se limitó a estos artefactos, como se podrá
observar en el listado de la siguiente sección. Aunque la validación de la propuesta
consiste principalmente en observar los resultados obtenidos con relación a los artefactos
TOGAF.
Tal y como se mencionó anteriormente, la generación de diagramas no se incluyó dentro
del alcance. Sin embargo, actualmente es posible extraer los diagramas desde
herramientas generadas con GMF o Eugenia. Como trabajo futuro se planea extender
esta importación a otras herramientas de modelado.
57
4. Listado de artefactos generados
Artefactos TOGAF
4.1. Matriz – Application vs MDLAProcess
Figura 33 – MDLA - Application vs MDLAProcess
4.2. Matriz – Data Objects vs Applications
Figura 34 - MDLA - Data Objects vs Applications
58
4.3. Matriz – Organizational Unit vs Role
Figura 35 - MDLA – Organizational Unit vs Role
4.4. Matriz – Applications vs System Softwares
Figura 36 - MDLA - Applications vs System Software
59
4.5. Matriz – Applications vs Devices
Figura 37 - MDLA – Applications vs Devices
4.6. Catálogo – Roles
Figura 38 - MDLA – Roles
60
4.7. Catálogo – Data Objects
Figura 39 - MDLA - Data Objects
4.8. Catálogo – Applications
Figura 40 - MDLA – Applications
61
4.9. Catálogo – Software Systems
Figura 41 - MDLA - Software Systems
4.10. Catálogo – Infrastructure Services
Figura 42 - MDLA - Infrastructure Services
62
4.11. Catálogo – Infrastructure nodes/devices
Figura 43 - MDLA - Infrastructure nodes
Artefactos propios del dominio de MDLA
4.12. Matriz – Aplicaciones vs Roles
4.13. Matriz – Aplicaciones vs Instancias de aplicación
4.14. Matriz – Aplicaciones vs Servicios de aplicación
4.15. Matriz – Estrategias vs Metas del negocio
4.16. Matriz – Estrategias vs Visión del negocio
4.17. Matriz – Cadena de proceso vs Procesos de negocio
4.18. Matriz – Servicios vs Instancias de servicio
4.19. Catálogo – Componentes de tecnología
4.20. Catálogo – Estándares de tecnología
4.21. Catálogo – Servicios de aplicación
4.22. Catálogo – Interfaces de aplicación
4.23. Catálogo – Productos y materiales
4.24. Catálogo – Servicios
4.25. Catálogo – Servicios concretos
4.26. Catálogo – Instancias de servicios
63
5. Evaluación de resultados obtenidos
Para realizar la evaluación de los resultados se tomó como base el entregable de
arquitectura empresarial elaborado por los arquitectos para Muebles de los Alpes. Este
documento contiene alrededor de 19 artefactos de arquitectura empresarial: 10 catálogos,
7 matrices (6 de ellas representadas como diagramas) y 2 diagramas para representar las
entidades de datos y un diagrama de despliegue.
De los 10 catálogos se han generado 7 (70%), de las 7 matrices se han generado 4
(57%), y los diagramas (realizados en Enterprise Architect) como se mencionó
anteriormente no hacen parte del alcance. Sin embargo, el documento está
desactualizado en relación con el modelo. Y evaluando estas cifras sería posible obtener
más del 50% de las matrices y catálogos, con la posibilidad de incluir los diagramas como
archivos externos de imagen.
Las dificultades para generar las 3 matrices y 3 catálogos restantes, están relacionadas
con cambios en la estructura del metamodelo y en algunos casos, debido a que el modelo
está en construcción, no se ha contado con la información necesaria.
64
Capítulo VI – Implementación
La implementación de los componentes se realizó en Java, usando como plataforma de
despliegue el entorno Eclipse. Todos los componentes se integraron en un plug-in que
permite acceder a la función de generación de documentos directamente sobre los
archivos de plantilla. El esquema general de la implementación se puede ver en la Figura
44.
Figura 44 - Esquema general de la implementación
1. EnArDocs y EnArDocsFragments
Se implementaron dos lenguajes de dominio específico para poder usar una plantilla
principal (EnArDocs) con una sintaxis estricta, y otro con una sintaxis relajada para los
fragmentos de plantilla (EnArDocsFragments). Este último, tal y como se mencionó
anteriormente pueden incluirse en otras plantillas, por lo tanto no tienen como requisito
importar modelos y librerías de funciones. La implementación se hizo usando XTEXT [34]
con un proyecto para cada lenguaje (Figura 45).
65
Figura 45 - Proyectos XTEXT para los lenguajes implementados
EnArDocsFragments define una gramática derivada del lenguaje EnArDocs. Gracias a
que XTEXT permite reutilizar gramáticas usando lo que se conoce como Grammar Mixins
no fue necesario re-escribir una gramática completa para poder usar los fragmentos de
plantilla con una sintaxis diferente (Figura 46).
Figura 46 - Gramática de EnArDocsFragments
Para lograr esta reutilización es necesario modificar el script de generación de
EnArDocsFragments (*.mwe2), para que importe el metamodelo generado para la
gramática principal. El parámetro modificado se puede observar en la Figura 47
Figura 47 – Modificación del script de generación de EnArDocsFragments
Una vez generados los editores para cada lenguaje se implementó un intérprete en Java,
que permite recorrer y procesar el árbol de sintaxis de cada programa escrito en ellos. El
intérprete carga los modelos importados en la plantilla usando el API de EMF [35]. Luego,
cada modelo se recorre y se convierte a una estructura de grafo en memoria usando la
librería JUNG [36]. Las clases usadas para esta representación se pueden ver en la
Figura 48.
66
Figura 48 - Clases usadas para almacenar el modelo en memoria
2. EnArAnalyse
La librería de funciones EnArAnalyse se encuentra implementada en cuatro proyectos
(Figura 49). El proyecto co.edu.uniandes.enar.analyse contiene las clases encargadas
de cargar el modelo en memoria, las clases para los artefactos (matriz y catálogo), y las
interfaces para extender la librería con nuevas funciones. El proyecto
co.edu.uniandes.enar.function.artifacts contiene las funciones básicas para generar los
artefactos TOGAF. El proyecto co.edu.uniandes.enar.function.core contiene las
funciones básicas para consultar elementos desde el modelo. Por último, el proyecto
co.edu.uniandes.enar.paths contiene funciones auxiliares para obtener caminos sobre el
grafo del modelo.
Figura 49 - Conjunto de proyectos que conforman la librería EnArAnalyse
El proceso para extender las funciones y poder crear nuevas librerías para cada proyecto
es el siguiente:
67
1. Crear una clase que implemente IFunction (Figura 50) que se encuentra dentro
de co.edu.uniandes.enar.analyse.core.function,
2. Crear un archivo MANIFEST.MF (Figura 51) que contenga las dependencias
necesarias,
3. Una vez implementadas las funciones deseadas, compilar el proyecto que las
contenga y crear un archivo JAR que contenga el archivo MANIFEST del paso
anterior,
4. Este archivo ya se puede importar en cualquier plantilla de EnArDocs.
Figura 50 - Interfaz para implementar nuevas funciones dentro de EnArAnalyse
68
Figura 51 – Ejemplo de archivo MANIFEST.MF con dependencias
3. Generador de documentos
El generador de documentos implementado permite generar archivos en formato MS
Word 2007, haciendo uso de la librería DOCX4J [37]. Esta implementación es práctica,
pero cuando se quieren hacer documentos con estilos precisos y listas anidadas puede
presentar problemas, debido a que requiere un conocimiento avanzado en el formato
Office Open XML [38]. Sin embargo funciona muy bien en comparación a otras
alternativas open-source, que presentan problemas mayores con este formato [39].
Los generadores que se deseen implementar deben utilizar el API de EMF para leer el
modelo del documento. Aunque también se puede optar por un lenguaje como XPAND o
Acceleo, más orientados a este tipo de modelos.
69
Capítulo VII – Conclusiones
Los modelos de arquitectura empresarial permiten abstraer y estructurar la realidad de la
organización, durante el desarrollo de un proyecto. Sin embargo, debido a la complejidad
propia de las organizaciones, la consulta y construcción de entregables de arquitectura
empresarial en base a ellos resulta dispendiosa. Más aun, cuando es necesario mantener
estos documentos en el transcurso del tiempo.
En este trabajo se abordaron estos problemas con una estrategia de solución compuesta
por: EnArDocs, el lenguaje de plantillas de entregables; EnArAnalyse, la librería de
funciones para realizar las consultas y generar los artefactos de arquitectura empresarial;
y por último un mecanismo para generar el documento final en el formato que se requiera.
El lenguaje propuesto contiene un conjunto simple y reducido de instrucciones para
estructurar la plantilla del entregable. Esta estructura se puede expresar usando los
elementos del modelo, permitiendo que ante un cambio en éste el entregable se
mantenga consistente. Además, para promover la reutilización se pueden utilizar
fragmentos de plantilla provenientes de EnArDocs o Velocity.
EnArAnalyse contiene mecanismos de extensión para agregar diferentes tipos de
consultas, y si es necesario generar nuevos artefactos. Se han generado 7 de los
artefactos propuestos por TOGAF, utilizando las funciones básicas propuestas. Esto ha
permitido validar la propuesta en primera instancia.
El generador del entregable en formato MS Word ha permitido verificar que el modelo de
documento producido como paso intermedio, sea lo suficientemente independiente para
producir el documento final.
Por último, se ha utilizado el escenario de Muebles de los Alpes como validación de la
propuesta y los resultados han sido satisfactorios. Se han generado 26 artefactos, en
comparación con los 19 que contiene el documento elaborado de forma manual, sobre un
modelo de un tamaño considerable.
70
Bibliografía y referencias
[1] T. Bucher, R. Fischer, S. Kurpjuweit, and R. Winter, ―Analysis and Application
Scenarios of Enterprise Architecture: An Exploratory Study,‖ 2006 10th IEEE International
Enterprise Distributed Object Computing Conference Workshops (EDOCW’06), pp. 28-28,
2006.
[2] S. Buckl, F. Matthes, C. Neubert, and C. M. Schweda, ―A wiki-based approach to
enterprise architecture documentation and analysis,‖ in The 17th European Conference on
Information Systems (ECIS)–Information Systems in a Globalizing World: Challenges,
Ethics and Practices, 2009, vol. 8, no. 10.
[3] S. Buckl, F. Matthes, and C. M. Schweda, ―Classifying enterprise architecture
analysis approaches,‖ Enterprise Interoperability, pp. 66–79, 2009.
[4] F. De Boer, M. Bonsangue, L. Groenewegen, A. Stam, S. Stevens, and L. Van Der
Torre, ―Change impact analysis of enterprise architectures,‖ in Information Reuse and
Integration, Conf, 2005. IRI-2005 IEEE International Conference on., 2005, pp. 177–181.
[5] E. Estevez, M. Marcos, and I. Sarachaga, ―Model based documentation of
automation applications,‖ , 2009. INDIN 2009., 2009.
[6] U. Frank, U. Koblenz-landau, and D.- Koblenz, ―Multi-Perspective Enterprise
Modeling ( MEMO ) - Conceptual Framework and Modeling Languages 2 . Enterprise
Modelling : Vision and,‖ Sciences-New York, vol. 0, no. c, pp. 1-10, 2002.
[7] M. Heinrich and A. Boehm-Peters, ―MoDDo-a tailored documentation system for
model-driven software development,‖ Proceedings of the, 2008.
[8] M. E. Iacob and H. Jonkers, ―Quantitative analysis of enterprise architectures,‖
Interoperability of enterprise software and applications, pp. 239–252, 2006.
[9] M. Jackson, C. Delp, D. Bindschadler, M. Sarrel, R. Wollaeger, and D. Lam,
―Dynamic gate product and artifact generation from system models,‖ in Aerospace
Conference, 2011 IEEE, 2011, pp. 1–10.
[10] P. Johnson, E. Johansson, T. Sommestad, and J. Ullberg, ―A Tool for Enterprise
Architecture Analysis,‖ 11th IEEE International Enterprise Distributed Object Computing
Conference EDOC 2007, pp. 142-142, 2007.
71
[11] M. Lankhorst, ―Enterprise architecture modelling—the issue of integration,‖
Advanced Engineering Informatics, vol. 18, no. 4, pp. 205-216, Oct. 2004.
[12] E. Niemi, ―Enterprise Architecture Stakeholders-A holistic view,‖ Information
Systems, 2007.
[13] T. J. Parr, ―Enforcing strict model-view separation in template engines,‖
Proceedings of the 13th conference on World Wide Web - WWW ’04, p. 224, 2004.
[14] C. Pena, ―An MDE approach to design enterprise architecture viewpoints,‖ and
Enterprise Computing (CEC), 2010, 2010.
[15] D. Quartel, W. Engelsman, H. Jonkers, and M. V. Sinderen, ―A Goal-Oriented
Requirements Modelling Language for Enterprise Architecture,‖ 2009 IEEE International
Enterprise Distributed Object Computing Conference, pp. 3-13, Sep. 2009.
[16] M. Riebisch and S. Wohlfarth, ―Introducing Impact Analysis for Architectural
Decisions,‖ 14th Annual IEEE International Conference and Workshops on the
Engineering of Computer-Based Systems (ECBS’07), pp. 381-392, Mar. 2007.
[17] J. R. Romero and A. Vallecillo, ―Requirements for ODP Enterprise Architecture
Tools,‖ in EDOC Conference Workshop, 2007. EDOC’07. Eleventh International IEEE,
2007, pp. 224–230.
[18] M. van Steenbergen, R. Foorthuis, N. Mushkudiani, W. Bruls, S. Brinkkemper, and
R. Bos, ―Achieving Enterprise Architecture Benefits: What Makes the Difference?,‖ 2011
IEEE 15th International Enterprise Distributed Object Computing Conference Workshops,
pp. 350-359, Aug. 2011.
[19] C. Wang, H. Li, Z. Gao, M. Yao, and Y. Yang, ―An automatic documentation
generator based on model-driven techniques,‖ in Computer Engineering and Technology
(ICCET), 2010 2nd International Conference on, 2010, vol. 4, pp. V4–175.
[20] B. R. Winter and R. Fischer, ―Essential Layers, Artifacts, and Dependencies of
Enterprise Architecture,‖ Architecture, vol. 3, no. May, pp. 1-12, 2007.
[21] H. Störrle, ―VMQL: A visual language for ad-hoc model querying,‖ Journal of Visual
Languages Computing, vol. 22, no. 1, pp. 3-29, 2011
72
[22] Casallas, John. ―Estructuración y manejo de Metainformación para soportar el
análisis en Arquitectura Empresarial‖, Tesis de maestría - Universidad de los Andes, 2011.
[23] Group, T, O., ―The Open Group Architecture Framework V. 9‖. 2009.
[24] ―Velocity Template Language‖ http://velocity.apache.org/, 2007.
[25] ―FreeMarker‖ http://freemarker.sourceforge.net/, 2011
[26] ―Agilian‖ http://www.visual-paradigm.com/product/ag/, 2011
[27] ―Enterprise Architect" http://www.sparxsystems.com/products/ea/, 2010.
[28] ―BizzDesign Architect‖ http://www.bizzdesign.com/, 2011
[29] ―Gendoc2‖ http://www.topcased.org/index.php?id_projet_pere=102, 2011
[30] ―Acceleo‖ http://www.acceleo.org/pages/home/en, 2010
[31] ―XPAND‖ http://www.eclipse.org/modeling/m2t/?project=xpand, 2011
[32] Universidad de los Andes, ―Laboratorio de arquitectura empresariales‖
http://sistemas.uniandes.edu.co/~lae/, 2011
[33] ―VizGraph‖ http://www.graphviz.org/, 2011
[34] ―XText‖ http://www.eclipse.org/Xtext/, 2011
[35] ―Eclipse Modeling Framework‖ http://www.eclipse.org/modeling/emf/, 2011
[36] ―JUNG‖ http://jung.sourceforge.net/, 2010
[37] ―Docx4j‖ http://www.docx4java.org/, 2011
[38] ―Office Open XML‖ http://www.microsoft.com/interop/openup/openxml/, 2011
[39] ―Apache POI‖ http://poi.apache.org/, 2011
[40] ―Eugenia‖ http://www.eclipse.org/gmt/epsilon/doc/eugenia/, 2011
.
73
Apéndice A – Gramática de EnArDocs
grammar co.edu.uniandes.enar.docs.EnArDocs with org.eclipse.xtext.common.Terminals import 'http://www.eclipse.org/emf/2002/Ecore' as ecore generate enArDocs "http://www.edu.co/uniandes/enar/docs/EnArDocs" Template: importModels+=ImportModel+ importFunctions+=ImportFunction* properties=TemplateProperties expressions+=ChapterContainerExp expressions+=Expression* ; TemplateProperties: {TemplateProperties} _kw=_TEMPLATE '{' (attributes+=AttributeExp ( ',' attributes+=AttributeExp )* )? '}' ; ImportModel: 'importModel' mUri=STRING 'as' alias=VariableName 'conformTo' mmUri=STRING ; ImportFunction: 'importFunction' uri=STRING 'as' alias=VariableName ; Expression: ContainerExp | DirectiveExp ; ContainerExp: ChapterContainerExp | SectionContainerExp | TableContainerExp | TableRowExp | TableDataExp | ListContainerExp | ListItemExp ; ChapterContainerExp: {ChapterContainerExp} _kw=_CHAPTER '{' (attributes+=ChapterAttribute ( ',' attributes+=ChapterAttribute )* )? '}' ; ChapterAttribute returns AttributeExp: IdAttribute | TitleAttribute ;
74
IdAttribute returns AttributeExp: name=ATT_ID ':' val=ConcatExpression ; TitleAttribute returns AttributeExp: name=ATT_TITLE ':' val=ConcatExpression ; SectionContainerExp: {SectionContainerExp} _kw=_SECTION '{' (attributes+=SectionAttribute ( ',' attributes+=SectionAttribute )* )? '}' ; SectionAttribute returns AttributeExp: IdAttribute | TitleAttribute | ParentAttribute ; ParentAttribute returns AttributeExp: name=ATT_PARENT ':' val=ConcatExpression ; TableContainerExp: {TableContainerExp} _kw=_TABLE '{' (attributes+=TableAttribute ( ',' attributes+=TableAttribute )* )? '}' ( rows+=TableRowExp | directives+=DirectiveControlExp )* end=EndTable ; TableAttribute returns AttributeExp: IdAttribute | TitleAttribute | ParentAttribute ; EndTable: {EndTable} _kw='/table' ; TableRowExp: {TableRowExp} _kw_start=_TR body+=TableCellExp* _kw_end='/tr' ; TableCellExp: TableDataExp | TableHeaderExp ; TableDataExp: {TableDataExp} _kw=_TD
75
contents+=Expression* end=EndTableData ; EndTableData: {EndTableData} _kw='/td' ; TableHeaderExp: {TableHeaderExp} _kw=_TH contents+=Expression* end=EndTableHeader ; EndTableHeader: {EndTableHeader} _kw='/th' ; ListContainerExp: {ListContainerExp} _kw_start=_LIST '{' ( attributes+=ListAttribute ( ',' attributes+=ListAttribute )* )? '}' ( items+=ListItemExp | directives+=DirectiveControlExp )* _kw_end='/list' ; ListAttribute returns AttributeExp: IdAttribute | TitleAttribute | ListTypeAttribute | ParentAttribute ; ListTypeAttribute returns AttributeExp: name=ATT_TYPE ':' val=ConcatExpression ; ListItemExp: {ListItemExp} _kw=_ITEM contents+=Expression* end=EndListItem ; EndListItem: {EndListItem} _kw='/item' ; DirectiveExp: DirectiveControlExp | TextDir | MinimizedTextDir | ImageDir | MatrixDir | CatalogDir | DiagramDir | ProcessExternalDir | IncludeDir ;
76
DirectiveControlExp: IfDir | ForEachDir ; IfDir: _kw=_IF '(' condition=EvalExpression ')' ':' ifBody+=Expression* elseIf+=ElseIfDir* else=ElseDir? end=EndIfDir ; EndIfDir: {EndIfDir} _kw='/if' ; ElseDir: {ElseDir} _kw=_ELSE ':' elseBody+=Expression* ; ElseIfDir: _kw=_ELSEIF '(' condition=EvalExpression ')' ':' elseIfBody+=Expression* ; EvalExpression returns OperableExpression: RelationalExpression ( {EvalExpression.left=current} operator+=LogicalOperator right=RelationalExpression )* ; RelationalExpression returns OperableExpression: UnaryOperatorExpression ( {RelationalExpression.left=current} operator+=RelationalOperator right=UnaryOperatorExpression )* ; UnaryOperatorExpression: ( unaryOperator=UnaryOperator )? expression=SimpleExpression ; SimpleExpression: LiteralExpression | CallExp | '(' EvalExpression ')' ; LiteralExpression: AttributeVal ; CallExp: FunctionCall | VariableCall ; FunctionCall: member=VariableName '.' functionName=ID '(' ( params+=Parameter ( ',' params+=Parameter )* )? ')'
77
( '.' nextFunctionCall=NextFunctionCall )? ; NextFunctionCall returns FunctionCall: ( member=VariableName '.' )? functionName=ID '(' ( params+=Parameter ( ',' params+=Parameter )* )? ')' ( '.' nextFunctionCall=NextFunctionCall )? ; Parameter: LiteralExpression | CallExp ; VariableCall: variable=VariableName ( '.' att=(ID|Keyword) )? ; ForEachDir: _kw=_FOREACH base=CallExp 'as' iterator=VariableName ':' body+=Expression* end=EndForEachDir ; EndForEachDir: {EndForEachDir} _kw='/forEach' ; ImageDir: {ImageDir} _kw=_IMAGE '{' ( attributes+=ImageAttribute ( ',' attributes+=ImageAttribute )* )? '}' ; ImageAttribute returns AttributeExp: IdAttribute | TitleAttribute | URIAttribute | ParentAttribute | WidthAttribute | HeightAttribute ; URIAttribute returns AttributeExp: name=ATT_URI ':' val=ConcatExpression ; WidthAttribute returns AttributeExp: name=ATT_WIDTH ':' val=IntVal ; HeightAttribute returns AttributeExp: name=ATT_HEIGHT ':' val=IntVal ; ProcessExternalDir: _kw=_PROCESSEXTERNAL uri=STRING
78
( '(' ( params+=AttributeExp ( ',' params+=AttributeExp )* )? ')' )? ; IncludeDir: _kw=_INCLUDE uri=STRING ( '(' ( params+=AttributeExp ( ',' params+=AttributeExp )* )? ')' )? ; AttributeExp: name=(ID|Keyword) ':' val=EvalExpression ; TextDir: {TextDir} _kw=_TEXT '{' ( attributes+=TextAttribute ( ',' attributes+=TextAttribute )* )? '}' ; MinimizedTextDir: {MinimizedTextDir} _kw=_T '{' contents=ConcatExpression '}' ; TextAttribute returns AttributeExp: IdAttribute | ContentsAttribute | ParentAttribute | IsExternalAttribute | DescriptionAttribute | URIAttribute ; ContentsAttribute returns AttributeExp: name=ATT_CONTENTS ':' val=ConcatExpression ; IsExternalAttribute returns AttributeExp: name=ATT_EXTERNAL ':' val=BoolVal ; DescriptionAttribute returns AttributeExp: name=ATT_DESCRIPTION ':' val=ConcatExpression ; MatrixDir: {MatrixDir} _kw=_MATRIX '{' ( attributes+=MatrixAttribute ( ',' attributes+=MatrixAttribute )* )? '}' ;
79
MatrixAttribute returns AttributeExp: IdAttribute | TitleAttribute | ParentAttribute | FunctionAttribute ; FunctionAttribute returns AttributeExp: name=ATT_FUNCTION ':' val=FunctionCall ; CatalogDir: {CatalogDir} _kw=_CATALOG '{' ( attributes+=CatalogAttribute ( ',' attributes+=CatalogAttribute )* )? '}' ; CatalogAttribute returns AttributeExp: IdAttribute | TitleAttribute | ParentAttribute | FunctionAttribute ; DiagramDir: {DiagramDir} _kw=_DIAGRAM '{' ( attributes+=DiagramAttribute ( ',' attributes+=DiagramAttribute )* )? '}' ; DiagramAttribute returns AttributeExp: IdAttribute | TitleAttribute | ParentAttribute | URIAttribute ; ConcatExpression: operand+=StringExpression ( PLUS_OPERATOR operand+=StringExpression )* ; StringExpression: StringVal | CallExp ; AttributeVal: StringVal | IntVal | BoolVal | DblVal ; StringVal: val=STRING ; IntVal: val=INT ; BoolVal: val=BOOLEAN ;
80
DblVal: val=DOUBLE ; VariableName: VARIABLE_PREFIX name=(ID|Keyword) ; Keyword: ATT_ID | ATT_TITLE | ATT_PARENT | ATT_TYPE | ATT_URI | ATT_CONTENTS | ATT_DESCRIPTION | ATT_EXTERNAL | ATT_WIDTH | ATT_HEIGHT | ATT_FUNCTION | _TEMPLATE | _CHAPTER | _SECTION | _TABLE | _TR | _TD | _TH | _LIST | _ITEM | _TEXT | _T | _IF | _ELSE | _ELSEIF | _FOREACH | _IMAGE | _PROCESSEXTERNAL | _INCLUDE | _MATRIX | _CATALOG | _DIAGRAM ; LogicalOperator: OR_OPERATOR | AND_OPERATOR ; RelationalOperator: GT_OPERATOR | GE_OPERATOR | EQ_OPERATOR | LE_OPERATOR | LT_OPERATOR | NE_OPERATOR ; UnaryOperator: NOT_OPERATOR | MINUS_OPERATOR ; //variable prefix terminal VARIABLE_PREFIX: '$'; //operators terminal GT_OPERATOR: '>'; terminal GE_OPERATOR: '>='; terminal EQ_OPERATOR: '=='; terminal LE_OPERATOR: '<'; terminal LT_OPERATOR: '<='; terminal NE_OPERATOR: '!='; terminal NOT_OPERATOR: '!'; terminal AND_OPERATOR: '&&'; terminal OR_OPERATOR: '||'; terminal PLUS_OPERATOR: '+'; terminal MINUS_OPERATOR: '-';
81
//data types terminal BOOLEAN: 'true' | 'false'; terminal DOUBLE returns ecore::EDouble: ('0'..'9')+ '.' ('0'..'9')+; //keywords terminal ATT_ID: 'id'; terminal ATT_TITLE: 'title'; terminal ATT_PARENT: 'parent'; terminal ATT_TYPE: 'type'; terminal ATT_URI: 'uri'; terminal ATT_CONTENTS: 'contents'; terminal ATT_EXTERNAL: 'external'; terminal ATT_DESCRIPTION: 'description'; terminal ATT_WIDTH: 'width'; terminal ATT_HEIGHT: 'height'; terminal ATT_FUNCTION: 'function'; terminal _TEMPLATE : 'template'; terminal _CHAPTER : 'chapter'; terminal _SECTION : 'section'; terminal _TEXT : 'text'; terminal _T : 't'; terminal _TABLE : 'table'; terminal _TR : 'tr'; terminal _TD : 'td'; terminal _TH : 'th'; terminal _LIST : 'list'; terminal _ITEM : 'item'; terminal _IF : 'if'; terminal _ELSE : 'else'; terminal _ELSEIF : 'elseif'; terminal _FOREACH : 'forEach'; terminal _IMAGE : 'image'; terminal _PROCESSEXTERNAL : 'processExternal'; terminal _INCLUDE : 'include'; terminal _MATRIX : 'matrix'; terminal _CATALOG : 'catalog'; terminal _DIAGRAM : 'diagram';
82
Apéndice B – Ejemplo de plantilla en EnArDocs
importModel "D:/model/archisurance.archimatemm" as $model conformTo "D:/model/archimatemm.ecore" importFunction "D:/functions/core.jar" as $f importFunction "D:/functions/artifacts.jar" as $fa importFunction "D:/functions/mdla.jar" as $fmdla importFunction "D:/functions/archimate.jar" as $farch template { name: "Archisurance Artifacts" } chapter { title: "Archisurance"} diagram { uri: "D:/model/archisurance.archimatemm_diagram" } chapter { title: "Business Architecture" } section { title: "Business Process vs Application Components" } matrix { function : $fa.customMatrix( $model, $f.filterByElementType($model, "BusinessProcess"), $f.filterByElementType($model, "ApplicationComponent"), $fmdla.BPxAppCheckFunction(), “X”) } section { title: "Business Actors vs Roles" } matrix { function : $fa.simpleMatrix( $model, "BusinessActor", "BusinessRole", "performs") } section { title: "Business Actors Catalog" } catalog { function : $fa.simpleCatalog( $model, "BusinessActor", "name", "description") }
83
Apéndice C – Listado de funciones de EnArAnalyse
1. filterByElementType (model, elementType1, elementType2, …) :
Collection<Element>
Recibe el modelo y el nombre de los tipos de elementos a filtrar. Retorna una
colección de Element.
2. filterByElementAttributes (model, AttOperator1, AttOperator2, …) :
Collection<Element>
Recibe el modelo y una serie de operadores que se evaluaran sobre los atributos
de cada elemento para realizar el filtro. Retorna los Element que han evaluado a
verdadero para cada operador. A continuación se presentan los operadores
implementados:
3. attEq (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea igual al valor attVal.
4. attGEt (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea mayor o igual al valor attVal.
5. attGt (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea mayor que el valor attVal.
6. attLEt (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea menor o igual al valor attVal.
7. attLt (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea menor que el valor attVal.
8. attNEq (Element, ―attName‖, attVal) : boolean
Evalúa que el atributo attName del Element sea diferente al valor attVal.
9. filterByElementName (model, elementName1, elementName2, …) :
Collection<Element>
Recibe el modelo y el nombre de los elementos a filtrar. Retorna una colección de
Element.
10. filterRelatedElements (Element, relationName) : Collection<Element>
Retorna los elementos relacionados al Element a través de la relación con el
nombre de relationName. Retorna una colección de Element.
11. extractAttributesOfElementType (Element, type, asList(―attName1‖, ―attName2‖,
…) ) : Map<String, Object>
Evalúa si el Element pertenece al tipo type y extrae los atributos listados. Retorna
un mapa con los valores de cada atributo filtrado asociado con su nombre.
84
12. asList (val1, val2, …) : List<Object>
Retorna una lista con los elementos que se pasan como parámetro.
13. firstOf (Collection) : Object
Retorna el primero de los elementos que se encuentre dentro de la colección.
14. lastOf (Collection) : Object
Retorna el últimos de los elementos que se encuentre dentro de la colección.
15. sizeOf (Collection) : Integer
Retorna el tamaño de la colección.
16. sortByProperty (Collection<Element>, propertyName) : List<Element>
Ordena la colección de elementos por la propiedad especificada y retorna una lista
con los elementos ordenados.
17. exactShortestPathBetween (Element1, Element2, pathSize) : boolean
Evalúa si el camino más corto entre los dos elementos es igual al tamaño
especificado. Retorna verdadero en este caso.
18. typePatternBetween (Element1, Element2, typePattern) : boolean
Evalúa si el camino entre los dos elementos corresponde al patrón especificado.
Este patrón puede ser una lista que contenga cada uno de los operadores de
camino. Los operadores son: “?” para 0 o 1 ocurrencias de un tipo de elemento, “*”
para 0 o más ocurrencias, y “[#]” para especificar el número exacto de ocurrencias.
Por ejemplo, un camino entre un proceso de negocio y una aplicación, que
contenga al menos un elemento de tipo interfaz de aplicación: asList(“*”,
“ApplicationInterface”, “*”).
19. simpleCatalog (model, ―elementType‖, ―attName1‖, ―attName2‖, …)
Explicado en el capítulo EnArAnalyse – Consultas y generación de artefactos.
20. customCatalog (model, fFilterElements(), fExtractAttributes())
Explicado en el capítulo EnArAnalyse – Consultas y generación de artefactos.
21. simpleMatrix (model, ―elementType1‖, ―elementType2‖, ―value‖)
Explicado en el capítulo EnArAnalyse – Consultas y generación de artefactos.
22. customMatrix (model, fCheckIntersection(), fValue(), showEmptyRowsCols)
Explicado en el capítulo EnArAnalyse – Consultas y generación de artefactos.
![[PARTNER LOGO] Mejorando la Productividad con la siguiente Generación de Movilidad Empresarial Nombre del Presentador Cargo](https://img.pdfslide.tips/doc/110x75/55320abe55034632578b4a0a/partner-logo-mejorando-la-productividad-con-la-siguiente-generacion-de-movilidad-empresarial-nombre-del-presentador-cargo.jpg){kind=logo}