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

47
4.1. Introducción
Para cumplir con el objetivo de esta tesis el desarrollo se divide en tres partes principales:
1. La obtención de un lenguaje de modelado de dominio específico para aplicaciones
Lotus Domino
2. El desarrollo de una herramienta de software de modelado visual que permita el
diseño de aplicaciones utilizando el DSL antes mencionado
3. El desarrollo de una herramienta de software que genere código automáticamente a
partir de un diagrama o modelo de aplicación Lotus.
Para el primer punto se obtuvo un DSL comenzando por el análisis del dominio
tecnológico para el desarrollo de aplicaciones Lotus Domino. El producto del análisis fue la
obtención de un metamodelo. A partir de este metamodelo se especificó un perfil de UML
con el propósito de poder implementarlo en una herramienta de modelado.
En el segundo punto se eligió el framework de modelado de Eclipse, como base para la
construcción de la herramienta visual de modelado. La herramienta de modelado puede
ser distribuida a los diseñadores y desarrolladores a través de plugins. El producto del
modelado nos entrega dos archivos. Uno contiene la estructura XML de la aplicación
modelada y el otro la interfaz gráfica del usuario para poder visualizar dicha estructura.
Para el tercer punto se desarrollo una aplicación Lotus Domino que importa la estructura
XML de la aplicación modelada, la transforma en una definición de aplicación utilizando el
Domino DXL y finalmente genera la aplicación Lotus representada en el modelo.
A continuación se presenta de manera detallada el desarrollo de cada uno de los puntos
de esta tesis.
4.2. Proceso para definir el lenguaje
Como se mencionó en la introducción, el propósito de esta etapa fue la obtención de un
DSL.
Para definir el DSL se realizaron los siguientes pasos:

48
1. Análisis del dominio
2. Definición del metamodelo
3. Especificación del DSL
4. Validación del DSL

Figura 20 Proceso para la obtención del DSL

4.2.1. Análisis de dominio
El desarrollo de toda aplicación Lotus Domino se centra en el uso de los elementos de
diseño proporcionados por la herramienta de desarrollo.
Se aclara que para propósitos de concordancia con el nombre de los elementos de diseño
de Lotus Notes, se ha mantenido su nombre original en el idioma inglés ya que es el
término usado cuando los programadores se refieren a ellos.
Cada uno de estos elementos tiene un comportamiento propio el cual puede ser utilizado
para realizar acciones controladas a través de código introducido por el programador.
A continuación se presenta una descripción breve de cada uno de los elementos.
Elemento de diseño Descripción
DataBase Toda aplicación está contenida en una base de datos. La
base de datos contiene los datos, la lógica y los
elementos de diseño de la aplicación.
Análisis del
dominio
Definición del
metamodelo
Especificación
del DSL
Validación del
DSL

49
Frameset Representa a un elemento Frameset en LDD que permite
estructurar páginas Web.
Frame Representa a una sección de un elemento Frameset.
Web Service Representa a un Servicio Web (aplicación autónoma) que
puede invocarse o publicarse en el Web.
Form Representa un formulario que permite mostrar e ingresar
información a la BD.
Subform Representa a un subformulario agrupador de elementos y
de cierta funcionalidad que puede compartirse entre
formularios.
Field Representa a un campo que recolecta datos de algún tipo.
Page Representa al elemento Page de LDD que se utiliza para
presentar información de la BD.
Action Bar Representa a una barra de botones. Cada botón es un
contenedor de acciones programadas.
Action Representa código fuente en algún tipo de lenguaje
soportado por LDD. Provee métodos de rápido acceso a
tareas rutinarias.
Agent Representa código fuente en algún tipo de lenguaje
soportado por LDD. Permiten automatizar tareas
rutinarias.
ScriptLibrary Representa a una librería codificada en algún lenguaje
soportado por LDD. Estas pueden compartirse entre
diversos elementos.
File Representa a un archivo importado en la BD para
utilizarse de manera compartida en el diseño de
aplicaciones.
Style Sheet Representa una hoja de estilo importada a la BD que
permite tener mejor control sobre muchos aspectos en el
diseño de páginas Web.
Outline Representan a un elemento Outline en LDD. Provee una
forma de navegar en una aplicación a los usuarios.

50
Outline Entry Representa un elemento de la estructura de navegación
de un Outline. Puede ser una liga o acción que invoque un
componente, incluso otra aplicación o BD.
Image Representa a una imagen importada a la BD.
Applet Representa un Applet de Java importado a la BD.
Computer Text Representa un campo calculado donde su valor está
determinado por una fórmula que el desarrollador
programa.
Table Representa una tabla de texto enriquecido que permite
agrupar y presentar información mostrada a través de
otros elementos.
Section Es una área que puede expandirse o colapsarse para
mostrar u ocultar elementos contenidos en esa área.
Navigator Representa una interfaz que permite a los usuarios
acceder a otros elementos o datos de una BD.
View Representa a una vista en LDD. Es una lista de
documentos de una BD que pueden seleccionarse de
acuerdo a un criterio de selección.
Folder Tienen la misma funcionalidad que un elemento View. La
diferencia radica en que aquí no existe un criterio de
selección de documentos.
Column Muestran un tipo de información acerca de los
documentos listados en un View o Folder. Son un
componente estructural de los mismos.
Button
Hotspot Representa texto o una imagen en un campo de texto
enriquecido donde puede hacerse clic para llevar a cabo
una acción, correr una formular, script o invocar una liga.
Tabla 2 Descripción de elementos de diseño de Lotus
Si bien Lotus Domino provee de los elementos de diseño anteriormente descritos para ser
utilizados como base del desarrollo de aplicaciones, en la práctica no todos los elementos
son usados en una determinada aplicación.

51
La siguiente tabla muestra la distribución en el uso de dichos elementos. Se tomaron para
el análisis tres aplicaciones desarrolladas por el IIE donde intervinieron varios
desarrolladores en su codificación.

Tabla 3 Porcentaje de uso de elementos de diseño en aplicaciones Lotus
Como puede observarse la distribución varía para cada aplicación debido a la
funcionalidad que implementa y a la manera en que un desarrollador implementa dicha
funcionalidad.
La siguiente gráfica muestra como elementos más importantes a los archivos y las
imágenes. Estos elementos no contienen propiamente código programado. En la práctica
los elementos más usados para programación son los forms, views, pages y agents.
Framesets 17 3.85% 0 0.00% 2 0.60%
Pages 55 12.47% 53 7.86% 12 3.59%
Forms 76 17.23% 62 9.20% 62 18.56%
Views 51 11.56% 69 10.24% 51 15.27%
Folders 0 0.00% 0 0.00% 0 0.00%
Agents 36 8.16% 70 10.39% 42 12.57%
WebServices 0 0.00% 0 0.00% 0 0.00%
Outlines 1 0.23% 0 0.00% 0 0.00%
SubForms 8 1.81% 3 0.45% 6 1.80%
Fields 5 1.13% 4 0.59% 3 0.90%
Columns 0 0.00% 0 0.00% 0 0.00%
Actions 12 2.72% 0 0.00% 2 0.60%
Script
Libraries 12 2.72% 16 2.37% 6 1.80%
Images 146 33.11% 130 19.29% 126 37.72%
Files 11 2.49% 257 38.13% 6 1.80%
Applets 0 0.00% 0 0.00% 0 0.00%
Style
Sheets 9 2.04% 8 1.19% 14 4.19%
Data
connections 0 0.00% 0 0.00% 0 0.00%
Icon 1 0.23% 1 0.15% 1 0.30%
Using 0 0.00% 0 0.00% 0 0.00%
About 1 0.23% 1 0.15% 1 0.30%
Database
Script 0 0.00% 0 0.00% 0 0.00%
Navigators 0 0.00% 0 0.00% 0 0.00%
441 100.00% 674 100.00% 334 100.00%
Minutas
Aplicaciones
Shared
codeShared
resources
Portal ServiceDesk
Elementos
de

diseño

52

Figura 21 Distribución de elementos de diseño en las aplicaciones
Otra característica importante de los elementos de diseño es la capacidad de contener a
otros elementos. Dada esta característica los elementos pueden ser contenedores,
contenidos o ambos.
Algunos elementos contenidos pueden desplegarse o ser invocados para su ejecución de
manera directa, otros sin embargo solo pueden existir como elementos contenidos por lo
que no pueden ejecutarse de manera directa sino a través de la invocación de su
elemento contenedor.
Dado lo anterior los elementos quedan clasificados como:
• Principal containers. Elementos de diseño que pueden contener a otros elementos y
pueden ser invocados o ejecutados por su mismos
• Secondary containers. Pueden contener a otros elementos pero no pueden ser
ejecutados o invocados de manera directa sino a través de otro elemento
contenedor
• No containers. Son elementos de diseño que no pueden contener a otros elementos

53

Figura 22 Clasificación de elementos de diseño

Principal
containersView
Form
Page
Frameset
Secondary containers
Folder
Outline
Hotspot
Table
Section
Frame
Navigator
Action
ActionBar
Subform
No containers
WebService
Button
File
Column
Agent
StyleSheet
Applet
Field
OutlineEntry
ScriptLibrary

54
4.2.2. Metamodelo
Como resultado del análisis de dominio se obtuvo el siguiente modelo que muestra las
relaciones que existen entre los elementos de diseño que componen una aplicación Lotus
Domino. Este metamodelo es utilizado como base para la definición de un lenguaje visual
de modelo.

Figura 23 Metamodelo de aplicaciones Lotus Domino

55
4.2.3. DSL para aplicaciones Lotus Domino
La especificación del DSL se realizó a través de un perfil de UML. Esto nos permite que
pueda ser implementado en diferentes herramientas de modelado propietarias y libres. De
esta manera puede aprovecharse el esfuerzo en la definición del lenguaje.
Cada elemento del metamodelo se representó como un estereotipo de UML que extiende
a una metaclase base. Los estereotipos se agruparon de acuerdo a la clasificación de
contención obtenida en el metamodelo.

Figura 24 Clasificación de los estereotipos del perfil de UML para Lotus

56
En el perfil se muestran: los elementos de diseño, su descripción, la metaclase a la que
extienden, sus relaciones con otros elementos, los valores etiquetados o propiedades que
lo componen, sus restricciones y el elemento visual que los representa.
Para propósitos de agilizar la lectura del trabajo presentado en este tesis, la especificación
completa del perfil se muestra como un anexo.
4.2.4. Validación del DSL
Para validar el DSL se implementó el perfil haciendo uso de la herramienta comercial de
modelado Enterprise Architect de la compañía Sparx System, con el propósito de realizar
una prueba de modelado. Para ello se le agregó el perfil una iconografía prototipo
arbitraria ya que la implementación final se realizara en la herramienta de Eclipse.
Para la validación se tomó una aplicación Lotus Domino ya existente, la cual contaba con
diagramas de diseño no estandarizados previamente elaborados.

Figura 25 Ejemplos de diagramas de diseño no estandarizados
En la validación se revisó que:

57
• Una aplicación Lotus Domino puede ser modelado a través del perfil.
• Para todo elemento de diseño existe un elemento visual que lo representa
• Para todo relación entre los elementos existe un elemento visual que lo representa
• Para cada propiedad de un elemento de diseño existe un valor etiquetado al que se
le puede asignar un valor válido de acuerdo del DSL
Como ejemplo se muestran diagramas de diseño obtenidos.

Figura 26 Ejemplo de diagrama simplificado para la validación del DSL

58

Figura 27 Ejemplo de diseño especificando las propiedades de los elementos
En la validación del DSL se comprobaron que los puntos antes mencionados fueron
cubiertos. Hecho esto se procedió a la elaboración de la herramienta final en la plataforma
de Eclipse.

Desarrollo de la herramienta
59

5. Capítulo: Desarrollo de la herramienta
Se presenta el proceso realizado para la
implementación de una herramienta de software
de modelo visual que implementa el DSL Lotus
Domino y un generador de código a partir del
modelo. Se propone una arquitectura para la
implementación de un extractor de modelos a
partir de aplicaciones existentes utilizando
ingeniería inversa.

60
5.1. Componentes de la herramienta
La herramienta desarrollada cuenta con dos componentes principales:
• Un modelador visual que permite la generación de diagramas de diseño utilizando
el DSL previamente especificado
• Un generador automático de aplicaciones que permite crear los elementos de
diseño descritos en el diagrama de diseño.

Figura 28 Desarrollo de herramienta de modelado
A continuación se describe el proceso de desarrollo de la herramienta de software.
5.2. Requerimientos
5.2.1. Alcances
Esta herramienta permite el diseño de aplicaciones Lotus Domino utilizando el DSL
definido para ello. La herramienta genera los elementos de diseño representados en el
modelo. La codificación detallada será realizada por el programador en la aplicación final
durante la fase de codificación.
5.2.2. Objetivo general del sistema
Modelar aplicaciones Lotus Domino y generar los elementos de diseño de la aplicación
representada en modelo.
5.2.3. Funciones del producto
• Permite la creación de diseños de aplicaciones Lotus
• Permite la generación de aplicaciones a partir del modelo
Desarrollo de
herramienta de
modelado
Desarrollo de
generador de
aplicaciones

61
5.2.4. Usuarios
Diseñador: Persona responsable del modelado de la aplicación
5.2.5. Interfaces y relaciones de los sistemas
El sistema se dividirá en los siguientes componentes principales:
• Modelador visual. La funcionalidad de modelado se implementará sobre la
plataforma de Eclipse y será distribuible a través de un plugin.
• Generador de aplicaciones. Esta funcionalidad se implementará en una aplicación
Lotus Notes.
5.2.6. Características de usuarios
Los usuarios de este sistema deberán tener conocimientos en desarrollo de aplicaciones
Lotus Notes y el uso básico del entorno de Eclipse.
5.2.7. Restricciones
El componente de modelado se ejecutará sobre el ambiente:
• Entorno de desarrollo de Eclipse 3.4 (Ganymade)
• Plugin Eclipse Modeling Framework 2.4
• Plugin Graphical Editing Framework 3.4
• Plugin Graphical Modeling Framework 1.0
El componente de generación de aplicaciones se ejecutará sobre el cliente Lotus Notes
versión 7 o superior.
5.2.8. Dependencias y supuestos
Se asume que el diseñador cuenta con el ambiente de desarrollo instalado en su equipo
personal.
5.2.9. Características del sistema
El sistema será usado en el equipo de cómputo del diseñador.
Las interfaces de la herramienta serán visualizadas desde los ambientes Eclipse y Lotus
Notes.

62
5.2.10. Especificación de casos de uso

Figura 29 Casos de uso de herramienta de modelado
Los casos de uso (por sus siglas C.U.) representan la funcionalidad accesible por el
usuario. Esta funcionalidad se describe a continuación
C.U. Gestionar diagramas de diseño
El sistema permitirá la gestión de diagramas de diseño. Se entiende por gestión las tareas
de creación, modificación y eliminación.
Los diagramas de diseño deberán implementar el DSL para aplicaciones Lotus Notes
definido en el perfil de UML.
Un diagrama de diseño se compone de: elementos de diseño y relaciones entre los
elementos de diseño.
Todo diagrama de diseño deberá presentar una interfaz gráfica de usuario y una
estructura de datos para su procesamiento.
C.U. Gestionar elementos de diseño
El sistema permitirá le gestión de elementos de diseño que serán utilizados en el modelo o
diagrama.

63
Los elementos de diseño que se deben incorporar son:
• Principal containers
o View
o Form
o Page
o Frameset
• Secondary containers
o Folder
o Outline
o Hotspot
o Table
o Section
o Frame
o Navigator
o Action
o ActionBar
o Subform
• No containers
o WebService
o Button
o File
o Column
o Agent
o StyleSheet
o Applet
o Field
o OutlineEntry
o ScriptLibrary

64
Cada elemento de diseño tiene propiedades o atributos configurables. La lista de
propiedades para cada elemento puede consultarse en el perfil de UML(ver Anexo).
Cada uno de los elementos de diseño se identificará por un icono gráfico definido en el
perfil de UML.
C.U. Gestionar relaciones
El sistema permitirá la gestión de relaciones que serán utilizadas en el modelo o diagrama.
Una relación es un símbolo gráfico que indica que dos elementos de diseño se encuentran
relacionados entre sí. Toda relación tiene un conector de origen y otro de destino.
C.U. Generar aplicación Lotus
El sistema permitirá la generación de los elementos de diseño representados en un
diagrama de diseño de aplicación Lotus Notes.
C.U. Importar diagrama de diseño
Se deberá importar la estructura del diagrama de diseño modelado para su posterior
procesamiento. Se debe implementar un mecanismo de lectura de dicha estructura.
C.U. Generar estructura de aplicación Domino
A partir del modelo importado se deberá generar una definición de cada elemento de
diseño en formato DXL para su uso posterior.
C.U. Crear aplicación Lotus Domino modelada
Se deberá tomar el DXL que representa a la aplicación modelada y generar una base de
datos Lotus Domino que contenga los elementos modelados en el diagrama de diseño de
la aplicación.

65
5.3. Diseño de la arquitectura
Para cumplir con el objetivo de la tesis y cumplir con los requerimientos especificados en
los casos de uso antes descritos, se diseñó la arquitectura que se presenta a continuación.
5.3.1. Arquitectura general de la herramienta
La herramienta DSM está construida sobre dos tecnologías principales: Eclipse y Lotus
Domino.
Ambas plataformas soportan cada uno de los componentes principales de la herramienta.

Figura 30 Arquitectura general del DSM
Los componentes del sistema interactúan usando el modelo o diagrama generado por el
diseñador. Este modelo contiene la estructura de la aplicación (elementos de diseño,
atributos y relaciones) a generar.

66

Figura 31 Secuencia de ejecución del modelado a la generación
5.3.2. Diseño de despliegue

Figura 32 Diagrama de despliegue de la herramienta
La herramienta se ejecutará en una computadora personal que cuente con las siguientes
características:
• Entorno de desarrollo de Eclipse 3.4 (Ganymade)
• Plugin Eclipse Modeling Framework 2.4
• Plugin Graphical Editing Framework 3.4

67
• Plugin Graphical Modeling Framework 1.0
• Cliente Lotus Notes 7 o superior
5.3.3. Diseño de interfaces
Para que los dos componentes interactúen, la interfaz de comunicación es proporcionada
por la estructura XML del diagrama de diseño.
El sistema presenta una interfaz de usuario para cada uno de los componentes.
Para el componente de modelado la interfaz de usuario está construida sobre el entorno
de Eclipse.
Esta interfaz se compone de las siguientes partes:
• Explorador de diagramas
• Área de diseño
• Barra de herramientas
• Área de propiedades
• Vista aérea del diagrama

