Modelado Visual de Aplicaciones Lotus Notes Domino

CON ESTUDIOS RECONOCIDOS ANTE LA SECRETARÍA DE EDUCACIÓN PÚBLICA (SEP),
SEGÚN ACUERDO No. 2007337 DE FECHA 23 DE MARZO 2007
MODELADO VISUAL DE APLICACIONES DOMINO
TESIS
QUE PARA OBTENER EL GRADO DE:
MAESTRÍA EN TECNOLOGÍAS DE INFORMACIÓN
PRESENTA:
HIRIAM EDUARDO PÉREZ VIDAL
ASESOR: MATI GWENDOLYNE DELGADO GARCÍA DE LA CADENA
CUERNAVACA, MORELOS. DICIEMBRE DE 2009

Abstract
The following research presents: a Domain Specific Language Modeling (DSLM) for Lotus
Notes applications and a software tool that implements it.
This tool allows to design applications using the DSL for Lotus Notes Applications, and
create the application code.
Resúmen
El siguiente trabajo de investigación presenta: un lenguaje de modelado de dominio
específico para aplicaciones Lotus Notes (DSLM) y una herramienta de software que lo
implementa.
Esta herramienta permitirá a partir de un determinado modelo generar el código de la
aplicación correspondiente.

Tesis: Modelado Visual de Aplicaciones Domino
Índices
i

Contenido
Introducción ........................................................................................................................ 1
Antecedentes ..................................................................................................................... 3
Planteamiento del problema .............................................................................................. 4
Objetivos de la tesis ........................................................................................................... 5
Objetivo general ............................................................................................................. 5
Objetivos específicos ..................................................................................................... 5
Justificación ....................................................................................................................... 5
Hipótesis ............................................................................................................................ 6
Beneficios esperados ........................................................................................................ 6
Alcance y limitaciones ....................................................................................................... 7
Metodología ....................................................................................................................... 7
Estructura de la tesis ......................................................................................................... 9
Estado del arte ................................................................................................................. 11
1. Capítulo: Diseño de software ................................................................................... 13
1.1. Introducción .......................................................................................................... 14
1.2. Diseño ................................................................................................................... 15
1.3. Lenguajes y modelado visual ................................................................................ 21
1.3.1. UML ............................................................................................................... 21
1.3.2. Lenguajes de dominio específico .................................................................. 23
1.3.3. Modelado de dominio específico ................................................................... 26
1.3.4. Perfiles de UML ............................................................................................. 27

Índices
ii
2. Capítulo: Herramientas de modelado ...................................................................... 31
2.1. MetaEdit+ .............................................................................................................. 32
2.2. Microsoft DSL Tools .............................................................................................. 34
2.3. Proyecto de modelado de Eclipse ........................................................................ 37
2.4. Elección de la herramienta ................................................................................... 39
3. Capítulo: Plataforma Lotus Notes / Domino ........................................................... 40
3.1. Breve historia ........................................................................................................ 41
3.2. Elementos de diseño ............................................................................................ 41
3.3. Funcionalidades y características ......................................................................... 42
3.4. Productos de la plataforma ................................................................................... 43
4. Capítulo: Lenguaje de modelado de dominio específico para Lotus Notes /
Domino .............................................................................................................................. 46
4.1. Introducción .......................................................................................................... 47
4.2. Proceso para definir el lenguaje ........................................................................... 47
4.2.1. Análisis de dominio ........................................................................................ 48
4.2.2. Metamodelo ................................................................................................... 54
4.2.3. DSL para aplicaciones Lotus Domino ............................................................ 55
4.2.4. Validación del DSL ........................................................................................ 56
5. Capítulo: Desarrollo de la herramienta ................................................................... 59
5.1. Componentes de la herramienta ........................................................................... 60
5.2. Requerimientos ..................................................................................................... 60
5.2.1. Alcances ........................................................................................................ 60
5.2.2. Objetivo general del sistema ......................................................................... 60
5.2.3. Funciones del producto ................................................................................. 60
5.2.4. Usuarios ......................................................................................................... 61

Índices
iii
5.2.5. Interfaces y relaciones de los sistemas ......................................................... 61
5.2.6. Características de usuarios ........................................................................... 61
5.2.7. Restricciones ................................................................................................. 61
5.2.8. Dependencias y supuestos ............................................................................ 61
5.2.9. Características del sistema ............................................................................ 61
5.2.10. Especificación de casos de uso ..................................................................... 62
5.3. Diseño de la arquitectura ...................................................................................... 65
5.3.1. Arquitectura general de la herramienta ......................................................... 65
5.3.2. Diseño de despliegue .................................................................................... 66
5.3.3. Diseño de interfaces ...................................................................................... 67
5.3.4. Diseño de los módulos .................................................................................. 69
5.3.5. Diseño de datos ............................................................................................. 80
5.3.6. Arquitectura propuesta para ingeniería inversa ............................................. 82
6. Capítulo: Uso de la herramienta .............................................................................. 84
6.1. Proceso de uso ..................................................................................................... 85
6.2. Uso del modelador ................................................................................................ 86
6.3. Uso del generador de código ................................................................................ 90
7. Capítulo: Pruebas ...................................................................................................... 92
7.1. Protocolo de pruebas ............................................................................................ 93
7.2. Interpretación de los resultados ............................................................................ 95
Conclusiones .................................................................................................................... 99
Conclusiones ................................................................................................................. 100
Beneficios ...................................................................................................................... 101
Recomendaciones .......................................................................................................... 103
Recomendaciones de mejora ........................................................................................ 104

Índices
iv
Trabajos futuros ............................................................................................................. 104
Áreas de oportunidad .................................................................................................... 104
Bibliografía ...................................................................................................................... 106
Referencias bibliográficas .............................................................................................. 107
Anexo............................................................................................................................... 110
Perfil UML para aplicaciones Lotus Notes ..................................................................... 111
Introducción ................................................................................................................ 111
Panorama general ...................................................................................................... 112
Perfiles UML ............................................................................................................... 115
Desarrollo del Perfil UML para Lotus Domino Designer ............................................ 118

Índices
v
Índice de figuras

Figura 1 Ejemplo de un diagrama de diseño no estandarizado ............................................ 3
Figura 2 Mapa conceptual del marco teórico ...................................................................... 15
Figura 3 El proceso unificado Rational: RUP( Rational Unified Process) (IBM, 2006) ....... 16
Figura 4 Flujo de trabajo de la etapa de análisis y diseño de RUP (IBM, 2006) ................. 18
Figura 5 Arquitectura Dirigida por Modelos ......................................................................... 19
Figura 6 Estructura de alto nivel de UML 2.1.1 (OMG, 2007b) ........................................... 23
Figura 7 Fases para el desarrollo de un DSL ...................................................................... 25
Figura 8 Función del DSL .................................................................................................... 27
Figura 9 Elementos definidos en el paquete perfil (OMG, 2007a) .................................... 28
Figura 10 Herramienta MetaEdit+ ....................................................................................... 33
Figura 11 Arquitectura de MetaEdit+ ................................................................................... 34
Figura 12 IDE de Microsoft VisualStudio con DSL Tool ...................................................... 35
Figura 13 Arquitectura DSL Tools ....................................................................................... 36
Figura 14 Proyectos de Visual Studio al crear un DSL ....................................................... 36
Figura 15 Analogía entre Eclipse EMF y GMF .................................................................... 38
Figura 16 Proceso de generación de un modelador con Eclipse GMF ............................... 38
Figura 17 Composición de una BDs Notes ......................................................................... 41
Figura 18 Elementos de diseño de Lotus Notes ................................................................. 42
Figura 19 Funciones y características de la plataforma Notes/Domino .............................. 43
Figura 20 Proceso para la obtención del DSL ..................................................................... 48
Figura 21 Distribución de elementos de diseño en las aplicaciones ................................... 52
Figura 22 Clasificación de elementos de diseño ................................................................. 53
Figura 23 Metamodelo de aplicaciones Lotus Domino ....................................................... 54
Figura 24 Clasificación de los estereotipos del perfil de UML para Lotus ........................... 55
Figura 25 Ejemplos de diagramas de diseño no estandarizados ........................................ 56
Figura 26 Ejemplo de diagrama simplificado para la validación del DSL ............................ 57
Figura 27 Ejemplo de diseño especificando las propiedades de los elementos ................. 58
Figura 28 Desarrollo de herramienta de modelado ............................................................. 60

Índices
vi
Figura 29 Casos de uso de herramienta de modelado ....................................................... 62
Figura 30 Arquitectura general del DSM ............................................................................. 65
Figura 31 Secuencia de ejecución del modelado a la generación ...................................... 66
Figura 32 Diagrama de despliegue de la herramienta ........................................................ 66
Figura 33 Interfaz gráfica del componente de modelado .................................................... 68
Figura 34 Interfaz gráfica del componente de generación de aplicaciones ........................ 69
Figura 35 Diseño del modelador ......................................................................................... 69
Figura 36 Proceso de creación de la herramienta gráfica basada en modelos .................. 71
Figura 37 Estructura del modelo de dominio dominoapp.ecore .......................................... 71
Figura 38 Documento XML del modelo de dominio ............................................................ 72
Figura 39 Vista gráfica del modelo de dominio ................................................................... 72
Figura 40 Estructura del modelo de generación ................................................................. 73
Figura 41 Modelo de definición gráfica ............................................................................... 74
Figura 42 Documento XML del modelo de definición gráfica .............................................. 74
Figura 43 Estructura del modelo de definición de herramientas o tooling .......................... 75
Figura 44 Documento XML del modelo de definición de herramientas ............................... 75
Figura 45 Estructura del modelo de definición de mapeo o mapping ................................. 76
Figura 46 Documento XML del modelo de definición de mapeo ......................................... 77
Figura 47 Estructura del modelo de generación GMF ........................................................ 77
Figura 48 Ejemplo de estructuras de diseños de aplicaciones ........................................... 78
Figura 49 Ejemplo de XML de un diagrama de diseño ....................................................... 79
Figura 50 Diseño del generador de aplicaciones ................................................................ 79
Figura 51 Arquitectura del generador de aplicaciones ........................................................ 80
Figura 52 Estructura de datos de la eclass database. Vista de clase ................................. 80
Figura 53 Estructura de la eclass database. Vista de árbol ................................................ 81
Figura 54 Estructura de la eclass database. Vista XML ...................................................... 81
Figura 55 Diseño propuesto para el extractor de diseño .................................................... 82
Figura 56 Arquitectura propuesta para el extractor de diseño ............................................ 82
Figura 57 Proceso de uso de la herramienta ...................................................................... 85
Figura 58 DSM - Herramienta de modelado ....................................................................... 86
Figura 59 Creación de un modelo de diseño de Lotus Notes/Domino ................................ 87

Índices
vii
Figura 60 Archivos de la estructura del modelo e interfaz gráfica ...................................... 87
Figura 61 Barra de herramientas de modelado ................................................................... 88
Figura 62 Ventana de propiedades de los elementos ......................................................... 89
Figura 63 Ejemplo de diagrama de diseño elaborado en el modelador .............................. 89
Figura 64 Estructura resultante del modelo ........................................................................ 90
Figura 65 DSM - Generador de aplicaciones ...................................................................... 91
Figura 66 Diseño de un formulario .................................................................................... 114
Figura 67 Diagrama de clase para un elemento form ....................................................... 115
Figura 68 Metamodelo de Lotus Domino Designer ........................................................... 119
Figura 69 Clasificación de los estereotipos de LDD .......................................................... 124
Figura 70 Metamodelo de Lotus ........................................................................................ 127
Figura 71 Extendiendo al metaelemento Class ................................................................. 128
Figura 72 Continuación de la extensión del metaelemento Class .................................... 129
Figura 79 Extendiendo al metaelemento Aggregation ...................................................... 136
Figura 80 Notación para la relación de contención ........................................................... 196
Figura 81 Notación para la relación de contención reflexiva ............................................. 197
Figura 82 Relación de agregación, esquema general ....................................................... 198
Figura 83 Relación de composición, esquema general .................................................... 199

Índices
viii
Índice de tablas

Tabla 1 Lista de productos de Lotus por categoría ............................................................. 45
Tabla 2 Descripción de elementos de diseño de Lotus ....................................................... 50
Tabla 3 Porcentaje de uso de elementos de diseño en aplicaciones Lotus ........................ 51
Tabla 4 Resultados de las pruebas ..................................................................................... 98
Tabla 5 Estereotipos definidos para Lotus Domino Designer ........................................... 123
Tabla 6 Definición de la propiedad multiplicidad ............................................................... 199
Tabla 7 Definición de la propiedad propagación de borrado ............................................. 199
Tabla 8 Definición de la propiedad reflexividad ................................................................. 200
Tabla 9 Valores fijos para la relaciones ............................................................................ 201

Introducción
1

Introducción
Introducción a este trabajo de tesis. Se
presentan los antecedentes al trabajo de
investigación, planteamiento del problema,
objetivos de la tesis, justificación del trabajo,
hipótesis, beneficios esperados, alcances y
limitaciones, metodología a utilizar y descripción
de la estructura de la tesis mediante un
resumen.

Introducción
2
El desarrollo de aplicaciones empresariales presenta complejidades como: integración de
diferentes plataformas tecnológicas, ambientes de desarrollo y procesos de ingeniería de
software.
El correcto modelado de dichas aplicaciones antes de su codificación, beneficia el
aseguramiento de la calidad del software, mejora la arquitectura, facilita el mantenimiento
y ayuda a la transferencia tecnológica al cliente.
Lenguajes de modelado genérico o de propósito general pueden emplearse para describir
una gran parte de las características de los sistemas. Este es el caso del Lenguaje
Unificado de Modelado: UML (Por sus siglas en inglés Unified Modeling Language).
Existen herramientas tanto libres como propietarias que permiten diseñar aplicaciones en
cada uno de los lenguajes de modelado existentes.
Es común que cada plataforma o tecnología presenten características propias que
requieren de una técnica o lenguaje de modelado en particular. Así para los sistemas de
bases de datos relacionales un modelo Entidad-Relación o un modelo de clases de UML
pueden ser suficientes.
Sin embargo en determinadas tecnologías o dominios tecnológicos un lenguaje de
modelado general puede ser insuficiente para describir todas las características deseadas.
Ante esta situación puede definirse un lenguaje de dominio específico, el cual provea de
los elementos que permitan describir con mayor precisión dichas características.
Lotus Domino es la plataforma líder en aplicaciones colaborativas. Presenta un ambiente
de desarrollo orientado a objetos y una base de datos documental.
El siguiente trabajo de investigación presenta: un lenguaje de modelado de dominio
específico para aplicaciones Lotus Notes y una herramienta de software que lo
implementa. Esta herramienta permitirá a partir de un determinado modelo generar el
código de la aplicación correspondiente.

Introducción
3
Antecedentes
Los equipos de desarrollo en aplicaciones Lotus Notes carecen de un lenguaje de
modelado adecuado a la naturaleza de esta tecnología.
Algunos equipos han implementado procesos de desarrollo software a la medida. Estos
procesos difícilmente pueden apoyarse por herramientas comerciales por lo que es común
contar con herramientas desarrolladas por los mismos equipos. Sin embargo, la etapa de
diseño requiere ser mejorada con el propósito de definir arquitecturas críticas que son
enviadas a los desarrolladores para su posterior codificación.
Se han utilizado distintos lenguajes de modelado para diseñar las aplicaciones. Entre
estos lenguajes destaca el uso del UML. Sin embargo no se ha encontrado un lenguaje de
modelado que permita definir con mayor precisión las características propias de una
aplicación de este dominio tecnológico.

Figura 1 Ejemplo de un diagrama de diseño no estandarizado
Ante esta necesidad en colaboración con el Centro Nacional de Investigación y Desarrollo
Tecnológico (CENIDET), bajo la tesis “Definición de un Lenguaje de Dominio Específico
para un entorno de desarrollo rápido de aplicaciones” presentada por Guillermo Rivera