68

Figura 33 Interfaz gráfica del componente de modelado
Para el componente generador de aplicaciones la interfaz se compone de:
• Área de información al usuario con los prerrequisitos e instrucciones de uso de la
herramienta
• Área de acciones con las operaciones que el usuario puede ejecutar

69

Figura 34 Interfaz gráfica del componente de generación de aplicaciones
5.3.4. Diseño de los módulos
Modelador visual

Figura 35 Diseño del modelador
El modelador se encuentra construido sobre la plataforma de Eclipse y el framework de
modelado.

70
La herramienta de modelado toma como base la especificación del DSL para aplicaciones
Lotus Domino Especificado en el perfil de UML que puede consultarse en el documento
anexo de esta tesis.
El desarrollo de la herramienta visual requirió de cuatro proyectos creados en Eclipse:
• Proyecto dominoapp. Contiene los modelos necesarios para la generación de la
herramienta visual (modelo de dominio, modelo de definición gráfica, modelo de
herramientas visuales, mapeo de modelos y modelo de generación de herramienta
visual)
• Proyecto dominoapp.edit. Contiene adaptadores que proporcionan una vista
estructurada y desempeñan la edición basada en componentes de los objetos del
modelo
• Proyecto dominoapp.editor. Contiene la interfaz gráfica del editor del dominio
• Proyecto dominoapp.diagram. Contiene el plugin de la herramienta de modelado
resultante
El proyecto dominoapp es el punto de inicio para la generación de la herramienta de
modelado. A continuación se describen cada uno de los modelos que lo componen.

71

Figura 36 Proceso de creación de la herramienta gráfica basada en modelos

El modelo de dominio se encuentra definido en dominoapp.ecore. Este modelo usa la
metodología ecore para definir un dominio. Se tomó como base la especificación del perfil
de UML.

Figura 37 Estructura del modelo de dominio dominoapp.ecore

72
La definición del modelo de dominio puede realizarse a través de un documento XML o
mediante la interfaz gráfica proporcionada por el ambiente de Eclipse.

Figura 38 Documento XML del modelo de dominio
En el modelo de dominio se encuentran descritos los elementos de diseño, sus
propiedades y relaciones.

Figura 39 Vista gráfica del modelo de dominio
El modelo de dominio ecore es construido sobre el framework EMF de Eclipse.

73
El modelo de generación está definido en dominoapp.genmodel. Este modelo representa
como un objeto raíz al modelo mismo. El modelo tiene hijos que representan sus paquetes
y dentro se encuentran los clasificadores (clases, tipos de datos y enumeraciones. Los
hijos de las clases son atributos, referencias y operaciones. Los hijos de los tipos
enumerados sin los literales de la enumeración.
Este modelo de generación es la base para construir los proyectos dominoapp.edit y
dominoapp.editor que permitirán la generación de modelos que obedecen al dominio
especificado en dominoapp.ecore. Con estos últimos proyectos podemos generar
diagramas de diseño en el dominio de aplicaciones Lotus Notes, sin embargo, solo
podremos hacerlo con una estructura arbórea y no mediante un área de diseño gráfico.

Figura 40 Estructura del modelo de generación
El modelo de generación es construido sobre el framework EMF de Eclipse.

74
El modelo de definición gráfica se encuentra especificado en dominoapp.gmfgraph. En
este modelo se definen las imágenes que representarán a los elementos de diseño, los
nodos, etiquetas, conectores de relaciones y área de dibujo. Estos elementos se
desplegarán en la herramienta visual final al momento de elaborar un diagrama de diseño.

Figura 41 Modelo de definición gráfica
El modelo de definición gráfica se almacena en un documento con estructura XML. Este
modelo está construido sobre el framework GMF de Eclipse.

Figura 42 Documento XML del modelo de definición gráfica
El modelo de definición de herramientas o tooling está definido en dominoapp.gmftool.
Este modelo contiene la especificación de la paleta, herramientas de creación, acciones y

75
otros elementos para la manipulación de los elementos gráficas. En términos coloquiales
define la paleta o barra de herramientas del modelador visual.

Figura 43 Estructura del modelo de definición de herramientas o tooling
El modelo de definición de herramientas se almacena en un documento con estructura
XML y está construido sobre el framework GMF de Eclipse.

Figura 44 Documento XML del modelo de definición de herramientas

76
El modelo de definición de mapeo o mapping está descrito en dominoapp.gmfmap. Este
modelo integra los tres modelos importantes para la generación de la herramienta gráfica:
el modelo de dominio, la definición gráfica y la definición de herramientas. Este modelo es
la entrada para el paso de transformación del modelo de generación.

Figura 45 Estructura del modelo de definición de mapeo o mapping
El modelo de definición de mapeo se almacena en un documento con estructura XML y
está construido sobre el framework GMF de Eclipse.

77

Figura 46 Documento XML del modelo de definición de mapeo
El modelo de generación GMF se encuentra definido en dominoapp.gmfgen. Este modelo
configura las propiedades de generación de código de manera similar al modelo de
generación definido previamente en dominoapp.genmodel.

Figura 47 Estructura del modelo de generación GMF

78
Este modelo de generación también se almacena en un documento con estructura XML y
está construido sobre el framework GMF de Eclipse.
El modelo de generación GMF es creado a partir del modelo de definición de mapeo. Este
contiene todos los ajustes para la creación del plugin de modelado en el proyecto
dominoapp.diagram.
A partir del plugin de modelado contenido en dominoapp.diagram se generan los
diagramas de diseño elaborados por el usuario desde el entorno de Eclipse.
Un diagrama de aplicación Lotus Notes se compone de los siguientes archivos:
• *.dominoapp. Contiene la estructura del diagrama o modelo de aplicación Lotus
Notes creada por el usuario diseñador.
• *.dominoapp_diagram. Contiene la interfaz gráfica para visualizar y manipular el
diagrama de diseño de la aplicación.

Figura 48 Ejemplo de estructuras de diseños de aplicaciones
La visualización arbórea de la estructura de los modelos es proporcionada por el proyecto
dominoapp.editor.
El estructura de los diagramas de diseño se almacena en una estructura XML.

79

Figura 49 Ejemplo de XML de un diagrama de diseño
Módulo de generación de aplicaciones

Figura 50 Diseño del generador de aplicaciones
El generador de aplicaciones está construido sobre la plataforma de Lotus Notes
encapsulado en una base de datos generador.nsf. Este módulo se componen de dos
agentes:
• Agente de importación y transformación. Este agente toma la estructura XML del
diagrama de diseño entregado por el modelador visual en un archivo *.dominoapp y

80
lo transforma en una definición de aplicación equivalente bajo el formato Domino
XML conocido también como DXL.
• Agente de generación de aplicaciones. Este agente genera una aplicación *.nsf a
partir de la definición *.dxl entregada por el agente de transformación.

Figura 51 Arquitectura del generador de aplicaciones
5.3.5. Diseño de datos
Los datos de los modelos se encuentran almacenados en formato XML y pueden ser
visualizados con ayuda de los visualizadores de estructuras proporcionados por Eclipse. El
modelo de dominio definido en dominoapp.ecore contiene la estructura de datos permitida
para cada elemento de diseño definido.
A continuación se muestra como ejemplo la estructura de datos de la eclassdatabase del
modelo de dominio dominoapp.ecore.

Figura 52 Estructura de datos de la eclass database. Vista de clase

81

Figura 53 Estructura de la eclass database. Vista de árbol

<eClassifiers xsi:type="ecore:EClass" name="Database" eSuperTypes="#//Element">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="title"
eType="ecore:EDataType http://www.Eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="server"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="fileName"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="replication"
eType="ecore:EDataType http://www.Eclipse.org/emf/2002/Ecore#//EBooleanObject"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="indexed"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="allowStoredForms"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="maintainUnreadMarks"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="replicateUnreadMarks"
eType="#//WhoReplicate"
defaultValueLiteral=""/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="whenOpenedInBrowser"
eType="#//OpenDesignElement"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="description"
<eStructuralFeatures xsi:type="ecore:EAttribute" name="useJavaScript"
</eClassifiers>
Figura 54 Estructura de la eclass database. Vista XML
La lista completa de los atributos y sus tipos para todas las eclasses del dominio pueden
consultarse en el perfil de UML.

82

5.3.6. Arquitectura propuesta para ingeniería inversa

Figura 55 Diseño propuesto para el extractor de diseño
Para extender la herramienta DSM se propone la siguiente arquitectura para implementar
la funcionalidad de ingeniería inversa.
Esta funcionalidad permitirá extraer el diseño de una base de datos de aplicación Lotus
Domino existente.

Figura 56 Arquitectura propuesta para el extractor de diseño
Se propone que el extractor de diseño o de ingeniería inversa esté construido sobre la
plataforma de Lotus Notes encapsulado en una base de datos extractor.nsf. Este módulo
se compondrá de dos agentes:

83
• Agente de extracción de estructura. Este agente toma una aplicación Lotus Notes,
extrae su estructura y la almacena en una definición Domino XML en un archivo
*.dxl
• Agente de generación de diseño. Toma la definición DXL de la aplicación, la
transforma en la estructura del diagrama de diseño *.dominoapp y lo guarda en el
disco.

Uso de la herramienta
84

6. Capítulo: Uso de la herramienta
Se presenta el uso de la herramienta
desarrollada para el diseño de aplicaciones
Lotus Notes y la generación automática de
código a partir del diseño.

85
6.1. Proceso de uso
Como se mostró en el apartado de arquitectura, la herramienta DSM consta de dos
componentes: el modelador y el generador de aplicaciones.
El proceso inicia con la elaboración de un diagrama de diseño en la herramienta de
modelado visual. Esta herramienta está disponible desde el entorno de desarrollo de
Eclipse.
El siguiente es la importación del modelo diseñado, y por último la generación de la
aplicación modelada usando el generador de aplicaciones. Esta herramienta de
generación está disponible desde el entorno de Lotus Notes.
La base de datos generada contiene los elementos de diseño descritos en el diagrama o
modelo.

Figura 57 Proceso de uso de la herramienta

86
6.2. Uso del modelador
A continuación se describe con mayor detalle el uso de la herramienta de DSM.

Figura 58 DSM - Herramienta de modelado
El modelador está asociado a un tipo de proyecto de modelos de aplicaciones Lotus Notes
accesible desde el entorno de Eclipse.

87

Figura 59 Creación de un modelo de diseño de Lotus Notes/Domino
La estructura del modelo de diseño se encuentra en un archivo llamado*.dominoapp el
cual sigue las reglas definidas en el modelo de dominio.
La interfaz gráfica del modelo o diagrama se encuentra en el archivo
*.dominoapp_diagram.

Figura 60 Archivos de la estructura del modelo e interfaz gráfica

88
Una vez creado el proyecto de modelado, Eclipse nos presentará el área de trabajo junto
con las herramientas de diseño necesarias.

Figura 61 Barra de herramientas de modelado
Estas herramientas representan a los elementos de diseño de las aplicaciones Lotus
Notes y sus relaciones.
Para cada elemento de diseño empleado en el diagrama, se nos presenta un área de
propiedades para describir las características del elemento. Estas propiedades son
distintas para cada tipo de elemento y se encuentran definidas en el modelo de dominio.

89

Figura 62 Ventana de propiedades de los elementos
Con estas herramientas diseñaremos nuestra aplicación Lotus Notes.

Figura 63 Ejemplo de diagrama de diseño elaborado en el modelador
Como se mencionó con anterioridad, la estructura del modelo se almacena en un
documento XML con una estructura arbórea.

90

Figura 64 Estructura resultante del modelo
6.3. Uso del generador de código

Para generar la aplicación abriremos el componente generador el cual se ejecuta desde el
entorno Lotus Notes.
A partir de el archivo con la estructura del modelo *.dominoappse realizara la generación
de la aplicación modelada.

91

Figura 65 DSM - Generador de aplicaciones
Para ello ejecutaremos las acciones de transformación del diseño a DXL, importación del
modelo y generación de la aplicación.
Terminado este proceso obtendremos una base de datos *.nsf que contiene los elementos
de diseño modelados.

Pruebas
92

7. Capítulo: Pruebas
Se presenta el protocolo de pruebas utilizado
para la comprobación de la hipótesis planteada
en la tesis

Pruebas
93
Con el objeto de comprobar la hipótesis al inicio de este trabajo, se realizó un protocolo de
pruebas a un conjunto de desarrolladores de aplicaciones Lotus Notes.
En la prueba se buscó conocer el desempeño de la herramienta para la elaboración de
diagramas de diseño, generación automática de los elementos de diseño de una
aplicación Lotus Notes y evaluar su usabilidad.
Las pruebas están enfocadas en comprobar las variables de la hipótesis de: facilidad de
modelado y disminución de tiempo de desarrollo.
Los desarrolladores pertenecen a distintos grupos de trabajo por lo que su conocimiento
del diseño de aplicaciones, lenguajes de modelado y herramientas de modelado es
variable.
En las pruebas los participantes realizaron el mismo ejercicio de diseño con su modelador
habitual y la herramienta de DSM desarrollado en esta tesis.
El tamaño de la prueba se vio limitado por la dificultad para encontrar una mayor cantidad
desarrolladores de aplicaciones en la plataforma Lotus Notes. Estas limitaciones se
originan por la dispersión y cantidad de desarrolladores disponibles
7.1. Protocolo de pruebas
A continuación se muestran las pruebas realizadas.

Nombre del tester: ________________________________________ Fecha: ______
Objetivo de la prueba:
Conocer el desempeño de la herramienta en la elaboración de diagramas diseño,
generación de elementos de una aplicación y evaluar su usabilidad.
Perfil del tester
Pregunta Respuesta
¿Conoce algún lenguaje de modelado de propósito general como el
UML?

Pruebas
94
R: Si /No
¿Ha realizado diseños de aplicaciones?
R: Si /No

¿Actualmente elabora diseños para todo el software que codifica?
R: Nunca, Casi nunca, regularmente, la mayoría de las veces,
siempre

Ejercicios
Ejercicio 1 Creación de un diagrama de diseño para aplicaciones Lotus Notes, en la
herramienta DSM
Procedimiento Crear un diagrama de diseño que modele un catálogo de usuarios que
incluya:
• Una base de datos de la aplicación
• Una vista
• Una página para personalizar la interfaz de la vista
• Un formulario de captura
• Un agente de actualización
Tiempo
utilizado
________minutos

Ejercicio 2 Creación de un diagrama de diseño para aplicaciones Lotus Notes, en la
herramienta de modelado de su preferencia
Procedimiento Crear un diagrama de diseño que modele un catálogo de usuarios que
incluya:
• Una base de datos de la aplicación
• Una vista
• Una página para personalizar la interfaz de la vista
• Un formulario de captura
• Un agente de actualización
Tiempo
utilizado
________minutos

Usabilidad
Conteste las siguientes preguntas:
* Escala de evaluación usada: del 1 al 5 donde, 1 es la calificación más baja y 5 la más
alta.
Orientación al producto
Pregunta
¿Considera la funcionalidad de modelado de la herramienta es adecuada?
¿Considera la funcionalidad de generación de aplicaciones es adecuada?
¿Se pueden generar todos los elementos necesarios del diseño solicitado?
¿Operó sin fallas el producto al utilizarlo?

Pruebas
95
¿La interfaz es clara?
¿Los textos son legibles?
¿Se distinguen claramente los elementos gráficos del sistema?
Orientación al usuario
Pregunta
¿Los iconos representan correctamente las funciones?
¿Las herramientas son de fácil acceso?
¿El diagrama elaborado es de fácil entendimiento?
¿El proceso de generar la aplicación modelada es sencillo?
¿Consideras que la herramienta es fácil de usar?
Orientación al desempeño
Pregunta
¿La aplicación generada a partir del diseño corresponde al modelo elaborado?
¿Considera que el diagrama representa de manera consistente una aplicación
real?

¿Considera que puede crear la estructura de una aplicación real a partir del
modelo?

Orientación al contexto
Pregunta
¿Considera que esta herramienta le ayuda a realizar su trabajo?
¿Con esta herramienta mejoraría el diseño de sus aplicaciones Lotus Notes?

7.2. Interpretación de los resultados
Todos los participantes de la prueba dijeron conocer algún lenguaje de modelado de
propósito general y tener experiencia en el diseño de aplicaciones. A pesar de ello, en el
promedio casi nunca diseñan el software que codifican. Debido a esto es difícil garantizar
que una aplicación posea una buena arquitectura disminuyendo la calidad del software
resultante.
En cuanto a la operación de la herramienta de DSM elaborada en esta tesis, el tiempo
empleado para la elaboración del ejercicio de diseño fue de 5.6 minutos en promedio. Este
tiempo es menor a los 7.8 minutos empleados usando otras herramientas por los
participantes. Esto significa una disminución del 29% en el tiempo empleado para el
modelado. Cabe aclarar que para los diseñadores esta fue la primera vez que usaron el

Pruebas
96
DSM. Con estos resultados podemos inferir que el tiempo utilizado para diseñar con el
DSM disminuirá aún más con su uso.
El tiempo promedio necesario para generar la aplicación a partir del modelo fue
ligeramente superior a un minuto. Aunque en las pruebas no se midió el tiempo necesario
para generar los elementos de diseño modelados de manera manual, suponemos que el
tiempo utilizado será mayor al de la generación automática lo que apoyará la disminución
del tiempo utilizado en el desarrollo de una aplicación.
Las pruebas de usabilidad se evaluaron en cuatro orientaciones o sentidos: al producto, al
usuario, al desempeño y al contexto del dominio. La calificación global promedio de
usabilidad fue de 4.5.
En cuanto al producto la calificación promedio fue de 4.6 lo que indica en términos
generales que el DSM como producto estuvo entre bueno y excelente. En este rubro las
calificaciones más altas fueron para: la operación sin fallas de la herramienta lo que
demuestra su estabilidad en la ejecución, la calidad de la interfaz de usuario y la
generación de aplicaciones.
Desde la perspectiva del usuario la calificación promedio fue de 4.4 que representa en
términos generales una gran sencillez en su uso y fácil entendimiento. Destacan en este
rubro la representatividad semántica de los símbolos gráficos pertenecientes al lenguaje
de modelado y la sencillez al generar automáticamente los elementos de diseño de la
aplicación modelada.
En el desempeño la calificación obtenida fue de 4.6, lo que nos indica su gran ejecución
en situaciones reales. Destaca la correspondencia entre el diseño y la aplicación
resultante, siendo este el objetivo de la arquitectura conducida por modelos o MDA.
En términos del contexto del diseño de aplicaciones Lotus Notes, la calificación obtenida
fue de 4.6. Los ejecutantes de este protocolo consideran que el DSM les ayuda a realizar
su trabajo mejorando el diseño de sus aplicaciones.

Pruebas
97
Como podemos apreciar, los encuestados admitieron que casi nunca diseñaban las
aplicaciones que codificaban. Con la herramienta de DSM elaborada en esta tesis se
puede mejorar esta situación disminuyendo el tiempo de aprendizaje en lenguajes de
modelado de propósito general y herramientas de modelado.
A continuación se presentan los resultados condensados de las pruebas realizadas.
Reactivo U1 U2 U3 U4 U5 Promedio
Perfil del tester
Conoce algun lenguaje de modelado de
proposito general como el UML Si Si Si Si Si Si
Ha realizado diseños de aplicaciones Si Si SI Si Si Si
Actualmente elabora diseños para todo el SW
que codifica? 2 3 2 4 3 2.8
Operación de la herramienta
Tiempo de elaboración del diseño con el DSM
de la tesis 5 7 11 3 2 5.6
Tiempo en generar la aplicación a partir del
diseño 1 2 1 1 1 1.2
Tiempo de elaboración del diseño con otro
modelador 4 5 15 8 7 7.8
Modelador usado PowerPoint StarUML PowerPoint StarUML Paradigm
Usabilidad - Orientación al producto 5 4.6 4.3 4.3 4.9 4.6
Considera que la funcionalidad de la
herramienta es adecuada 5 4 4 4 5 4.4
Considera que la funcionalidad de generación
de aplicaciones es adecuada 5 5 4 5 5 4.8
Se pueden generar todos los elementos
necesarios en el diseño de prueba 5 5 4 3 5 4.4
Opera el modelador sin fallas 5 5 5 5 5 5.0
La interfaz es clara 5 4 4 5 4 4.4
Los textos son legibles 5 4 5 5 5 4.8
Se distinguen claramente los elementos
gráficos 5 5 4 3 5 4.4
Usabilidad - Orientación al usuario 5.0 4.4 3.8 4.0 4.6 4.4
Los iconos representan correctamente las
funciones 5 5 4 5 5 4.8
Las herramientas son de fácil acceso 5 4 4 3 5 4.2
El diagrama elaborado es de fácil de
entender 5 5 3 4 5 4.4
El proceso de generar la aplicación desde el
modelo es sencillo 5 5 4 4 4 4.4
Consideras que la herramienta es fácil de
usar 5 3 4 4 4 4.0
Usabilidad - Orientación al performance 5.0 5.0 3.7 4.3 5.0 4.6
La aplicación generada corresponde al
diagrama de diseño 5 5 4 5 5 4.8
Considera que el diagrama representa
consistentemente una aplicación real 5 5 3 4 5 4.4

Pruebas
98
Reactivo U1 U2 U3 U4 U5 Promedio
Considera que puede crear la estructura de
una app real a partir del modelo 5 5 4 4 5 4.6
Usabilidad - Orientación al contexto 5.0 4.5 3.5 5.0 5.0 4.6
Considera que esta herramienta le ayuda a
realizar su trabajo 5 4 4 5 5 4.6
Con esta herramienta mejoraria el diseño de
sus aplicaciones Lotus Notes 5 5 3 5 5 4.6
Usabilidad general 5.00 4.62 3.81 4.40 4.86 4.54
Tabla 4 Resultados de las pruebas

Conclusiones
99

Conclusiones
Se presentan las conclusiones del trabajo de
tesis, y los beneficios obtenidos

Conclusiones
100
Conclusiones

Como indican los resultados de este trabajo de tesis y con base en la hipótesis planteada
al inicio, se puede concluir que contar con una herramienta de modelado para aplicaciones
Lotus Notes / Domino facilita el modelado de las aplicaciones y disminuye el tiempo de
desarrollo al generar la estructura de la aplicación a partir de su diseño, por lo tanto la
hipótesis es cierta.
La herramienta facilita el modelado de las aplicaciones ya que implementa un lenguaje de
modelado visual propio del dominio de aplicaciones Lotus Notes / Domino. Como se pudo
comprobar en las pruebas de usabilidad, la calificación promedio obtenida para el
modelador fue de 4.5 de una escala de evaluación entre 1 y 5 lo que la ubica entre buena
y excelente por lo tanto queda comprobada la primera variable de la hipótesis.
La herramienta desarrollada en este trabajo de tesis permite generar la estructura de la
aplicación a partir de su diseño, ya que se pudieron generar automáticamente los
elementos de diseño representados en el modelo, tal y como se comprobó en los
resultados de las pruebas ejecutadas del ejercicio 1. En estas pruebas el tiempo utilizado
para el diseño de una aplicación con el modelador de esta tesis disminuyó en un 29% con
respecto a otras herramientas de modelado. Debido a lo anterior el tiempo de desarrollo
de una aplicación Lotus disminuye con el uso de la herramienta quedando comprobada la
segunda variable de la hipótesis.
El tiempo de codificación disminuirá aún más gracias a la generación automática de
código a partir de un diseño dado.
Como resultado del trabajo de investigación y desarrollo se cumple el objetivo general y
los objetivos específicos planteados al inicio de la tesis ya que:
• Se obtuvo una herramienta de modelado visual que permite diseñar aplicaciones
Lotus Notes y la generación de código de la aplicación correspondiente

Conclusiones
101
• En el desarrollo de la herramienta se utilizó un proceso formal de desarrollo de
software que contempla las actividades de análisis, diseño, desarrollo e
implementación
• Se revisaron las herramientas para generación de código a través del modelado
visual
• Se definió un lenguaje de modelado de dominio específico que permite modelar
aplicaciones Lotus Notes basado en la especificación de Perfiles de UML
• La herramienta desarrollada implementa el lenguaje de dominio específico para
aplicaciones Lotus Notes
• La herramienta de software desarrollada permite generar diagramas de
aplicaciones utilizando el lenguaje de dominio específico definido
• La herramienta desarrollada genera el código correspondiente a los elementos
de diseño de la aplicación a partir de un diagrama de diseño de dicha aplicación
Beneficios

Adicionalmente, este trabajo de tesis alcanzó los beneficios esperados de:
• Precisión y acercamiento entre el diseño y las aplicaciones reales, principios de la
Arquitectura Dirigida por Modelos
• Uniformidad en los diagramas de diseño
• Aprendizaje natural y rápido del lenguaje visual
La herramienta de modelado, generación de aplicaciones y el lenguaje visual de dominio
específico son de un alto grado de innovación en el dominio de desarrollo de aplicaciones
Lotus Notes, ya que hasta al momento no existe una solución similar en el mercado.
Con el uso de esta herramienta, los equipos de desarrollo pueden estandarizar el
modelado de aplicaciones. Adicional a ello, existen más posibilidades de mejorar la fase
de diseño y la calidad del software, ya que la fase de diseño es importante para detectar

Conclusiones
102
errores de las aplicaciones que pueden presentarse hasta la codificación o implantación
final.
Como beneficios adicionales tenemos que:
• Se ha adquirido conocimiento valioso para análisis y definición de modelos de
dominio para resolver problemas de diseño o modelado en otras disciplinas.
• Se ha obtenido capacidad para desarrollar herramientas visuales de modelado de
dominios y generación automática de código o aplicaciones.

Recomendaciones
103

Recomendaciones
Se presentan las recomendaciones surgidas de
este trabajo de tesis, los trabajos futuros y
áreas de oportunidad como resultado de la
experiencia obtenida

Recomendaciones
104
Recomendaciones de mejora
Es deseable aumentar el número de participantes involucrados en las pruebas. Debido a
la cantidad reducida de desarrolladores Lotus disponibles y a la carga de trabajo de los
mismos, se requiere un tiempo mayor para la ejecución de pruebas extensas que escapa
al alcance de este trabajo de tesis.
Es deseable el uso del modelador y el generador de aplicaciones en el desarrollo de un
proyecto de software de la vida real para evaluar su desempeño.
Trabajos futuros
La arquitectura de este trabajo es extensible lo que permitirá:
• Implementar la funcionalidad de ingeniería inversa. En esta tesis se propone la
arquitectura para esta solución
• Implementar patrones de diseño. Para reutilización de código y soluciones
probadas a problemas específicos, permitiendo explotar el conocimiento de los
desarrolladores y arquitectos de software
• Integrar la herramienta de modelado a nuevas versiones del IDE de desarrollo
Lotus Domino Designer. IBM ha apostado a la infraestructura de Eclipse como base
de sus herramientas de software
Áreas de oportunidad
Con el conocimiento generado en este trabajo de investigación y desarrollo, tenemos
como posibles implementaciones el modelado de:
• Sistemas empresariales
• Procesos de negocios
• Procesos de gestión del conocimiento
• Procesos de producción, químicos, automotrices, etc.
• Procesos de generación eléctrica
• Procesos de distribución

Recomendaciones
105
• Procesos de transformación

Bibliografía
106

Bibliografía
Se presentan las referencias bibliográficas
utilizadas para el desarrollo y sustento de la
tesis

Bibliografía
107
Referencias bibliográficas

References
Alves, A., Arkin, A., Askary, S., Barreto, C., Bloch, B., Curbera, F., et al. (2007). Web services
business process execution language version 2.0. OASIS Standard, 11
Booch, G., Rumbaugh, J., & Jacobson, I. (1999). The unified modeling language user guide
Addison-Wesley Reading Mass.
Bos, B., Lie, H. W., Lilley, C., & Jacobs, I. (1998). Cascading style sheets, level 2 CSS2
specification. W3C Recommendations are Available at Http://www.w3.org/TR, may, 12, 80.
Bottoni, P., Chang, S. K., Costabile, M. F., Levialdi, S., & Mussio, P. (2002). Modeling visual
interactive systems through dynamic visual languages. Systems, Man and Cybernetics, Part A,
IEEE Transactions on, 32(6), 654-669.
Budgen, D. (2003). Software design Addison Wesley.
Budinsky, F. (2003). Eclipse modeling framework Addison-Wesley Professional.
Chen, P. P. S. (1976). The entity-relationship model—toward a unified view of data. ACM
Transactions on Database Systems (TODS), 1(1), 9-36.
Cook, S., Jones, G., Kent, S., & Wills, A. (2007). Domain-specific development with visual studio
DSL tools.
Cuadrado, J. S., & Molina, J. G. (2007). Building domain-specific languages for model-driven
development. IEEE Software, , 48-55.
Date, C. J., & Darwen, H. (1993). The SQL standard. Addison-Wesley Publishing Company, 1993,
414, 0-201.
Deursen, A. v., Klint, P., & Visser, J. (2000). Domain-specific languages: An annotated
bibliography. SIGPLAN Not., 35(6), 26-36.
Ehrig, K., Ermel, C., Hänsgen, S., & Taentzer, G. (2005). Generation of visual editors as eclipse
plug-ins. Proceedings of the 20th IEEE/ACM International Conference on Automated Software
Engineering,

Bibliografía
108
Fowler, M., Scott, K., González V, J., & Morales Peake, D. (1999). UML gota a gota. Mexico:
Addison Wesley Longman de México.
Freeze, J. (2006). Creating DSLs with ruby.
Fuentes, L., & Vallecillo, A. (2004). Una introducción a los perfiles UML. Revista Novatica –
Asociación De Técnicos De Informática, 168
Gomez, P., & Sanchez, O. Herramientas de metamodelado: Microsoft DSL tools vs
MetaEdit+Universidad de Murcia.
IBM. (2005a). Application development with lotus domino designer
IBM. (2005b). Lotus domino designer programming guide, volume 4: XML, domino DTD, and JSP
tags IBM.
IBM. (2006). Rational unified process v7. USA:
Kelly, S. (2004). Tools for domain-specific modeling. Dr. Dobb’s Journal, September,
Kelly, S., & Tolvanen, J. P. (2000). Visual domain-specific modeling: Benefits and experiences of
using metaCASE tools. International Workshop on Model Engineering, ECOOP,
Kelly, S., & Tolvanen, J. P. (2008). Domain specific modeling. enabling full code generation
Ledeczi, A., Bakay, A., Maroti, M., Volgyesi, P., Nordstrom, G., Sprinkle, J., et al. (2001).
Composing domain-specific design environments. Computer, 34(11), 44-51.
Leroux, D., Nally, M., & Hussey, K. (2006). Rational software architect: A tool for domain-specific
modeling-author bios. IBM Systems Journal, 45
Luoma, J., Kelly, S., & Tolvanen, J. P. (2004). Defining domain-specific modeling languages:
Collected experiences. Proceedings of the 4th OOPSLA Workshop on Domain-Specific
Modeling (DSM04),
Mernik, M., & Sloane, A. M. (2005). When and how to develop domain-specific languages. ACM
Computing Surveys (CSUR), 37(4), 316-344.
Moore, B. (2004). Eclipse development using the graphical editing framework and the eclipse
modeling framework IBM, International Technical Support Organization.

Bibliografía
109
Mukerji, J., & Miller, J. (2003). MDA guide V1.0.1.
OMG. (2006). Object constraint language specification
OMG. (2007a). OMG unified modeling language (OMG UML), infrastructure, V2.1.2 Object
Management Group, Inc.
OMG. (2007b). In OMG (Ed.), OMG unified modeling language (OMG UML), superstructure,
V2.1.2
Parra, I. (2000). Modelado visual orientado a objetos. cenidet).
Partners, S. M. L. (2005). Systems modeling language (SysML) specification
Plaza, J. (2000). Lotus Notes Domino R5.x Desarrollo de aplicaciones.
Pressman, R. S. (2000). Software engineer: A Practionary’s approach (5th ed.) McGraw-Hill.
Rivera, G. (2008). Definición de un lenguaje de dominio específico para un entorno de desarrollo
rápido de aplicaciones. cenidet).
Rumbaugh, J., Jacobson, I., & Booch, G. (1998). The unified modeling language reference manual
Addison-Wesley Longman Ltd. Essex, UK, UK.
Steven, P., & Pooley, R. (2007). Utilización de UML en ingeniería del software con objetos y
componentes. Madrid: Addison Wesley.
Wikipedia. (2007a). Domain-specific programming language.http://en.wikipedia.org/wiki/Domain-
specific_programming_language
Wikipedia. (2007b). Visual programming
language.http://en.wikipedia.org/wiki/Visual_programming_language