Introducción
4
(Rivera, 2008), se realizó el trabajo de investigación para la definición de un Lenguaje de
dominio apropiado para Lotus Notes.
Lotus Notes es una tecnología que difiere de la programación orientada a objetos y del
modelo tradicional de bases de datos relacionales. Esta tecnología proporciona un
ambiente de desarrollo rápido de aplicaciones llamado Lotus Domino Designer. Lotus
Notes integra en una solo base de datos:
• Elementos de programación o lógica de negocios
• Interfaz del usuario
• Datos
• Seguridad
Planteamiento del problema
Existen una gran cantidad de aplicaciones colaborativas y portales desarrollados e
instalados en la plataforma Lotus Notes / Domino. Muchas de estas aplicaciones carecen
de un modelado formal o completo por la ausencia de técnicas específicas para esta
tecnología.
Estos problemas de diseño provocan:
• Dificultad en el mantenimiento de las aplicaciones
• Defectos en el software que pueden evitarse al detectarse durante el modelado
• Duplicidad de esfuerzos al no poder reutilizarse soluciones para requerimientos
similares
Como consecuencia de todo lo anterior, podemos decir que el problema en la etapa de
diseño de las aplicaciones Lotus Notes se basa en la ausencia de un lenguaje de
modelado específico para esta plataforma y una herramienta de diseño que lo implemente.

Introducción
5
Objetivos de la tesis
Objetivo general
Analizar, diseñar, e implementar una herramienta de modelado visual, que permita diseñar
aplicaciones Lotus Notes / Domino y generar el código de la aplicación correspondiente
utilizando un lenguaje de modelado de dominio específico.
Objetivos específicos
• Revisar las herramientas para generación de código a través del modelado visual
• Definir un lenguaje de modelado de dominio específico que permite modelar
aplicaciones Lotus Domino basado en la especificación de Perfiles de UML
• Desarrollar una herramienta de software que permita generar diagramas de
aplicaciones utilizando el lenguaje de dominio específico definido previamente
• Desarrollar una herramienta que permita, dado un diagrama de aplicación, generar
el código correspondiente de la aplicación.
Justificación
Actualmente no existe una herramienta de modelado específico para esta tecnología o
dominio por lo que esta investigación será innovadora en este terreno.
El producto de esta tesis puede ser utilizada en el diseño de aplicaciones Lotus Notes. Así
mismo, mejorando la calidad de las aplicaciones al detectar errores desde la etapa de
diseño y evitando detectarlos hasta la etapa de comercialización e implementación de
productos donde los costos para reparar dichos errores es muy alto.
Dado que no se cuenta con un lenguaje de modelado y herramienta que permita definir
con mayor precisión las características propias de una aplicación Lotus Notes y para
resolver el problema planteado se propone obtener:
1. Un Lenguaje de Modelado de Dominio Específico
2. Una herramienta de modelado visual que implemente el lenguaje de modelado
3. Una herramienta que permita la generación automática de los elementos de
diseño que componen la aplicación modelada

Introducción
6
El lenguaje obtenido modelará con mayor precisión las aplicaciones Lotus Notes. Esta
herramienta permitirá a partir de un determinado modelo generar el código de la aplicación
correspondiente.
Hipótesis
Ante las necesidades de modelar con mayor precisión las aplicaciones Lotus Notes, dando
mayor semántica a los diagramas de diseño y la generación de la estructura de la
aplicación a partir de dichos diseños se plantea la siguiente hipótesis:
Contar con una herramienta de modelado de dominio específico permitirá facilitar el
modelado de las aplicaciones Lotus Notes y disminuir el tiempo de desarrollo.
En esta hipótesis se mencionan las variables de:
• Facilidad de modelado
• Disminución de tiempo de desarrollo
Beneficios esperados
Con el trabajo de esta tesis se esperan alcanzar los beneficios de:
• Mayor precisión en la generación de diagramas de diseño de las aplicaciones
• Diseños uniformes al contar con un lenguaje visual único en los equipos de
desarrollo
• Reducción en el tiempo de modelado. Los desarrolladores toman objetos visuales
conocidos y evitan tener que aprender lenguajes y reglas distintas a su entorno.
• Congruencia entre los diagramas de diseño y las aplicaciones generadas.

Introducción
7
Alcance y limitaciones
El trabajo de esta tesis tiene como alcances: la definición de un DSL que permite diseñar
aplicaciones Lotus Domino, el desarrollo de una herramienta visual que lo implementa y la
generación automática de la aplicación modelada.
La funcionalidad de generación automática de aplicaciones crea los elementos de diseño
principales modelados pero la codificación detallada queda en manos del programador
para la etapa de codificación en un proceso de ingeniería de software.
La herramienta no implementa la funcionalidad de ingeniería inversa pero se propone la
arquitectura para implementarla.
Metodología
Este trabajo de tesis se basa en un proyecto de tipo investigación y desarrollo (I+D). Por
esta razón tiene dos componentes principales:
• La investigación de técnicas, herramientas, y soluciones para la definición de una
herramienta de modelado visual. Como resultado de la etapa de investigación y con
el conocimiento generado se definirá un lenguaje de modelado mediante un
estándar formal de especificación de lenguajes.
• El desarrollo de una herramienta de software que implemente el resultado de la
investigación siguiendo un proceso formal de desarrollo de software. Con esta
herramienta se implementa el resultado de la investigación en un producto tangible
Para la etapa de investigación de utilizan los mecanismos de:
• Análisis y síntesis en la determinación del lenguaje de modelo de dominio
específico
• Encuesta y prueba para evaluar el resultado de la herramienta de software
desarrollada y comprobar las variables planteadas en la hipótesis.
Las pruebas y la validación del DSL se realizan con el apoyo de expertos en el desarrollo
de aplicaciones de la plataforma Lotus Notes

Introducción
8
La metodología seguida para el desarrollo del siguiente trabajo se divide en las siguientes
fases:
FASE 1. Investigación del estado del arte. Estudio del estado del arte en la definición de
lenguajes de dominio específico.
FASE 2. Definición del DSL para modelado de aplicaciones Lotus Notes. Definición
del lenguaje de modelado a utilizar.
FASE 3. Estudio de herramientas para la generación de DSL. Se estudian los
alcances, ventajas y desventajas de las herramientas que implementan DSL y generan
código automáticamente.
FASE 4. Definición del modelo para generación de código a partir del DSL. Definición
del modelo a utilizar para la generación de código automático a partir del DSL descrito
FASE 5. Validación del DSL para modelado de aplicaciones Lotus Notes. Validar los
diagramas obtenidos a partir del uso del DSL de manera tal que representen
correctamente el diseño de la aplicación Lotus Notes
FASE 6. Desarrollo de la herramienta de modelado y generación automática de
código. Se implementa la herramienta de modelado para elaborar diseños de aplicaciones
utilizando el DSL para aplicaciones Lotus Notes y a partir del diseño generar
automáticamente el código de los elementos de diseño representados.
Esta actividad sigue un proceso formal de desarrollo de software, el cual se compone de:
i. Requerimientos
ii. Diseño (arquitectura, detallado, interfaces, datos)
iii. Codificación
iv. Pruebas
FASE 7. Validación de la herramienta desarrollada. Validar la herramienta contra
aplicaciones reales desarrolladas