Anexo: Perfil para aplicaciones Lotus Notes
110

Anexo
En el anexo se encuentra la especificación del
Lenguaje de Modelado de Dominio Específico
para aplicaciones Lotus Notes utilizando el
estándar de perfiles de UML

111
Perfil UML para aplicaciones Lotus Notes
Introducción
El lenguaje de modelado UML (del inglés, Unified Modeling Process) es el estándar más
utilizado para especificar y documentar cualquier sistema de forma precisa,
proporcionando flexibilidad y expresividad a la hora de modelar sistemas. Sin embargo, el
hecho de que UML sea una notación de propósito muy general obliga a que muchas veces
sea deseable poder contar con algún lenguaje más específico para modelar y representar
los conceptos de ciertos dominios particulares. Esto sucede, por ejemplo, cuando la
sintaxis o la semántica de UML no permiten expresar los conceptos específicos de un
dominio, o cuando se desea restringir y especializar los constructores propios de UML,
que suelen ser demasiado genéricos y numerosos. Los Perfiles UML [1, 2] constituyen el
mecanismo que proporciona el propio UML para extender su sintaxis y semántica para
expresar los conceptos específicos de un determinado dominio de aplicación.
OMG (Por sus siglas en inglés: Object Management Group) define dos posibilidades a la
hora de definir lenguajes específicos de dominio y que se corresponden con las dos
situaciones mencionadas anteriormente: Definir un nuevo lenguaje (alternativa de UML), o
bien extender el propio UML, especializando algunos de sus conceptos y restringiendo
otros, pero respetando la semántica original de los elementos de UML (clases,
asociaciones, atributos, operaciones, transiciones, etc.) utilizando una serie de
mecanismos recogidos llamados Perfiles UML.
Cada una de estas alternativas presenta ventajas e inconvenientes. Definir un nuevo
lenguaje ad hoc permite mayor grado de expresividad y correspondencia con los
conceptos del dominio de aplicación particular, al igual que cuando nos hacemos un trajea
la medida. Sin embargo, el hecho de no respetar el metamodelo estándar de UML impide
que las herramientas UML existentes en el mercado puedan manejar sus conceptos de
una forma natural. En general, resulta difícil decidir cuándo debemos crear un nuevo
metamodelo, y cuándo en cambio es mejor definir una extensión de UML usando los
mecanismos de extensión estándares definidos con ese propósito.

112
En este trabajo se ha elegido la opción de extender UML utilizado los mecanismos de
extensión del mismo, los Perfiles UML. Un Perfil se define en un paquete UML
estereotipado «profile», que extiende a un metamodelo o a otro Perfil. Tres son los
mecanismos que se utilizan para definir Perfiles: estereotipos (stereotypes), restricciones
(constraints), y valores etiquetados (taggedvalues). El metamodelo realizado para LDD no
se explica en su totalidad en este documento, pero el Perfil realizado contiene una
descripción de todas las restricciones, entidades y relaciones que el lenguaje utiliza para
modelar conceptualmente la estructura de una aplicación Web.
Panorama general
La siguiente especificación del Perfil se basa en una selección de los elementos de diseño
que conforman al entorno de desarrollo Lotus Domino Designer. Esta selección se llevó a
cabo a través de un proceso de análisis del entorno, en donde se seleccionaron un
conjunto de elementos que se utilizan continuamente en el desarrollo de aplicaciones
Web. El análisis también consistió en la búsqueda de atributos importantes y de las
relaciones existentes entre los elementos. Un conjunto de restricciones fueron definidas de
acuerdo a la usabilidad y a los atributos de cada entidad.
Como resultado del análisis se obtuvo un metamodelo que describe a las entidades,
relaciones y restricciones entre los elementos seleccionados para el desarrollo de
aplicaciones Web. El metamodelo resultante fue traducido a una notación UML,
especializando los conceptos como clases a estereotipos con sus respectivos nombres y
atributos.
Meta
El Perfil UML de Lotus Domino Designer fue diseñado para proveer a los analistas de
sistemas una manera estándar para expresar la estructura de las aplicaciones Web en la
fase de diseño conceptual. Esto significa que no se está modelando la estructura de
código fuente (clases, herencia, polimorfismo), sino que LDD utiliza una base de datos
documental donde no se utilizan registros organizados por renglones y columnas. Por el
contrario, LDD almacena documentos (información y estructura de diseño) con una
estructura basada en los elementos de diseño y en la misma información que se introduce