Introducción
9
FASE 8. Elaboración de la tesis. Se reúne la información generada para generar el
documento de tesis y seguir el proceso de revisión y aceptación del trabajo
Estructura de la tesis
A continuación se presenta un breve resumen de cada uno de los capítulos que se
presentan en esta tesis:
En los Antecedentes, se exponen la problemática que da origen a este trabajo haciendo
énfasis en la carencia de un lenguaje de modelado específico para las aplicaciones Lotus
Notes y por ello las deficiencias en la etapa de diseño Antecedentes. Se presenta el
estado del arte en la definición de lenguajes de modelado y las herramientas más
importantes. Para finalizar se presentan: preguntas de investigación, los objetivos de esta
tesis, justificación, hipótesis, beneficios esperados, alcance y limitaciones y la metodología
empleada en el desarrollo de este trabajo
En el Diseño de software, se describe esta etapa como parte de un proceso formal de
desarrollo de software. La actividad de diseño está ligada a enfoques como la Arquitectura
Dirigida por Modelos la cual implementa herramientas de modelado y regeneración
automática de código. En el diseño de aplicaciones se pueden utilizar dos tipos de
lenguajes de modelado: de propósito general y de dominio específico. El UML es el
lenguaje de modelado de propósito general más utilizado por lo que se describe su
composición. Para finalizar se presentan a los las características y el proceso para la
obtención de un lenguaje de modelado de dominio específico, los perfiles de UML como
un método para representarlos y el proceso a seguir para definir un DSL
En las Herramientas de modelado se presentan las características de las tres
herramientas más utilizadas en la actualidad: MetaEdit+, Microsoft DSL Tools y el
Proyecto de modelado de Eclipse. Adicionalmente se presentan los motivos de la elección
de Eclipse como la herramienta base a utilizar en este trabajo.
En el capítulo de la Plataforma Lotus Domino, se presentan las características de esta
plataforma colaborativa empresarial. Se describen sus, elementos de diseño,

Introducción
10
funcionalidades, características y productos comerciales de la plataforma con el objeto de
entender su complejidad, capacidad y alcance.
En el capítulo de Lenguaje de Modelado de Dominio Específico para Lotus
Notes, se presenta el lenguaje de modelado de dominio específico a utilizar para el
diseño de aplicaciones. Para la definición de este lenguaje se realizó el análisis de
dominio, la definición del Metamodelo, la especificación del DSL mediante un perfil de
UML y la validación de dicho DSL mediante la elaboración de diagramas de diseño de
aplicaciones Lotus Notes ya existentes.
En el Desarrollo de la herramienta, se presentan el proceso utilizado para la
implementación del lenguaje dentro de una herramienta de modelado y generación
automática de código. Para la elaboración de la herramienta se utilizó un proceso formal
de desarrollo de software por lo que se presentan de manera detallada los requerimientos
y el diseño de la arquitectura. Aunque no es parte de este trabajo la incorporación de
técnicas de ingeniería inversa, se presenta la arquitectura para su implementación en
trabajos futuros.
Uso de la herramienta describe el funcionamiento y uso del modelador desarrollado
para la elaboración de diagramas de diseño basados en el DSL. De la misma manera se
presenta el uso del generador de código para la generación automática de los elementos
de diseño Lotus Notes descritos en el diagrama.
En Pruebas, se presenta el protocolo de pruebas realizado para la evaluación de la
herramienta desarrollada, los resultados de la evaluación y su interpretación.
En conclusiones se presentan las conclusiones resultado del desarrollo de este trabajo,
los beneficios obtenidos, los trabajos futuros, áreas de oportunidad para la reutilización de
la experiencia obtenida durante la realización de este trabajo.
Se presentan las recomendaciones a seguir para mejorar el presente trabajo en un
futuro, los trabajos futuros y áreas de oportunidad.

Introducción
11
El anexo final contiene la especificación del Lenguaje de Modelo de Dominio Específico
para aplicaciones Lotus Notes mediante un perfil de UML
Estado del arte
El modelado como parte fundamental del proceso del desarrollo de software, puede
realizarse a través de: lenguajes de modelado de propósito general o lenguajes de
modelado de dominio específico.
Los lenguajes de modelado de propósito general, tienen como finalidad representar de
manera genérica las facetas de un sistema. Estos lenguajes están más enfocados en la
descripción que en la generación de código, además tienen como problema principal que
los elementos de un diagrama pueden tener diferentes interpretaciones si son utilizados en
diferentes contextos o dominios tecnológicos. El mejor exponente de los lenguajes de
modelado de propósito general es el UML (por sus siglas en inglés: Unified Modeling
Language). (Steven & Pooley, 2007), (OMG, 2007b)
Este tipo de lenguajes no han sido suficientes para modelar muchos de los dominios
donde se desean implementar. Por esta razón muchas empresas se han visto en la
necesidad de generar sus propios lenguajes de modelado.
Los lenguajes de modelado de dominio específico: DSL (por sus siglas en inglés: Domain
Specific Language), tienen como objeto describir con mayor precisión las características
propias de un dominio tecnológico. Estos lenguajes en la mayoría de los casos están
asociados a la generación automática de código. La especificación de un DSL está
asociada a un metamodelo o modelo de dominio. Existen varias opciones para la
descripción de un lenguaje de modelado de domino específico(Kelly & Tolvanen, 2008),
entre ellas la más usada son los perfiles de UML(Fuentes & Vallecillo, 2004).
Para facilitar el uso de un lenguaje de modelado de dominio específico, este debe
implementarse a través de una herramienta de software. Existen dos caminos para su
implementación:
1. Crear una herramienta de software a la medida o

Introducción
12
2. utilizar herramientas de terceros especializadas en la implementación de un
DSL. (Kelly, 2004) , (Ehrig, Ermel, Hänsgen, & Taentzer, 2005), (Leroux,
Nally, & Hussey, 2006)
Las tres herramientas actuales más utilizadas para la implementación de un DSL son:
MetaEdit+, Eclipse y Microsoft DSL Tools.

Diseño de software
13

1. Capítulo: Diseño de software
En esta sección se describen los conceptos
claves del diseño de software que sustentan el
desarrollo del trabajo de investigación. Se
presenta la etapa de diseño dentro de un
proceso formal de desarrollo de software, los
lenguajes de modelado visual, el UML como
lenguaje de modelado de propósito general, los
lenguajes de dominio específico y los perfiles de
UML para su especificación

Diseño de software
14
1.1. Introducción
El diseño de software traduce los requerimientos en modelos que serán la base de la
etapa posterior de codificación de la aplicación.
En esta etapa de diseño existen distintos enfoques sobre el uso de los modelos. En los
últimos años el enfoque de la Arquitectura Dirigida por Modelos: MDA (Por sus siglas en
inglés: Model Driven Architecture), ha hecho énfasis en la importancia de obtener en
primer lugar dichos modelos y a partir de estos, obtener de manera automática el código
de la aplicación.
Los modelos mencionados pueden elaborarse utilizando lenguajes de propósito general o
lenguajes de dominio específico: DSL (por sus siglas en inglés: Domain Specific
Language).
La elaboración de un DSL, es una tarea de profundo análisis del dominio que se desea
modelar obteniendo al final una especificación de un lenguaje textual o visual.
Existen dos opciones principales para la definición de un DSL: La extensión de un
lenguaje de propósito general como el UML o la definición completa de uno nuevo
utilizando algún estándar abierto o de facto.
Para facilitar el uso de un DSL, estos lenguajes suelen implementarse en herramientas de
modelado visual que permiten: Elaborar modelos basados en el DSL y generar
automáticamente el código de la aplicación equivalente. Algunas herramientas modernas
permiten realizar ingeniería inversa. La ingeniería inversa es el proceso de convertir
código fuente de aplicaciones en elementos de un modelo.
Cuando se han obtenido las partes antes descritas se cuenta con una herramienta de
Modelado de Dominio Específico: DSM (por sus siglas en inglés: Domain Specific
Modeling) bajo el enfoque MDA.

Diseño de software
15

Figura 2 Mapa conceptual del marco teórico

1.2. Diseño
El diseño de software es una actividad multidisciplinaria que proporciona soluciones a
través de la comunicación efectiva de ideas y el uso de prácticas de ingeniería. El
propósito del diseño es simplemente producir una solución a un problema.(Budgen, 2003)

Diseño de software
16

Figura 3 El proceso unificado Rational: RUP( Rational Unified Process) (IBM, 2006)
La etapa de diseño es una parte fundamental de todos los procesos de desarrollo de
software más importantes, ya que su propósito es describir el cómo los requerimientos
serán convertidos en productos usando la solución más apropiada.
Dada la profundidad del diseño puede considerarse como:
• Alto nivel, cuando se enfoca más a aspectos de arquitectura. Ejemplo: diagramas
de componentes, modelado de negocios
• Detallado, cuando describe con mayor precisión la implementación. Ejemplos:
diagramas de clases
Para Pressman (Pressman, 2000), esta actividad es un proceso que está enfocado
principalmente en cuatro aspectos o atributos: estructura de datos, arquitectura de
software, representaciones de interfaces y detalles de procedimientos o módulos. El
proceso de diseñar traduce los requerimientos en una representación del software que
permite evaluar su calidad antes de iniciar la etapa de codificación.

Diseño de software
17
Muchos procesos de desarrollo de software implementan la etapa de diseño como una
actividad fundamental. Uno de los procesos de desarrollo más conocidos es el Proceso
Unificado de Rational.
Para RUP, la etapa de diseño es actividad extensa y se encuentra integrada a la etapa de
análisis. El propósito de esta etapa es:(IBM, 2006)
• Transformar los requerimientos en el diseño de lo que el sistema debe hacer
• Desarrollar una arquitectura robusta para el sistema
• Adaptar el diseño para integrarlo al ambiente de implementación considerando su
desempeño
Para RUP las tareas a realizar durante el análisis y diseño son:
• Análisis de la Arquitectura
• Evaluación de la viabilidad de pruebas de concepto de la arquitectura
• Diseño de cápsulas
• Diseño de clases
• Pruebas de concepto de construcción de la arquitectura
• Diseño de la base de datos
• Definir contexto del sistema
• Descripción de la distribución
• Descripción de la arquitectura de ejecución
• Diseño de elementos de prueba
• Diseño de interfaces de usuario
• Identificación de elementos de diseño
• Identificación de mecanismos de diseño
• Identificación de servicios
• Incorporación de elementos de diseño existentes
• Análisis de operaciones
• Diseño de operaciones

Diseño de software
18
• Prototipos de interface de usuarios
• Revisión de la arquitectura
• Revisión de el diseño
• Diseño de servicios
• Especificación de migración de datos
• Diseño de subsistemas
• Análisis y diseño de casos de uso

Figura 4 Flujo de trabajo de la etapa de análisis y diseño de RUP (IBM, 2006)
El resultado de la etapa de diseño es la obtención de modelos. Estos modelos pueden ser
descritos utilizando lenguajes de modelado de propósito general como el UML o lenguajes
de modelado de dominio específico.

Diseño de software
19
Un modelo es la representación simplificada de la realidad, que generalmente utiliza
símbolos para significar a los elementos reales, y por medio de un proceso de abstracción,
distinguir las partes esenciales de una situación ignorando las prescindibles, con el objeto
de entender con mayor claridad cómo funciona, descubrir relaciones, reflexionar de una
manera sencilla acerca de su operación y en general disminuir el grado de complejidad.
(Parra, 2000)
La tarea de diseñar puede estar guiada por diferentes enfoques o técnicas como la
Arquitectura Dirigida por Modelos: MDA (por sus siglas en inglés: Model Driven
Architecture).
MDA busca alinear el diseño contra las aplicaciones resultantes en distintos dominios. Los
modelos diseñados bajo este enfoque pueden ser elaborados con lenguajes de propósito
general como el UML o lenguajes de dominio específico.

Figura 5 Arquitectura Dirigida por Modelos
El MDA tiene como promesa permitir la definición de modelos de datos y aplicaciones
entendibles por la máquina los cuales permiten mantener durante largo tiempo la
flexibilidad de: (Mukerji & Miller, 2003)

Diseño de software
20
• Implementación. Una nueva infraestructura de implementación puede ser integrada
o integrada por diseños existentes
• Integración: Se puede automatizar la integración de datos a nuevas
infraestructuras.
• Mantenimiento: La disponibilidad de diseños entendibles por la máquina da a los
desarrolladores acceso directo a la especificación del sistema haciendo su
mantenimiento mucho más simple
• Pruebas y simulación. Los modelos desarrollados pueden ser usados para generar
código, lo que equivale a validarlos contra los requerimientos, probar varias
infraestructuras y usarlos directamente para simular el comportamiento de un
sistema que está siendo diseñado
Un DSM está fuertemente ligado al enfoque MDA ya que a través de los modelos
diseñados, es posible generar código de aplicación, cumpliendo así lo que este enfoque
propone.
Los modelos generados utilizando un DSM realizan los siguientes cambios o mejores en el
proceso de diseño: (Kelly & Tolvanen, 2008)
• El control de versiones de una aplicación puede llevarse desde los modelos y no
exclusivamente desde el código
• Disminución del tiempo de pruebas de la aplicación anticipándola desde la etapa de
diseño
• La actividad de depuración puede realizarse desde el diseño
• Mejoran la comunicación ya que expresan los conceptos importantes del dominio
sin separarla de la implementación
• Se convierten en elementos de entrada para diferentes artefactos, pudiendo
utilizarse estos modelos para obtener por ejemplo: documentación, casos de
prueba y configuración de los datos
En equipos de desarrollo pequeños no siempre existe una figura de arquitecto de software
o diseñador cuya función sea la de generar los modelos de diseño de las aplicaciones.

Diseño de software
21
Esta actividad es frecuentemente cubierta por los mismos desarrolladores o
programadores.

1.3. Lenguajes y modelado visual
Los lenguajes visuales permiten manipular elementos de programación gráficamente en
lugar de especificarlos textualmente. (Wikipedia, 2007b)
Pueden clasificarse de acuerdo al tipo de expresión visual utilizada en: lenguajes basados
en íconos, lenguajes basados en formularios y lenguajes de diagramas.
Los lenguajes visuales proporcionan elementos de íconos o gráficos que pueden ser
manipulados por los usuarios de manera interactiva de acuerdo a un conjunto de reglas
especificadas.
La definición de patrones de características puede ser la base de usabilidad entre los
patrones identificados por el usuario y aquellos que son administrados por el sistema. Un
lenguaje visual dinámico es un conjunto ordenado de sentencias visuales caracterizadas
por la presencia de elementos comunes(Bottoni, Chang, Costabile, Levialdi, & Mussio,
2002). Se pueden especificar las transformaciones posibles especificando formalmente
este proceso.
El modelado visual es el uso de semántica, notaciones de diseño textuales y gráficas para
describir diseños de software. Una notación como el UML, permite establecer un nivel de
abstracción, mientras se mantienen reglas de sintaxis y semántica. El modelado visual
proporciona un medio de comunicación entre el equipo de trabajo para la revisión del
diseño, su justificación y la determinación de las bases de su implementación sin
ambigüedades.(IBM, 2006)
1.3.1. UML
El Lenguaje de Modelado Unificado es un lenguaje de modelado visual orientado a
objetos(Rumbaugh, Jacobson, & Booch, 1998). EL UML es el sucesor de métodos y

Diseño de software
22
diseños orientados a objetos que surgió a finales de los 80’s. Fue creado por Booch,
Rumbaugh y Jacobson. En la actualidad es un estándar del Grupo de Administración de
Objetos: OMG (por sus siglas en inglés: Object Management Group)(Fowler, Scott,
González V, & Morales Peake, 1999). Contiene abstracciones para muchos conceptos de
modelado orientado a objetos estándar. Entre ellos se encuentran los diagramas de clase,
diagramas de máquinas de estado, diagramas de casos de uso y diagramas de
secuencia(Booch, Rumbaugh, & Jacobson, 1999). Con estos diagramas los usuarios
pueden describir la arquitectura, diseño y aún la implementación de sistemas de software.
El UML se encuentra fuertemente integrado el proceso de desarrollo iterativo
implementado por RUP.
El UML 2.0 define en la actualidad trece tipos de diagramas divididos en tres categorías: la
estructura estática de la aplicación, tipos generales de comportamiento y aspectos de
interacción.(OMG, 2007b)
• Diagramas de estructura: Diagrama de clases, diagramas de objetos, diagrama de
componentes, diagrama de composición de la estructura, diagrama de paquetes y
diagrama de implementación.
• Diagramas de comportamiento: diagrama de casos de uso, diagramas de actividad
y diagrama de máquina de estados.
• Diagramas de interacción: derivados de los diagramas de comportamiento incluyen
el diagrama de secuencia, diagrama de comunicación, diagrama de tiempo y
diagrama general de interacción