113
a través de estos elementos. Por esta razón no podemos modelar una aplicación por
medio de su código fuente, sino por la estructura que compone a un documento, el cual es
la unidad básica para almacenar información.
Un ejemplo de lo anterior sería: la base para crear documentos es un elemento form, en
éste se introducen otras entidades como tables, fields, view, entre otros. Estos elementos
permiten tener una estructura de la aplicación para introducir información a la base de
datos en forma de un documento. Por lo tanto, el form tiene dos funciones: 1) introducir
información a través de sus elementos de diseño y almacenarla en forma de un
documento;; y 2) el form es utilizado para mostrar la información del documento
almacenado, pues es este formquien tiene la estructura necesaria para mostrar dicha
información. Por esta razón es que el Perfil UML para Lotus Domino Designer se centra en
modelar la estructura de una aplicación enfocada en el almacenamiento de documentos.
Alcance
El Perfil UML de Lotus Domino Designer para aplicaciones Web descrito en esta
especificación permite el diseño conceptual de la estructura de aplicaciones basadas en
bases de datos documentales. Un ejemplo de la estructura de un documento se da a
través del form. compuesto de dos elementos de tipo field y una entidad de tipo table, en la
cual se aprecian tres entidades más de tipo field con sus respectivas etiquetas.

114

Figura 66 Diseño de un formulario
En la actualidad, no es posible expresar a través de un lenguaje de modelado la estructura
que tienen las aplicaciones desarrolladas en el entorno de desarrollo Lotus Domino
Designer. La mayoría de los lenguajes modelan código fuente orientados a objetos. Lotus
Domino Designer no es un entorno tradicional de este tipo.
Para modelar una aplicación Domino, se utiliza toda la semántica que ofrece UML. Un
ejemplo es la instanciación de objetos, que permite tener diferentes instancias con sus
propios atributos. Otro ejemplo es la forma de relacionar entidades a través de relaciones
bien definidas. A continuación se presenta un form modelado con el Perfil UML que se
especifica en este documento.

115

Figura 67 Diagrama de clase para un elemento form
El modelo de clases mapea a través de este diagrama la estructura de un documento
creado con el elemento form y sus componentes inmersos en éste. Al mismo tiempo se
modela la estructura de la aplicación. De esta manera pueden utilizarse todos los
elementos, relaciones y restricciones especificadas en el Perfil para describir modelos de
aplicaciones de LDD. Está permitido a los modeladores utilizar otras relaciones de UML no
especificadas en el Perfil, de esta manera se utiliza toda la semántica y el poder de UML
con los nuevos conceptos extendidos.
Perfiles UML
Para el caso en el que no queramos modificar la semántica de UML, sino sólo
particularizar algunos de sus conceptos, no necesitamos definir un nuevo lenguaje

116
utilizando el MOF. UML incluye un mecanismo de extensión en el propio lenguaje que
permite definir lenguajes de modelado que son derivados de UML. De forma más precisa,
el paquete Profilesde UML 2.1.2 define una serie de mecanismos para extender y adaptar
las metaclases de un metamodelo cualquiera (y no sólo el de UML) a las necesidades
concretas de una plataforma (como puede ser .NET, J2EE o Domino) o de un dominio de
aplicación (tiempo real, modelado de procesos de negocio, etc.).
UML 2.1.2señala varias razones por las que un diseñador puede querer extender y
adaptar un metamodelo existente, sea el del propio UML, el de CWM, o incluso el de otro
Perfil:
• Disponer de una terminología y vocabulario propio de un dominio de aplicación o de
una plataforma de implementación concreta (por ejemplo, poder manejar dentro del
modelo del sistema terminología propia de LDD como formularios o vistas con su
semántica y propiedades asociadas).
• Definir una sintaxis para construcciones que no cuentan con una notación propia.
• Definir una nueva notación para símbolos ya existentes, más acorde con el dominio
de la aplicación objetivo (poder usar, por ejemplo, una figura con un ordenador en
lugar del símbolo para representar un nodo que por defecto ofrece UML para
representar ordenadores en una red).
• Añadir cierta semántica que no existe en el metamodelo (por ejemplo, incorporación
de tipos de relaciones entre los elementos de Domino que son inexistentes en
UML).
• Añadir restricciones a las existentes en el metamodelo, restringiendo su forma de
utilización (por ejemplo, impidiendo que ciertos elementos puedan relacionarse con
otros de acuerdo a las propiedades seleccionadas de cierto elemento).
• Añadir información que puede ser útil a la hora de transformar el modelo a otros
modelos, o a código.
Un Perfil se define en un paquete UML, estereotipado «profile», que extiende a un
metamodelo o a otro Perfil. Tres son los mecanismos que se utilizan para definir Perfiles:

117
estereotipos (stereotypes), restricciones (constraints) y valores etiquetados (tagged
values).
En primer lugar, un estereotipo viene definido por un nombre, y por una serie de
elementos del metamodelo sobre los que puede asociarse. Gráficamente, los estereotipos
se definen dentro de cajas, estereotipadas «stereotype». A los estereotipos es posible
asociarles restricciones, que imponen condiciones sobre los elementos del metamodelo
que han sido estereotipados. De esta forma pueden describirse, entre otras, las
condiciones que ha de verificar un modelo “bien formado” de un sistema en un dominio de
aplicación.
Finalmente, un valor etiquetado es un meta-atributo adicional que se asocia a una
metaclase del metamodelo extendido por un Perfil. Todo valor etiquetado ha de contar con
un nombre y un tipo, y se asocia un determinado estereotipo. Los valores etiquetados se
representan de forma gráfica como atributos de la clase que define el estereotipo.
Elaboración de Perfiles UML
En esta sección se describe un posible método de elaboración de Perfiles UML. La
especificación de UML 2.1.2 sólo se limita a definir el concepto de Perfil y sus contenidos.
Sin embargo, se propone una serie de pasos que permiten contar con ciertas guías y
recomendaciones que sirven de ayuda a la hora de definir un Perfil UML para una
plataforma o dominio de aplicación concreto. En este caso queremos definir un Perfil UML
para desarrollar aplicaciones Lotus Notes a través del entorno de desarrollo LDD.A la hora
de definir un Perfil UML, Lidia Fuentes propone seguir los siguientes pasos:(Fuentes &
Vallecillo, 2004)
1. Antes de comenzar, es preciso disponer de la correspondiente definición del
metamodelo de la plataforma o dominio de aplicación a modelar con un Perfil. Si no
existiese, entonces definiríamos dicho metamodelo utilizando los mecanismos del
propio UML (clases, relaciones de herencia, asociaciones, etc.), de la forma usual
como lo haríamos si nuestro objetivo no fuese definir un perfil UML. Deberemos

118
incluir la definición de las entidades propias del dominio, las relaciones entre ellas,
así como las restricciones que limitan el uso de estas entidades y de sus relaciones.
2. Si ya disponemos del metamodelo del dominio, pasaremos a definir el Perfil. Dentro
del paquete «profile» incluiremos un estereotipo por cada uno de los elementos del
metamodelo que deseamos incluir en el Perfil. Estos estereotipos tendrán el mismo
nombre que los elementos del metamodelo, estableciéndose de esta forma una
relación entre el metamodelo y el Perfil. En principio cualquier elemento que
hubiésemos necesitado para definir el metamodelo puede ser etiquetado
posteriormente con un estereotipo.
3. Es importante tener claro cuáles son los elementos del metamodelo de UML que
estamos extendiendo sobre los que es posible aplicar un estereotipo. Ejemplo de
tales elementos son las clases, sus asociaciones, sus atributos, las operaciones, las
transiciones, los paquetes, etc. De esta forma cada estereotipo se aplicará a la
metaclase de UML que se utilizó en el metamodelo del dominio para definir un
concepto o una relación.
4. Definir como valores etiquetados de los elementos del Perfil los atributos que
aparezcan en el metamodelo. Incluir la definición de sus tipos, y sus posibles
valores iníciales.
5. Definir las restricciones que forman parte del Perfil, a partir de las restricciones del
dominio. Por ejemplo, las multiplicidades de las asociaciones que aparecen en el
metamodelo del dominio, o las propias reglas de negocio de la aplicación deben
traducirse en la definición de las correspondientes restricciones.
En la siguiente sección se abordará el desarrollo del perfil UML para el entorno de
desarrollo LDD de acuerdo a la metodología propuesta por Lidia Fuentes. Se partirá del
hecho de que se cuenta con el metamodelo, restricciones y semántica de cada elemento
de este entorno.
Desarrollo del Perfil UML para Lotus Domino Designer
Para desarrollar el Perfil para LDD se seguirá el método propuesto en la sección 0 por
Lidia Fuentes. El punto uno de este método precisa que hay que disponer de una
correspondiente definición del metamodelo del dominio que se quiere modelar. En la

119
siguiente subsección se describe de manera general el metamodelo de LDD para el
desarrollo de aplicaciones Web.
Metamodelo de Lotus Domino Designer
Para el caso del entorno de desarrollo LDD ya se cuenta con la correspondiente definición
del metamodelo. Éste se compone de un conjunto de elementos con sus propiedades,
relaciones y restricciones. En la figura siguiente se muestra a los elementos sin su
conjunto de propiedades, esto se debe a que cada uno tiene varias propiedades que
harían que el metamodelo fuese muy grande. Algunas relaciones que aparecen no son
propias de UML, pero aparecen con su respectiva multiplicidad.
No se describirá en esta sección el conjunto de entidades, restricciones y propiedades
debido a que no es el propósito describirlas como lo marca el método sino que se detallan
en las siguientes secciones donde se desarrolla el Perfil.

Figura 68 Metamodelo de Lotus Domino Designer

120
Definición del perfil
El punto dos de la sección 0 menciona que para definir un Perfil se debe crear un
estereotipo dentro del paquete «profile» de UML. Cada estereotipo debe concordar con
algún elemento definido en el metamodelo, estableciéndose así una relación uno a uno
entre el metamodelo y el Perfil. Los estereotipos deben tener el mismo nombre que los
elementos del metamodelo.
La siguiente tabla resume los estereotipos definidos para este Perfil, éstos concuerdan con
cada elemento definido en el metamodelo. Los elementos del metamodelo coinciden al
mismo tiempo con cada elemento de diseño de LDD. En la tabla no se indica la semántica,
las propiedades ni las restricciones que aplican a cada estereotipo. En las siguientes
secciones se describirá con detalle la semántica y componentes de cada uno.
Nombre del
elemento
Nombre
del Estereotipo
Meta-clase
base en
UML
Descripción IMG
Data Base <<dataBase>> Class
Representa a la base de datos que
contiene a todos los elementos para
construir aplicaciones en LDD.

Frameset <<frameset>> Class
Representa a un elemento Frameset en
LDD que permite estructurar páginas
Web.

Frame <<frame>> Class
Representa a una sección de un
elemento Frameset.
Web Service <<webservice>> Class
Representa a un Servicio Web
(aplicación autónoma) que puede
invocarse o publicarse en el Web.

Form <<form>> Class
Representa un formulario que permite
mostrar e ingresar información a la BD.
Subform <<subform>> Class
Representa a un subformulario
agrupador de elementos y de cierta
funcionalidad que puede compartirse
entre formularios.

121
Field <<field>> Class
Representa a un campo que recolecta
datos de algún tipo.
Page <<Page>> Class
Representa al elemento Page de LDD
que se utiliza para presentar información
de la BD.

Action Bar <<actionBar>> Class
Representa a una barra de botones.
Cada botón es un contenedor de
acciones programadas.

Action <<action>> Class
Representa código fuente en algún tipo
de lenguaje soportado por LDD. Provee
métodos de rápido acceso a tareas
rutinarias.

Agent <<agent>> Class
Representa código fuente en algún tipo
de lenguaje soportado por LDD. Permiten
automatizar tareas rutinarias.

ScriptLibrary <<scriptlibrary>> Class
Representa a una librería codificada en
algún lenguaje soportado por LDD. Estas
pueden compartirse entre diversos
elementos.

File <<file>> Component
Representa a un archivo importado en la
BD para utilizarse de manera compartida
en el diseño de aplicaciones.

Style Sheet <<stylesheet>> Component
Representa una hoja de estilo importada
a la BD que permite tener mejor control
sobre muchos aspectos en el diseño de
páginas Web.

Outline <<outline>> Class
Representan a un elemento Outline en
LDD. Provee una forma de navegar en
una aplicación a los usuarios.

Outline Entry <<outlineEntry>> Class
Representa un elemento de la estructura
de navegación de un Outline. Puede ser
una liga o acción que invoque un
componente, incluso otra aplicación o
BD.

Image <<image>> Component
Representa a una imagen importada a la
BD.

122
Applet <<applet>> Component
Representa un Applet de Java importado
a la BD.
Computer
Text
<<computertext>
>
Class
Representa un campo calculado donde
su valor está determinado por una
fórmula que el desarrollador programa.

Table <<table>> Class
Representa una tabla de texto
enriquecido que permite agrupar y
acomodar información mostrada a través
de otros elementos.

Section <<section>> Class
Es una área que puede expandirse o
colapsarse para mostrar u ocultar
elementos contenidos en esa área.

Navigator <<navigator>> Class
Representa una interfaz que permite a
los usuarios acceder a otros elementos o
datos de una BD.

View <<view>> Class
Representa a una vista en LDD. Es una
lista de documentos de una BD que
pueden seleccionarse de acuerdo a un
criterio de selección.

Folder <<folder>> Class
Tienen la misma funcionalidad que un
elementoView. La diferencia radica en
que aquí no existe un criterio de
selección de documentos.

Column <<column>> Class
Muestran un tipo de información acerca
de los documentos listadosen un View o
Folder. Son un componente estructural
de los mismos.

Button <<button>> Class
Representa un botón em que puede
hacerse clic y ejecutar una acción
codificada

Hotspot <<hotspot>> Class
Representa texto o una imagen en un
campo de texto enriquecido donde puede
hacerse clic para llevar a cabo una
acción, correr una formular, script o
invocar una liga.

123
Tabla 5 Estereotipos definidos para Lotus Domino Designer

Metamodelo Virtual (MV)
El Metamodelo Virtual (MV) es un modelo formal de un conjunto de extensiones de UML
expresadas en notación UML. El MV para el perfil UML de Lotus Domino Designer se
presenta en esta sección como un conjunto de clases que concuerdan con el metamodelo
mostrado anteriormente.
Cada uno de los elementos que conforman el metamodelo tienen alguna de las siguientes
categorías: contenedores principales (principal containers), contenedores secundarios
(secondary containers) o no contenedores (no containeres). Esta clasificación se utiliza
para saber si cierto elemento puede ser relacionado con otro a través de alguna de las
relaciones definidas posteriormente en el Perfil.

Containment <<contention>> Aggregation
Representa un tipo de relación más
fuerte que la asociación pero más débil
que la agregación en UML.

Reflexive
Containment
<<ReflexiveConte
ntion>>
Aggregation
Relación similar a la “<<contention>>”, se
diferencia en que sólo se utiliza para
relacionar elementos del mismo tipo.
R

124

Los principales contenedores que aparecen en el diagrama de paquete principalcontainers
en la son elementos que pueden ejecutarse en una aplicación sin necesidad de estar
contenidos en otros elementos. En la figura falta el elemento agent, este elemento también
puede existir sin la necesidad de estar contenido en otro elemento, pero al no ser un
contenedor, no puede entrar en esta clasificación. En esta figura también aparecen los
elementos contenedores de segunda importancia. Se les ha denominado así debido a que
no pueden ejecutarse en una aplicación sin estar sobre un elemento contenedor principal.
Figura 69 Clasificación de los estereotipos de LDD

125
Por último aparecen los elementos que no son contendores, éstos sólo pueden estar
contenidos tanto en contenedores principales como secundarios.
Para definir el metamodelo de LDD se tomaron los elementos definidos durante el análisis
del entorno de desarrollo, así como las relaciones encontradas para cada elemento en
términos de usabilidad. El metamodelo no muestra a todos los elementos que LDD tiene
para el diseño de sistemas, sino a los más comunes y usables en la construcción de
aplicaciones Web. Las relaciones son las que se dan de manera natural al diseñar la
estructura de una aplicación Domino. Cabe mencionar que existen relaciones que no se
dan de manera natural porque el desarrollador necesita realizar alguna artimaña para
poder empotrar un elemento sobre otro o poder realizar alguna función específica con
algún elemento.
Como cabecera del metamodelo se muestra al estereotipo Database. Éste indica que
todos los objetos son elementos de diseño de LDD y que todos los elementos están
incluidos en la base de datos. Ésta es un elemento que colecciona información
relacionada y se almacena en un solo archivo con extensión NSF. Una base de datos en
Lotus Notes/Domino no utiliza la misma semántica que una base de datos relacional.
En una base de datos de Lotus Notes/Domino se almacena información acerca del diseño
de la aplicación en forma de datos estructurados (información sobre el diseño de la
aplicación), código y la propia información que se introduce desde el mundo exterior. Esta
información o datos que introduce el usuario en una aplicación se organiza en forma de
documentos. Un documento se define como un objeto que contiene texto, gráficos, video,
objetos de audio o cualquier tipo de dato de texto enriquecido. Los documentos se crean a
través de los elementos de diseño que LDD ofrece. Por ejemplo, comúnmente a través de
forms. Por otra parte una base de datos relacional no utiliza la misma semántica, sino que
necesita de campos y registros para almacenar la información.
Otra característica importante es que la mayoría de las aplicaciones que se hacen en el
desarrollo tradicional pueden existir sin la necesidad de una base de datos, mientras que
en LDD es necesario primero crear la base de datos donde se almacenara la estructura de

126
la aplicación y los datos. Por lo tanto una aplicación de LDD y sus elementos no pueden
existir sin una base de datos y esta es la razón por la cual el elemento base de datos
encabeza el diseño del metamodelo.
Los elementos pueden clasificarse de tres formas como se mencionó anteriormente:
principales contenedores, contenedores secundarios y no contenedores. Los principales
contenedores pueden contener a la mayoría de los elementos. Entre los más importantes
para introducir información a la base de datos se encuentran los forms. En el metamodelo
se muestra que un form y su especialización subform pueden contener a la gran mayoría
de los elementos, por ejemplo pueden contener fields, sections, navigators, entre otros.
Los views son el principal elemento que permite mostrar información contenida en la base
de datos. También se puede mostrar información en un page o en un frameset.
El MV representa entonces a los elementos analizados y obtenidos como resultado del
análisis del entorno RAD Lotus Domino Designer. También representa las relaciones más
comunes entre los elementos que utiliza LDD. Este metamodelo la transición entre el
metamodelo de la figura 68 y el metamodelo definido en UML. Éste muestra a los
elementos, relaciones y permite especificar nuevos modelos. Las relaciones definidas
posteriormente en el Perfil permiten ver la usabilidad entre elementos. Por ejemplo, un
elemento view debe contener al menos a un elemento column;; un navigator puede
contener a un elemento hotspot, entre otros. Este tipo de relaciones son las que se
muestran a través del metamodelo, además también se pueden observar propiedades
como la multiplicidad.

127

Figura 70 Metamodelo de Lotus
Representación de los estereotipos
El MV representa un estereotipo como una clase estereotipada «stereotype». Por ejemplo,
una clase estereotipada «Form» representa a un elemento cuyo proveedor es el elemento

128
Class, el cual pertenece al metamodelo de UML que está siendo extendido. Los
estereotipos que se definieron de acuerdo a los elementos de LDD son extensiones de las
metaclases Class, Component y Aggregation.

Figura 71 Extendiendo al metaelemento Class
En la imagen anterior se muestran los estereotipos que especializan y extienden a la
metaclase Class. Las clases con la leyenda «enumeration» corresponden a opciones de
alguna propiedad específica de un estereotipo. Por ejemplo, la clase VersioningForm
corresponde a las opciones posibles para la propiedad Versioning del estereotipo Form.

129

La imagen muestra a los estereotipos page, subform, frameset y frame extendiendo a la
metaclase Class. También se muestran sus valores etiquetados (atributos del estereotipo)
y algunas clases de tipo «enumeration» correspondientes a propiedades de los
estereotipos.
Figura 72 Continuación de la extensión del metaelemento Class

130

La figura anterior muestra a los estereotipos fieldy action extendiendo a la metaclase
Class. También se muestran sus valores etiquetados (atributos del estereotipo) y algunas
clases de tipo «enumeration» correspondientes a propiedades de los estereotipos.


131

En esta imagen se muestra a los estereotipos view y folder extendiendo a la metaclase
Class. También se muestran sus valores etiquetados (atributos del estereotipo) y algunas
clases de tipo «enumeration» correspondientes a propiedades de los estereotipos.


132
La siguiente imagen muestra a los estereotipos file, image, applety stylesheet extendiendo
a la metaclase Component. También se muestran sus valores etiquetados (atributos del
estereotipo) y algunas clases de tipo «enumeration» correspondientes a propiedades de
los estereotipos.


133

La imagen muestra a los estereotipos outline, computertext, outlineEntryy hotspot
extendiendo a la metaclase Class. También se muestran sus valores etiquetados
(atributos del estereotipo) y algunas clases de tipo «enumeration» correspondientes a
propiedades de los estereotipos.


134

La figura muestra a los estereotipos agent y button extendiendo a la metaclase Class.
También se muestran sus valores etiquetados (atributos del estereotipo) y algunas clases
de tipo «enumeration» correspondientes a propiedades de los estereotipos.


135

La imagen muestra a los estereotipos scriptlibrary, section, actionbar, table y webservice
extendiendo a la metaclase Class. También se muestran sus valores etiquetados
(atributos del estereotipo) y algunas clases de tipo «enumeration» correspondientes a
propiedades de los estereotipos.

136

Esta imagen muestra a los estereotipos contention y reflexivecontention extendiendo a la
metaclase Aggregation.
Descripción de cada estereotipo
En esta sección se describirá con detalle cada uno de los estereotipos introducidos en el
metamodelo virtual, así como sus valores etiquetados (atributos) y restricciones.

Estereotipo «Database»
Descripción
Es la base para crear aplicaciones en LDD y para todos los estereotipos. Sin la
creación de éste no puede utilizarse ningún otro estereotipo. Representa a la base
de datos que contiene a todos los elementos para construir aplicaciones en LDD.

Metaclase UML extendida
Class

Elementos Relacionados

Elementos que puede contener
Puede contener a cualquier elemento de la BD. Los principales estereotipos
que pueden relacionarse a éste son: forms, views, pages, agent y frameset.

Elementos que pueden contenerlo
Figura 79 Extendiendo al metaelemento Aggregation

137
Ningún estereotipo puede hacer uso de éste para relacionarlo como
elemento que puede estar contenido en otro. La única excepción es asociar
dos elementos de éste mismo tipo.

Valores Etiquetados

Title: string
Valor string que representa el título de la BD que aparece en la barra
de bookmarks en LDD. Este título puede cambiar en la barra, pero el
nombre inicial con el que se guarda la BD permanece y no cambiará si
cambiamos su título.

Server: string
Valor string que representa el nombre del servidor donde se aloja la
BD.

FileName: string
Valor string que representa el nombre permanente que mantendrá la
BD. Este nombre no cambiará si la propiedad Title cambia.

Replication: boolean = false
Valor booleano que permite organizar BD distribuidas y consistentes.

Indexed: Boolean = false
Valor booleano que permite tener capacidades de búsqueda textual.

UseJavaScript: boolean = true
Valor booleano que permite definir si la BD tendrá la capacidad de
ejecutar JavaScript.

AllowStoredForms: boolean = true
Valor booleano que permite que se almacene un formulario junto con
el documento. Esto se utiliza para asegurar que un documento se
despliega correctamente.

MaintainUnreadMarks: boolean=false
Valor booleano que permite identificar documentos no leídos.

ReplicateUnreadMarks:WhoReplicate = Never
Propiedad que permite tener la capacidad de replicar los
identificadores de lectura de documentos. Los valores posibles para
esta propiedad son:

Never

138
Opción que permite que nunca haya replicación.

ClusteredServersOnly
Opción que permite que haya replicación sólo en servidores
redundantes.
AllServers
Opción que permite que haya replicación en todos los
servidores.

WhenOpenedInBrowser: OpenDesignElement = UseNoteLaunchOption
Propiedad que permite especificar el elemento que se abrirá al iniciar
una aplicación. Las opciones para esta propiedad son:

UseNotesLaunchOption
Opción que permite lanzar las opciones definidas en Lotus
Notes.

OpenAboutDatabaseDocument
Opción que permite abrir el documentoacerca de.

OpenDesignatedFrameset: string
Valor string que permite especificar el framesetque se lanzará al
momento de abrir la BD.

OpenDesignatedPage: string
Valor string que permite especificar el pageque se lanzará al
momento de abrir la BD.

OpenDesignatedNavigator: string
Valor string que permite especificar el navigatorque se lanzará
al momento de abrir la BD.

Description: string
Valor string que se utiliza para proporcionar una descripción general
de la función que desempeña este estereotipo.

Restricciones
• La propiedad ReplicateUnreadMarks sólo puede utilizarse en el caso de que
el valor de MaintainUnreadMarks sea true.

Notación
Estereotipo «Form»

139

Descripción
Representa a un form y es uno de los estereotipos más importantes para el diseño
de aplicaciones debido a que es la base para introducir información en una base de
datos.

Class

Relaciones

Este estereotipo puede relacionarse directamente y contener a los siguientes
estereotipos: table, section, actionbar, view, agent, folder, computertext, file,
outline, subform, stylesheet, field, scriptlibrary, images, applet, navigator,
hotspot y button.

Este estereotipo puede estar relacionado y contenido en los siguientes
estereotipos: database y frame.

Valores Etiquetados

Name: String
Valor string que representa el nombre del formulario.

Comment: String
Valor string que representa un comentario que puede hacerse sobre el
formulario.

Type: TypeForm= Document
Propiedad que permite definir una jerarquía documental. Propiedad en
la que sólo pueden elegirse los siguientes valores:

Document
Opción que permite que los documentos sean de tipo normal.

Response
Opción que permite asignarle como padre a un documento otro
documento de tipo Document.

ResponseToResponse
Opción que permite asignarle como padre a un documento otro
documento de tipo Response.

Versioning: VersioningForm = None

140
Propiedad que permite asignar la capacidad para guardar el historial
de cambios de los documentos. Propiedad en la que sólo pueden
elegirse los siguientes valores:

None
No se habilita el mecanismo de versioning.

NewVersionsBecomeResponse
Permite que las nuevas versiones de documentos se conviertan
en documentos tipo Response.

PriorVersionsBecomeResponse
Permite que las versiones previas de documentos se conviertan
en documentos tipo Response.

NewVersionsBecomeSiblings
Permite que las nuevas versiones de documentos adquieran el
mismo documento padre.

CreateVersions: CreateVersionOptions = Automatic-File,Save
Permite que la propiedad versioning maneje el guardado de
documentos de manera automática o manual. Esta propiedad admite
las siguientes opciones:

Manual- File,NewVersion
Opción que permite al usuario elegir cuando crear nuevas
versiones de los documentos o sólo sobrescribir la versión
actual.

Automatic-File,Save
Opción que permite crear automáticamente una nueva versión
de un documento cada vez que se guarde el mismo.

DefaultDatabaseForm: boolean = false
Permite especificar que el documento actual se abrirá por defecto al
iniciar una aplicación.

AutomaticallyRefreshFields: boolean = false
Valor booleano utilizado para actualizar el resultado de un campo cada
vez que este cambie de valor. Los campos se actualizarán
automáticamente cuando el valor de esta propiedad sea true.

AnonymousForm: boolean = false
Valor booleano que permite ocultar el nombre del autor de un
formulario. El nombre del autor se ocultara si el valor de esta
propiedad es true.

141

ConflictHandling: ConflictHandlingOption = CreateConflict
Permite especificar la capacidad para manejar la concurrencia de
usuarios sobre un documento. Propiedad en la que sólo pueden
elegirse los siguientes valores:

CreateConflict
Permite crear un documento conflicto.

MergeConflict
Permite combinar los documentos modificados al mismo tiempo
como un solo documento conflicto.

Merge/NoConflict
Permite combinar los documentos modificados sin conflicto.

DoNotCreateConflict
Permite no crear documentos conflictos.

FormulasInheritValuesFromSelectedDocument: boolean = false
Permite heredar valores basados en un documento original al crear
nuevos documentos.

InheritEntireSelectedDocumentIntoRichTextField: Boolean = false
Permite heredar todo el documento en un campo de texto enriquecido.

AutomaticallyEnableEditMode: boolean = flase
Valor booleano que permite que los documentos creados en un
formulario se abran en modo edición automáticamente. Para que esto
suceda dejar su valor como true.

ContentType: ContentTypeOptions = Notes
Propiedad que permite especificar si este elemento tendrá sólo código
HTML o si será un documento tipo Notes o tendrá otro formato.
Propiedad en la que sólo pueden elegirse los siguientes valores:

Notes
Permite especificar que este elemento será un documento de
tipo Notes.

HTML
Permite especificar que este elemento tendrá sólo código
HTML.

Other: string

142
Valor string utilizado para especificar otro tipo de contenido para
este elemento.

GenerateHTMLforAllFields: boolean = false
Permite a los documentos en una aplicación Web trabajar como un
documento en una aplicación Notes. También permite generar
información HTML acerca de los campos ocultos en un formulario.
Para que los documentos en clientes Web y Notes se comporten de
manera similar el valor de esta propiedad debe ser true.

AvailableToPublicAccessUsers: boolean= false
Permite que los usuarios tengan acceso al formulario. Para que un
usuario tenga acceso al formulario el valor de esta propiedad debe ser
true.

Description: string

Restricciones
• La propiedad CreateVersions solo puede utilizarse cuando no se elige el
valor por defecto None de la propiedad Versioning.

Notación

Estereotipo «Subform»
Descripción
Representa a un subformulario en LDD. El elemento subform es un elemento
importante para construir aplicaciones y provee una manera de evitar el duplicado
en el diseño de una sección de un form. Los subforms reducen el esfuerzo de
desarrollo debido a que se pueden mantener grupos de elementos en un lugar y
usar el subform en varios formularios.

Class

Relaciones

estereotipos: table, section, actionbar, view,folder, computertext, file, outline,
subform, stylesheet, field, scriptlibrary, images, applet, navigator, hotspot y
button.

143
Este estereotipo puede estar relacionado y contenido sólo en el estereotipo
form.

Valores Etiquetados

Name: String
Valor string que representa el nombre del subform.

AvailableToPublicAccess: boolean= false
Permite que los usuarios tengan acceso a este elemento. Para que un
usuario tenga acceso, el valor de esta propiedad debe ser true.

Description: string

Restricciones
• El único estereotipo que no puede contener un subform es un agent.

Notación
Estereotipo «Frameset»
Descripción
Representa a un frameset en LDD. Es una colección de elementos frame, los cuales
permiten estructurar o dividir los sitios web o las bases de datos Notes.

Class

Relaciones

Este estereotipo puede relacionarse directamente y contener sólo al
estereotipo frame.


Valores Etiquetados

Name: String
Valor string que representa el nombre del frameset.

144

Title: String
Valor string que representa el titulo del frameset. En esta propiedad
también puede introducirse una formula calculada que obtiene
automáticamente el titulo del frameset.

Los HTML Tags son propiedades que permiten manejar este elemento con
Javascript en el Web.

HTMLTag_Id: string
Propiedad que representa el elementoID en los tags de HTML.

HTMLTag_Class: string
Propiedad que representa el elemento Class en los tags de HTML.

HTMLTag_Style: string
Propiedad que representa el elemento Style en los tags de HTML.

HTMLTag_Title: string
Propiedad que representa el elemento Title en los tags de HTML.

HTMLTag_Other: string
Propiedad que permite representar otros elementos para los tags de
HTML. Por ejemplo: align, border, height, entre otros.

Description: string

Restricciones

Notación

Estereotipo «Frame»
Descripción
Un elemento frame es una sección de un elemento frameset que puede
personalizarse y ser independiente de cualquier otro frame contenido en el mismo
frameset.

Class

Relaciones

145
estereotipos: frameset, form, view, folder, page y navigator.

Este estereotipo puede estar relacionado y contenido sólo en el estereotipo
frameset.

Valores Etiquetados

Name: string
Valor string que representa el nombre del frame.

Type: typeOptions = URL
Valor string que representa el tipo de contenido que desplegará el
frame. Existen tres tipos de contenidos que pueden elegirse:

URL
Opción que se utiliza para especificar que el frame abrirá una
página Web especificando una URL completa en la propiedad
value del tipo http://www.paginaweb.com.

NamedElement
Opción que se utiliza para especificar que el frame abrirá el
elemento especificado en la propiedad value. Los elementos
que soporta esta propiedad son: page, frameset, view, form,
folder y navigator.

Link
Opción que se utiliza para especificar que el frame abrirá un
documento o elemento View especificado en la propiedad value.

Value: string
Valor string que se utiliza para especificar la liga hacia el tipo de
contenido que el frame desplegará. Esta liga puede ser una dirección
URL, el nombre de algún elemento soportado por la opción
NamedElement de la propiedad Typeo una fórmula que lanzará otro
contenido, dirección o elemento de LDD.

DefaultTargetForLinksInFrame: string
Valor string que permite indicar el marco en el que se desplegará el
contenido solicitado.

FrameWidth: int = 20
Valor entero que especifica el ancho que tendrá el elemento frame de
acuerdo a la medida especificada en la propiedad measuremente.

146

FrameHeight: int= 1
Valor entero que especifica el alto que tendrá el elemento frame.

Measurement: measurementType = percent
Especifica el tipo de medida utilizado en el las propiedades
FrameWidth y FrameHeight. Existen tres medidas que pueden
utilizarse:

Relative
Medida utilizada para redimensionar el frame de manera
relativa a otros frames contenidos en el frameset.

Percent
Medida utilizada para redimensionar el frame de acuerdo a un
porcentaje con el frameset. Un porcentaje de un 50% significa
un frame con la mitad del tamaño del frameset.

Pixel
Medida utilizada para redimensionar el frame en pixeles.

Scrolling: scrollingOption = default
Permite especificar el comportamiento de aparición de la barra de
desplazamiento en el frame. Existen cuatro opciones para especificar:

On
Permite forzar la aparición de la barra en el frame.

Off
Permite que la barra no aparezca en el frame.

Auto
Permite la aparición de la barra en el caso de que sea
necesario.

Default
La opción por defecto (default) es Auto.


HTMLTag_Id: string


147




Restricciones

Notación

Estereotipo «Page»
Descripción
Un page es un elemento de diseño que se usa para desplegar información. A
diferencia de un form que recolecta datos, los pages se diseñan para presentar
información al usuario. Por esta razón, no se puede crear ningún elemento tipo field
o un subform en un page.

Class

Relaciones

estereotipos: applet, file, hotspot, actionbar, view, agent, folder, section, table,
button, outline, image, scriplibrary, navigator, stylesheet y computertext.


Valores Etiquetados

Name: string
Valor string que representa el nombre del estereotipo page.

ContentType: ContentTypeOptions = Notes

148
Propiedad que permite especificar si este elemento tendrá sólo código
HTML o si será un documento tipo Notes o tendrá otro formato.
Propiedad en la que sólo pueden elegirse los siguientes valores:

Notes
Permite especificar que este elemento será un documento de
tipo Notes.

HTML
Permite especificar que este elemento tendrá sólo código
HTML.

Other: string
Valor string utilizado para especificar otro tipo de contenido para
este elemento.

AvailableToPublicAccessUsers: boolean= false
Permite que los usuarios tengan acceso al elemento page. Para que
un usuario tenga acceso, el valor de esta propiedad debe ser true.

Description: string

Restricciones
• No puede tener relaciones de contención con estereotipos del tipo form,
subform y field.

Notación

Estereotipo «Field»
Descripción
Un elemento field es la parte de una aplicación que recolecta datos. Cada campo
almacena sólo un tipo de información. El tipo de dato de un field define el tipo de
información que acepta. Los fields pueden ser de tipo simple o compartido, la
diferencia es la forma en la que se crea y utiliza cada uno.