Diseño de software
23

Figura 6 Estructura de alto nivel de UML 2.1.1 (OMG, 2007b)
UML fue diseñado para ser un lenguaje gráfico de modelado de propósito general. Esto le
permite especificar la mayoría de los sistemas basados en objetos o componentes.
Cuando el UML no permite expresar los conceptos de un dominio específico o se desea
restringir o especializar sus constructores propios se puede definir un lenguaje de dominio
específico. Ante esta situación se puede definir un lenguaje totalmente nuevo o extender el
propio UML, especializando algunos de sus conceptos y extendiendo otros pero
respetando la semántica original. Para extender el lenguaje UML existen una serie de
mecanismos llamados perfiles de UML. (Fuentes & Vallecillo, 2004)
1.3.2. Lenguajes de dominio específico
Un lenguaje de dominio específico o DSL (Por sus siglas en inglés: Domain-Specific
Language) es un lenguaje que permite a través de notaciones apropiadas y abstracciones,
expresar un dominio de problemas específico.(Deursen, Klint, & Visser, 2000)
Un lenguaje de dominio específico está definido por un modelo del dominio.

Diseño de software
24
Ejemplos de DSL son:
• Diagramas entidad – relación(Chen, 1976)
• BPEL - Business Process Execution Language(Alves et al., 2007)
• CSS - Cascading Style Sheets(Bos, Lie, Lilley, & Jacobs, 1998)
• SQL - Structured Query Language(Date & Darwen, 1993)
Muchos lenguajes son de un dominio específico más que de propósito general.(Mernik &
Sloane, 2005)
Existen otros nombres para un DSL(Wikipedia, 2007a) como:
• Pequeños lenguajes
• Macros
• Lenguajes de aplicación
• Lenguajes orientados a problemas
Adoptar un DSL implica riesgos y oportunidades(Deursen et al., 2000). Entre los beneficios
tenemos:
• Expresar en un nivel de abstracción el dominio del problema
• Son concisos, autodocumentados y reutilizables para diferentes propósitos
• Aumentan la productividad, lectura, mantenimiento y portabilidad
• Describe un dominio de conocimiento, conservándolo y reutilizándolo
Las herramientas de cómputo que implementan un DSL capturan especificaciones en
forma de modelos de dominio. Comúnmente pueden generar, configurar e integrar
determinados componentes de aplicaciones. Estos ambientes traducen el diseño
verificado mediante un modelado formal a una variedad de artefactos que pueden incluir
código, esquemas de bases de datos y configuraciones.(Ledeczi et al., 2001). La intención
de crear un DSL es llegar a la generación automática de código.
Se pueden distinguir 5 fases para el desarrollo de un DSL: (Mernik & Sloane, 2005)

Diseño de software
25
• Decisión,
• análisis,
• diseño,
• implementación e
• implantación

Figura 7 Fases para el desarrollo de un DSL
En el modelado de un dominio específico se pueden distinguir al menos cuatro
direcciones(Luoma, Kelly, & Tolvanen, 2004):
• Conceptos del desarrollador o del experto del dominio. Cuando el lenguaje es
modelado por un experto es más fácil de entender.
• Salida generada. Definición de la estructura de código requerida.
• Representatividad del sistema construido. El modelo debe entenderse claramente
cuando es visto por el usuario final.
• Espacio de variabilidad. Definiciones de lenguajes flexibles que puedan extenderse
para ser empleadas en futuras variantes.
Para elaborar un DSL se debe realizar un análisis de dominio formal. La salida de esta
etapa es un modelo de dominio que consiste de(Mernik & Sloane, 2005):
• Una definición de dominio que describe el alcance del dominio
• Terminología del dominio (vocabulario, ontología)
Desición de
elaboración
Análisis del
dominio Diseño Implementación Implantación

Diseño de software
26
• Descripciones de los conceptos del dominio
• Modelos característicos que describen las constantes y variables de los conceptos
del dominio y sus interdependencias.
El tiempo que un desarrollador necesita para aprender un lenguaje de modelado de
propósito general es mayor que el que requiere para aprender un DSL. Un DSL representa
de manera más cercana el dominio que se desea modelar. En Nokia por ejemplo, el
conocimiento del dominio contenido en su DSL produjo una disminución en la curva de
aprendizaje para nuevos empleados. Ello redujo el inicio de la productividad de los
desarrolladores de seis meses a 2 semanas.(Kelly & Tolvanen, 2000)
1.3.3. Modelado de dominio específico
El Modelado de dominio específico: DSM (Por sus siglas en inglés: Domain Specific
Modeling) comúnmente es utilizado como sinónimo de DSL. Sin embargo un DSL puede
hacer traducciones entre lenguajes textuales como es el caso de Ruby. (Freeze,
2006)(Cuadrado & Molina, 2007).
El DSM tiene como beneficio principal una mayor alineación entre el modelo de la
aplicación y el código generado.(Kelly & Tolvanen, 2008)
Los DSM están más relacionados a herramientas visuales de modelado que soportan la
implementación de un DSL.
Actualmente muchas empresas apoyan la generación de DSM y su implementación a
través de sus herramientas. Tal es el caso de Microsoft, IBM, MetaCase y Eclipse.
El modelado de dominio específico requiere principalmente de tres cosas: (Kelly &
Tolvanen, 2008)
• Un lenguaje de modelado de dominio específico
• Un generador de código de dominio específico
• Un marco o herramientas de dominio

Diseño de software
27

Figura 8 Función del DSL
Los generadores de código asociados a los DSM surgen como una evolución de los
lenguajes de cuarta generación.
1.3.4. Perfiles de UML
Un perfil de UML es una opción para definir un DSL extendiendo la capacidad del UML.
Los perfiles de UML permiten la definición de estereotipos los cuales son extensiones de
diseño de elementos UML que permiten contar con elementos UML con información
adicional.(Leroux et al., 2006)
La siguiente imagen muestra la estructura de los elementos utilizados para definir un perfil
de UML proporcionados por la especificación del estándar.
Un perfil de UML es una especificación que hace una o más de las siguientes cosas(OMG,
2007a)(OMG, 2007b):
• Identificar un subconjunto de el metamodelo UML
• Especificar un conjunto de restricciones para elementos bien formados mediante el
Lenguaje de Restricción de Objetos de UML: OCL (Por sus siglas en inglés Object
Constraint Language) (OMG, 2006)
• Especificar elementos estándar mediante instancias de estereotipos de UML,
valores etiquetados o restricciones
• Especificar la semántica de los elementos del perfil expresada en lenguaje natural

Diseño de software
28
• Especificar los elementos comunes del modelo en términos del perfil

Figura 9 Elementos definidos en el paquete perfil (OMG, 2007a)
El OCL puede ser usado para diferentes propósitos:(OMG, 2006)
• Como un lenguaje de consulta
• Para especificar invariabilidad de clases y tipos en el modelo de clases
• Para especificar tipos invariantes para estereotipos
• Para describir pre y post condiciones en operaciones y métodos
• Para describir guardas
• Para especificar destinos para mensajes y acciones
• Para especificar restricciones en operaciones