Class

Relaciones

Este estereotipo no puede contener a ningún otro.

149

estereotipos: form, subform, table y section.

Valores Etiquetados

Name: string
Valor string que representa el nombre del estereotipo field.

Type: fieldType = text
Esta propiedad determina el tipo de información que se puede
introducir en el field. Los tipos de datos soportados por este campo
son:

Text
Tipo de dato que permite recolectar, guardar y desplegar texto
simple.

Date/Time
Tipo de dato que permite desplegar la fecha y horario en una
variedad de formatos.

Number
Tipo de dato que permite limitar al field para aceptar sólo
valores numéricos, así como el formato de despliegue.

DialogList
Tipo de dato que permite comportarse al field como una lista de
de opción múltiple a través de una caja de texto que contiene
un botón que permite abrir una cuadro de dialogo con una lista
de opciones para su elección.

Checkbox
opciónmúltiple a través de casillas de selección.

RadioButton
opción múltiple donde sólo puede elegirse una de ellas a través
de botones de radio.

Listbox
dos botones (arriba-abajo) para navegar a través de la lista.

150
Combobox
una lista desplegable con opciones para su elección.

RichText
Tipo de dato que permite recolectar, guardar y desplegar texto
enriquecido (texto con formato).

Authors
Tipo de datos que trabaja con el modelo de seguridad de LDD.
Permite controlar quien puede crear, editar y leer documentos
creados en un form.

Names
Tipo de dato que permite desplegar nombres de usuarios a
través de un campo calculado o editable.

Readers
Tipo de datos que trabaja con el modelo de seguridad de LDD.
Permite controlar quien puede leer documentos creados en un
form.

Password
Tipo de dato que permite ocultar los caracteres escritos en un
field a través de asteriscos.

TimeZone
Tipo de dato que permite desplegar una lista de las zonas
horarias en el mundo.

RichTextLite
Tipo de dato que permite recolectar, guardar y desplegar
cualquier tipo de texto. Permite tener un mayor control sobre los
datos que el field puede aceptar. La caja de texto viene
acompañada de un botón de ayuda y un botón que muestra el
tipo de dato que el campo acepta.

Color
Tipo de dato que permite al field comportarse como un selector
de color desplegando una caja de colores para la selección de
un color.

Category: CategoryOptions = editable
Permite definir la categoría del tipo de dato seleccionado. Las
categorías existentes son las siguientes:

151

Editable
Permite que el tipo de dato seleccionado sea editable.

Computed
Permite que el tipo de dato seleccionado sea calculado cada
vez que un documento se crea, guarda o actualiza.

ComputedForDisplay
Permite que el tipo de dato seleccionado sea calculado cada
vez que un documento sea abierto o cerrado.

ComputedWhenComposed
Permite que el tipo de dato seleccionado sea calculado sólo
cuando el documento se cree por primera vez.

Options:string
Valor de tipo string que permite especificar más opciones que algún
field pueda requerir y que no pueda ser especificado por alguna de las
propiedades que este tiene.

AllowMultipleValues: boolean = false
Valor booleano que permite a los usuarios poder introducir más de un
valor en un field. Para que los usuarios puedan introducir más de un
valor en el campo, esta propiedad debe ser true.

Shared: boolean = false
Valor booleano que indica si el estereotipo es compartido o simple. Un
field simple se crea directamente sobre el elemento contenedor,
mientras que un compartido se crea por separado y puede utilizarse
en múltiples elementos que puedan contenerlo. Para que este
elemento pueda ser compartido, esta opción debe tener un valor true.

HideParagraphFrom: HideOptions
Propiedad que determina para cuales clientes se encontrará oculto
este elemento. Los clientes de los cuales puede ocultarse este
elemento son:

NotesR4.6orLater: boolean= false
Valor booleano que indica que este elemento se ocultará al
utilizar un cliente Notes versión 4.6 o superior.

WebBrowser: boolean= false
utilizar un cliente del tipo navegador Web.

152
Mobile: boolean= false
utilizar un cliente móvil.

HideParagraphWhenDocumentIs: WhenDocumentIsOptions
Propiedad que determina las circunstancias en las que debe ocultarse
este elemento. Las circunstancias posibles son:

PreviewedForReading: boolean = false
Valor booleano que determina que la información de este
elemento no sea visible cuando un usuario lea un documento
en el panel visualizador de documentos.

OpenedForReading: boolean = false
Valor booleano que determina si la información de este
elemento estará visible cuando un usuario abre un documento
en modo lectura.

Printed: boolean = false
Valor booleano que determina si la información oculta de este
elemento estará visible en documentos impresos.

Embedded: boolean = false
Valor booleano que determina si el elemento estará visible
cuando los usuarios acceden a un documento en el cual se ha
utilizado el editor embebido para embeber el elemento.

PreviewedForEditing: boolean = false
elemento estará visible cuando un usuario trabaja con un
documento en modo edición en el panel de previsualización.

OpenedForEditing: boolean = false
Valor booleano que determina si la información estará visible
cuando los usuarios trabajen sobre documentos en modo
edición.

CopiedToTheClipboard: boolean = false
Valor booleano que determina si se debe ocultar el contenido
de este elemento cuando un usuario copia un documento.

HideParagraphIfFormulaIsTrue: boolean = false
Valor booleano que indica si una formula indicará las circunstancias en
las cuales la información se ocultará.

Formula: string

153
Valor de tipo string que permite especificar una fórmula para este
elemento.


HTMLTag_Id: string





Restricciones
• Un field puede estar contenido en un table o section sólo cuando estos
elementos estén contenidos en un form o subform.
• Los tipos de datos Text, Date/Time, Number, DialogList, Checkbox,
RadioButton, Listbox, Names y Readers sólo pueden utilizar los siguientes
valores de la propiedad Category: Editable, Computed, ComputedForDisplay
y ComputedWhenComposed.
• Los tipos de datos RichText y Color sólo pueden utilizar los siguientes
valores de la propiedad Category: Editable y Computed.
• Para el tipo de dato Checkbox, la propiedad AllowMultipleValues debe ser
siempre true.
• Para los tipos de datos: Combobox, RichText, RadioButton, TimeZone o
Color;; la propiedad AllowMultipleValues no puede utilizarse.
• Para los tipos de datos: Password o RichTextLite, las propiedades Category
y AllowMultipleValues no pueden utilizarse.
• Las propiedades HideParagraphFrom,HideParagraphWhenDocumentIs,
HideParagraphIfFormulaIsTruey Formula sólo están disponibles cuando la
propiedad shared tiene un valor de false.
• Cuando el valor de la propiedad HideParagraphFrom es
NotesR4.6orLatersólo pueden utilizarse las opciones OpenedForReading y
OpenedForEditing de la propiedad HideWhenDocumentIs.

Notación

154

Estereotipo «Action»
Descripción
Un elemento action es código que consiste de una combinación de acciones o una
simple acción de Domino. Un action provee métodos de acceso rápido a las tareas
rutinarias y puede codificarse con el lenguajeJavaScript o CommonJavaScript. Un
action sólo puede estar disponible a través del elemento actionbar.

Class

Relaciones

Este estereotipo sólo puede relacionarse directamente y contener al
estereotipo agent.

estereotipos: page, folder, view, form y subform, pero sólo a través del
elemento actionbar.

Valores Etiquetados

Name: string
Valor string que representa el nombre del estereotipo action.

action simple es aquel que se codifica directamente en alguno de los
elementos de diseño que soportan al elemento actionbar. Un action
compartido se codifica independientemente de los elementos de diseño y
puede por tanto insertarse en múltiples elementos que soporten la
utilización de acciones compartidas. Por ejemplo, view, folders, form,
page o subforms.

HideActionFrom: HideOptions
este elemento. Los clientes de los cuales puede ocultarse un elemento
son:

NotesR4.6orLater: boolean = false

155
WebBrowser: boolean = false
Valor booleano que indica que un elemento se ocultará al

Mobile: boolean = false

HideActionWhenDocumentIs: WhenDocumentIsOptions


Valor booleano que determina si la información de este elemento
estará visible cuando un usuario abre un documento en modo
lectura.

Valor booleano que determina si la información de este elemento
estará visible cuando un usuario trabaja con un documento en
modo edición en el panel de previsualización.

edición.

HideActionIfFormulaIsTrue: boolean = false

Formula: string
elemento.

Description: string
de la función que desempeña este elemento.

Restricciones

156
• Sólo están disponibles los valores PreviewedForReading,
OpenedForReading, PreviewedForEditing y OpenedForEditing en la
propiedad HideActionWhenDocumentIs.

Notación

Estereotipo «View»
Descripción
Representa una lista de documentos de una BD. Dependiendo del criterio de
selección, se pueden desplegar todos los documentos o sólo un conjunto de ellos.
Un view es una tabla de los contenidos de una BD y sirve para mostrar información
contenida en uno o varios documentos. Un view se encuentra estructurado por
elementos de tipo column.

Class

Relaciones

estereotipos: column y actionbar.

estereotipos: database, page,form, subform, table, section y frame.

Valores Etiquetados

Name: string
Valor string que representa el nombre del estereotipo view.

Alias: string
Valor string que representa el alias para el estereotipo view.

ViewType: ViewTypeOptions
Esta propiedad puede tener los siguientes valores:

Operation
Interface

Style: ViewStyle = StandardOutline
Permite seleccionar el estilo del view. Los valores posibles son:

157
StandardOutline
Opción que permite presentar un view como una tabla de
contenidos de la BD. Esta opción es el tipo de view más común
y es la que se utiliza por defecto.

Calendar
Opción que permite presentar un view como calendario para
agrupar y desplegar documentos con un formato de calendario.

ShowResponseDocumentsInAhierarchy: boolean = true
Valor booleano utilizado para indentar los documentos de una manera
jerárquica.

CollapseAllWhenDBisFirstOpened: Boolean = false
Valor booleano utilizado para

DefaultWhenDBisFirstOpened: Boolean = true
Valor booleano utilizado para especificar que el view sea el elemento
que se despliegue por omisión la primera vez que se abra la BD.

RowHeight: int = 1
Valor entero utilizado para especificar la altura en líneas que tendrán
los renglones del view.

AvailableToPublicAccess: boolean = false
Permite que los usuarios tengan acceso al view. Para que un usuario
tenga acceso al view el valor de esta propiedad debe ser true.

DontShowEmptyCategories: boolean = false
Valor booleano que permite eliminar el despliegue de categorías que
no contienen documentos. Para no desplegar las categorías sin
documentos, elegir para esta propiedad el valor true.

Description: string

ViewSelection: string
Evento que se ejecuta al momento que el view es desplegado. Es un
valor de tipo string utilizado para especificar una fórmula para realizar
una selección de documentos que aparecerán en este elemento una
vez abierto.

Restricciones
• Un view puede estar contenido en un table o section sólo cuando estos
elementos estén contenidos en un form,subform o page.

158
• Un nuevo view debe contener al menos a un elemento column simple al
momento de su creación.
• Las propiedades CollapseAllWhenDBisFirstOpened, RowHeight y
ShowResponseDocumentsInAhierarchyno están disponibles cuando se elige
la opción calendar de la propiedad Style.

Notación

Estereotipo «Folder»
Descripción
Un folderes estructuralmente similar a un view y tiene los mismos elementos de
diseño. Los folders son contenedores de documentos relacionados o de grupos de
éstos. Este tipo de elemento no tiene un criterio para seleccionar documentos, los
usuarios deciden cuales de estos se almacenan en los folders. Un folder se
encuentra estructurado por elementos de tipo column.

Class

Relaciones

estereotipos: column y actionbar.

estereotipos: database, page,form, subform, table, section y frame.

Valores Etiquetados

Name: string
Valor string que representa el nombre del estereotipo folder.

Alias: string
Valor string que representa el alias para el estereotipo folder.

FolderType: ViewTypeOptions
Esta propiedad puede tener los siguientes valores:
Operation
Interface

Style: ViewStyle = standardOutiline
Permite seleccionar el estilo del folder. Los valores posibles son:

159

StandardOutline
Opción que permite presentar un folder como una tabla de
contenidos de la BD. Esta opción es el tipo de folder más
común y es la que se utiliza por defecto.

Calendar
Opción que permite presentar un folder como calendario para
agrupar y desplegar documentos con un formato de calendario.

ShowResponseDocumentsInAhierarchy: boolean = false
Valor booleano utilizado para indentar los documentos de una manera
jerarquica.

CollapseAllWhenDBisFirstOpened: boolean= false
Valor booleano utilizado para

DefaultWhenDBisFirstOpened: boolean = true
Valor booleano utilizado para especificar que la folder sea el elemento
que se despliegue por omisión la primera vez que se abra la BD.

RowHeight: int = 1
Valor entero utilizado para especificar la altura en líneas que tendrán
los renglones del folder.

Permite que los usuarios tengan acceso al folder. Para que un usuario
tenga acceso, el valor de esta propiedad debe ser true.

DontShowEmptyCategories: boolean = false
Valor booleano que permite eliminar el despliegue de categorías que
no contienen documentos. Para no desplegar las categorías sin
documentos, elegir para esta propiedad valor true.

Description: string

Restricciones
• Un folder puede estar contenido en un table o section sólo cuando estos
elementos estén contenidos en un form,subformo page.
• Un nuevo folder debe contener al menos a un elemento column simple al
momento de su creación.

160
• Las propiedades CollapseAllWhenDBisFirstOpened, RowHeight y
ShowResponseDocumentsInAhierarchyno están disponibles cuando se elige
la opción calendar de la propiedad Style.

Notación

Estereotipo «Column»
Descripción
Los columns muestran un tipo de información acerca de los documentos listados en
un view. Un column en un view es el elemento organizador y es también el
elemento por el que un view se encuentra estructurado. Los columns pueden ser
simples o compartidos al igual que los actions y los fields. Un column simple se crea
y utiliza solamente en un view y un folder. Los columns compartidos permiten la
creación de un column común para insertarse en múltiples viewso foldersen la
misma BD.

Class

Relaciones

Este estereotipo no puede relacionarse directamente y contener a ningún
otro elemento.

estereotipos: viewy folder.

Valores Etiquetados

Title: string
Valor string que representa el titulo de la columna y que se utiliza
como ayuda para que los usuarios puedan identificar su contenido.

column simple es aquel que se diseña directamente en un view o folder.
Una columnacompartida permite ser insertada en múltiples view o folders
en la misma BD eliminando la necesidad de crear la misma columna con
las mismas funcionalidades para otros elementos.

DisplayValuesAsIcons: boolean = false

161
Valor booleano que permite desplegar iconos en vez de texto en una
columna para hacer que ésta sea distintiva.

ShowResponsesOnly: boolean = false

ShowTwistieWhenRowIsExpandable: boolean = false
Valor booleano que permite mostrar un triangulo azul expandible junto
a una columna para mostrar categorías.

Sort: sortType = None
Propiedad que permite especificar el método de ordenamiento de los
documentos mostrados en la columna. Los métodos disponibles son:

None
Opción que permite especificar que los documentos mostrados
en la columna no se ordenarán.

Ascending
Opción que permite ordenar en forma ascendente (A precede a
B, 1 precede a 2 y fechas anteriores preceden a fechas
posteriores) los documentos mostrados en la columna.

Descending
Opción que permite ordenar en forma descendente (B precede
a A, 2 precede a 1 y fechas posteriores preceden a fechas
anteriores)los documentos mostrados en la columna.

Type: typeOption = standard

StandardType

CategorizedType

ShowMultipleValuesAsSeparateEntries: boolean = true
Si una columna ordenada despliega valores provenientes de una lista
de valores multiples, éste valor debe establecerse a true para mostrar
cada valor en un renglón separado.

ClickOnColumnHeaderToSort: sortType = None
Propiedad que permite asignar al encabezado de la columna la
función de ordenar el contenido de formas ascendente, descendente o
ambas a través de un clic en el mismo.

None
Opción que permite especificar que no se podrá ordenar el
contenido de la columna a través de su encabezado.

162

Ascending
Opción que permite ordenar en forma ascendente (A precede a
B, 1 precede a 2 y fechas anteriores preceden a fechas
posteriores) los documentos mostrados en la columna a través
de su encabezado.

Descending
Opción que permite ordenar en forma descendente (B precede
a A, 2 precede a 1 y fechas posteriores preceden a fechas
anteriores)los documentos mostrados en la columna a través de
su encabezado.

Both
Opción que permite ordenar en forma ascendente y
descendente los documentos mostrados en la columna a través
de su encabezado.

CaseSensitiveSorting: boolean = false
Valor booleano que permite especificar si el ordenamiento será
sensitivo a mayúsculas y minúsculas.

AccentSensitiveSorting: boolean = false
Valor booleano que permite especificar si el ordenamiento será
sensitivo a caracteres acentuados.

HideColumn: boolean = false
Valor booleano que permite especificar si la columna se encontrará
visible o no al momento de ejecutar el view.

ShowValuesAsLink: boolean = false
Valor booleano que permite convertir una columna en una liga hacia el
documento que contiene.

Description: string

ColumnValue: string

Restricciones
• La propiedad ShowTwistieWhenRowIsExpandable no aplica cuando el
elemento view en el que se encuentra contenido la columna es de tipo
calendar.

163
• La propiedad Sort no tiene disponible la opción both.
• Cuando se ha seleccionado el valor de Categorized para la propiedad Type,
el valor de la propiedad Sort debe ser ascending o descending pero nunca
None.
• Cuando se selecciona el valor de Categorized para la propiedad Type la
propiedad ShowMultipleValuesAsSeparateEntries no está disponible y
siempre tendrá un valor true.

Notación

Estereotipo «File»
Descripción
Representa a un archivo externo que se ha importado a la BD de LDD. Estos
archivos se utilizan en el diseño de aplicaciones.Por ejemplo, probablemente se
necesite una misma página inicial para todas las aplicaciones de una empresa, esta
página puede ser un archivo HTML importado. De esta manera un archivo puede
compartirse con las aplicaciones que se desarrollen.

Component

Relaciones

otro elemento.

estereotipos: form, subform y page.

Valores Etiquetados

Name: string
Valor string que representa el nombre del archivo importado a la BD.

FileType: string
Valor string que permite describir el tipo de archivo importado. El tipo
debe definirse con la extensión del mismo.