Diseño de software
29
• Para especificar reglas de derivación de atributos para cualquier expresión sobre un
modelo UML
Para definir un perfil debe contarse con un metamodelo previo que muestre los elementos
del dominio y sus relaciones.
Un metamodelo es un modelo que define otro modelo. (Leroux et al., 2006)
Un perfil se compone de:
• La declaración de un paquete perfil de UML.
• Tipos primitivos. Son utilizados en los estereotipos como etiquetas definidas.
Pueden estar predefinidas en una librería del dominio específico referenciada por el
perfil o pueden importarse de otras librerías como la del plugin de Eclipse
org.Eclipse.uml2.uml.resources. Por ejemplo “texto”, “entero”, “booleano”.
• Enumeraciones. Es un tipo de dato que permite definir cualquier número de valores
nombrados definidos por el usuario. Por ejemplo “Tipo de inmueble”.
• Valores etiquetados(en inglés: enumeration literals). Un valor de dato definido por el
usuario para ser usado en una enumeración. Por ejemplo “condominio”,
“departamento”, “residencia”
• Estereotipos. Definen el cómo puede ser extendida una metaclase, permitiendo en
lugar de esta el uso de la notación o terminología del dominio. Cada estereotipo
puede extender una o más clases a través de extensiones como parte de un perfil.
Por ejemplo <<inmueble>>, <<constructor>>,<<comprador>>
• Generalizaciones de estereotipos. Como en las clases los estereotipos pueden
estar involucrados en generalizaciones. Una generalización es una relación
taxonómica entre un clasificador específico y un clasificador mas general. Cada
clasificador específico hereda las características del clasificador general pudiendo
agregar sus características propias.
• Propiedades de estereotipos. Como en las clases los estereotipos pueden tener
propiedades o atributos. Cuando un estereotipo es aplicado a un elemento del

Diseño de software
30
modelo, los valores de las propiedades pueden ser referenciados como valores
etiquetados
• Referencias a metaclases. Un perfil es una forma restricta de un metamodelo que
siempre debe estar referenciado a un metamodelo (por ejemplo UML). Un perfil no
puede ser usado sin la referencia a un metamodelo, este define el límite para
extender las metaclases de un metamodelo de referencia vía estereotipos.
• Extensiones. Son usadas para indicar que las propiedades de las metaclases son
extendidas a través de estereotipos y permiten de manera flexible aplicar dichos
estereotipos a los elementos.
A medida que se desea mejorar el modelado acercándolo a las características propias del dominio, el
diseño de un DSL se vuelve recomendable.
Tanto los perfiles de UML como el UML están basados en el MOF estándar definido por el OMG.
Existen varios ejemplos de perfiles de UML empleados en la actualidad. Entre ellos
tenemos:
• Lenguaje de modelado de sistemas: SysML (por sus siglas en inglés:Systems
Modeling Language)(Partners, 2005)
• Perfil de UML para CORBA
• Perfil UML para distribución de datos
• Perfil de UML para el modelado y análisis de sistemas embebidos y en tiempo real:
MARTE (por sus siglas en inglés: Modeling and Analysis of Real-time and
Embedded Systems)

Herramientas de modelado
31

2. Capítulo: Herramientas de modelado
En esta sección se presenta la revisan las
características de las herramientas para
implementar lenguajes de modelado de dominio
específico. Las herramientas que se presentan
son: MetaEdit+, Microsoft DSL Tools y el
proyecto de modelado de Eclipse

32
Introducción
Existen en la actualidad varias herramientas para modelado visual capaces de utilizar un
DSL. Entre las más importantes tenemos:
• MetaEdit+,
• MS DSL Tool,
• Eclipse Modeling Framework.
Una herramienta no es suficiente para la implementación de un DSL. Debe contarse
previamente con el modelo de domino o metamodelo para un trabajo completo.
2.1. MetaEdit+
MetaEdit+ es una herramienta de la marca metaCASE que permite diseñar lenguajes de
modelado y generación de código para automatizar el desarrollo de software. Fue creada
en el año de 1995.
En Metaedit+, el lenguaje de metamodelado se denomina GOPPRR (por sus siglas en
inglés: Graph, Object, Property, Port, Relationship y Role), que son los meta-tipos que
proporciona para describir los lenguajes de modelado.(Gomez & Sanchez, )

33

Figura 10 Herramienta MetaEdit+
Esta herramienta permite representar modelos de manera textual y gráfica. Dichos
metamodelos y los mismos modelos son almacenados en un repositorio.
El método de desarrollo de esta herramienta es definir conceptos, propiedades asociadas
y reglas.
A diferencia de otras herramientas, el entorno de trabajo que utiliza no diferencia
claramente los conceptos de sintaxis abstracta y sintaxis concreta. De esta forma, cuando
se define un nuevo elemento del metamodelo y sus propiedades, se diseña también el
aspecto visual del mismo.

34

Figura 11 Arquitectura de MetaEdit+
Esta herramienta se ha utilizado para implementar más de 100 técnicas de modelado y
docenas de código y reportes.
Esta herramienta ha sido utilizada por Nokia para personalizar métodos de desarrollo de
sistemas de administración de redes y sus teléfonos móviles. Deloitte & Touche utilizaron
metaCASE para implementar una herramienta que soporta su metodología orientada a
objetos.
2.2. Microsoft DSL Tools
Esta herramienta es una extensión del Visual Studio que permite la construcción de
diseñadores gráficos y la generación de código usando una notación diagramática para
dominio específico. DSL Tools incluye las siguientes herramientas:(Cook, Jones, Kent, &
Wills, 2007)

35
• Un asistente de proyectos con plantillas de soluciones que ayudan a iniciar el
desarrollo de un DSL del usuario
• Un diseñador gráfico para crear y editar la definición del DSL
• Un motor de validación para asegurar que la definición del DSL está bien formada
• Un generador de código que toma la definición del DSL como entrada para
producir código
Para liberar la herramienta se debe empaquetar la solución, la cual solo puede ser
ejecutada en el entorno propietario de Visual Studio.
Microsoft DSL Tools permiten definir lenguajes gráficos usando sintaxis abstracta
(metamodelo) en una notación propietaria. La base de dichos modelos es el XML como
mecanismo de persistencia.

Figura 12 IDE de Microsoft VisualStudio con DSL Tool

36
EL desarrollo de un DSL en Visual Studio debe tener las siguientes características:
notación, modelo del dominio, generación de artefactos, serialización e integración con
Visual Studio.

Figura 13 Arquitectura DSL Tools
Esta herramienta genera un DSL a través de un asistente el cual nos permite elegir una
plantilla base que puede ser personalizada.
El resultado son dos proyectos enlazados que permiten definir el DSL y construir la
interface gráfica del usuario.(Gomez & Sanchez, )

Figura 14 Proyectos de Visual Studio al crear un DSL
Desarrollo del DSL
(Definición del modelo)
DomainModel.dsldm
Modelodel
dominio
Notación
gráficaycajade
herramienta
Exploradory
ventanade
propiedades
Validación
Serialización
Implantación
DSL Designer
(Desarrollo de la GUI)
Designer.dsldd
Construccion
delmodelode
dominio
Significadodel
modelo
Progamación
usandoDSL
API

37
2.3. Proyecto de modelado de Eclipse
Eclipse es una organización que implementa modelos, marcos de trabajo y herramientas
libres.
Entre los muchos proyectos con los que cuenta, se encuentra el proyecto de modelado de
Eclipse: EMP (por sus siglas en inglés: Eclipse Modeling Project). Este proyecto se centra
en el desarrollo de herramientas de modelado y la generación automática de código.
Empresas importantes como IBM, Borland y Sun son algunos de los principales
promotores de este proyecto.
En Eclipse para definir un DSL puede usarse un Metamodelo generado en EMF (por sus
siglas en inglés: Eclipse Modeling Framework).
El modelo fuente de un proyecto EMF contiene la descripción de los datos de una
aplicación incluyendo: objetos y sus atributos, relaciones, operaciones y restricciones.
El EMF permite generar código desde meta-modelos definidos como diagramas de clase
de UML usando plugins apropiados. El EMF puede utilizarse como base para la
especificación de lenguajes visuales. (Ehrig et al., 2005)
Los modelos de dominio o metamodelos (modelos que representan modelos) pueden
generarse a través de las siguientes opciones:
• Interfaces de clases en Java
• Modelo de clases de Rational Rose
• Documento XML
• Modelo ecore
El EMF (Budinsky, 2003) ofrece además de la descripción de un metamodelo,
herramientas para importar y generar código de modelos fuente en varios formatos,
ofreciendo un camino simple y práctico para el modelado y metamodelado.
Una vez que se cuenta con el modelo del dominio se puede utilizarse el GEF para la
generación de una herramienta visual. (Moore, 2004)

38

Figura 15 Analogía entre Eclipse EMF y GMF
Para facilitar la generación de herramientas gráficas basadas en un modelo de dominio,
Eclipse creo el framework de modelado gráfico: GMF (por sus siglas en inglés: Graphical
Modeling Framework). El objetivo de este framework es servir como un puente amigable al
usuario entre el EMF y el GEF para la generación de editores visuales.

Figura 16 Proceso de generación de un modelador con Eclipse GMF

39
2.4. Elección de la herramienta
Para el desarrollo de la herramienta de modelado visual presentado en esta tesis se ha
elegido a Eclipse debido a:
• Utiliza estándares abiertos de modelado
• No requiere costos de licenciamiento
• El componente de modelado es fácilmente distribuible mediante plugins
• La creación de herramientas visuales es altamente configurable
• Soporta diferentes sistemas operativos
• La empresa IBM propietaria de Lotus Notes apoya fuertemente a la fundación
Eclipse. IBM está migrando sus clientes Lotus Notes a esta plataforma lo que
permitirá en trabajos futuros integrar las actividades de diseño y codificación de
aplicaciones en un mismo entorno

Plataforma Lotus Notes
40

3. Capítulo: Plataforma Lotus Notes / Domino
En esta sección se describen las características
de la plataforma colaborativa IBM Lotus Notes /
Domino

41
3.1. Breve historia
La plataforma IBM Lotus Domino/Notes permite el desarrollo e implementación de
aplicaciones colaborativas empresariales.
Entre sus características más destacables se encuentra el gran número sistemas
operativos sobre los que puede ejecutarse como: Windows, IBM OS, Mac, Novell, UNIX
(AIX de IBM, Solaris de Sun, UX de HP y Linux). Ello permite a los programadores la
facilidad de desarrollar aplicaciones independientemente de la plataforma.(Plaza, 2000)
Lotus Notes está fuertemente orientado al desarrollo de aplicaciones colaborativas donde
interactúen personas, información y procesos.
Lotus almacena de manera integrada los datos y elementos de diseño (estructura de los
datos y código de la aplicación)(IBM, 2005a)utilizando un ítem básico llamado nota (en
inglés Notes) de ahí el origen de su nombre de marca. Todos estos elementos se
encuentran contenidos en una sola base de datos de extensión “nsf”.

Figura 17 Composición de una BDs Notes
3.2. Elementos de diseño
Estos elementos de diseño son utilizados para codificar la funcionalidad de la aplicación.
Los elementos de diseño pueden contener opcionalmente acciones, eventos y otros
elementos de diseño. Las acciones y eventos pueden contener código en alguno de los
lenguajes soportados como: Java, JavaScript, LotusScript, comandos y fórmulas.

42
Un elemento de diseño puede contener al mismo tiempo la lógica de la aplicación
(funcionalidad), la interfaz del usuario y la estructura de datos).

Figura 18 Elementos de diseño de Lotus Notes
Lotus proporciona mecanismos para exportación e importación no solo de los datos sino
de la estructura de sus aplicaciones. Para ello proporciona una estructura XML
estandarizada llamada Domino en DTD (por sus siglas en inglés: Domino Document Type
Definitionk).(IBM, 2005b)
3.3. Funcionalidades y características
Lotus Notes se ha consolidado como una plataforma colaborativa de desarrollo rápido de
aplicaciones: RAD (por sus siglas en inglés: Rapid Application Develop). Ello le permite
desarrollar fácilmente aplicaciones simples.
Elementos de diseño
Framesets
Pages
Forms
Views
Folders
Agents
WebServices
Outlines
SubForms
Fields
Columns
Actions
ScriptLibraries
Images
Files
Applets
StyleSheets
Dataconnections
Icon
Using
About
DatabaseScript
Navigators

43

Figura 19 Funciones y características de la plataforma Notes/Domino
Al tratarse de un entorno de desarrollo RAD y su base de datos diferente al modelo
entidad-relación tradicional, el modelado tradicional de aplicaciones usando lenguajes de
propósito general como el UML, puede ser complicado y difícilmente estandarizado.
3.4. Productos de la plataforma
Debido a su aceptación en el mercado, facilidad de integración y servicios integrados, IBM
ha extendido las capacidades originales de la plataforma. En la actualidad bajo la marca
Lotus se han creado e integrado gran número de aplicaciones y servidores especializados
para distintas necesidades como: portales, gestión del conocimiento, administración
documental y multimedia, BalanceScorecard, etc.

44
Categoría Productos
Applications - Desktop & Enterprise
Diseñadas para automatizar procesos
empresariales, incrementar la
productividad del personal y educación.
Productivity & Office Suites
• Lotus 1-2-3
• Lotus Organizer
• Lotus SmartSuite
• Lotus Symphony
Business Integration
Proporciona una infraestructura
centralizada para integración de
aplicaciones y automatización de procesos
de negocio
Application Integration and Connectivity
• Lotus Connector for SAP Solutions
• Lotus Enterprise Integrator for Domino
Other Business Integration
• Workplace for SAP Software
Enterprise Content Management
Administración de contenido,
cumplimiento con optimización de
procesos de negocio y de contenido.
Content Management
• Lotus Domino Document Manager
• Lotus Quickr
• Lotus Web Content Management
Messaging Applications
Proporcionan ambientes colaborativos
integrados basados en directorios, correo
electrónico y calendario de grupos.
Advanced Messaging
• Lotus Complete Collaboration Express Starter Pack
• Lotus Domino
• Lotus Domino Express
• Lotus Domino WebMail
• Lotus iNotes
• Lotus Notes
• Lotus Notes Hosted Messaging
• Lotus Symphony
• Lotus Workflow
Mobile, Speech and Enterprise Access
Middleware que soporte el acceso a los
recursos de la empresa por clientes ricos,
comandos de voz y dispositivos.
Mobile and Enterprise Access
• Lotus EasySync Pro
• Lotus Expeditor
• Lotus Mobile Connect
Organizational Productivity, Portals
and Collaboration
Proporciona mensajería instantánea,
conferencia Web, ambientes portales
colaborativos y ambientes basados en
roles.
Forms Management
• Lotus Forms (Forms, Turbo)
Learning Software
• Lotus Learning Management System
• Workplace Collaborative Learning
Portals
• IBM Business Process Accelerator
• IBM Collaboration Accelerator
• IBM Content Accelerator
• IBM Dashboard Accelerator
• IBM Enterprise Suite Accelerator
• IBM Healthcare Accelerator
• IBM Learning Accelerator
• IBM Self-Service Accelerator

45
• Lotus ActiveInsight
• Lotus Workforce Management
• Workplace for Business Controls and Reporting
• Workplace for SAP Software
Enriches, extends and complements your SAP
investments
Real-time & Team Collaboration
• Lotus Foundations Start
• Lotus Quickr
• Lotus Quickr Content Integrator
• Lotus Sametime (Advanced, Entry, Standard, Unyte)
Social Software
• Lotus Connections
Security
Protege la confidencialidad,
integridad, privacidad y
aseguramiento de sistemas de
información.
Security Compliance and Vulnerability Management
• Lotus Protector for Mail Security
Software Development
Herramientas de desarrollo de SW
para construir aplicaciones y soportar
la ejecución de procesos de
implantación
Analysis, Modeling, Design & Construction
• Lotus Domino Designer
Mashup Development
• Lotus Mashups
Tabla 1 Lista de productos de Lotus por categoría

Lenguaje de modelado de dominio específico para Lotus Notes / Domino
46

4. Capítulo: Lenguaje de modelado de dominio
específico para Lotus Notes / Domino
Se presenta el proceso realizado durante la I+D
para la definición del DSL para aplicaciones
Lotus Notes

Modelado Visual de Aplicaciones Lotus Notes Domino

Modelado Visual de Aplicaciones Lotus Notes Domino

Recomendados

Recomendados

Más contenido relacionado

Similar a Modelado Visual de Aplicaciones Lotus Notes Domino

Similar a Modelado Visual de Aplicaciones Lotus Notes Domino (20)

Más de Hiriam Eduardo Perez Vidal

Más de Hiriam Eduardo Perez Vidal (9)

Último

Último (20)

Modelado Visual de Aplicaciones Lotus Notes Domino