Author: string
Valor string que representa el nombre del autor del archivo.

ElaborationDate: string

164
Valor string que representa la fecha de elaboración del archivo.

Permite que los usuarios tengan acceso al archivo. Para que un

KindOfFile: string
Propiedad que permite describir si el archivo importado es código
fuente u otro tipo de archivo. Los valores posibles para esta propiedad
son:

Code
Opción que representa que el tipo de archivo importado es un
archivo con código fuente. Por ejemplo un archivo HTML.

Other
Opción que representa que el tipo de archivo importado no es
código fuente y pertenece a otra categoría.

Description: string

Restricciones

Notación

Estereotipo «Image»
Descripción
Representa a una imagen externa que se almacena en la BD.

Component

Relaciones

otro elemento.


165
Valores Etiquetados

Name: string
Valor string que representa el nombre de la imagen importada a la BD.

ImageType: string
Valor string que permite describir el tipo de imagen importada. El tipo
debe definirse con la extensión del mismo.

Author: string
Valor string que representa el nombre del autor de la imagen.

Valor string que representa la fecha de elaboración de la imagen.

Permite que los usuarios tengan acceso a la imagen. Para que un

Description: string

Restricciones

Notación

Estereotipo «Stylesheet»
Descripción
Representa a una hoja de estilo importada en la BD.

Component

Relaciones

otro elemento.


166
Valores Etiquetados

Name: string
Valor string que representa el nombre de la hoja de estilo importada a
la BD.

Author: string
Valor string que representa el nombre del autor de la hoja de estilo.

Valor string que representa la fecha de elaboración de la hoja de
estilo.

Permite que los usuarios tengan acceso a la hoja de estilo. Para que
un usuario tenga acceso, el valor de esta propiedad debe ser true.

Description: string

Restricciones

Notación

Estereotipo «Applet»
Descripción
Representa a un Applet de Java importado a la BD.

Component

Relaciones

estereotipo.

estereotipos: form, page, subform, table y section.

Valores Etiquetados

167
Name: string
Valor string que representa el nombre del Applet importado a la BD.

Author: string
Valor string que representa el nombre del autor del Applet.

Valor string que representa la fecha de elaboración del Applet.

Description: string

Restricciones

Notación

Estereotipo «Outline»
Descripción
Representa a un elemento outline en LDD. Los outlines proveen a los usuarios una
forma de navegar en una aplicación y mantener una estructura de navegación fija,
similar a un diagrama de jerarquías.

Class

Relaciones

Este estereotipo sólo puede relacionarse directamente y contener al
estereotipo outlineEntry.

Este estereotipo puede relacionarse directamente y estar contenido en los
siguientes estereotipos: form, subform, table, section y page.

Valores Etiquetados

Name: string
Valor string que representa el nombre del outline.


168
Permite que los usuarios tengan acceso al outline. Para que un

Description: string

Restricciones
• Un outline no puede estar contenido en un table o section al menos que
estos estén contenidos en un form, subform o page.

Notación

Estereotipo «OutlineEntry»
Descripción
Representa a una entrada en un outline. Estas entradas constituyen una pieza en la estructura
de navegación del mismo. Un outlineEntry puede ser una acción o categoría que organiza
otras entradas con nivel más profundo en el outline.

Class

Relaciones

otro elemento.

Este estereotipo sólo puede estar relacionado y contenido en el estereotipo
outline.

Valores Etiquetados

Name: string
Valor string que representa el nombre del outlineEntry.

Frame: string

outlineEntry. Existen cuatro tipos de contenidos que pueden elegirse:

169
Action
Opción que se utiliza para especificar una acción que provea
una tarea automatizada.

URL
Opción que se utiliza para especificar que el outlineEntry abrirá
una página Web especificando una URL completa en la
propiedad value del tipo http://www.paginaweb.com.

NamedElement
el elemento especificado en la propiedad value. Los elementos
folder y navigator.

Link
un documento o elemento view especificado en la propiedad
value.

Frame: string

Value: string
contenido que el outlineEntry desplegará. Esta liga puede ser una
dirección URL, el nombre de algún elemento soportado por la opción
NamedElement de la propiedad Typeo una fórmula que lanzará otro
contenido, dirección o elemento de LDD.

elemento son:




170


en modo lectura.


Embedded: boolean = false

documento en modo edición en el panel de pre visualización.

edición.


HideParagraphIfFormulaIsTrue: boolean = false

Formula: string
elemento.

Description: string

171

Restricciones
• La propiedad value no se encuentra disponible cuando se elige el valor
Link de la propiedad Type.
• La propiedad Frame no se encuentran disponibles cuando se elige el
valor Action de la propiedad Type.
NotesR4.6orLatersólo pueden utilizarse las opciones OpenedForReading
y OpenedForEditing de la propiedad HideWhenDocumentIs.

Notación

Estereotipo «Hotspot»
Descripción
Representa a un elemento hotspot en LDD. Es un área programada donde se
puede ejecutar una acción a través de un simple clic. Para automatizar un hotspot
se necesita programarle una acción.

Class

Relaciones

otro elemento.

estereotipos: form, subform, page, table, section y navigator.

Valores Etiquetados

Name: string
Valor string que representa el nombre del hotspot y al mismo tiempo la
cadena de caracteres que representa a este elemento en el diseño de
una aplicación.

HotspotType: hotspotType
Propiedad que permite especificar el tipo de hotspot al cual
representará este estereotipo. Existen cinco tipos de hotspot que
pueden elegirse:

172

Link
Opción que se utiliza para especificar que el tipo de hotspot es
LinkHotspot. Este tipo de opción permite crear una liga a un
documento, view, DB, URL u otros.

Action
ActionHotspot. Este tipo de opción permite crear una acción
programada utilizando alguno de los lenguajes soportados por
LDD.
Rectangle
RectangleHotspot. Este tipo de opción permite crear un área
rectangular programada y seleccionable que permite ejecutar
una acción o invocar a un elemento de la BD.

Polygon
Polygon Hotspot. Este tipo de opción permite crear un área
poligonal programada y seleccionable que permite ejecutar una
acción o invocar a un elemento de la BD.

Circle
Circle Hotspot. Este tipo de opción permite crear un área
circular programada y seleccionable que permite ejecutar una
acción o invocar a un elemento de la BD.

hotspot. Existen cuatro tipos de contenidos que pueden elegirse:

URL
Opción que se utiliza para especificar que el hotspot abrirá una
página Web especificando una URL completa en la propiedad
value del tipo http://www.paginaweb.com.

NamedElement
Opción que se utiliza para especificar que el hotspot abrirá el
elemento especificado en la propiedad value. Los elementos
folder y navigator.

Link

173
Opción que se utiliza para especificar que el hotspot abrirá un
documento o elemento view especificado en la propiedad value.

Frame: string


HTMLTag_Id: string





Click: ClickOptions
Evento que permite especificar el tipo de acción que se ejecutará al
momento de hacer clic sobre el tipo de hotspot seleccionado. Las
acciones que se pueden ejecutar son de tres tipos:

Fórmula
Opción que permite especificar una fórmula en la propiedad
value que se ejecutará al momento de hacer clic sobre el
hotspot.

SimpleAction
Opción que permite especificar el elemento de LDD que se
lanzará al momento de hacer clic sobre el hotspot. Los posibles
elementos que se pueden lanzar son: view, navigator, folder,link
o URL.

LotusScript
Opción que permite especificar una acción escrita en lenguaje
LotusScript, la cual se ejecutará al momento de hacer clic sobre
el hotspot.

Value: string

174

contenido que el hotspot desplegara. Esta liga puede ser una dirección
URL o el nombre de algún elemento soportado. Por ejemplo, el
nombre de un form, page o cualquiera de los estereotipos que puede
contener o relacionarse. Esta propiedad también se utiliza para
especificar la formula que se ejecutará al momento de hacer clic en el
hotspot siempre y cuando se haya seleccionado la opción formula de
la propiedad click. En este valor también se introduce el nombre del
elemento que se lanzará si la opción simpleaction se ha seleccionado
de la propiedad click.

Description: string

Restricciones
• Un hotspot no puede estar contenido en un table o section al menos que
• La opción action de la propiedad Type no está disponible para un hotspot.
• Las opciones rectangle, polygon y circle de la propiedad hotspotType sólo
están disponibles si el elemento hotspot está contenido en un elemento
navigator.
• La propiedad Type no está disponible para los tipos de de hotspot: rectangle,
circle y polygon.
• La propiedad value sólo está disponible para la propiedad click con los
valores formula y simpleaction.
• Las propiedades HTMLTags, Type y Frame sólo están disponibles para los
tipos de hotspot:action y link.
• La propiedad click sólo está disponible para los tipos de hotspot: rectangle,
circle y polygon.

Notación

Estereotipo «ComputerText»
Descripción
Representa a un elemento Computer Text en LDD. Un computer text es un campo
donde su valor se determina a través de una fórmula que el desarrollador programa.
Los campos calculados pueden ser simples, compuestos o para desplegar
información. Un campo simple se calcula cada vez que un documento se crea,
actualiza o guarda información. Un campo compuesto se calcula sólo cuando un
documento se crea por primera vez. Un campo para desplegar información se
calcula cada vez que un documento se abre o guarda.

175
Class

Relaciones

otro elemento.

estereotipos: form, subform, page, tabley section.

Valores Etiquetados

Value: string
Valor string que representa

elemento son:







176
en modo lectura.


Embedded: Boolean = false

documento en modo edición en el panel de pre visualización.

edición.


HideIfFormulaIsTrue: boolean = false

Formula: string
elemento.


HTMLTag_Id: string



177



Description: string

Restricciones
• Un computertext no puede estar contenido en un table o section al menos
que estos estén contenidos en un form, subform o page.

Notación

Estereotipo «Navigator»
Descripción
Representa a un navigator en LDD. Un navigator es una interfaz gráfica que permite
a los usuarios acceder a views, datos de la BD de Domino u otras aplicaciones.
Este elemento puede incluir botones gráficos o hotspots.

Class

Relaciones

estereotipo hotspot.

estereotipos: form, subform, page, frame, tabley section.

Valores Etiquetados

Name: string
Valor string que representa el nombre del navigator.

178

Description: string

Restricciones
• Un navigator no puede estar contenido en un table o section al menos que
• Un navigator sólo puede contener a hotspots del tipo: rectangle, polygon y
circle.

Notación

Estereotipo «Button»
Descripción
Representa a un button, el cual es un tipo de hotspot en LDD. Este elemento se
utiliza para llevar a cabo una acción o fórmula, código LotusScript o JavaScript.Los
hotspots tipo botón y acción realizan lo mismo. La diferencia radica en que el
hotspot tipo botón aparecer como botón y el de tipo acción aparece como texto
resaltado.

Class

Relaciones

otro estereotipo.

estereotipos: form, subform, page, tabley section.

Valores Etiquetados

Name: string
Valor string que representa el nombre y la etiqueta del button.

elemento son:

179





en modo lectura.




edición.


180


Formula: string
elemento.


HTMLTag_Id: string





Description: string

OnclickLanguage: LanguageType
Propiedad que permite especificar el tipo de lenguaje para codificar el
evento que se lanzará al momento de hacer clic sobre el botón. Los
lenguajes soportados son JavaScript y CommonJavaScript.

OnClick
Método que se ejecuta al momento de hacer clic sobre el elemento
button.

OnMouseOver
Método que se ejecuta al momento de pasar el puntero del ratón sobre
el elemento button.

181

OnkeyDown
Método que ejecuta el código del elemento button al momento de
presionar una tecla que se ha programado para ejecutar el código.

OnMouseDown
Método que se ejecuta al momento de presionar el botón del ratón
sobre el elemento button.

Restricciones
• Un button no puede estar contenido en un table o section al menos que

Notación

Estereotipo «Agent»
Descripción
Representa a un elemento Agenten LDD. Estos elementos permiten automatizar
tareas en Domino. Son programas independientes que realizan una tarea específica en
una BD.

Class

Relaciones

otro estereotipo.

estereotipos: database,form, subform, action, y page.

Valores Etiquetados

Name: string
Valor string que representa el nombre del agent.

Type: AgentType= shared

182
Propiedad que se utilizara para especificar el tipo de agente. Los tipos
posibles son:

Private
Opción que permite especificar que el agente será privado y no
podrá ser utilizado por otros usuarios.

Shared
Opción que permite especificar que el agente será compartido y
utilizado por varios usuarios.

RunAsWebUser: boolean = false
Valor booleano que permite al agente correr con el nombre de usuario
que utiliza el usuario Web.

RunOfBehalftUser: string
Valor string que permite especificar los usuarios sobre los cuales este
agente podrá ejecutarse.

SetRuntimeSecurity:securityLevel = DoNotAllowRestrictedOperations(RO)
Propiedad que permite especificar el nivel de seguridad del agente.
Las opciones posibles son:

DoNotAllowRestrictedOperations(RO)
Opción que permite que el agente no lleve a cabo operaciones
restringidas.

AllowRestrictedOperations
Opción que permite que el agente lleve a cabo operaciones
restringidas.

AllowROWithFullAdministrationRigths
Opción que permite al agente llevar a cabo operaciones
restringidas y realizarlas con todos los derechos de
administración.

DefaultAccessForAllReaders: boolean = true
Valor booleano que permite especificar en la propiedad users a los
usuarios que tendrán acceso al agente. Un valor true permite el
acceso a todos los usuarios, un valor false permite el acceso
solamente a los usuarios especificados en la propiedad users.

Users: string
Valor string que permite especificar los usuarios que tendrán acceso al
agente.

183
AllowUserToViewAndRunThisAgent: boolean = false
Valor booleano que permite a los usuarios que tienen acceso público a
los documentos de la BD ejecutar el agente.

TriggerOnEvent: boolean = true
Valor booleano que permite especificar que el agente se lanzará una
vez que ocurra el evento seleccionado en la propiedad OnEventType.

TriggerOnSchedule: boolean = false
Valor booleano que permite especificar que el agente se lanzará en
una fecha y horario señalado en las propiedad OnScheduleType.

Target: TargetOptions = AllNew&ModifiedDocuements
Propiedad que permite especificar el tipo sobre el cual se ejecutará el
agente. Los tipos de documentos son:

AllNew&ModifiedDocuments
Opción que permite especificar que el agente se ejecutará
solamente sobre todos los documentos nuevos y modificados
de la BD.

AllDocumentInDatabase
sobre todos los documentos de la BD.

AllUnreadDocumentsInView
solamente sobre todos los documentos sin leer de un view.

AllDocumentInView
sobre todos los documentos de un view.

AllSelectedDocument

None

OnEventType: OnEventTypeOptions = ActionMenuSelection
Propiedad que permite especificar que el agente se iniciará cuando
ocurra cierto evento. Los eventos posibles son:

ActionMenuSelection

AgentListSelection

184

BeforeNewMailArrives
Opción que permite al agente ejecutarse antes de que el correo
se deposite en la BD.

AfterNewMailHasArrived
Opción que permite al agente ejecutarse después de que el
correo se deposite en la BD.

AfterDocumentAreCreatedOrModified
Opción que permite al agente ejecutarse después de que un
documento es creado o modificado en la BD.

WhenDocumentArePasted
Opción que permite al agente ejecutarse cuando un documento
se ha pegado en la BD.

OnScheduleType: OnScheduleTypeOptios = MoreThanOnceADay
Propiedad que permite especificar que el agente se iniciará en una
fecha y horario determinado. Esta propiedad está ligada a las
propiedades: RunAgentEvery, StopRunningAgentOnThisDate, AllDay,
OnDay, AtTime, StartRunningAgentOnThisDate, BetweenTimes, y
StartRunningAgentAt.Las opciones disponibles para esta propiedad
son:

MoreThanOnceADay
Opción que permite especificar que el agente se ejecutará más
de una vez al día. Esta opción se encuentra ligada con las
propiedades RunAgentEvery, BetweenTimes y AllDay.

Daily
diariamente. Esta opción se encuentra ligada a la propiedad
StartRunningAgentAt.

Weekly
semanalmente. Esta opción se encuentra ligada a las
propiedades AtTime y OnDay.

Montly
mensualmente. Esta opción se encuentra ligada a las
propiedades AtTime y OnDay.

Never

185
Opción que permite especificar que el agente no tendrá un
horario y fecha determinada para ejecutarse.

Nota: ver las restricciones de uso de cada una de estas propiedades.

RunAgentEvery: string
Valor string utilizado para especificar el intervalo de tiempo en el cual
se ejecutará el agente. Por ejemplo: “cada hora”, “cada media hora”,
entre otros.

BetweenTimes: string
Valor string utilizado para especificar los tiempos entre los cuales se
ejecutará el agente. Por ejemplo: “entre 12:00 y 12:30”, “entre 10:00 y
10:25”, entre otros.

AllDay: boolean = true
Valor booleano utilizado para especificar si el agente se lanzará
diariamente.

OnDay: string
Valor stringutilizado para especificar el día de la semana en el que el
agente se lanzará.

StartRunningAgentAtTime: string
Valor string utilizado para especificar la hora de lanzamiento del
agente en la fecha especificada.

StartRunningAgentOnThisDate: string
Valor string utilizado para restringir la fecha en la que el agente se
lanzará.

StopRunningAgentOnThisDate: string
Valor stringutilizado para restringir la fecha en la que el agente se
detendrá.

DontRunAgentOnWeekends: boolean = false
Valor booleano utilizado para especificar si el agente tendrá permitido
ejecutarse los fines de semana.

RunOn: string
Valor string utilizado para especificar el nombre del servidor donde el
agente se ejecutará.

ChooseServerWhenAgentIsEnable: boolean = false

186
Valor booleano utilizado para especificar que los usuarios sean
avisados de que un agente está habilitado y necesita especificársele
un servidor de ejecución.

Description: string

Restricciones
• Las propiedades TriggerOnEvent y TriggerOnScheduleno pueden tener un
valor true al mismo tiempo, una de ellas debe ser false.
• La propiedad OnEventType sólo puede utilizarse cuando la propiedad
TriggerOnEvent tiene un valor de true.
• La propiedad OnScheduleType sólo puede utilizarse cuando la propiedad
TriggerOnSchedule tiene un valor de true.
• Las propiedades ChooseServerWhenAgentIsEnables, BetweenTimes,
AllDay, StartRunningAgentAtTime, OnDay,
StartRunningAgentOnThisDate,RunOn, StopRunningAgentOnThisDate,
DontRunAgentOnWeekends y RunAgentEvery sólo pueden utilizarse cuando
la propiedad TriggerOnSchedule tiene un valor true.
• La propiedad Target no está disponible cuando se eligen las opciones
BeforeNewMailArrives, AfterNewMailHasArrived, WhenDocumentArePasted
y AfterDocumentAreCreatedOrModified de la propiedadOnEventType.
• Con la opción AfterDocumentAreCreatedOrModified de la propiedad
OnEventType el agente se ejecutará por defecto en intervalos de 30 minutos,
pero no inmediatamente después de cada actualización de un documento.
• Cuando la propiedad TriggerOnSchedule tiene un valor true, sólo están
disponibles los valores AllDocumentsInDatabase y
AllNew&ModifiedDocuments de la propiedad Target.
• Las propiedades RunAgentEvery, BetweenTimes y AllDay sólo están
disponibles para la opción MoreThanOnceADayde la propiedad
OnScheduleType.
• Las propiedades AllDay y BetweenTimes no pueden utilizarse al mismo
tiempo. Si la propiedad AllDay tiene un valor false, entonces puede utilizarse
la propiedad BetweenTimes.
• La propiedad StartRunningAgentAtTimesólo está disponible para las
opciones Daily, weekly y montly de la propiedad OnScheduleType.
• La propiedad OnDay sólo está disponible para las opciones weekly y montly
de la propiedadOnScheduleType.
• La propiedad users sólo puede utilizarse si la propiedad
DefaultAccessForAllReaders tiene un valor false.
• La propiedad DontRunAgentOnWeekends no está disponible cuando se
eligen las opciones weekly y montly de la propiedad OnScheduleType.
• La propiedad RunOn no está disponible cuando la propiedad
ChooseServerWhenAgentIsEnabletiene un valor true.

187

Notación

Estereotipo «ActionBar»
Descripción
Representa a una barra de acciones en LDD. Un action bar es un contenedor de
acciones programadas. Un action bar es una barra horizontal de botones, estos
botones pueden contener tanto acciones simples como compartidas.

Class

Relaciones

estereotipo action.

estereotipos: form, subform, view, folder y pages.

Valores Etiquetados

Display: DisplayOptions
Propiedad que permite elegir la forma en que la barra de acciones se
desplegará en el Web. Las opciones disponibles son:

UsingHTML
Opción por defecto que permite desplegar la barra de acciones
utilizando HTML.

UsingJavaApplet
Opción que permite desplegar la barra de acciones como un
applet de Java, dándoles a los usuarios una mejor apariencia y
funcionalidad en el manejo de la barra.

Description: string

Restricciones
• Las propiedades de una barra de acciones no están disponibles cuando ésta
se utiliza en un subform.

188

Notación

Estereotipo «Table»
Descripción
Representa una tabla de texto enriquecido en LDD. d) tablas programables: son
tablas que intercambian renglones basándose en una acción o un campo de
fórmula.

Class

Relaciones

Este estereotipo puede relacionarse directamente y contener a los
estereotipos: table, sections, hotspot, button, view, folder, computer text,
outline, files, subform, stylesheet, field, scriptlibrary, image, navigator, y
applets.

estereotipos: form, subform, page.

Valores Etiquetados

RowsNumber: int = 2
Valor entero que representa el número inicial de renglones que tendrá
la tabla.

ColumnNumber: Int = 2
Valor entero que representa el número inicial de columnas que tendrá
la tabla.

With: WithOptions = fitWithMargins
Propiedad que permite definir el comportamiento de una tabla cuando
se abre un documento. Las tablas pueden ajustarse al tamaño de un
documento abierto o simplemente tomar el tamaño de la ventana. Las
opciones disponibles para esta propiedad son:

FitWithMargins
Permite tomar los márgenes del elemento que lo contiene.

FitToWindows

189
Permite que una tabla tome los márgenes completos de un
documento de izquierda a derecha.

FixedWith
Permite finar un tamaño fijo para cada columna de la tabla.

Type: TypeOptios = basic
Propiedad que permite elegir el tipo de tabla utilizada en el
documento. Los tipos de tablas disponibles son:

Basic
Son tablas con un número de columnas y renglones definidos.

Tabbed
Tipo de tabla que permite a los usuarios cambiar renglones
haciendo clic en las fichas que se encuentra en la parte superior
de la misma.

Animated
Tipo de tabla que permite intercambiar renglones en un
intervalo de tiempo que el usuario determina.

Caption
Tipo de tabla que permite tener secciones desplegables que
permite ocultar u mostrar la información contenida en cada
renglón.

Programed
Tipo de tabla que permite intercambiar renglones basándose en
una acción o un campo de fórmula.

ColumnTitles: boolean = false
Valor booleano que determina si las columnas tendrán un titulo
definido.

Description: string

Restricciones
• Un table puede contener a un subform y field cuando éste no se encuentre
contenido en un page.

Notación

190
Estereotipo «Section»
Descripción
Representa un área que puede expandirse o colapsarse para mostrar, ocultar,
agrupar y organizar los elementos contenidos en esa área. Un section puede incluir
campos, objetos, regiones de diseño y texto.

Class

Relaciones

Este estereotipo puede relacionarse directamente y contener a los
estereotipos: table, sections, hotspot, button, view, folder, computer text,
outline, files, subform, stylesheet, field, scriptlibrary, image, navigator, y
applets.

estereotipos: form, subform, page.

Valores Etiquetados

Titulo: string
Valor string que representa el título de la sección, el cual puede ser de
tipo texto o calculado por una fórmula introducida en esta propiedad.

AccessControled: boolean
Valor booleano que determina si este elemento será de acceso
controlado.

elemento son:




191



en modo lectura.




edición.



Formula: string

192
elemento.

Description: string

Restricciones
• Un section puede contener a un subform y field cuando éste no se encuentre
contenido en un page.

Notación

Estereotipo «WebService»
Descripción
Representa a un servicio Web utilizado en LDD. Un elemento Webservice es una
aplicación autónoma basada en XML que puede publicarse e invocarse en el Web.

Class

Relaciones

estereotipo.

estereotipos: database.

Valores Etiquetados

Name: string
Valor string que permite especificar el nombre del WebService.

WarnIfTheWSDLinterfaceIsModified: boolean
Valor booleano que permite especificar que se realice un aviso en
caso de que el documento WSDL sea modificado.

PortTypeClass: string

193
Permite especificar la clase que contiene las operaciones (el código de
ejecución) para el tipo de puerto.

RunAsWebUser: boolean = false
Valor booleano que permite al WebService correr con el nombre de
usuario que utiliza el usuario Web.

RunOfBehalftUser: string
Valor string que permite especificar los usuarios sobre los cuales este
WebService podrá ejecutarse.

SetRuntimeSecurity:securityLevel = DoNotAllowRestrictedOperations(RO)
Propiedad que permite especificar el nivel de seguridad del
WebService. Las opciones posibles son:

DoNotAllowRestrictedOperations(RO)
Opción que permite que el agente no lleve a cabo operaciones
restringidas.

AllowRestrictedOperations
Opción que permite que el WebService lleve a cabo
operaciones restringidas.

AllowROWithFullAdministrationRigths
Opción que permite al WebService llevar a cabo operaciones
restringidas y realizarlas con todos los derechos de
administración.

DefaultAccessForAllReaders: boolean = true
Valor booleano que permite especificar en la propiedad users a los
usuarios que tendrán acceso al WebService. Un valor true permite el
acceso a todos los usuarios, un valor false permite el acceso
solamente a los usuarios especificados en la propiedad users.

Users: string
Valor string que permite especificar los usuarios que tendrán acceso al
WebService.

AllowPublicAccessUserToUse: boolean = false
Valor booleano que permite a los usuarios que tienen acceso público
utilizar el WebService.

ProgrammingLevel: ModelOptions
Propiedad que permite especificar el modelo de programación del
WebService. Las opciones disponibles son:

194
RPC
Opción que se utiliza para deserealizar los datos en tipos de
datos concretos.

Message
Opción que permite utilizar MOM (Message Oriented Model,
por sus siglas en inglés), el cual utiliza parámetros específicos
como firmas para pasar mensajes XML de SOAP en lugar de
deserealizar en tipos de datos concretos.

SOAPmessageFormat: strig
Valor string utilizado para especificar el formato del mensaje SOAP.
Los formatos soportados por LDD son: RPC/encoded, RPC/literal,
DOC/literal y Wrapped.

PortTypeName: string
Valor string utilizado para especificar el nombre del tipo de puerto por
el que se accederá al WebService. Esta especificación corresponde al
atributo “name” de <wsdl:portType> en el documento WSDL.

ServiceElementName: string
Valor string utilizado para especificar el nombre del WebService. Esta
especificación corresponde al atributo “name” de <wsdl:service> en el
documento WSDL.

ServicePortName: string
Valor string utilizado para especificar el puerto del por el que se
accederá al WebService. Esta especificación corresponde al atributo
“name” de <wsdl:port> debajo de <wsdl:service> en el documento
WSDL.

Description: string

Restricciones
• La propiedad users sólo puede utilizarse si la propiedad
DefaultAccessForAllReaders tiene un valor false.
• La propiedad SOAPmessageFormat no está disponible cuando se utiliza la
opción RPC de la propiedad ProgrammingLevel.

Notación

Estereotipo «ScriptLibrary»

195
Descripción
Representa un scriptLibrary en LDD. Una librería es un lugar donde se almacena
código que será compartido en una aplicación utilizando LotusScript, JavaScript o
Java. Se pueden utilizar estos tres tipos de lenguajes para codificar librerías que
posteriormente podrán compartirse entre elementos como los forms y pages.

Class

Relaciones

Este estereotipo no puede relacionarse directamente y contener ningún
estereotipo.


Valores Etiquetados

Name: string
Valor string que representa el nombre de la librería.

Languaje: string
Valor string que permite describir el tipo de lenguaje en el que se
encuentra codificada la librería.

Author: string
Valor string que representa el nombre del autor de la librería.

Valor string que representa la fecha de elaboración de la librería.

Version: string
Valor string que representa la versión de elaboración de la librería.

Description: string

Restricciones

Notación

196
Etiqueta identificadora decontención
«Containment»
«stereotype
»contenedor
Indicador de agregación
«stereotype
» contenido
Estereotipo «Contention»
Descripción
Representa un tipo de relación más fuerte que la asociación, pero más débil que la
agregación en UML. Esta relación se da entre un elemento contenedor y un
elemento contenido, el cual puede ser también un elemento contenedor. Esta
relación es binaria y debe de satisfacer un conjunto de propiedades para que la
relación sea válida. En una relación de contención los objetos contenedor y
contenido no tienen una relación todo/parte, sino que es una relación más débil
donde no existe una dependencia estructural entre ambos elementos.

Agregation

Valores Etiquetados
Para ver los atributos de esta relación ver la sección anterior.

Restricciones
• Esta relación no puede utilizarse con objetos del mismo tipo. Por ejemplo

Notación
Una relación de contención se dibuja como una línea sólida conectado dos objetos
(estereotipos). La contención se indica con un rombo pequeño ahuecado que se
añade al final del enlace. El rombo se dibuja en el objeto que hace la función de
contenedor y el enlace debe tener una etiqueta con la palabra “«Containment»”. La
siguiente figura muestra un ejemplo de la notación para esta relación en UML.

Estereotipo «ReflexiveContention»
Descripción
Representa un tipo de relación más fuerte que la asociación, pero más débil que la
agregación en UML. Es un tipo de contención que se da sólo entre algunos
elementos contenedores. Esta relación es binaria y debe de satisfacer un conjunto
de propiedades para que la relación sea válida. En una relación de contención
reflexiva ambos elementos son de tipo contenedor y no tienen una relación
todo/parte, sino que es una relación más débil donde los objetos no tienen que ver
estructuralmente uno con el otro. La diferencia con una contención es que la
contención reflexiva permite contener un elemento de su mismo tipo.
Figura 80 Notación para la relación de contención

197
Etiqueta identificadora decontención
reflexiva
«ReflexiveContainment»
«stereotype
»contenedor
«stereotype
»
contenedor
contenido

Agregation

Valores Etiquetados
Restricciones
• Esta relación puede utilizarse sólo entre elementos contenedores que sean
del mismo tipo. Por ejemplo: un subform puede contener a otro subform, un
table puede contener a otro table, entre otros.

Notación
La contención reflexiva se dibuja como una línea sólida conectado dos objetos. La
contención se indica con un rombo pequeño ahuecado que se añade al final del
enlace. El rombo se dibuja en el objeto que hace la función de contenedor y el
enlace debe tener una etiqueta con la palabra “«ReflexiveContainment»”. La siguiente
imagen muestra un ejemplo de la notación para esta relación en UML.

Otras relaciones
Se han incluido dos relaciones más (agregación y composición de UML) con el fin de
complementar las relaciones descritas en las secciones anteriores. Estas relaciones se
utilizarán con la misma semántica, sólo se han restringido algunos de sus atributos con
ciertos valores que se puede ver más adelante. Esto quiere decir que estas dos relaciones
también podrán utilizarse para modelar aplicaciones Domino con la misma semántica de
estas relaciones.

Relación de agregación
Descripción
Esta relación se da entre un elemento contenedor y un elemento contenido que
tiene la característica de ser un elemento compartido o embebido. Esuna relación
binaria tipo todo/parte, en la cual uno de los extremos representa el todo
(contenedor) y el otro representa la parte de la agregacióno la parte que constituye
al todo (contenido).

Figura 81 Notación para la relación de contención reflexiva

198
«stereotype
»contenedor
«stereotype
» contenido
Esta relación no extiende a ningún elemento de UML, sólo se han fijado los valores
de algunas relaciones.

Valores etiquetados

Restricciones

Notación
La agregación se representa por una línea sólida conectando a dos objetos, es
decir, una relación binaria. La agregación se indica con un diamante ahuecado que
se añade al final del enlace. El diamante se dibuja en la clase que es el conjunto
como se muestra en la figura siguiente.

Relación de composición
Descripción
La composición es un tipo de agregación más fuerte, donde existe una estrecha
relación entre un elemento agregado y sus elementos componentes. El punto
central de la composición es que el componente se considera como tal sólo como
parte del objeto compuesto.

La composición se da entre un elemento contenedor y un elemento contenido. En
esta relación uno de los extremos representa un todo y el otro representa un objeto
que necesariamente debe existir con la creación del contenedor. En esta relación se
requiere que el elemento contenido esté incluido mínimamente en un contenedor al
momento de crearlo. Un elemento compuesto tiene el mismo tiempo de vida que
sus propios componentes. Al destruir al objeto compuesto también los componentes
serán destruidos.

Esta relación no extiende a ningún elemento de UML, sólo se han fijado los valores
de algunas relaciones..

Notación
La composición se representa por una línea sólida conectando a dos objetos, es
decir, una relación binaria. La composición se indica con un diamante relleno que se
Figura 82 Relación de agregación, esquema general

199
Indicador de
composición
«stereotype
»contenedor
«stereotype
» contenido
añade al final del enlace. El diamante se dibuja en la clase que es el contenedor
como se muestra a continuación

Características
de relaciones de contención, contención reflexiva, agregación y composición.
En este apartado se presenta un conjunto de propiedades estructurales y funcionales.
Estas propiedades están basadas en las propiedades de las relaciones de UML. No
obstante se describen en términos más estrictos con la finalidad de caracterizar las
relaciones para las primitivas de modelado de LDD.
Multiplicity
Tabla 6 Definición de la propiedad multiplicidad
Definición Especifica el más bajo (Min) o alto (Max) número de elementos de
tipo contenido que deben o pueden ser conectados a un solo
elemento de tipo contenedor.
Definida sobre association-end.
Nomenclatura Lowassociation-end, Uppassociation-end
Valores 1, 0…1, 0…*, 1…*
UML relacionados Atributo multiplicidad: especifica el número de instancias objetivo
que pueden estar asociadas con una sola instancia fuente a través
de una asociación dada.
Delete Propagation
Tabla 7 Definición de la propiedad propagación de borrado
Definición Indica qué acción debe ser ejecutada cuando un elemento es
borrado (sobre sus enlaces o sus objetos asociados):
• {Restrictivo}: si el elemento tiene enlaces, los enlaces y
Figura 83 Relación de composición, esquema general

200
los objetos asociados no pueden ser borrados.
• {Cascada}: si el objeto tiene enlaces, los enlaces y los
objetos asociados deben ser borrados. Se utiliza
cuando no se tienen elementos compartidos o
embebidos asociados.
• {Cascada restrictiva}: si el objeto tiene enlaces, estos y
los enlaces deben ser borrados con excepción de
aquellos elementos que son compartidos o embebidos.
Nomenclatura DPassociation-end
Valores Restrictivo|Cascada|Cascada restrictiva
UML relacionados Semánticas de propagación: un compuesto implica semánticas de
propagación a sus partes. Por ejemplo, si el todo es copiado o
destruido, entonces las partes también (porque una parte puede
pertenecer a lo sumo a un compuesto).
Reflexivity
Tabla 8 Definición de la propiedad reflexividad
Definición Especifica si un elemento contenedor puede contener a otro
elemento de su mismo tipo. El valor {Reflexiva} indica que esto es
posible y {No reflexiva} indica lo contrario.
Nomenclatura RFrelationship
Valores Reflexiva| No reflexiva
UML relacionados Una característica de relaciones de agregación y composición:
[…] la instancia forma un grafo dirigido, no cíclico.
Valores fijos de las relaciones definidas
Para completar la semántica de las relaciones, se especifica el valor de las propiedades
introducidas en la sección 0 para cada una de las relaciones. De esta manera cada

201
relación contiene ciertas propiedades definidas. La tabla muestran los valores de las
propiedades definidas anteriormente. El símbolo * indica que una cualquier valor. Para
cada relación (columna) la tabla muestra los valores de las propiedades.

Tabla 9 Valores fijos para la relaciones
Propiedad/Relación Contención Contención
reflexiva
Agregación Composición
Multiplicidad * * * (1,1…*)
Propagación de
borrado
* * Cascada restrictiva Cascada
Reflexividad No reflexiva * No reflexiva No reflexiva

Modelado Visual de Aplicaciones Lotus Notes Domino

Más contenido relacionado

La actualidad más candente (20)

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

Más de Hiriam Eduardo Perez Vidal (8)

Último (20)

Modelado Visual de Aplicaciones Lotus Notes Domino