· cenidet departamento de ciencias computacionales tesis de maestrÍa en ciencias definición de...

cenidet

Departamento de Ciencias Computacionales

TESIS DE MAESTRÍA EN CIENCIAS

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones

Presentada por

Jesús Guillermo Rivera Parra Lic. en Informática por la Universidad Autónoma de Sinaloa

Como requisito para la obtención del grado de:

Maestría en Ciencias en Ciencias de la Computación

Director de tesis: M.C. Hugo Estrada Esquivel

Co-Directores de tesis: Dr. Máximo López Sánchez

M.C. Isaac Alberto Parra Ramírez

Jurado:

Dr. Javier Ortiz Hernández – Presidente

Dr. Guillermo Rodríguez Ortiz – Secretario

M.C. Humberto Hernández García – Vocal

M.C. Hugo Estrada Esquivel – Vocal Suplente

Centro Nacional de Investigación y Desarrollo Tecnológico

Cuernavaca, Morelos, México. 5 de diciembre del 2008

Dedicatorias

A mis padres

Por haberme apoyado siempre para salir adelante, son mi ejemplo de vida y de fortaleza,

sin ustedes no hubiera llegado a dar este gran paso Los amo

A mis hermanos Por ser parte importante en mi vida,

gracias Anette, Moisés y Cristina por estar siempre a mi lado apoyándome incondicionalmente para salir adelante,

por ustedes y mis padres estoy aquí Los amo

A toda mi familia Por haberme apoyado siempre para estar tan lejos

de ustedes y alentarme a seguir siempre

A Cynthia Gracias por todo el apoyo que me brindaste,

por todo tu cariño y por haber estado conmigo cuando lo necesité, siempre tendrás un lugar especial en mi corazón

A mis sobrinitos René Alberto y Christopher

Por traer alegría a mi vida y a toda mi familia Los amo

Agradecimientos

A CONACYT Por ser la institución que me brindó su apoyo económico para dar este gran paso.

Al Centro Nacional de Investigación y Desarrollo Tecnológico y al personal que en el labora

Por confiar en mí brindándome la oportunidad de formar parte de esta gran institución.

A mi director de tesis M.C. Hugo Estrada Esquivel Gracias por todo el apoyo y tiempo que me ha dedicado estos dos años, pero sobre todo, gracias por su amistad. Gracias también al Dr. Máximo López Sánchez por todo su apoyo.

Al Instituto de Investigaciones Eléctricas M.C. Isaac Alberto Parra Ramírez

I.S.C. Hiriam Eduardo Pérez Vidal Gracias por todo el tiempo que me dedicaron, gracias por la

paciencia, todo el apoyo y disposición que mostraron para atenderme, aún cuando tenían mucho trabajo.

Se los agradeceré por siempre.

A la Universidad Autónoma de Sinaloa Al Rector M.C. Héctor Melesio Cuén Ojeda Al L.C.P. José Paz López Elenes Al L.I. Eustacio Emilio Lara Velasco Al Dpto. de Soporte Técnico Por ser la institución que me brindó su apoyo económico pero principalmente al Rector, a José Paz y a mi jefe Emilio por brindarme el apoyo para superarme y pertenecer a esta gran institución.

A mis revisores M.C. Humberto Hernández García, Dr. Guillermo Rodríguez Ortiz

y Dr. Javier Ortiz Hernández. Les agradezco por todos los comentarios que se hicieron para desarrollar este trabajo de

investigación y por todo su apoyo.

Agradecimientos

A mis amigos y compañeros en el CENIDET Gracias por todas las vivencias que compartieron conmigo, pero en especial por su amistad. Les agradezco a Alex, José Luis, Omar, Richard, Wilfrido y Claudia, pero especialmente a Matilde por ser una persona llena de virtudes quien me dio su amistad incondicional, estuvo cerca apoyándome y de quien siempre tendré un grato recuerdo. También a Erick, Edna, Cindy, Elvia, Itzel y Lalo en el laboratorio de IS, así como Favio, Ángel y las colombianas Adriana y Paty.

A mis amigos Les agradezco por todo el tiempo que hemos compartido juntos y

por el simple hecho de ser mis amigos. Especialmente a Fernando, Zaida, Noé, Ernesto, Edgar, Carlos, Vianey, Mahonri, Jair, Ely y

Yemima, a quienes aprecio por haber estado cerca durante todo este tiempo y por su amistad.

A mis familiares Gracias a toda mi familia, desde mis tíos, abuelos, primos, por todo el tiempo que hemos compartido Juntos, a mi cuñado René por todo el apoyo. Los quiero a todos por igual, he llegado ha culminar este ciclo de mi vida gracias a que ustedes han sido parte importante a lo largo

de ella. Gracias a todos.

Resumen

Esta investigación involucra temáticas relacionadas con el Modelado de Dominios Específicos DSM

(Domain Specific Modeling) y la generación de Lenguajes de Dominio Específico DSL (Domain

Specific Language) a través de DSM.

El objetivo de esta tesis es definir un DSL ad hoc al entorno de desarrollo de software Lotus

Domino Designer (LDD) que permita modelar aplicaciones Web construidas en este entorno de

desarrollo. Para definir este lenguaje de modelado se analizó el dominio de LDD. En la primera fase se

modeló el dominio (DSM) y se caracterizó un conjunto de elementos de diseño utilizados en la

construcción de aplicaciones Web en LDD. Como resultado se obtuvo un conjunto de primitivas de

modelado que se compone de elementos de diseño, relaciones y restricciones entre las primitivas. En la

caracterización se modificó la metodología orientada al análisis de características FODA (Feature

Oriented Domain Analysis). En la segunda fase se generó un DSL tomando como base las primitivas

de modelado y formalizándolas utilizando un perfil UML. Lo anterior significa que para modelar una

aplicación Web de Lotus Notes/Domino se utilizan las primitivas especializadas en el perfil y toda la

semántica y potencial del Lenguaje de Modelado Unificado (UML).

El aporte de esta tesis es un lenguaje de modelado que permite modelar aplicaciones Web de

Lotus Domino Designer con las primitivas de modelado obtenidas durante el análisis del entorno y con

el potencial que provee UML. Los modelos realizados con el DSL son un puente entre el diseñador y el

desarrollador, estableciéndose un medio de comunicación más claro que con los modelos utilizados

anteriormente en la ingeniería de software de LDD.

El método utilizado para realizar la caracterización puede utilizarse como referencia para

construir una metodología adecuada que permita obtener componentes reutilizables. El DSL

pretende introducir a los diseñadores de software en el mundo formal de la ingeniería de software

para Lotus Domino Designer, tratando de complementar los modelos actuales con un modelo más

representativo y con características propias del entorno de desarrollo.

Abstract

This research involves topics related to the Domain Specific Modeling (DSM) and the generation of

Domain Specific Languages (DSL) through DSM.

The aim of this thesis is to define a DSL ad hoc to the software development environment

Lotus Domino Designer (LDD) that allows modeling Web applications developed in this environment.

To define the modeling language, a LDD domain analysis was done. In the first phase the domain was

modeling (DSM), at this stage was characterized a set of design elements used to construct LDD Web

applications. As a result of this characterization, a set of modeling primitives was obtained that consists

of design elements, relations and constrains among them. During the characterization the Feature

Oriented Domain Analysis (FODA) methodology was modified. In the second phase a DSL was

generated taking as a base the modeling primitives and formalizing them using a UML profile. The

previous means that for modeling a Lotus Notes/Domino Web application there is used the specialized

primitives in the profile and the whole semantic and potential of the Unified Modeling Language

(UML).

The contribution of this thesis is a modeling language that allows modeling Lotus Domino

Designer Web applications with the modeling primitives obtained during the environment analysis and

with the potential that UML provides. The models realized with the DSL are a bridge between the

designer and the developer, there being established a way of communication clearer than with the

models used previously in LDD's engineering software.

The method used to realize the characterization can be in use as reference to construct a

suitable methodology that allows obtaining reusable components. The DSL tries to introduce the

software designers in the formal world of the engineering software for Lotus Domino Designer, trying

to complement the current models with a more representative model and with proper characteristics of

the development environment.

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones i

Índice de contenido

Capítulo 1. Introducción ......................................................................................................... 1

Capítulo 2. Antecedentes ........................................................................................................ 5 2.1. Antecedentes de esta investigación ...................................................................................... 5 2.2. Estado del arte ...................................................................................................................... 6

2.2.1. Generación de un DSL mediante MetaEdit+ ................................................................... 7 2.2.1.1. Definición de un metamodelo mediante MetaEdit+ ................................................. 8

2.2.2. Generación de un DSL mediante Microsoft DSL Tool .................................................... 9 2.2.2.1. Introducción a DSL Tools ........................................................................................ 9 2.2.2.2. Arquitectura de DSL Tools .................................................................................... 10 2.2.2.3. Modelo de Dominio (DomainModel.dsldm) .......................................................... 11 2.2.2.4. Diseñador (Designer.dsldd) .................................................................................... 11

2.2.3. Generación de un DSL mediante Eclipse Modeling Framework (EMF) ....................... 11 2.2.3.1. Eclipse .................................................................................................................... 11 2.2.3.2. Eclipse Modeling Project (EMP) ........................................................................... 12 2.2.3.3. Eclipse Modeling Framework (EMF) .................................................................... 12 2.2.3.4. Graphical Modeling Framework (GMF) ................................................................ 13 2.2.3.5. Tabla de resumen de características ....................................................................... 14

2.3. Descripción del problema ................................................................................................... 16 2.4. Objetivos ............................................................................................................................ 16

2.4.1. General ........................................................................................................................... 16 2.4.2. Específicos ..................................................................................................................... 17

2.5. Justificación y beneficios ................................................................................................... 17 2.5.1. Justificación .................................................................................................................... 17 2.5.2. Beneficios ....................................................................................................................... 18

2.6. Metodología de solución .................................................................................................... 19 2.7. Alcances y límites del proyecto.......................................................................................... 20

2.7.1. Alcances ......................................................................................................................... 20 2.7.2. Límites ............................................................................................................................ 21

Capítulo 3. Marco teórico ..................................................................................................... 22 3.1. Desarrollo Rápido de Aplicaciones .................................................................................... 22 3.2. Modelado conceptual ......................................................................................................... 23 3.3. La ingeniería de dominios .................................................................................................. 24 3.4. Análisis de dominio ............................................................................................................ 25 3.5. Método de Análisis de Dominio Orientado a Características (FODA) .............................. 25

3.5.1. Fundamentos de la metodología FODA ......................................................................... 26 3.5.2. El proceso FODA ........................................................................................................... 26

3.5.2.1. Análisis de contexto ............................................................................................... 27 3.5.2.2. Modelo del dominio ............................................................................................... 28 3.5.2.3. Modelado de arquitectura ....................................................................................... 29

3.6. Modelo de características ................................................................................................... 29 3.7. Análisis de Dominio y Ambiente de Reuso (DARE) ......................................................... 30

3.7.1. Libro del dominio ........................................................................................................... 31 3.8. Lotus Notes/Domino, un panorama general ....................................................................... 35

3.8.1. Lotus Domino Designer (LDD) ..................................................................................... 36 3.9. Lenguaje de Dominio Específico (DSL Domain-Specific Language) .............................. 36 3.10. Perfiles UML ...................................................................................................................... 37

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones ii

3.10.1. Razones para elaborar un Perfil UML ............................................................................ 38 3.10.2. Elaboración de Perfiles UML ......................................................................................... 39

Capítulo 4. Análisis de Lotus Domino Designer ................................................................. 40 4.1. Estudio del entorno Lotus Domino Designer (LDD) ......................................................... 40 4.2. Trabajando en Domino Designer ....................................................................................... 41

4.2.1. Iniciando Domino Designer ........................................................................................... 41 4.2.2. LDD como cliente .......................................................................................................... 42 4.2.3. El panel de diseño .......................................................................................................... 43 4.2.4. Ventanas a través de fichas ............................................................................................ 44 4.2.5. La carpeta de marcadores (bookmark) ........................................................................... 44 4.2.6. La ventana de propiedades del objeto ............................................................................ 45

4.2.6.1. Ventana de propiedades del documento de diseño ................................................. 45 4.2.6.2. Ficha de información del documento (info tab) ..................................................... 46 4.2.6.3. Ficha para el tipo de campo (Fields tab) ................................................................ 46 4.2.6.4. Ficha de diseño ....................................................................................................... 46 4.2.6.5. Ficha de identificadores (ID) del documento ......................................................... 47 4.2.6.6. Propiedades de los elementos de diseño ................................................................. 47 4.2.6.7. Bloqueo de los elementos de diseño ....................................................................... 48 4.2.6.8. Vista previa del diseño ........................................................................................... 49 4.2.6.9. Paneles para programadores ................................................................................... 49

4.3. Elementos de Domino Designer ......................................................................................... 50

Capítulo 5. Caracterización de Lotus Domino Designer ................................................... 55 5.1. Estudio de metodologías para analizar dominios de aplicación ......................................... 55 5.2. Caracterización de Lotus Domino Designer....................................................................... 57 5.3. Proceso de Análisis de Dominio de Lotus Domino Designer ............................................ 58

5.3.1. Análisis del Contexto de Lotus Domino Designer ......................................................... 58 5.3.1.1. Analizando el dominio de LDD ............................................................................. 59 5.3.1.2. Diagrama de Contexto ............................................................................................ 63 5.3.1.3. Diagrama de Estructura .......................................................................................... 64 5.3.1.4. Limitando el alcance del dominio .......................................................................... 68

5.3.2. Modelado de Dominio de Lotus Domino Designer ....................................................... 69 5.3.2.1. Elementos de Domino Designer ............................................................................. 69 5.3.2.2. Modelo de características de Lotus Domino Designer ........................................... 70

5.3.2.2.1. Elementos Contenedores y Contenidos ............................................................... 71 5.3.2.2.2. Elemento Base de Datos ...................................................................................... 72 5.3.2.2.3. Elemento Form .................................................................................................... 72 5.3.2.2.4. Elemento View .................................................................................................... 72 5.3.2.2.5. Elemento Page ..................................................................................................... 73 5.3.2.2.6. Elemento Frameset .............................................................................................. 73 5.3.2.2.7. Elemento Action Bar ........................................................................................... 74 5.3.2.2.8. Elemento Folder .................................................................................................. 74 5.3.2.2.9. Elemento Tabla (table) ........................................................................................ 74 5.3.2.2.10. Elemento Sección (section) ............................................................................... 75 5.3.2.2.11. Otros elementos contenedores ........................................................................... 75

5.3.2.3. Relaciones entre elementos de Lotus Domino Designer ........................................ 75 5.3.2.4. Características de relaciones de contención, contención reflexiva, agregación y

composición ............................................................................................................................... 78 5.3.2.5. Definición del metamodelo .................................................................................... 79

5.4. Aplicando una técnica de modelado visual ........................................................................ 83

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones iii

Capítulo 6. Pruebas ............................................................................................................... 84 6.1. Introducción ....................................................................................................................... 84 6.2. Demostración del lenguaje ................................................................................................. 84

6.2.1. Características del lenguaje ............................................................................................ 85 6.3. Modelado del portal SIGCO............................................................................................... 91

Capítulo 7. Conclusiones ..................................................................................................... 106 7.1. Conclusiones .................................................................................................................... 106 7.2. Aportaciones..................................................................................................................... 108 7.3. Trabajos futuros ................................................................................................................ 109 7.4. Publicaciones .................................................................................................................... 109

Anexo A. Perfil UML para Lotus Domino Designer ..................................................... 110

Índice de figuras

Figura 2.1. Explorador de solución ........................................................................................................ 10

Figura 2.2. Propiedades de la cardinalidad............................................................................................ 11

Figura 2.3. Componentes y modelos usados durante el desarrollo basado en GMF .............................. 14

Figura 2.4. Metodología de solución ...................................................................................................... 20

Figura 3.1. Ciclos de desarrollo de software. ......................................................................................... 23

Figura 3.2. Estructura de la metodología FODA.................................................................................... 27

Figura 3.3. Notación del diagrama de características ............................................................................. 29

Figura 3.4. Diagrama de características para la elección de un automóvil ............................................ 30

Figura 3.5. Ejemplo del editor con un grupo .......................................................................................... 32

Figura 3.6. Usuarios de DARE ............................................................................................................... 33

Figura 3.7. Modelo de procesos en DARE ............................................................................................. 34

Figura 3.8. Editor de Arquitecturas ........................................................................................................ 34

Figura 4.1. Iniciando LDD desde el cliente Lotus Notes ....................................................................... 42

Figura 4.2. Personalizando la página de bienvenida de Lotus Domino Designer .................................. 43

Figura 4.3. Panel de Lotus Domino Designer ........................................................................................ 44

Figura 4.4. Organización de ventanas por medio de fichas .................................................................... 44

Figura 4.5. Cuadro de dialogo para crear una nueva carpeta ................................................................. 44

Figura 4.6. Propiedades del documento de diseño ................................................................................. 45

Figura 4.7. Ficha de información del documento ................................................................................... 46

Figura 4.8. Ficha de campo .................................................................................................................... 46

Figura 4.9. Ficha de diseño .................................................................................................................... 47

Figura 4.10. Ficha de ID......................................................................................................................... 47

Figura 4.11. Ventana de propiedades de una Vista (View) .................................................................... 48

Figura 4.13. Vista de objetos y vista de referencia ................................................................................ 49

Figura 4.12. Barra de herramientas para la vista previa ......................................................................... 49

Figura 4.14. Área de Scripts ................................................................................................................... 50

Figura 5.1. Fases del proceso para crear un DSL para Lotus Domino Designer.................................... 58

Figura 5.2. Fases del análisis del contexto ............................................................................................. 59

Figura 5.3. Arquitectura general de Lotus Notes Domino ..................................................................... 63

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones iv

Figura 5.4. Diagrama de contexto, factores externos que impactan el desarrollo de aplicaciones en LDD

................................................................................................................................................................ 64

Figura 5.5. Diagrama de estructura del dominio de Lotus Notes/Domino ............................................. 65

Figura 5.6. Limitando el alcance para el análisis del dominio ............................................................... 68

Figura 5.7. Fases del modelado de dominio de Lotus Domino Designer ............................................... 69

Figura 5.8. Principales elementos de una base de datos Domino ........................................................... 72

Figura 5.9. Elementos relacionados con un form ................................................................................... 72

Figura 5.10. Elementos relacionados con un view ................................................................................. 73

Figura 5.11. Elementos con los que se relaciona el elemento page ....................................................... 73

Figura 5.12. Elementos relacionados con los elementos frameset y frame ............................................ 73

Figura 5.13. Elementos relacionados con un action bar y un action ..................................................... 74

Figura 5.14. Elementos relacionados con un folder ............................................................................... 74

Figura 5.15. Elementos relacionados con una table ............................................................................... 74

Figura 5.16. Elementos relacionados con un section ............................................................................. 75

Figura 5.17. Elementos relacionados con un outline y un navigator ..................................................... 75

Figura 5.18. Relación de contención, esquema general ......................................................................... 76

Figura 5.19. Relación de conteción reflexiva, esquema general ............................................................ 76

Figura 5.20. Relación de agregación, esquema general ......................................................................... 77

Figura 5.21. Relación de composición, esquema general ...................................................................... 77

Figura 5.22. Principales elementos contenedores de LDD .................................................................... 79

Figura 5.23. Elementos contendores secundarios .................................................................................. 80

Figura 5.24. Elementos no contendores ................................................................................................. 80

Figura 5.25. Metamodelo de LDD ......................................................................................................... 82

Figura 5.26. Posición en la estructura de Lotus Notes/Domino de los elementos de diseño ................. 83

Figura 6.1. Diagrama de clases que trataba de representar la arquitectura de una aplicación Domino . 85

Figura 6.2. Diagrama ejemplificando la notación y simbología del DSL ............................................. 87

Figura 6.3. Representación de las relaciones de UML más utilizadas en diagramas anteriores ............ 88

Figura 6.4. Diseño de las entidades en modelos anteriores .................................................................... 88

Figura 6.5. Uso de las relaciones containment, composition y uses....................................................... 89

Figura 6.6. DSL actuando como puente de comunicación entre diseñador y desarrollador ................. 90

Figura 6.7. Página inicial del portal SIGCO .......................................................................................... 91

Figura 6.8. Aplicaciones disponibles en el portal SIGCO...................................................................... 92

Figura 6.9. Arquitectura general del portal ............................................................................................ 92

Figura 6.10. Arquitectura de la base de datos Comunidades de práctica .............................................. 93

Figura 6.11. Roles para los usuarios de la aplicación y funciones para ambos roles ............................. 93

Figura 6.12. Diagrama correspondiente a la arquitectura de navegación de la base de datos Foros de

Comités. ................................................................................................................................................. 94

Figura 6.13. Arquitectura general de coordinador de comités ............................................................... 95

Figura 6.14. Pantallas correspondientes a la creación de un comité de práctica .................................... 96

Figura 6.15. Diagrama correspondiente al CU creación de una Copr .................................................... 97

Figura 6.16. Pantallas correspondientes a la eliminación de un comité de práctica............................... 98

Figura 6.17. Diagrama correspondiente al CU eliminación de un Copr ................................................ 99

Figura 6.18. Pantallas correspondientes a la creación, edición y eliminación de grupos de trabajo .... 100

Figura 6.19. Diagrama correspondiente a los caso de uso crear, editar y eliminar grupos .................. 101

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones v

Figura 6.20. Pantalla correspondiente a la configuración de comités de especialistas ........................ 102

Figura 6.21. Diagrama correspondiente a la configuración de comités de especialistas ...................... 103

Figura 6.22. Creación, edición y eliminación de una categoría de un comité ...................................... 104

Figura 6.23. Diagrama estructural para crear, editar y eliminar una categoría .................................... 105

Índice de tablas

Tabla 2.1. Resumen de características de las herramientas para crear un DSL ..................................... 15

Tabla 3.1. Actividades de las fases del método FODA .......................................................................... 27

Tabla 3.2. Componentes del libro de dominio ....................................................................................... 31

Tabla 4.1. Elementos de diseño de Lotus Domino Designer ................................................................. 51

Tabla 5.1. Servicios ofrecidos por Lotus Domino Designer .................................................................. 60

Tabla 5.2. Clientes para Domino ............................................................................................................ 62

Tabla 5.3. Incidencia de los elementos en las aplicaciones de Lotus Domino Designer ....................... 67

Tabla 5.4. Elementos utilizados en el desarrollo de aplicaciones .......................................................... 70

Tabla 5.5. Otros elementos de diseño de LDD....................................................................................... 70

Tabla 5.6. Elementos que realizan la función de contenedores en LDD ............................................... 71

Tabla 5.7. Elementos que realizan la función de contenidos en LDD ................................................... 71

Tabla 5.8. Definición de la propiedad multiplicidad .............................................................................. 78

Tabla 5.9. Definición de la propiedad propagación de borrado ............................................................. 78

Tabla 5.10. Definición de la propiedad reflexividad .............................................................................. 78

Tabla 5.11. Valores fijos para la relaciones ........................................................................................... 79

Tabla A.1. Estereotipos definidos para Lotus Domino Designer ......................................................... 114

Tabla A.2. Definición de la propiedad multiplicidad ........................................................................... 178

Tabla A.3. Definición de la propiedad propagación de borrado .......................................................... 178

Tabla A.4. Definición de la propiedad reflexividad ............................................................................. 178

Tabla A.5. Valores fijos para la relaciones .......................................................................................... 179

Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 1

Capítulo 1. Introducción

“En muchas organizaciones, el desarrollo de aplicaciones Lotus Notes/Domino está fuera de control”

[IVES 99].

Lotus Notes/Domino popularizó el concepto de groupware (trabajo colaborativo) y con éste la

promesa del desarrollo rápido de aplicaciones. Pero, como muchas organizaciones adoptaron esta

plataforma, la demanda de características más sofisticadas fue creciendo. Como resultado de este

crecimiento, en la actualidad la plataforma Lotus Notes/Domino tiene un ambiente complejo para

desarrollar aplicaciones colaborativas debido a que cuenta con un paradigma de programación

diferente al orientado a objetos. Este ambiente se compone por una base de datos documental

constituida por varios elementos nativos de Domino, estos elementos constituyen a los documentos

almacenados en la base de datos y a los diversos tipos de aplicaciones que esta plataforma permite

desarrollar.

Además de IBM, muchas compañías ofrecen herramientas de desarrollo las cuales ayudan a

reducir esta complejidad. Sin embargo, la mayoría de las actuales soluciones tiene soporte para tareas

de desarrollo simples. Por ejemplo, para administrar la configuración. Pero la carencia de un método

Capitulo 1. Introducción


estándar para desarrollar aplicaciones Notes está todavía en un proceso muy reservado para los

expertos en el desarrollo de este tipo de aplicaciones. De esta manera el entorno de desarrollo rápido de

aplicaciones de Lotus Notes/Domino carece de un método adecuado de ingeniería de software para

modelar sus aplicaciones.

En la actualidad existe una tendencia notable hacia el desarrollo de aplicaciones basadas en el

Web. Estas aplicaciones por lo general necesitan de varios componentes para su desarrollo, por

ejemplo, un manejador de bases de datos, un servidor de aplicaciones y un entorno de desarrollo para

construir dichas aplicaciones. Los diferentes sectores industriales necesitan que la construcción se

realice en el menor tiempo posible y que permita compartir y obtener rápidamente información

importante para el flujo de trabajo o para la toma de decisiones. Es en este sentido que tienen su razón

de ser los entornos de desarrollo rápido de aplicaciones. Estos entornos permiten crear aplicaciones

rápidamente en un promedio de 60 y 90 días.

Dentro del dominio de los Entornos de Desarrollo Integrado (IDE del inglés Integrated

Development Environment) se encuentran los ambientes RAD (del inglés Rapid Application

Development) o ambientes de Desarrollo Rápido de Aplicaciones, que se caracterizan por ser

ambientes de desarrollo generalmente completos. Los entornos RAD se encuentran conformados por

una mezcla de ambientes tradicionales de programación y de ambientes de desarrollo rápido, donde se

reutilizan conceptos bien definidos desde el punto de vista tecnológico, los cuales, se usan como

primitivas de diseño de aplicaciones.

Si bien los RAD cuentan con la ventaja de generar rápidamente prototipos que pueden ser

evaluados por los usuarios finales, también tienen desventajas derivadas de la filosofía con la que estos

ambientes fueron creados: programar sin diseñar conceptualmente las aplicaciones, es decir, sin

modelarlas antes de empezar su desarrollo.

Actualmente, los entornos RAD no cuentan con lenguajes de modelado conceptual que

permitan diseñar una aplicación antes de programarla directamente con las facilidades del entorno, al

menos no los entornos que no se orientan a la Programación Orientada a Objetos (POO). Esto podría

ser tecnológicamente comparable con la aparición hace casi 50 años de lenguajes de programación en

los que se programaba directamente sin contar con un lenguaje de modelado que permitiera describir la

arquitectura de los sistemas a desarrollar. Como resultado de la tendencia de programación en RAD,

los analistas de sistemas han perdido el papel fundamental de buscar la funcionalidad básica de un

sistema a desarrollar antes de empezar a programarlo.

Como primer intento para lograr llevar a cabo un diseño adecuado durante las etapas de

análisis y diseño en entornos RAD, los diseñadores han tenido la idea de utilizar las primitivas básicas

que ofrece el Lenguaje de Modelado Unificado (UML del inglés Unified Modeling Language) como

primitivas para modelar los entornos RAD, pero este enfoque trajo consigo una serie de problemas

debido a que los elementos básicos de UML no ofrecen el apropiado nivel de abstracción para

representar de manera adecuada los elementos que se utilizan para desarrollar un aplicación en un

ambiente RAD.

En la actualidad, UML es uno de los lenguajes de modelado más utilizados en entornos

industriales y académicos. UML es un lenguaje de propósito general orientado al modelado de sistemas

Orientados a Objetos (OO). Una de las razones del éxito de UML es que éste contiene abstracciones

para muchos de los conceptos que se utilizan en POO. De esta forma, cada primitiva de modelado

conceptual tiene una contraparte en su correspondiente primitiva de implementación en un lenguaje

OO.



A pesar de las ventajas de UML, éste tiene limitaciones inherentes a su característica de ser un

lenguaje de modelado de propósito general. En ocasiones, los usuarios desean utilizar UML para

modelar dominios de aplicación muy específicos, esto ocasiona que la base del lenguaje tenga que ser

sobrecargada para permitir conceptos específicos. Este fenómeno ha sido ampliamente comentado en la

literatura científica cuando UML ha sido utilizado para representar dominios específicos. Una de las

opciones que UML ofrece para solucionar este problema se conoce como perfiles UML (UML

profiles), los cuales, son extensiones que se efectúan a la base de UML, especializando conceptos que

se encuentran ya definidos, para ofrecer una mayor funcionalidad y así representar conceptos más

abstractos acordes a las necesidades concretas de una plataforma o de un dominio de aplicación.

No obstante, existe también otra opción para definir lenguajes de dominio específico, esta

opción es construir desde cero un lenguaje ad hoc que permita un mayor grado de expresividad y

correspondencia con los conceptos de un dominio de aplicación en particular. Estos lenguajes, que

definen conceptos diferentes de los estándares de UML, se denominan Lenguajes de Dominio

Específico (DSL del inglés Domain Specific Language). Cabe mencionar que un perfil UML también

es considerado un DSL. Algunos DSL describen conceptos que son específicos a un dominio en

particular, pero fuera del alcance del estándar que utiliza UML. Estos lenguajes se generan a través del

Modelado de Dominio Específico (DSM del inglés Domain Specific Modeling).

Como resultado de la especificidad de un DSL, éste no puede utilizarse como lenguaje de

modelado de propósito general, sino como un lenguaje de modelado para un propósito específico. Por

estas razones un DSL es una opción viable para construir modelos ad hoc a un dominio en particular.

Para construir un DSL se pueden especializar algunos conceptos de UML. Los perfiles UML son el

mecanismo que el Lenguaje de Modelado Unificado maneja para este propósito.

En esta tesis se aborda al entorno RAD que la plataforma Lotus Notes/Domino utiliza para el

desarrollo de aplicaciones colaborativas, Lotus Domino Designer (LDD). Lotus Notes/Domino es una

suite que se compone de clientes y servidores. Es una plataforma que integra aplicaciones web y de

mensajería. Estas aplicaciones permiten el flujo de trabajo y el desarrollo de aplicaciones para trabajar

en ambientes colaborativos a través de LDD.

LDD pertenece a la familia Lotus Notes/Domino, es un entorno Web de programación de

aplicaciones que dispone de las herramientas necesarias para crear e implantar aplicaciones de

colaboración con funciones de seguridad. LDD está diseñado específicamente para crear aplicaciones

que faciliten el flujo de información entre los sistemas de una organización y sus procesos de negocios.

Estas aplicaciones ayudan a establecer relaciones comerciales con los clientes y socios a través de sus

servicios de aplicaciones. Por ejemplo, flujo de trabajo, compartición de directorio, mensajería y

seguridad; al mismo tiempo, permiten a los empleados que tratan directamente con el público tomar

decisiones, basándose en la información que tienen a su alcance.

El Instituto de Investigaciones Eléctricas (IIE) de la ciudad de Cuernavaca Morelos es una

organización que desarrolla software para Web sobre la plataforma Lotus Notes/Domino y

específicamente a través del entorno LDD. Este entorno sufre las mismas carencias de los entornos

RAD mencionadas previamente. LDD no cuenta con una herramienta o lenguaje de modelado

apropiado para describir la estructura de los sistemas a desarrollar, así como las relaciones y la

semántica entre los elementos de desarrollo que conforman al entorno.

En este trabajo de tesis se describe el proceso para crear un DSL para el entorno de desarrollo

Lotus Domino Designer proporcionado por el IIE. Este lenguaje se desarrolló en dos fases: 1) se llevó

a cabo un estudio de LDD entorno con el fin de analizar cuáles son los principales componentes que se

utilizan para desarrollar aplicaciones Web de Lotus Notes/Domino; y 2) se formalizó el lenguaje a



través de un perfil UML, especializando los conceptos obtenidos (entidades, relaciones y restricciones)

durante el análisis del dominio de LDD.

Los siguientes capítulos se estructuran de la siguiente manera: en el capítulo 2 se describen los

antecedentes de la investigación, los objetivos, problemática presentada, la metodología de solución y

un estudio de las herramientas actuales para desarrollar DSL; en el capítulo 3 se describen los

conceptos que se manejan en el desarrollo de esta tesis; en el capítulo 4 se describe un estudio del

entorno LDD con el fin de conocer los componentes de éste; en el capítulo 5 se describe el proceso de

análisis del dominio de LDD y la formalización del lenguaje de modelado; en el capítulo 6 se presentan

las pruebas realizadas al DSL; y por último, en el capítulo 7 se describen las conclusiones obtenidas al

termino de este trabajo de investigación.


Capítulo 2. Antecedentes

El presente capítulo describe los antecedentes de esta investigación, así como un estudio del estado del

arte sobre herramientas actuales para generar lenguajes para dominios específicos. También se

presentan los objetivos, la problemática resuelta y la metodología de solución llevada a cabo para

llegar a los objetivos y resolver la problemática presentada.

2.1. Antecedentes de la investigación

El Instituto de Investigaciones Eléctricas (IIE) cuenta con uno de los entornos RAD que está

influyendo en el mercado actual, denominado Lotus Domino Designer. Este entorno fue desarrollado

por IBM y tiene como principal característica la generación de sistemas cooperativos o colaborativos.

Estos sistemas utilizan servicios de mensajería, videoconferencia, administración documental,

administración de información personal (correo, agenda y libreta de direcciones) PIM (del inglés

Personal Information Management), entre otros.

Capitulo 2. Antecedentes


El entorno de desarrollo LDD utiliza una base de datos documental para almacenar

información introducida por las aplicaciones que en este entorno se desarrollan. Esta información se

almacena en forma de documentos (datos y estructura de diseño del documento), los cuales tienen una

estructura basada en un conjunto de elementos de diseño que contienen texto, gráficos, video, objetos

de audio o cualquier tipo de dato de texto enriquecido. Por esta razón, una aplicación de Lotus

Notes/Domino no utiliza una semántica para almacenar la información en renglones y registros, puesto

que no utiliza la forma tradicional de una base de datos relacional.

Almacenar información a través de documentos estructurados por un conjunto de elementos es

un paradigma diferente al de la POO. En la base de datos documental de LDD no se almacena

información a través de los conceptos tradicionales de OO (clases, encapsulamiento, herencia y

polimorfismo), sino a través de una estructura basada en un conjunto de elementos que LLD

proporciona para la construcción de los documentos y por tanto de la aplicación en sí. Por esta razón,

las aplicaciones desarrolladas en este entorno no pueden modelarse a través de los lenguajes de

modelado tradicionales OO. Estos lenguajes están orientados a modelar el código fuente y en LDD se

necesita modelar la estructura de la aplicación, la cual es también la estructura que compone a la

unidad básica para almacenar información, un documento.

Debido a la falta de un lenguaje para modelar la estructura de una aplicación en LDD y no su

código fuente, el equipo de desarrollo del IIE ha adoptado modelos UML para solucionar la parte de

modelar conceptualmente una aplicación de LDD previamente a su implementación. No obstante, sus

actuales propuestas no representan, ni definen, ni describen adecuadamente la forma o estructura que

tendrá una aplicación antes de ser desarrollada. Lo anterior se debe a que la base de UML no

proporciona la abstracción adecuada para representar correctamente los elementos de desarrollo de

aplicaciones que se requieren representar, así como sus propiedades, la semántica y las relaciones que

existen entre los diferentes elementos. Esta es una de las principales razones que propiciaron el análisis

del entorno LDD y de esta investigación para obtener un lenguaje de modelado adecuado al mismo.

2.2. Estado del arte

En la actualidad los lenguajes de modelado de propósito general como UML se basan principalmente

en modelos conceptuales que representan directamente el código fuente. Por ejemplo, los diagramas de

clase que describen los atributos y métodos que lo componen. Así, el nivel de abstracción entre el

modelo conceptual diseñado y la implementación propia del código fuente de la aplicación es

prácticamente el mismo. Tener un nivel de abstracción más alto permitiría trabajar elementos que

representan directamente conceptos del dominio de aplicación, ocultando detalles de implementación y

permitiendo tener un mejor entendimiento de la solución del problema. No tener un nivel de

abstracción más alto trae consigo que las organizaciones construyan modelos pobres de sus dominios

de aplicación, duplicando esfuerzos en la creación de sus diseños y codificación. Esto ocasiona que el

desarrollador considere escribir directamente código fuente como una solución más rápida y viable que

desarrollar un modelo conceptual que tenga que ser posteriormente traducido a código fuente.

Por estas razones se necesitan lenguajes de modelado que implementen conceptos más

cercanos a los que se trabajan en un dominio de aplicación específico. Éste es precisamente el objetivo

de los lenguajes de modelado de dominio específico.

La implementación de lenguajes de modelado de dominio específico a través del modelado de

dominio específico (DSM, por sus siglas en inglés) es una opción viable para la generación automática

de aplicaciones a través de un lenguaje de modelado ad hoc al dominio en cuestión. En este sentido, la

construcción del lenguaje no es una tarea fácil. En [JUHA 06] se mencionan tres aspectos que implican



el desarrollo de un lenguaje de modelado: los conceptos del dominio, la notación utilizada para

representar éstos en modelos gráficos y las reglas que guían el proceso de modelado.

Actualmente existen dos formas para implementar un DSL: construir uno partiendo de cero o a

través de la especialización de los conceptos de un lenguaje existente. En el desarrollo de un DSL

también intervienen metodologías para llevar a cabo un análisis del dominio para obtener los conceptos

o entidades del dominio. Estos métodos permiten caracterizar sus elementos, definiendo los conceptos,

propiedades, semántica y las relaciones existentes entre los elementos definidos. Aplicar una técnica de

análisis de dominio permite tener conceptos más cercanos al domino de aplicación, ocultando la

complejidad y aumentando el nivel de productividad de los desarrolladores.

Para generar un nuevo lenguaje de modelado existen en la actualidad herramientas como

MetaEdit+, Microsoft DSL Tool y Eclipse Modeling Framework. Éstas prometen la posibilidad de

definir un lenguaje de manera rápida y sencilla.

A continuación se presenta un estudio del estado del arte sobre herramientas para generar un

DSL. Éste se basa en los estudios comparativos de [PELECHANO 06], [MUÑOZ 05] y [GARCIA 06],

los cuales presentan como principal objetivo el desarrollo de un DSL. Este análisis sirve para conocer

las características, ventajas y desventajas que cada una posee y también para decidir si alguna de ellas

se puede utilizar en el proceso de generación de un DSL para un entorno RAD.

2.2.1. Generación de un DSL mediante MetaEdit+

MetaEdit+ es un conjunto de herramientas integradas basadas en un repositorio para crear lenguajes de

modelado y generadores de código. Estas herramientas fueron originalmente desarrolladas como un

prototipo de MetaCase en el proyecto de investigación SYTI y MetaPHOR en la Universidad de

Jyväskylä, Finlandia, entre 1988 y 1995 [STEVEN 07]. La versión comercial de la herramienta estuvo

disponible en MetaCase desde 1993. La última versión al tiempo de esta escritura es la 4.5 de

Noviembre del 2006. MetaEdit+ se encuentra actualmente disponible para los sistemas operativos

Windows, Mac OS X y Linux.

MetaEdit+ provee herramientas de soporte para diferentes lenguajes de modelado a través de la

configuración de un conjunto de herramientas genéricas. Para definir metamodelos, MetaEdit+ emplea

el lenguaje de metamodelado GOPPRR. Todos los datos de diseño se almacenan en un sistema de

repositorio orientado a objetos, el cual soporta referencias complejas entre los elementos diseñados.

MetaEdit+ viene en dos versiones: MetaEdit+ Workbench (MWB) que integra las herramientas de

desarrollo del lenguaje y el generador de código, además de las herramientas ordinarias de modelado.

La versión normal incluye solamente las herramientas ordinarias de modelado.

En la literatura relacionada a MetaEdit+ [MetaCase 07] se menciona que para implementar un

lenguaje de modelado, MetaEdit+ provee de una herramienta de metamodelado para ingresar los

conceptos, sus propiedades, reglas y símbolos asociados. Alternativamente se puede especificar el

metamodelo usando lenguajes de metamodelado gráfico. La definición del lenguaje se almacena como

un metamodelo en un repositorio, permitiendo futuras modificaciones que se reflejarán

automáticamente en modelos y generadores de código fuente.

En [MetaCase 07] se definen las tres propiedades básicas para generar un DSL a través de

MetaEdit+:



1) Definir los conceptos del dominio: un lenguaje de modelado debe aplicar conceptos que

representen con exactitud la semántica del dominio. Usando herramientas de metamodelado de

MetaEdit+ se puede introducir cada concepto de dominio y definir sus propiedades.

2) Elegir reglas de dominio: un lenguaje debe seguir las reglas que existen en el dominio. Una

vez definidas, el lenguaje (representado por la herramienta de desarrollo) garantiza que todos

los desarrolladores sigan las mismas reglas del dominio. Estas reglas son de diferentes tipos y

relacionadas típicamente a conexiones entre conceptos, modelos de capas, diseño de

reutilización, entre otras.

3) Dibujar símbolos de notación: un lenguaje de modelado visual requiere definir símbolos. La

notación debe ilustrar tan bien como sea posible la correspondencia entre la visualización

natural y los conceptos del dominio. Los usuarios finales son las personas indicadas para

inventar estos símbolos.

2.2.1.1. Definición de un metamodelo mediante MetaEdit+

En [STEVEN 07] se muestra que los metamodelos necesarios para construir un DSL pueden definirse

de forma gráfica o a través de formularios que utilizan el lenguaje de metamodelado GOPPRR. El

nombre de GOPPRR es un acrónimo hecho de los nombres de los metatipos reconocidos por el

lenguaje: Graph (Grafo), Object (Objeto), Property (Propiedad), Port (Puerto), Relationship

(Relación) y Role (Rol que juega).

a) Metamodelo gráfico

Un metamodelado gráfico usualmente cubre los conceptos de modelado básicos, sus

propiedades, conexiones y reglas relacionadas. En términos de MetaEdit+, estos conceptos se

cubren con el lenguaje de metamodelado GOPPRR.

El metamodelado gráfico se lleva a cabo a través de la construcción de un metamodelo

(diagrama o grafo) donde se describen todos los objetos, conexiones y reglas que definirán al

lenguaje. Estos objetos, conexiones y reglas se construyen a través de formularios en donde se

pueden agregar propiedades a distintos elementos.

Una vez construido el metamodelo se procede a la construcción del DSL a través de la

generación de un documento XML. Éste contiene la descripción detallada de cada uno de los

objetos, conexiones y reglas que fueron descritas en el metamodelo gráfico definido. Este

documento XML se construye automáticamente en el editor de diagramas de MetaEdit+. Dicho

documento se almacena en el repositorio como una definición de lenguaje de modelado. Con

esta definición se continúa para finalizar el lenguaje de modelado definiendo los símbolos

correspondientes a cada elemento. Un ejemplo práctico para la construcción de un metamodelo

se muestra en [MetaCase 06].

b) Metamodelado con base en formularios

Como una alternativa para elaborar metamodelos gráficos, MetaEdit+ provee un conjunto de

herramientas de metamodelado basadas en formularios. Usar estas herramientas puede ser

menos intuitivo para los principiantes, pero provee más precisión y algunas opciones extras.

Un metamodelo creado gráficamente puede ser también editado utilizando formularios.



Existe un formulario para definir cada metatipo de GOPPRR. Por ejemplo para un objeto se

tiene la herramienta de objetos (Object tool). Cada objeto, puerto, rol y relación puede definirse

de esta manera a través de su respectivo formulario. Las propiedades adjuntas a estos

elementos se definen a través de la herramienta de propiedades. Todos los tipos de propiedades

deben tener un nombre y un tipo de dato definido. Dependiendo del tipo de dato, existen

también definiciones adicionales.

Una vez que se definen los tipos y sus propiedades, la definición final del lenguaje puede

conjuntarse con la herramienta de gráficos, esta herramienta combina los tipos individuales

definidos.

Es posible tener restricciones para los elementos del lenguaje o definir referencias entre los

modelos y los elementos del propio modelo. Las reglas y restricciones que guían el uso del lenguaje de

modelado también son parte importante del metamodelo. El conjunto de reglas más elementales en

GOPPRR son las conexiones, las cuales describen cómo los objetos, puertos, roles y relaciones pueden

combinarse para definir tipos de conexiones entre tipos de objetos. Aunque las reglas se expresan en

términos sencillos, en realidad se construyen eligiendo uno o varios tipos y valores de números enteros

entre un número de formas de reglas y plantillas. Las reglas establecidas por conexiones y restricciones

se cumplen automáticamente y en tiempo real durante el modelado. Esto significa que no es posible,

incluso temporalmente, crear una pieza de un modelo que no esté en concordancia con el metamodelo.

Como se observó en los apartados anteriores, las dos formas para crear metamodelos ofrecen

ventajas. Por un lado, el metamodelado gráfico es mejor para definir lenguajes de modelado más

pequeños y es más útil para metamodeladores con menos experiencia. El metamodelado gráfico

también provee una buena manera para documentar los lenguajes de modelado, mientras que el

metamodelado basado en formularios es mejor para crear lenguajes de modelado más grandes y con un

nivel de producción mayor, esta opción provee mejor soporte para estructuras en capas y referencias

complejas entre los elementos de diseño, a menudo encontrados en cada lenguaje. El metamodelado

basado en formularios permite al metamodelador probar al instante los lenguajes definidos en la

herramienta de modelado de MetaEdit+ al tiempo que se crean los metamodelos.

La siguiente y última fase de la creación del metamodelo es definir los símbolos visuales que

representarán los conceptos del lenguaje. MetaEdit+ provee un editor de símbolos que permite crear su

correspondiente representación a los diferentes conceptos, roles y relaciones. Para llevar a cabo el

modelado final, MetaEdit+ proporciona tres maneras para realizarlo: a través de un editor de

diagramas, un editor de matriz o un editor de tabla, cada uno de estos editores cuenta con una diferente

vista representativa de los datos conceptuales.

2.2.2. Generación de un DSL mediante Microsoft DSL Tool

En el siguiente apartado se describe la manera en la que se utiliza Microsoft DSL Tools para definir

Lenguajes de Dominio Específico. El análisis de las características que posee este lenguaje de

modelado está basado en un estudio comparativo entre MetaEdit+ y DSL Tools realizado en la

Universidad de Murcia España, el estudio completo puede encontrarse en [GARCIA 06].

2.2.2.1. Introducción a DSL Tools

La alternativa que Microsoft ofrece para el desarrollo de un DSL es una herramienta que se encuentra

integrada en el entorno de desarrollo Visual Studio 2005, denominada DSL Tools. Esta herramienta

permite definir el Modelo de Dominio (Domain Model). Aquí se modelan todos los elementos del



lenguaje y es con base en este modelo que se define el Diseñador (Designer). Microsoft utiliza la

terminología de “Modelo de Dominio” y “Diseñador” para referirse a la sintaxis abstracta y concreta

respectivamente. La sintaxis abstracta se refiere a la definición de los conceptos, semánticas, reglas,

restricciones y todos los elementos que conforman el lenguaje de modelado, mientras que la sintaxis

concreta se refiere a la definición de las figuras que representan visualmente a los elementos que

conforman el lenguaje de modelado.

2.2.2.2. Arquitectura de DSL Tools

En [García 06] se menciona que para el desarrollo de modelos gráficos, el cual es una de las bases en la

construcción de un DSL, el desarrollador debe definir los siguientes elementos:

1) Modelo de Dominio (Domain Model): se refiere al metamodelo o sintaxis abstracta del DSL.

Este modelo se define con un lenguaje de metamodelado que se utiliza a través de un editor de

metamodelos y que tiene una naturaleza similar al MOF y a otros lenguajes de metamodelado.

2) Figuras del diagrama (shapes) y conectores (connector) asociados al modelo de dominio: Se corresponden con la representación gráfica de los artefactos de modelado, es decir, con la

sintaxis concreta del DSL. Cada figura agregada en un diagrama representa una instancia

concreta de un concepto determinado dentro de un dominio, por ejemplo una clase en un

diagrama de clases. Los conectores son la representación gráfica de la relación existente entre

dos figuras.

3) Plantillas de Texto: son las guías que definen el proceso de generación de código a partir de

un modelo de entrada.

Las plantillas son la base para crear un nuevo lenguaje, dan

la posibilidad al programador de elegir aquella que considere más

apropiada y que permita definir el mayor número de características

posibles a su lenguaje. Las cuatro plantillas básicas que se pueden

elegir son: diagramas de actividad, diagramas de clase, lenguaje

mínimo y diagrama de casos de uso.

Una plantilla se elige a través de un asistente que guía en la

elección de la misma. Al finalizar el asistente, se muestra el

explorador de solución que permite elegir entre dos proyectos

principales: Designer y ModelDomain (ver figura 2.1), a partir de

éstos el resto se generará automáticamente.

El proyecto DomainModel contiene las clases y relaciones

del lenguaje, se trata del metamodelo (sintaxis abstracta) del

lenguaje. El metamodelo se construye de forma visual mediante la

herramienta que se proporciona en la edición del archivo

DomainModel.dsldm.

El proyecto Designer establece la sintaxis concreta de los elementos o figuras y los conectores

que aparecen en el lenguaje, así como la relación con los conceptos del modelo de dominio. Al igual

que ocurre en DomainModel, en este proyecto tampoco existen restricciones en modificar el código

que se genera de forma automática para perfilar o definir alguna característica.

Figura 2.1. Explorador de solución



2.2.2.3. Modelo de Dominio (DomainModel.dsldm)

DSL Tools proporciona una herramienta de diseño que

permite editar el modelo de dominio. Esta herramienta

permite añadir atributos a las clases, clases nuevas,

además de relaciones de herencia y referencias entre las

mismas. En los diagramas aparecen diversos elementos

que dan información del modelo, como la cardinalidad de

las relaciones o información desplegable en las clases,

también se muestran las etiquetas de las clases.

En DSL Tools las relaciones de embebido

(Embedding) y referencia (Reference) en ocasiones se ven

como clases implícitas a las que se pueden agregar

atributos.

La cardinalidad es otro atributo importante que es

posible modificar al definir relaciones (ver figura 2.2). En

esta imagen, se remarcan con un círculo los valores de las

propiedades que indican el valor de la cardinalidad, un

mínimo (Min) y máximo (Max) de 0 se traduce por un valor de N (*). Actualmente en DSL Tools las

relaciones tienen dos roles (uno de origen y otro de destino) pero en versiones futuras quizá aparezcan

relaciones con N roles [García 06].

2.2.2.4. Diseñador (Designer.dsldd)

Todos los aspectos que conciernen a lo que el diseñador conforma se especifican en el archivo

Designer.dsldd que es un archivo XML. En éste se especifica la sintaxis concreta del lenguaje,

indicando desde la representación de las figuras y conectores hasta la configuración del propio editor

definiendo la barra de herramientas (toolbox). Debe existir una correcta correspondencia entre el

Modelo de Dominio (archivo DomainModel.dsldm) y el Diseñador (archivo Designer.dsldd), las

propiedades de un elemento que no se declaren previamente en el metamodelo o Modelo de Dominio

no deben especificarse en el Diseñador.

2.2.3. Generación de un DSL mediante Eclipse Modeling Framework (EMF)

Eclipse Modeling Framework es un marco de herramientas integrado que tiene la finalidad de crear

modelos o metamodelos a través de un conjunto de herramientas que se integran en la plataforma

Eclipse. EMF se deriva del proyecto de modelado Eclipse Modeling Project que se orienta hacia la

construcción de software a través de modelos y adopta los estándares de la Object Management Group

(OMG). A continuación se describirá brevemente la plataforma Eclipse y algunos de sus principales

componentes.

2.2.3.1. Eclipse

Eclipse fue desarrollado originalmente por la International Business Machines Corporation (IBM)

como sucesor de la familia de herramientas VisualAge en noviembre del 2001. Eclipse se encuentra

ahora desarrollado por la Fundación Eclipse. Esta fundación fomenta independientemente una

comunidad de código abierto y un conjunto de productos de desarrollo complementarios, así como

otras capacidades y servicios sin propósitos de lucro [Eclipse].

Figura 2.2. Propiedades de la cardinalidad



Eclipse es un proyecto de desarrollo de software independiente de la plataforma y de código

abierto, su propósito es proveer de plataforma de herramientas altamente integradas que proporcionen

funcionalidades distintas y al mismo tiempo incorporadas en un mismo ambiente de desarrollo. Eclipse

se encuentra conformado por un proyecto central, el cual incluye un framework genérico y un ambiente

de desarrollo Java. Otros proyectos extienden la estructura del framework central para dar soporte a

tipos específicos de herramientas y ambientes de desarrollo de software. Los proyectos se implementan

en Java, corriendo en muchos sistemas operativos incluyendo Windows y Linux.

El principal mecanismo para extender la funcionalidad del IDE que provee Eclipse se llama

plug in. Este mecanismo hace que el entorno sea mucho más ligero que los IDEs tradicionales donde

toda la funcionalidad viene integrada en un mismo entorno, sin importar que el usuario la necesite o no

para el desarrollo de un sistema. Los plug in permiten a los desarrolladores extender sólo la

funcionalidad requerida, por ejemplo: extender los lenguajes de programación que soporta el IDE,

como son: C/C++, Python, entre otros; trabajar con lenguajes de procesamiento de texto como LaTeX,

con aplicaciones en red como Telnet y sistema de gestión de base de datos [Eclipse].

Es en esta plataforma donde EMF se integra en forma de plug in, permitiendo construir

modelos, su representación y el soporte correspondiente al mismo.

2.2.3.2. Eclipse Modeling Project (EMP)

Eclipse Modeling Project se centra en la evolución y promoción de tecnologías de desarrollo basadas

en modelos sin la necesidad de la comunidad Eclipse. Grandes compañías como Borland e IBM son

líderes del proyecto y se han unido para continuar en el avance de tecnologías de modelado a través de

Eclipse, adoptando estándares abiertos y relacionados con el modelado de software [EMP]. En

[Eclipse-1] se muestra el alcance propuesto por EMP que a continuación se describe:

a) Desarrollo de la sintaxis abstracta (metamodelado)

Es un framework para dar soporte a la definición de la sintaxis abstracta de lenguajes de

modelado que soporten modelado de negocios y software, utilizando un metalenguaje o un

estándar de metamodelado. El framework para desarrollar la sintaxis abstracta soporta la

edición, validación, pruebas y reconstrucción de los metamodelos creados con las facilidades

del metamodelado. Este conjunto de capacidades son proporcionadas por EMF, el cual es una

parte esencial de EMP [Eclipse-1].

b) Desarrollo de la sintaxis concreta (símbolos correspondientes al metamodelo)

La sintaxis concreta se define a través de una sintaxis abstracta que se haya construido

previamente. Esta sintaxis puede ser textual o gráfica y se define a través del proyecto

Graphical Modeling Framework (GMF).

2.2.3.3. Eclipse Modeling Framework (EMF)

EMF es un Java framework y generador de código para construir herramientas y otras aplicaciones

basadas en un modelo estructurado. EMF permite crear estos modelos en cuatro diferentes maneras: a

través de interfaces Java, modelos de clase de Rational Rose, modelos de clase de Ecore y documentos

XML. Para llevar a cabo esta tarea, el entorno Eclipse debe cargarse con diferentes plug in necesarios

para trabajar con archivos “.ecore” y para generar modelos y editores gráficos [EMF].



a) Crear un modelo EMF a través de interfaces Java

Para definir un modelo EMF usando código Java, se utiliza la programación tradicional de

Java, definiendo los atributos de cada clase y las relaciones entre las mismas a través de código

fuente. Cada atributo o clase que forma parte del modelo EMF debe tener una etiqueta

“@model” para identificar a cada elemento del modelo y para especificar información que no

puede ser capturada directamente en las declaraciones del código Java.

b) Crear un modelo EMF a través de un modelo de clases de Rational Rose

Para generar modelos a través de la especificación de un diagrama de clases de Rational Rose

se necesita seguir un procedimiento similar al anterior. La diferencia radica en el tipo de fuente

con la que se generará el modelo EMF.

Existe una mínima diferencia entre generar un modelo a partir de código Java y por medio de

modelos de Rational Rose. La diferencia radica en el nombre de los atributos, esto se debe a las

diferentes convenciones para nombrar a los atributos en los modelos Rose y en la convención

del estándar de Java.

c) Crear un modelo EMF a través de un documento XML

Crear un modelo a partir de un esquema XML no es algo trivial. La relación existente entre el

modelo resultante y el introducido inicialmente por el esquema XML es considerablemente

menos franca que la relación existente con una entrada a través de código Java o un modelo de

UML. Por consiguiente, la alternativa de generar un modelo de un esquema XML es más

complicada, resultando también en modelos más complicados, a veces innecesarios [EMF 03].

d) Crear un proyecto EMF a través de un modelo Ecore

Crear un modelo Ecore es la manera más simple para crear un generador de modelos. Un

modelo Ecore puede construirse a través de las herramientas que Eclipse proporciona para

dicha tarea o a través de Omondo. Éste es un plug in que se integra con el entorno Eclipse y

permite crear modelos UML.

2.2.3.4. Graphical Modeling Framework (GMF)

El proyecto Graphical Modeling Framework provee la infraestructura y componentes fundamentales

para el desarrollo de diseños visuales e interfaces de modelado con Eclipse. El objetivo de GMF es

proveer un puente generativo entre EMF y GEF [GMF-2].

GMF trata de expresar los modelos de dominio construidos en EMF, agregando la capacidad

de representar visualmente estos modelos mediante la construcción de editores visuales. Por lo tanto, se

puede decir que GMF es una extensión a las capacidades ofrecidas por EMF.

Para completar el desarrollo de un modelo (elementos, atributos, semántica de los elementos,

reglas, restricciones, roles, etc.), su notación gráfica (símbolos asociados a cada elemento, conectores,

etc.) y su correspondiente herramienta (soporte para el modelo) en Eclipse, se necesita la integración

de tres fases fundamentales y de los archivos generados en cada una de estas fases [GMF-2]. A

continuación se describe brevemente en qué consisten las fases de definición del modelo, la notación

gráfica y componentes necesarios para construir un DSL. Estas fases se muestran en el diagrama de la

figura 2.3.



1) Desarrollo de un modelo de dominio: puede desarrollarse de tres maneras diferentes para

EMF: a través de código Java, un documento XML o un diagrama UML. Cada una de estas

técnicas se mencionaron y describieron de manera general en el punto 2.2.3.3 (pág. 12). El

modelo descrito con cualquiera de las tres técnicas mencionadas se carga dentro del proyecto

EMF, generando como salida el archivo con extensión “.ecore” (modelo de dominio)

contenedor de toda la definición del modelo.

2) Desarrollo de la definición gráfica: aquí se define la notación grafica correspondiente a cada

uno de los elementos descritos por el modelo (elementos del modelo, tipos de conectores entre

elementos del modelo, etc.). Éstos pueden ser rectángulos con puntas redondas o cuadradas,

círculos, cuadrados o cualquier figura geométrica necesaria para representar un elemento o

relación del modelo. En GMF la notación gráfica puede obtenerse de un conjunto de imágenes

predefinidas que se utilizan con frecuencia o definiendo una galería de figuras propias.

Figura 2.3. Componentes y modelos usados durante el desarrollo basado en GMF

2.2.3.5. Tabla de resumen de características

La tabla comparativa que a continuación se presenta aborda a las tres herramientas más importantes en

el desarrollo de lenguajes de modelado y las más importantes en el mercado actual. Los estudios

encontrados en la literatura solamente se enfocan en comparar alguna combinación de dos de estas tres

herramientas. En la tabla 2.1 se pueden apreciar y comparar las características más importantes, así

como ventajas y desventajas de una u otra herramienta.



Tabla 2.1. Resumen de características de las herramientas para crear un DSL

EMF Microsoft DSL Tools MetaEdit+

Características de un DSL

Definición de la Sintaxis Abstracta (SA)

Lenguaje de metamodelado Ecore

(Versión ligera de MOF)

propietario

(no explicito)

Propietario

(GOPPRR)

Conceptos del lenguaje de

metamodelado

Eannotation, Eclass,

EDataType, EEnum,

Epackage, EEnumLiteral,

EAtribute, Ereference

Clase, propiedad,

referencia, embebido,

herencia

Objeto, propiedad,

relación, rol, puerto,

grafo

Estructura del metamodelo Jerárquica (árbol) Jerárquica (árbol) grafo

Editor visual para sintaxis

abstracta

Si (diagrama en árbol) Si (diagrama en árbol) NO

(tabla de bindings)

Definición de la Sintaxis Concreta (SC)

Editor visual para sintaxis

concreta

Si (GMF) NO (editar fichero

XML)

Si (editor simbol)

Nivel de personalización

del aspecto gráfico del DSL

Alto Bajo Alto

Separación clara entre

sintaxis abstracta y

concreta

Si No No

Otros

Técnicas a utilizadas Utiliza estándares de la

OMG (MOF, UML)

No propone ninguna

técnica en concreto

Tiempo en el mercado Desde junio del 2002 Desde el 2005 Desde 1993

Estrategia general

Promovido por Fundación Eclipse (IBM,

Intel, Borland, Nokia, etc.)

Por el líder del

mercado Microsoft

MetaCase

Lenguaje utilizado para

restricciones

OCL C# Lenguaje de

informes

(propietario)

Lenguaje utilizado para

generación de código

Java C# (o Visual Basic) y

etiquetas

Lenguaje de

informes

propietario

Potencia lenguaje para

restricciones

Muy Alta Muy alta (C#) Media, necesidad de

usar

un lenguaje externo

en

ocasiones

Representación de los

metatipos

Objetos Etiquetas en un

archivo

XML

Objetos

Almacenamiento del

metamodelo

Archivo (.ecore) Archivo Repositorio

(Base de datos)

Facilidad de manejo del

editor de DSL

Media Baja Alta

Documentación Media Escasa Muy buena

Integrada en un entorno Eclipse Visual Studio No

Tipo Libre Comercial Comercial

Nivel de madurez Medio-Alto Bajo Muy Alto

Plataforma/portabilidad Java (muy portable) Windows

(poco portable)

Herramienta basada

en Java (muy

portable)



2.3. Descripción del problema

Cuando se pretende desarrollar aplicaciones de gran tamaño bajo el planteamiento del entorno RAD

Lotus Domino Designer, se parte directamente de la implementación a nivel ambiente de desarrollo sin

modelar la aplicación previamente. El problema consiste en que actualmente no se cuenta con un

lenguaje de modelado conceptual adecuado y con un nivel de abstracción que permita realizar el

diseño conceptual de las aplicaciones en este entorno RAD. Es decir, un lenguaje apropiado que

permita especificar y diseñar la estructura que tendrán los sistemas de software antes de empezar a

implementarlos.

Este enfoque, basado en la programación directa sobre el entorno de desarrollo sin un diseño

previo ocasiona:

Dificultad para manejar el proceso de desarrollo de software, ocasionando problemas de

comunicación, sistemas mal diseñados, equipos de trabajo sin coordinación y pérdida del

compromiso de realizar un sistema de la manera fácil y simple debido a que no fueron

planeados y diseñados adecuadamente.

La complejidad de los sistemas de software de gran tamaño excede la capacidad intelectual de

un solo individuo, tanto que una sola persona sería incapaz de comprender todos los detalles de

su implantación y transportarlos directamente a código fuente de una manera fluida y rápida

obteniendo un sistema de software con un nivel alto de calidad. Esto es prácticamente

imposible sin la ayuda de métodos o técnicas con las que se puedan describir aplicaciones antes

de implementarlas. Por otro lado, la complejidad no puede desaparecer, ya que no existen los

medios para eliminarla, por lo tanto se busca tratar de manejarla y reducirla. Como

consecuencia de un mal manejo de la complejidad se tienen proyectos retrasados, con costos

extras y que no cumplen con los requisitos planteados inicialmente.

Como consecuencia de la complejidad de desarrollar software de gran tamaño, se presenta la

imposibilidad para calcular el tiempo de desarrollo de aplicaciones. Esto implica también no

calcular costos, así como el esfuerzo humano-computadora que se necesita para llevar a cabo

de principio a fin el desarrollo de un proyecto de software. Por lo tanto, no puede predecirse

información con exactitud y de manera general sobre las variables mencionadas anteriormente

para el futuro desarrollo de sistemas.

2.4. Objetivos

2.4.1. General

Los objetivos que se persiguieron en este trabajo de investigación son dos: el primero es caracterizar

los elementos que se utilizan para desarrollar aplicaciones en el entorno RAD Lotus Domino Designer.

El segundo y principal objetivo que se persigue es generar un DSL tomando como base el resultado de

la caracterización. Con el lenguaje resultante se busca llevar a cabo la etapa de diseño conceptual de

aplicaciones Web desarrolladas en Lotus Domino Designer a través del modelado conceptual de las

mismas.



2.4.2. Específicos

Los objetivos específicos que se satisficieron son los siguientes:

Se realizó un análisis del entorno RAD Lotus Domino Designer. Con este estudio se conoció

de manera general la forma en que las aplicaciones se desarrollan en este entorno. Se tuvo un

primer contacto con el conjunto de componentes que se utilizan en el desarrollo, así como de

las características generales de cada componente. Después de haber realizado el

reconocimiento del dominio de Lotus Notes/Domino se pudo seleccionar el método de análisis

de dominio orientado a características (FODA) para llevar a cabo la caracterización del

entorno.

Se modificó el método FODA para caracterizar los elementos de diseño de software de LDD

como primitivas de modelado conceptual. Se identificaron los elementos para desarrollar

aplicaciones Web, así como el conjunto de propiedades de cada uno, sus relaciones y

restricciones.

Se formalizaron los componentes obtenidos como resultado de la caracterización (entidades,

relaciones y restricciones) como especializaciones de elementos del lenguaje de modelado

unificado UML. La formalización se realizó a través de un Perfil UML, el cual es el

mecanismo para extender el propio UML y crear así lenguajes para dominios más específicos.

Por lo tanto, la técnica de modelado para la representación de las primitivas de diseño de

aplicaciones de LDD son los Perfiles UML.

2.5. Justificación y beneficios

2.5.1. Justificación

En la actualidad, los entornos RAD no cuentan con lenguajes para modelar una aplicación antes de

comenzar su desarrollo. No contar con un lenguaje de modelado implica no reducir la complejidad para

llevar a cabo el ciclo de desarrollo de software, también no realizar diseños que permitan solucionar

problemas que pueden presentarse en etapas posteriores. Por ejemplo en la implementación, en donde,

el costo de reparar los errores por lo general es elevado, todo esto viene a reducir por tanto la calidad

del software. Además, no es posible modelar las aplicaciones que se pretenden desarrollar ni realizar

estimaciones del posible tamaño que tendrán y por ende, no es posible obtener datos del esfuerzo y

costo, así como el tiempo que implica llevar a cabo su desarrollo.

Cuando no se cuenta con un modelo conceptual de la aplicación a desarrollar, el analista

trabaja sólo con elementos de modelado aislados, es decir, sólo los utiliza en el desarrollo y no en un

diseño conceptual previo al desarrollo de la aplicación, por tanto, estos elementos sólo tienen sentido al

formar parte o estar integrados en una aplicación final.

Como se comentó anteriormente, Lotus Domino Designer sufre las mismas carencias que otros

entornos RAD al no contar con una fase de modelado conceptual que permita describir la estructura

(estática) de los sistemas a desarrollar, representando tanto las primitivas de modelado como las

relaciones entre estas primitivas.

En el año 2006, IBM estimó que existían más de 125 millones de usuarios desarrolladores de

sistemas de software que utilizan LDD como herramienta de desarrollo [IBM 07], por lo que podemos

constatar que LDD no es un software que tenga poco tiempo en el mercado. Por ejemplo, la Comisión



Federal de Electricidad (CFE) cuenta con la red de servidores de Lotus Domino más grande de

Latinoamérica y sus aplicaciones de trabajo colaborativo se encuentran basadas en esta plataforma de

desarrollo.

En el contexto de la CFE, el IIE se encarga de realizar el desarrollo de aplicaciones

colaborativas para la CFE y en los últimos 6 años ha desarrollado un gran número de este tipo de

aplicaciones. Existen alrededor de 400 bases de datos y aplicaciones desarrolladas e instaladas en dicha

plataforma. Muchas de estas aplicaciones carecieron de un modelado formal o completo por la

ausencia de técnicas específicas para esta tecnología. Algunos ejemplos del tipo de aplicaciones

desarrolladas son: mensajería instantánea, agendas electrónicas, aplicaciones para compartir

documentos, aplicaciones para mejorar el flujo de trabajo, foros de discusión, entre otros.

Como puede observarse, el espectro de aplicaciones desarrolladas con LDD es grande, por lo

que se tiene una necesidad real de diseñar modelos conceptuales que representen las aplicaciones antes

de empezar su desarrollo. Una ventaja importante que se tuvo en el desarrollo de esta tesis es que se

cuenta con la colaboración del IIE, esto permite contar con el apoyo de expertos desarrolladores de

aplicaciones en Lotus Domino Designer, además de contar con infraestructura y material necesario

para llevar a cabo un análisis de este entorno RAD.

2.5.2. Beneficios

El diseño de un DSL permite la reducción de la complejidad de diseñar modelos para

aplicaciones Lotus. Esto es útil debido a que para diseñar actualmente modelos de aplicaciones

Lotus se tienen que agregar manualmente los atributos a cada elemento utilizado y cada vez

que se modele con el mismo. También tiene que cuidarse que los elementos relacionados en

verdad puedan relacionarse, pues las reglas para relacionar un elemento contra otro sólo están

en mente de quienes saben desarrollar aplicaciones Lotus. Un lenguaje ad hoc a Domino

permite que esta validación se realice de manera automática en una herramienta que dé soporte

al lenguaje.

Se obtuvo un lenguaje de modelado conceptual específico (DSL) que permite diseñar modelos

utilizando los elementos de desarrollo de LDD. Estos modelos se generan con el DSL

permitiendo utilizar las primitivas conceptuales y relaciones del entorno LDD para definir la

estructura estática de la aplicación a desarrollar. Además pueden utilizarse los elementos de

UML para enriquecer la semántica de los modelos.

El proceso de desarrollo del DSL sirve como referencia para seguir un proceso similar en la

caracterización de otros entornos de desarrollo y en la construcción de nuevos lenguajes para

esos entornos.

El DSL para aplicaciones Lotus Notes/Domino permite llevar a cabo un mejor diseño de la

estructura de las aplicaciones para este dominio permitiendo tener un mejor desempeño en su

desarrollo guiando al implementador a través de los diagramas para que éste tenga una idea

más completa de los elementos que deben intervenir para desarrollar cierta funcionalidad.

El uso de un lenguaje facilita definir mecanismos que permitan traducir los modelos

conceptuales que se generen en especificaciones de más bajo nivel de abstracción, por ejemplo

el código fuente de una aplicación. Esto facilita también aplicar métricas para definir el tamaño

esperado del sistema a desarrollar, basándose en el modelo conceptual. En este sentido, existen

propuestas de investigación que calculan el tamaño y complejidad de un sistema, dado el

modelo conceptual que lo define.



Actualmente se está desarrollando una herramienta computacional con el perfil UML (DSL)

presentado en esta tesis que permite automatizar el proceso de generar modelos conceptuales

para futuras aplicaciones de LDD.

2.6. Metodología de solución

La metodología de solución que se realizó comprende el desarrollo de actividades que aparecen en la

figura 2.4 y que a continuación se muestran:

Estudio de LDD. Se realizó un estudio sobre LDD con la finalidad de conocer mejor la manera

en la que se desarrollan las aplicaciones en LDD, así como los elementos que se utilizan en la

construcción de aplicaciones Web para Notes.

Estudio de metodologías de análisis de dominio. Se realizó un estudio de los diferentes

métodos de análisis de dominio para analizar cuál de éstos era el más adecuado para

caracterizar los elementos de diseño que tiene LDD. Se seleccionó el método de análisis

orientado a características FODA para realizar dicho análisis.

Caracterización de los elementos de diseño de LDD. Se aplicó el método de análisis de

dominio FODA para caracterizar los elementos de LDD. La caracterización comprendió las

siguientes actividades:

a. Análisis del contexto de LDD. Actividad que comprendió el análisis del dominio de

aplicación de LDD para determinar cuáles son los elementos de diseño de aplicaciones

Web. En esta actividad se desarrollaron diagramas de contexto y de estructura que

ayudaron a delimitar el dominio que se modeló en la fase de modelado del dominio.

b. Modelado del dominio de LDD. Actividad que comprendió definir los elementos que se

modelaron y sus características. Así como determinar cuáles elementos se relacionan con

el elemento analizado y cuál es el tipo de relación manejada en términos de modelado, así

como las características de las relaciones.

En esta actividad se definió el metamodelo de LDD, el cual permite ver los elementos y

relaciones existentes entre los mismos para definir modelos de aplicaciones Web para

Notes.

Estudio de técnicas de representación visual. Se realizó un estudio de técnicas de

representación visual, encontrando que los símbolos que mejor representan a cada elemento

son los utilizados en el entorno de desarrollo LDD, puesto que el desarrollador ya se encuentra

familiarizado con los mismos.

Aplicación de un Perfil UML para aplicaciones Web de LDD. Se aplicó esta técnica a los

elementos y relaciones resultantes de la caracterización de LDD. La técnica consistió en

especializar algunos elementos del núcleo de UML y aportándole a los mismos un conjunto de

propiedades que caracterizan a cada elemento. Con lo anterior se aprovecha todo el potencial

de UML y su semántica para especificar modelos.

Pruebas. Para probar el lenguaje se realizaron algunos modelos de una aplicación que se

encuentra en un portal del IIE denominado Sistema Integral para la Gestión del Conocimiento

(SIGCO). Las pruebas se realizaron a través de un prototipo implementado en la herramienta

de modelado UML Enterprise Architect en su versión de evaluación 7.1.



2.7. Alcances y límites del proyecto

2.7.1. Alcances

Como producto final de la caracterización se obtuvo una serie de primitivas conceptuales (elementos

de diseño de LDD), sus relaciones y la semántica de estas relaciones. Definir las primitivas, su

semántica y relaciones fue el punto de partida para definir el DSL que se desarrolló.

A continuación se mencionan los alcances considerados dentro de esta tesis:

1. Selección de una metodología de análisis de dominio adecuada para llevar a cabo la

caracterización de los elementos de diseño del entorno RAD Lotus Domino Designer.

2. Se caracterizaron las primitivas de diseño de LDD mediante la aplicación de la técnica de

análisis de dominio orientada a características FODA y se obtuvo cada elemento como

primitiva de modelado, así como las relaciones entre cada elemento.

3. Se diseño un Lenguaje de Dominio Específico (DSL) para modelar conceptualmente

permitiendo definir, representar y describir (diseñar) la estructura que tienen las aplicaciones

antes de ser implementadas.

Figura 2.4. Metodología de solución



2.7.2. Límites

En esta sección se mencionan las limitaciones que se tuvieron para la caracterización y desarrollo en

general de esta tesis:

1. La caracterización sólo se llevó a cabo para un entorno RAD, el cual es Lotus Domino

Designer proporcionado por el IIE.

2. No se construyó un ambiente visual para dar soporte al lenguaje de modelado, sólo se

implementó un prototipo con el cual se realizaron los modelos para probar el lenguaje.

3. El prototipo construido en Enterprise Architect no tuvo implementados el conjunto de reglas de

modelado y restricciones del lenguaje, por esta razón no se pudo medir la correctez, completez

y no ambigüedad, puesto que el prototipo incompleto no facilitaba al usuario crear los

modelos. Para realizar una mejor prueba se necesita un ambiente que dé soporte a todos los

atributos, entidades, relaciones y restricciones que en el lenguaje se definen.

4. Los diferentes RAD que existen en el mercado manejan una serie de elementos de

programación diferentes. Por esta razón sería muy complicado generar un lenguaje de

modelado específico de manera general, es decir, que pueda ser usado e implementado para

varios entornos RAD. En caso de proponerse un lenguaje de modelado, sería demasiado

genérico y por tanto no podría describir de manera correcta y completa a los elementos,

propiedades y relaciones que existen para todos los elementos de los entornos RAD que se

encuentran en el mercado. De esta manera, se plantea utilizar un entorno RAD específico:

Lotus Domino Designer.

5. El DSL sólo permite modelar la estructura de las aplicaciones Web que se pretendan

desarrollar en LDD. Este lenguaje sólo puede utilizarse para modelar en etapas de diseño y no

para modelar otras etapas del ciclo de desarrollo de software. Por ejemplo, no es para modelar

la ingeniería de requerimientos.

6. No es la intención del lenguaje reducir la velocidad de desarrollo de una aplicación Domino,

sino que se utilizará para etapas de diseño y no de implementación.


Capítulo 3. Marco teórico

En esta sección se presentan los conceptos claves para la realización de esta tesis: entornos de

desarrollo rápido de aplicaciones (RAD), modelado conceptual, análisis de dominios, un panorama

general de LDD, Perfiles UML y Lenguaje de Dominio Específico (DSL).

3.1. Desarrollo Rápido de Aplicaciones

El Desarrollo Rápido de Aplicaciones (RAD, por sus siglas en inglés), es un proceso de desarrollo de

software creado inicialmente por James Martin en 1980. El método comprende el desarrollo

interactivo, la construcción de prototipos y el uso de utilidades CASE (del inglés Computer Aided

Software Engineering). Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar

también la usabilidad, la utilidad y la rapidez de ejecución.

En la actualidad, el término RAD se suele utilizar para referirse al desarrollo rápido de

Interfaces Graficas de Usuario (GUI, por sus siglas en inglés) tal como Glade, o IDEs de desarrollo

completas como Delphi, Foxpro, Visual Basic o Anjuta [WikiP 07].

Capitulo 3. Marco teórico


En [WALT 07], se define a los RAD de la siguiente manera: es un proceso de desarrollo de

software que permite construir sistemas utilizables en poco tiempo, aproximadamente de 60 a 90 días.

El RAD es una metodología para comprimir el análisis, el diseño, la estructura y las fases de

prueba en una serie de ciclos de desarrollo cortos, iterativos. Esto tiene distintas ventajas sobre el

modelo secuencial tradicional de desarrollo. Por ejemplo, la iteración permite eficacia y autocorrección

[CREAT 07].

La figura 3.1 muestra cómo se lleva a cabo el ciclo de desarrollo de software tradicional contra

el de un ciclo RAD.

Existen en la actualidad entornos RAD con diferentes funcionalidades que permiten crear

rápidamente aplicaciones específicas para un ámbito, en [WikiP-2 07] se mencionan y describen

brevemente algunos de estos entornos.

3.2. Modelado conceptual

En la actualidad no existe un acuerdo general que defina este término, sin embargo los modeladores de

datos entienden generalmente el alcance aproximado del mismo. Es por ello que la siguiente definición

se encuentra basada en las definiciones dadas en [EPS 05] y [GUERRERO 07].

El modelo conceptual de un sistema de software constituye una abstracción externa que

describe mediante diagramas y notaciones con distinto grado de formalidad el conocimiento que debe

poseer una persona acerca de un sistema, conocimiento que se encuentra almacenado en la memoria a

largo plazo de quien necesita un sistema. Un modelo conceptual explica cosas del mundo real, los

conceptos más significativos en un dominio del problema, identificando sus atributos y asociaciones.

Visto desde el punto de vista del usuario, el modelo conceptual:

Representa la información que cualquier usuario debería tener o adquirir sobre el sistema.

Figura 3.1. Ciclos de desarrollo de software.



Está formado por un conjunto de elementos (conceptos) y relaciones entre ellos, observables

desde el exterior.

El modelo conceptual debe suministrar información al usuario acerca de qué hace el sistema y

los mecanismos para llevarlo a cabo, puede incluir pocos atributos significantes para aumentar la

definición y visualización de entidades. Su importancia radica en que debe favorecer el aprendizaje del

sistema, es una guía para predecir el comportamiento del sistema, y además, el usuario utilizará este

modelo para establecer estrategias encaminadas a resolver sus problemas. Los principios en los que

debe estar basado el modelo conceptual harán, por tanto, que sea:

Asimilable (mediante el uso de conceptos familiares al dominio en cuestión).

Consistente (coherente y bien formulado).

Simple (uso de descripciones comprensibles por un usuario medio).

Un modelo conceptual es un diagrama que ilustra una serie de relaciones entre ciertos factores

que se cree impactan o conducen a una condición de interés. Un buen modelo conceptual presenta un

cuadro de la situación en el sitio del proyecto, muestra supuestos vínculos entre los factores que afectan

a la condición de interés, muestra las principales amenazas directas e indirectas que afectan a la

condición de interés, presenta sólo factores relevantes, está basado en datos e información sólidos y es

el resultado de un esfuerzo de equipo [FOF 07].

3.3. La ingeniería de dominios

El desarrollo de sistemas siempre consume un conjunto de actividades que aumentan el tiempo de

desarrollo y por lo tanto los costos de éstas. Los paradigmas o ciclos de vida para el desarrollo de

nuevas aplicaciones han solucionado en parte este problema. Ejemplos de estos paradigmas son la

ingeniería inversa y la reingeniería. Existen sistemas que tienen similitudes funcionales con otros

sistemas y que forman una familia entre ellos. Si se pudieran reutilizar algunas partes de estos sistemas,

el desarrollo de nuevas aplicaciones que tengan similitudes funcionales sería menos complejo. Por esta

razón es importante encontrar las similitudes y diferencias que pueden localizarse en una familia de

sistemas para crear componentes reutilizables de software que permitan crear aplicaciones dentro del

dominio con el que se trabaja.

La Ingeniería de Dominios (ID) es el proceso de identificar dominios candidatos en un

conjunto de sistemas, mediante la selección y desarrollo de métodos de análisis, diseño e implantación

y creación de activos de software reutilizables [HOLIB 93]. El dominio es una familia de aplicaciones

de sistemas existentes o futuros que comparten funciones y datos comunes. La ID dirige la creación

sistemática de arquitecturas y modelos de dominios, los cuales son utilizados por la ingeniería de

aplicaciones para construir nuevos sistemas. Es decir, la ID define procesos repetibles del desarrollo de

sistemas y los automatiza tanto como sea posible.

La ingeniería de dominios se caracteriza por dos fases: análisis e implantación. El análisis de

dominios consiste en identificar similitudes entre problemas, encontrar soluciones con partes comunes

e identificar diferencias entre problemas. La implantación de dominios es el proceso de identificar

componentes reutilizables basados en el conocimiento, el modelo y la arquitectura genérica, resultado

de la fase de análisis de dominios [SEI 07]. La creación, administración y mantenimiento de un

depósito de activos reutilizables es también una parte importante de esta fase.



3.4. Análisis de dominio

Es el proceso de identificar, recolectar, organizar y representar información relevante en un dominio

basándose en el estudio de sistemas existentes y sus historias de desarrollo, el conocimiento capturado

de expertos, la teoría fundamental y la tecnología que surge dentro de un dominio. El análisis debe

limitar con cuidado el dominio, considerar la manera en la que se asemejan los sistemas en el mismo y

la forma en que se diferencian, organizar un entendimiento de las relaciones entre varios elementos y

representar este entendimiento de un modo útil [KRUT 96].

La meta del análisis de dominio es definir la estructura, requisitos y captura de los mismos en

un modelo de dominio. Para entender adecuadamente el dominio, deben analizarse los sistemas

existentes para identificar los requisitos de software. Se entrevista a los expertos para definir las

abstracciones de dominio de alto nivel y verificar la información obtenida del análisis de sistemas

existentes. Las tendencias futuras en los requisitos y tecnología de dominio deben ser identificados

para asegurar que los resultados permanezcan viables de manera que un reembolso en la inversión de

análisis de dominio sea obtenido [HOLIB 93].

El análisis de dominio es la actividad clave que debe ser integrada dentro del proceso de

desarrollo para sistemas de software. Un análisis de dominio identifica concordancias entre sistemas

dentro de un dominio de problema dado. Estas concordancias se implementan entonces como

componentes de software los cuales pueden ser reutilizados por nuevos sistemas dentro de ese dominio

[COMER 90].

En [PRIETO 90] se define al análisis de domino de la siguiente manera: puede verse como un

proceso donde la información usada en los sistemas de software que se desarrollan se identifica,

captura, estructura, y organiza para una extensa reusabilidad. Específicamente, el análisis de dominio

se trata del desarrollo y evolución de una infraestructura de información para apoyar la reutilización.

Los componentes de esta infraestructura incluyen modelos de dominio, normas de desarrollo y

bibliotecas de componentes reusables.

Actualmente existen numerosas técnicas de análisis de dominios. Cada técnica se enfoca en

incrementar el entendimiento de un dominio capturando la información como un modelo. Es necesario

hacer notar que uno de los resultados de aplicar una técnica de análisis de dominio es la caracterización

precisa de los elementos que componen el dominio de aplicación. Por este motivo, el término

caracterización se utiliza como parte del objetivo de esta tesis. A continuación se describirán

brevemente algunos acercamientos hacia el análisis de dominio.

3.5. Método de Análisis de Dominio Orientado a Características (FODA)

En 1990, el Instituto de Ingeniería de Software (SEI) de la Universidad de Carnegie Mellon en

Pittsburgh, Pennsylvania, introdujo una metodología de análisis de dominio conocida como Análisis de

Dominio Orientado a Características FODA (del inglés Features Oriented Domain Analysis). El

método FODA sostiene el descubrimiento, análisis y documentación de similitudes y diferencias de un

dominio. El resultado del proceso de análisis es representar un gran volumen de información dentro de

un modelo; los analistas de aplicación analizan, organizan y clasifican la información de cada uno de

los sistemas [KRUT 93].

El método FODA fue resultado de un estudio profundo de otros acercamientos hacia el análisis

de dominio. La aplicación exitosa de varias metodologías hizo que se enfocara hacia los procesos y

productos del análisis de dominio. Como resultado, el estudio de la viabilidad FODA [SEI 90]



estableció métodos para llevar a cabo un análisis de dominio, describiendo los productos para el

proceso del análisis de dominio y estableciendo el significado para usar estos productos en el desarrollo

de aplicaciones. El concepto orientado a características de FODA se basa en el énfasis que el método

pone en identificar características distintivas dentro de una clase de sistemas de software relacionados.

Estas características resultan en la creación de un conjunto de productos que definen el dominio

[HOLIB 93].

3.5.1. Fundamentos de la metodología FODA

El método FODA se basa en un conjunto de conceptos y primitivas de modelado, estos se utilizan para

desarrollar productos genéricos de un dominio y que sean ampliamente aplicables en el mismo. Los

conceptos básicos de modelado utilizados para crear los productos del dominio son: la abstracción y el

refinamiento [KRUT 96]. La abstracción se utiliza para crear aplicaciones específicas de un dominio.

La naturaleza genérica de los productos se crea abstrayendo "factores" comunes de un dominio. El

método FODA se enfoca en las aplicaciones del dominio que pueden ser abstraídas al nivel donde no

existen diferencias entre las mismas. Los refinamientos se utilizan para obtener productos genéricos.

Una vez que la abstracción de las aplicaciones se realizó, el factor que hace a cada aplicación única se

incorpora en los productos genéricos del dominio como refinamiento de la abstracción.

Las aplicaciones de un dominio específico pueden desarrollarse como refinamientos

posteriores de los productos del dominio utilizando la abstracción general como punto de partida y

seleccionando después las características alternativas y opcionales que los hacen específicos. La

abstracción de las aplicaciones de un dominio se realiza utilizando las primitivas de modelado de

agregación/composición, generalización/especialización y la parametrización. El método FODA aplica

las primitivas de agregación y generalización para capturar las características de abstracción de las

aplicaciones en el dominio en función [KRUT 93].

Las diferencias entre las aplicaciones se capturan en refinamientos. Una abstracción puede ser

refinada (compuesta o especializada) en diferentes formas, dependiendo del contexto en el cual se

hacen los refinamientos, el resultado es un producto de dominio consistente de una colección de

abstracciones y de una serie de refinamientos para cada abstracción junto con sus parámetros.

3.5.2. El proceso FODA

El estudio de la viabilidad de FODA [SEI 90] define un proceso para el análisis de dominio y establece

productos específicos para uso posterior. El proceso FODA se caracteriza por tres fases básicas:

1. Análisis del Contexto: definir los alcances (o límites) de un dominio para el análisis.

2. Modelado del Dominio: provee una descripción del espacio del problema hacia el

dominio, específicamente hacia el software.

3. Modelado de la arquitectura: crea la arquitectura del software para implementar

soluciones a los problemas en el dominio.

La figura 3.2 provee la estructura de la metodología FODA y la tabla 3.1 resume las entradas,

actividades y productos de cada fase en el proceso FODA y las relaciones entre sus productos.



Tabla 3.1. Actividades de las fases del método FODA

Fase Entrada Actividades Productos

Análisis del

Contexto

Sistemas Operativos, estándares Análisis de contexto Modelo de contexto

Modelado de

Dominio

Características, modelo de

contexto

Análisis de

características

Modelo de

características

Conocimiento del dominio de

aplicación

Modelado de

información

Modelo de

información

Tecnología del dominio, modelo

de contexto, modelo de

características, modelo de

información, requerimientos

Análisis funcional Modelo funcional

Modelo de

comportamiento

Modelado

Arquitectónico

Implementación de la tecnología,

modelo de contexto, modelo de

características, modelo de

información, información de

diseño

Modelado

arquitectónico

Estructura

Modelo de

subsistema(s)

3.5.2.1. Análisis de contexto

El análisis de contexto define el alcance de un dominio. Durante el análisis de contexto las relaciones

entre el "dominio de interés" y el exterior se establecen para identificar las diferencias entre las

instancias de los elementos. Las diferencias pueden ser identificadas, por ejemplo: cuando las

aplicaciones de un dominio tienen diferentes requerimientos de información o medidas de operación.

Los resultados del análisis de contexto junto con otros factores como la disponibilidad de experiencia

en el dominio, formación del dominio y las restricciones del proyecto, se utilizan para limitar el

alcance del dominio [CRUZ 01].

Fuente: [SEI90]

Figura 3.2. Estructura de la metodología FODA

Fuente: [SEI90]



El producto resultante del análisis es el modelo de contexto. Este modelo incluye un diagrama

de estructura y un diagrama de contexto. El diagrama de estructura puede ser un diagrama de bloque

informal, donde el dominio se divide en tres niveles: nivel alto (describe a las aplicaciones), medio

(funcionalidades de las aplicaciones) y bajo (describe la implementación de las funcionalidades).

Un análisis exhaustivo proporciona un mayor detalle y en consecuencia el dominio se

comprende mejor. Cualquier otro dominio relevante debe estar incluido en este diagrama. El diagrama

de contexto es un diagrama de flujo de datos mostrando el flujo de datos entre una aplicación

generalizada dentro del dominio y las entidades y abstracciones con las que se comunica. La diferencia

de utilizar diagramas de flujo de datos dentro del análisis de dominio con respecto a otros usos típicos

es la variedad de flujo de información a través de la frontera del dominio. El análisis de dominios debe

considerar ya sea un conjunto de diagramas o texto para describir esta variabilidad.

Estos productos proporcionan a los participantes del análisis de dominio una comprensión

común de la relación del alcance del dominio con otros dominios, de las entradas/salidas y de los

requerimientos de información almacenados en un alto nivel [KRUT 93, KRUT 96].

3.5.2.2. Modelo del dominio

El modelo del dominio identifica las similitudes (características comunes) y las diferencias que

caracterizan las aplicaciones dentro del dominio. La etapa de modelado del dominio consiste de tres

actividades: modelar la información, analizar sus características y analizar la funcionalidad.

1. Modelado de la información. Se define el conocimiento y se capturan los requerimientos de

la información del dominio que son esenciales para las aplicaciones instrumentadas del

dominio. El modelo de la información puede tomar la forma de un modelo Entidad Relación

(ER), una red semántica u otras representaciones como un modelo de objetos. El modelo de

información es utilizado por el analista de requerimientos y el diseñador de software para

garantizar que las abstracciones y descomposiciones adecuadas de información sean utilizadas

en el desarrollo del sistema. El modelo de información también define información que se

supone proviene de fuentes externas [SEI 90].

2. El Análisis de características. Captura la comprensión que los clientes tienen de las

capacidades generales de las aplicaciones en un dominio. Para un dominio, las similitudes y las

diferencias entre sistemas relacionados, son designadas como características y son proyectadas

en el modelo de características. Estas características junto con las operaciones necesarias, sus

atributos y las variaciones de representación son resultados del modelo de características; ya

que este modelo generaliza y parametriza los modelos producidos en este análisis. El modelo

de características es el medio principal de comunicación entre los clientes y los desarrolladores

de nuevas aplicaciones. Las características son significativas para los usuarios finales y ayudan

a los analistas en las derivaciones de una especificación del sistema que proporcionará las

capacidades deseadas [SEI 90].

3. El Análisis funcional. Identifica el control y flujo de datos, las similitudes y diferencias del

software de las aplicaciones de un dominio. Esta actividad permite abstraer y estructurar las

funciones comunes encontradas en el dominio y la secuencia de aquellas acciones en un

modelo. Las similitudes y las entidades del modelo de información forman la base para la

abstracción del modelo funcional. El control y flujo de datos de una aplicación individual

pueden ser instanciados o derivados del modelo funcional con una adaptación apropiada. Con

un modelo funcional el diseñador comienza a comprender cómo debe proporcionar las

características y hacer uso de las entidades seleccionadas [SEI 90].



El proceso de modelar el dominio también produce un diccionario de términos y abreviaturas

que se utiliza para describir características comunes y entidades en el modelo. Este diccionario ayuda a

evitar una gran cantidad de errores de comunicación ofreciendo a los usuarios información del dominio

que incluye: una ubicación central para buscar términos y abreviaturas que son completamente nuevos

y definiciones de términos que son utilizados de una manera muy específica dentro del dominio.

3.5.2.3. Modelado de arquitectura

El modelado de arquitectura proporciona una solución de software para aplicaciones en el dominio. En

esta fase se desarrolla un modelo de arquitectura o modelo de referencia para la fase de diseño. El

diseño detallado y la construcción de componentes pueden ser hechos a partir de este modelo. El

modelo es un diseño de alto nivel de aplicaciones de un dominio y se enfoca en identificar procesos

concurrentes y módulos comunes orientados al mismo. También localiza características comunes,

funciones y objetos de información definidos en los modelos del dominio para los módulos y procesos

[SEI 90].

3.6. Modelo de características

El propósito original del análisis de características es capturar en un modelo el entendimiento de los

usuarios y clientes acerca de las capacidades de las aplicaciones en un dominio [SEI 90].

Este modelo es un conjunto de características jerárquicamente organizadas. Es también una

notación y aproximación para modelar concordancias y variantes de una familia de productos. Las

relaciones entre características padres e hijas se categorizan por Batory (2005) de la siguiente manera:

1. Y (and). Corresponde a todas las subcaracterísticas que deben seleccionarse con la

característica padre.

2. Alternativa (alternative). Corresponde a que sólo una subcaracterística puede seleccionarse.

3. O (or). Corresponde a que una o más características pueden seleccionarse.

4. Obligatoria (mandatory). Corresponde a las características que son necesarias.

5. Opcional (optional). Corresponde a las características que son opcionales.

Un diagrama de características es una representación gráfica del modelo de características. La

notación gráfica se describe en la figura 3.3.

En un diagrama de características debe mostrarse si una característica es opcional, alternativa,

obligatoria u otra. También deben de mostrarse las diferentes figuras de acuerdo al tipo de relación

existente entre características. Cada característica debe nombrarse distintivamente y su definición debe

incluirse en un diccionario de la terminología del dominio.

La figura 3.4 muestra un ejemplo de un diagrama de características sobre las decisiones que

tiene que tomar un comprador de un nuevo automóvil. En la figura se muestra la característica

Y alternativo O obligatorio opcional

Fuente: [DON 05]

Figura 3.3. Notación del diagrama de características



alternativa para elegir entre transmisión automática, manual o ambas de un automóvil. También se

muestra la característica obligatoria para mostrar que un automóvil requiere un tipo de transmisión.

La característica opcional indica que un automóvil puede equiparse con aire acondicionado, pero no

necesariamente.

Las características alternativas pueden pensarse como especializaciones de una categoría más

general. Por ejemplo, las características manual, automática y ambos pueden pensarse como

especializaciones de la característica general transmisión.

3.7. Análisis de Dominio y Ambiente de Reuso (DARE)

DARE (del inglés, Domain Analysis and Reuse Environment) en una herramienta que da soporte al

análisis de dominio. DARE permite capturar información del dominio proveniente de los expertos del

dominio, de documentos de texto o del propio código fuente. DARE trata de dar soporte a los analistas

de dominios para extraer y recopilar información del dominio analizado produciendo varios modelos

de dominio (representaciones de importantes aspectos de un dominio) y produciendo también un

repositorio de recursos reusables para el mismo.

El método de DARE está parcialmente basado en método START Reuse Library Process Model

[PRIETO 91] y el primer prototipo se desarrolló en lenguaje C en una Workstation con UNIX

corriendo X-Windows y Motif en 1994. La primera versión de DARE se utilizo para desarrollar y

elaborar un libro de dominio y para investigar sobre el agrupamiento y extracción de frases y palabras

de un dominio asistido por computadora.

La meta principal de DARE es crear una arquitectura genérica que describa elementos de la

arquitectura y sus relaciones para una familia de sistemas. Algunos elementos y relaciones se

encuentran en la mayoría de los sistemas en el dominio (a esto se le llama concordancias o cosas

comunes). Otros elementos y relaciones, las variantes, se encuentran sólo en algunos sistemas

pertenecientes a la familia de sistemas. Las cosas comunes y variantes deben ser reconocidas,

analizadas y utilizadas para crear una arquitectura genérica con una estructura basada en cosas

comunes, pero capaz de acomodar a las cosas variantes.

Automóvil

Transmisión Caballos de fuerza Aire acondicionado

Característica

obligatoria

Característica

opcional

Característica

alternativa

Manual Ambos Automática

Principal razón: manual es más eficiente en el combustible.

Regla de composición: aire acondicionado

requiere más de 100 caballos de fuerza.

Fuente: [SEI 90]

Figura 3.4. Diagrama de características para la elección de un automóvil



3.7.1. Libro del dominio

Para dar soporte al análisis de dominios, DARE utiliza un libro de dominio. En [DARE 98] se

menciona que el analista de dominio ve a las tareas de análisis como la creación de un libro de dominio

que almacena la información provista por los expertos, documentos de texto y de sistemas

pertenecientes al dominio. Estas son las fuentes para producir un repositorio de componentes

reutilizables. El libro de dominio se compone principalmente de tres partes: las fuentes del dominio, el

análisis del vocabulario y el análisis de la arquitectura. La tabla 3.2 muestra los componentes del libro

de análisis de dominio.

Los expertos del dominio son personas capaces de proveer descripciones de los sistemas que se

encuentran en el dominio. El código fuente de los sistemas debe ser analizado para descubrir

información sobre la arquitectura y así obtener componentes reusables, mientras que los documentos

como manuales de usuario, documentos de requerimientos, documentos de diseño y otra

documentación disponible se analizan a través de la herramienta de análisis de texto de DARE. Esta

herramienta permite extraer términos y frases de los documentos para después utilizar las herramientas

de editor de grupos (cluster editor) y la de tabla de faces (facets table).

Tabla 3.2. Componentes del libro de dominio

Sections Chapters Entries How created

Table of Contents -- Headings Automatic

Part 1:

Domain Sources

Source Documents Document files User input & ordering

Source Code Code files User input & ordering

System Descriptions Structured text Direct user input

System Architectures Architecture specs Graphical user input

System Feature Table Feature table Assisted user input

Source Notes Notes User input & ordering

Part 2:

Vocabulary

Analysis

Basic Vocabulary Keywords & phrases Assisted text analysis

Facets Facet table & editor Assisted text analysis

Synonyms Synonym table Assisted user input

Templates Template table Assisted user input

Thesaurus Terms & definitions Assisted user input

Vocabulary Notes Notes User input & ordering

Part 3:

Architecture

Analysis

Generic Architecture Architecture spec Graphical user input

Generic Features Feature table Assisted user input

Code structure Hierarchies Automatic code analysis

Architecture Notes Notes User input & ordering

Glossary -- Words & definitions User input, auto ordering

Bibliography -- Citations User input, auto ordering

User index -- Words & locators Automatic

Appendix Analysis Parameters Parameters & values Automatic

Activities log Event descriptions Automatic

Fuente: [DARE 98]

El editor de grupos soporta el análisis de dominio a través de la creación de grupos

conceptuales de palabras y frases relacionadas. Estos grupos ayudan a identificar entidades comunes a

un dominio como lo son funciones y objetos. Agrupar entidades es una técnica que permite descubrir

conceptos abstractos que no son obvios en el análisis, estas entidades comparten algún grado de

similitud conceptual. Una vez que se tiene el conjunto de palabras inmerso en un vocabulario, la

creación de grupos con el editor puede realizarse automáticamente.



La figura 3.5 muestra un ejemplo de una agrupación realizada a través del editor de grupos. A

la izquierda del editor se muestra una lista con el vocabulario (palabras o frases provenientes del las

fuentes textuales analizadas por el analista asistido por DARE). El analista puede arrastrar palabras al

centro del editor e ir modificando grupos o crear nuevos en caso de que no se utilice la creación

automática de grupos con el vocabulario.

Las fases proveen información organizacional de bajo nivel que el analista puede utilizar para

revisar y refinar las arquitecturas de los sistemas provistos por los expertos del dominio. La tabla de

faces, la tabla de características del sistema, las arquitecturas del sistema y las estructuras de código

son utilizadas por el analista para crear una arquitectura genérica y una tabla de características

genéricas para caracterizar los aspectos comunes y variantes que se permitirán en los sistemas

construidos, usando la arquitectura genérica. Cuando un proyecto se completa, el libro del dominio

representa un estudio minucioso, un análisis del dominio, una arquitectura genérica, una tabla de

características, un vocabulario y un repositorio de recursos reutilizables. Todo esto proporciona la base

para implementar el dominio.

En [DARE 98] se menciona que DARE puede ser útil a varios tipos de ingenieros de software

y administradores. La figura 3.6 muestra a los usuarios que pueden hacer uso de esta herramienta, en la

figura se muestra al analista encargado de tomar los requerimientos, del mantenimiento, a los expertos

analistas de un dominio, entre otros.

Fuente: [DARE 98] Figura 3.5. Ejemplo del editor con un grupo



El libro de dominio de DARE organiza la información que se adquiere y produce durante el

análisis del dominio y guía al analista a través de la metodología DARE. El libro de dominio incluye:

todas las fuentes del dominio;

el resultado de un análisis del vocabulario;

el resultado de un análisis de la arquitectura, incluyendo el análisis del código;

información resumida como lo es un glosario, una bibliografía, un catalogo de usuario y

apéndices.

DARE también incluye un modelo de procesos. El modelo de procesos ilustra cómo la

herramienta DARE da soporte a las secciones del libro.

Como ya se menciono anteriormente, existen tres fuentes para el dominio: texto, código y

expertos del dominio. Las entradas de estas tres fuentes se procesan y colocan en la sección de fuentes

del dominio en el libro. El análisis del vocabulario contiene el resultado de análisis extensivo de las

fuentes textuales. La sección del análisis de la arquitectura contiene los resultados del análisis del

código y la documentación realizada por el analista sobre las cosas comunes y variables que se

encontraron en el análisis. El glosario y la bibliografía se crean y actualizan continuamente durante el

análisis de dominio, mientras que la tabla de contenidos, el catalogo y el apéndice se generan

automáticamente por la herramienta DARE. La figura 3.7 muestra el modelo de proceso de DARE.

Figura 3.6. Usuarios de DARE



La última pieza de información adquirida de los expertos del dominio es la arquitectura de cada

sistema en el dominio. Las arquitecturas del sistema se registran utilizando un editor de arquitecturas

de propósito general. La figura 3.8 muestra un ejemplo del editor de arquitecturas.

Figura 3.7. Modelo de procesos en DARE

Figura 3.8. Editor de Arquitecturas



Como resumen, a continuación se mostrarán las principales herramientas que DARE incluye:

una interface basada en formas para recoger información general de los expertos del dominio;

un editor grafico que permite registrar arquitecturas del sistema;

una tabla de características para resumir cosas comunes y variables de los sistemas;

una suite de herramientas de procesamiento de texto para extraer el vocabulario del dominio a

través de las fuentes textuales;

una herramienta de agrupación para clasificar faces y esquemas del vocabulario del dominio y

para identificar cosas comunes y variables;

una tabla de características del sistema para registrar decisiones acerca de las cosas comunes y

variantes en sistemas basados en una arquitectura genérica;

y un glosario, bibliografía, catálogo de usuario y un apéndice para recolectar y organizar

información como referencia.

Una vez que se completa el libro del dominio, contendrá una especificación detallada de todo

el dominio analizado.

3.8. Lotus Notes/Domino, un panorama general

En [IBM 07] Lotus ha sido descrito de la siguiente manera: Lotus Notes/Domino es una familia de

servidores y clientes, se define como una plataforma integrada de software de aplicaciones web y

mensajería, esta familia se encuentra conformada por una gama de herramientas, entre éstas se

encuentran tres servidores: Domino Messaging Server, Domino Enterprise Server y Domino Utility

Server. Los servidores ofrecen diferentes servicios, por ejemplo:

Almacenamiento de objetos: permite almacenar cualquier cantidad de documentos de

diferentes tipos.

Directorio: un directorio simple maneja todas las fuentes de información para el servidor y la

configuración de la red, administración de la aplicación y la seguridad.

Seguridad: se cuenta con autenticación de usuarios, control de acceso flexible, firma digital y

encriptación.

Reproducción: la reproducción automática distribuye y sincroniza información y aplicaciones

entre sitios geográficamente distribuidos.

Mensajería: un avanzado sistema de mensajería cliente-servidor con un calendario y

planificador pre construido permite enviar información personal y en grupos fácilmente.

Servidor Web: cuenta con un servidor de aplicaciones web integrado que puede almacenar

sitios web que un navegador, cliente Notes y un cliente móvil pueden acceder, un servidor de

páginas que son almacenadas en el sistema de archivos o en una base de datos Domino.

Flujo de trabajo: permite la distribución, envío y rastreo de documentos acorde al proceso

definido en una aplicación.

Agentes: permiten automatizar procesos que frecuentemente se llevan a cabo, eliminando la

tediosa tarea de administración y apresurando las aplicaciones de negocios.

Entorno de desarrollo: Domino Designer es un software de propósito general, un IDE que

provee un acceso fácil a todas las características del servidor Domino.

Modelo de objetos Domino: ofrece un modelo unificado para acceder sus objetos a través de

clases, donde se usa LotusScript o Java. Esto permite cambiar entre lenguajes de programación

sin tener que aprender nuevas maneras de programar para Domino.

Integración libre con datos de la empresa.

Escalabilidad y confiabilidad.



Como se mencionó anteriormente, Lotus cuenta con una variedad de herramientas disponibles

para las diferentes necesidades que pueden presentarse. Por lo tanto estas herramientas tienen

numerosos clientes disponibles para usar, cada uno diseñado para encontrar necesidades específicas,

estos clientes son:

Lotus Notes 6

Domino Designer 6: el cliente de desarrollo

Domino Administrator 6: el cliente administrador del sistema

Clientes móviles (PDAs, celulares con Internet habilitado)

iNotes Web Access

iNotes para Microsoft Outlook

Otros clientes POP/IMAP

3.8.1. Lotus Domino Designer (LDD)

Lotus Domino Designer pertenece a la familia Lotus Notes/Domino, es un entorno Web de

programación de aplicaciones abiertas e integradas que dispone de herramientas para crear e implantar

aplicaciones de colaboración con funciones de seguridad. Lotus Domino Designer está diseñado

específicamente para crear aplicaciones que faciliten el flujo de información entre los sistemas de una

organización y sus procesos de negocios. Estas aplicaciones ayudan a establecer relaciones comerciales

con los clientes y socios a través de sus servicios de aplicaciones. Por ejemplo, flujo de trabajo,

directorio, mensajería y seguridad; al mismo tiempo permiten a los empleados que tratan directamente

con el público tomar decisiones eficaces basándose en la información que tienen a su alcance.

Lotus Domino Designer permite escribir aplicaciones que pueden correr en navegadores Web y

clientes Notes. Se puede escribir código en Java, Lotus Scripts, XML, lenguaje de formulas, acciones

simples, Java Script, este último soportado por los navegadores Web y los clientes [TULI 02].

3.9. Lenguaje de Dominio Específico (DSL Domain-Specific Language)

Los Lenguajes de Dominio Específico son lenguajes adaptados a un dominio de aplicación específico.

Brindan beneficio en la expresividad y la facilidad de uso, comparado con lenguajes de programación

de propósito general. Sin embargo, el desarrollo de un DSL es complejo, requiriendo conocimiento

profundo del dominio de aplicación y destreza en el desarrollo del lenguaje [MERNIK 03].

En [NGOC 07] se describe a un DSL de la siguiente manera:

Los lenguajes de dominio específico se diseñan para dar soporte a un dominio específico y para

resolver un problema a través de abstracciones y semánticas específicas al mismo. Esto define un

conjunto de conceptos de modelado específico, reglas y restricciones extraídas de un dominio del

problema. Cada concepto generalmente tiene una representación visual que puede utilizarse para

construir un modelo de dominio de una manera visualmente configurable. El modelo representa el

problema en un alto nivel sin involucrar ningún aspecto de implementación. Generadores de código

específico para un dominio interpretan estos modelos y producen la implementación para una

plataforma y lenguaje de programación específica.

A través del uso de un DSL para modelar, los diseñadores pueden trabajar directamente con los

conceptos del dominio del problema especificando la solución que puede proveer potencialmente un

número de beneficios incluyendo:



Notaciones visuales amigables con el usuario para el dominio.

Optimización y análisis específico de dominio a través del modelo.

Automatización de tareas a través de la generación de código.

Adopción de líneas de productos para un dominio específico.

Facilitar la descripción de datos y configuración de sistemas.

El Modelado de Dominio Especifico (DSM, por sus siglas en inglés) provee una solución:

permite al desarrollador ocultar detalles a través de la elevación del nivel de abstracción en el cual las

aplicaciones se construyen. Los conceptos básicos se representan como tipos de objetos disponibles en

un nuevo DSL. Los desarrolladores de aplicaciones pueden modelar las aplicaciones usando estos

conceptos de alto nivel y generar código fuente [JUHA 06].

En la actualidad, existe un número considerable de herramientas para generar un DSL. Algunas

de éstas como MetaEdit+ son herramientas independientes, mientras que otras, como el kit de

herramientas DSL Tools de Microsoft u openArchitectureWare se encuentran integradas dentro de un

IDE, lo que limita a estas herramientas ser efectivamente utilizadas fuera de su entorno.

3.10. Perfiles UML

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 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 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 [HECKEL 03, FUENTES 02].

OMG (del inglés, Object Management Group) especifica dos posibilidades a la hora de definir

lenguajes para dominios específicos. Éstas corresponden con las dos situaciones mencionadas

anteriormente: 1) se define un nuevo lenguaje (alternativa de UML); o 2) se extiende 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 que se denominan Perfiles UML (del inglés UML Profiles).

Cada una de estas dos alternativas presenta ventajas e inconvenientes. Así, definir un nuevo

lenguaje ad hoc permite mayor grado de expresividad y correspondencia con los conceptos del

dominio de aplicación, al igual que cuando se hace un traje a la medida. No obstante, 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 se debe

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.

En este trabajo se ha elegido la opción de extender UML utilizado el mecanismo de los Perfiles

UML. 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.



3.10.1. Razones para elaborar un Perfil UML

Para el caso en el que no se requiera modificar la semántica de UML, sino sólo particularizar algunos

de sus conceptos, no es necesario definir un nuevo lenguaje utilizando el MOF (del inglés Meta Object

Facility) [FUENTES]. UML incluye un mecanismo de extensión en el propio lenguaje que permite

especificar lenguajes de modelado que son derivados de UML. De forma más precisa, el paquete

Profiles de UML 2.1.2 [OMG 07] utiliza 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.).

En la especificación de UML 2.1.2 [OMG 07] se señalan varias razones por las que un

diseñador quisiera 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, 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 (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: 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 a un determinado estereotipo. Los valores etiquetados se representan de forma gráfica como

atributos de la clase que define el estereotipo.



3.10.2. 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 [OMG 07] sólo se limita a definir el concepto de Perfil y sus contenidos. Sin embargo, en

[FUENTES] se propone una serie de pasos que permiten contar con ciertas guías y recomendaciones

que sirven de ayuda a la hora de especificar un Perfil UML para una plataforma o dominio de

aplicación concreto. En este caso se requiere definir un Perfil UML para desarrollar aplicaciones Web

a través del entorno de desarrollo LDD. A la hora de construir un Perfil UML, Lidia Fuentes

[FUENTES] propone seguir los siguientes pasos:

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 se

definiría dicho metamodelo utilizando los mecanismos del propio UML (clases, relaciones de

herencia, asociaciones, etc.), de la forma usual como se haría si el objetivo no fuese definir un

perfil UML. Se debe 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 se dispone del metamodelo del dominio, entonces se pasa a definir el Perfil. Dentro del

paquete «profile» debe incluirse un estereotipo por cada uno de los elementos del metamodelo

que se desea 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

un principio cualquier elemento que se hubiese 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 se están

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.

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.


Capítulo 4. Análisis de Lotus Domino

Designer

El presente capítulo aborda el análisis del entorno LDD con la finalidad de conocer el ambiente de

desarrollo, así como los elementos que lo conforman.

4.1. Estudio del entorno Lotus Domino Designer (LDD)

Iniciando con la metodología presentada en el capítulo 2 (ver figura 2.4), se llevó a cabo un estudio

sobre el entorno de desarrollo Lotus Domino Designer. El objetivo de este estudio fue conocer los

componentes con los cuales se desarrollan las aplicaciones Lotus Notes/Domino y conocer de manera

general la funcionalidad del entorno y del dominio.

En la actualidad existe una tendencia notable hacia el desarrollo de aplicaciones basadas en el

Web. Estas aplicaciones por lo general necesitan de varios componentes para su desarrollo, por

ejemplo, un manejador de bases de datos, un servidor de aplicaciones y un entorno de desarrollo para

construir dichas aplicaciones. Los diferentes sectores industriales necesitan que la construcción se

realice en el menor tiempo posible y que permita compartir y obtener rápidamente información

Capitulo 4. Análisis de Lotus Domino Designer


importante para el flujo de trabajo o para la toma de decisiones. Es en este sentido que tienen su razón

de ser los entornos de desarrollo rápido de aplicaciones.

Un entorno RAD permite crear aplicaciones rápidamente en un promedio de 60 a 90 días.

Algunos RAD se encuentran conformados por un conjunto de herramientas que ofrecen una

funcionalidad completa desde la fase inicial de desarrollo hasta la fase terminal.

El entorno de desarrollo LDD pertenece a la familia de los entornos RAD. Este entorno se

compone de clientes y servidores, es una plataforma que integra aplicaciones web y de mensajería.

Estas aplicaciones permiten el flujo de trabajo y el desarrollo de aplicaciones para trabajar en

ambientes colaborativos.

LDD pertenece a la familia Lotus Notes/Domino, es un entorno Web de programación de

aplicaciones abiertas e integradas que dispone de las herramientas necesarias para crear e implantar

aplicaciones de colaboración con funciones de seguridad. LDD está diseñado específicamente para

crear aplicaciones que faciliten el flujo de información entre los sistemas de una organización y sus

procesos de negocios. Estas aplicaciones ayudan a establecer relaciones comerciales con los clientes y

socios a través de sus servicios de aplicaciones. Por ejemplo: flujo de trabajo, compartición de

directorio, mensajería y seguridad; al mismo tiempo permiten a los empleados que tratan directamente

con el público tomar decisiones, basándose en la información que tienen a su alcance.

LDD permite escribir aplicaciones que pueden correr en navegadores Web y en clientes Notes.

Se puede escribir código en Java, LotusScripts, XML, lenguaje de formulas, acciones simples y

JavaScript, este último soportado tanto por navegadores Web como por los clientes Notes.

4.2. Trabajando en Domino Designer

En esta sección se muestra un panorama general de las interfaces de usuarios de LDD. El espacio de

trabajo se encuentra conformado por varias páginas donde las base de datos de Domino se despliegan

como iconos. La base de datos también es accesible a través de marcadores, los cuales se localizan

dentro de la carpeta de marcadores, dentro de los documentos o en la barra de bookmarks (barra de

marcadores).

4.2.1. Iniciando Domino Designer

Existen tres maneras para iniciar LDD:

1. Desde el cliente Notes a través de un icono. Cuando se inicia Lotus Notes, la ventana que

aparecerá se ve como se muestra en la figura 4.1 (al menos que se haya especificado otra

página de inicio para el cliente Notes). En cualquier caso, en la parte izquierda de la figura, en

la barra de bookmarks, se puede ver un icono señalado. Hacer clic para abrir LDD.

2. Dando clic derecho en el icono de una base de datos y seleccionando Database Abrir en

Designer. Esta opción abre LDD con la base de datos especificada.

3. Seleccionando el menú Inicio de WindowsProgramasLotus ApplicationDomino

Designer (o simplemente dar clic en el icono de LDD sobre el escritorio de Windows).



4.2.2. LDD como cliente

Cuando LDD se abre, aparece la página de bienvenida. La funcionalidad de esta página (ver figura 4.2)

en Designer es similar a la del cliente Notes. Esta página tiene ligas a las tareas más comunes que se

pueden realizar, por ejemplo: crear una nueva base de datos o abrir una existente. La página inicial

provee cuatro opciones que se pueden elegir para personalizar el contenido de la página. Se puede

cambiar el contenido como se muestra en la caja desplegable de la figura 4.2. Las cuatro opciones

disponibles son las siguientes:

Quick links for common tasks (the default option)

Domino Objects for LotusScript and OLE

Domino Objects for DXL Support

JavaScript Object Model

Figura 4.1. Iniciando LDD desde el cliente Lotus Notes



Figura 4.2. Personalizando la página de bienvenida de Lotus Domino Designer

4.2.3. El panel de diseño

El panel de diseño permite acceder a los elementos de diseño de la base de datos con la que se trabaja.

Sólo basta hacer clic en la esquina superior derecha (Recent Database) para mostrar las bases de datos

recientes que se han utilizado en este panel. Se pueden crear carpetas para almacenar distintas bases de

datos. Por ejemplo, si se desea mantener varias bases de datos juntas de un proyecto central, sólo tiene

que agregarse una nueva carpeta al panel y crear las bases de datos en la misma.

Dentro de cada base de datos que se encuentra en el panel de diseño (ver figura 4.3) se localiza

una lista de los elementos de diseño y los tipos de fuentes que la base de datos puede contener. Un

signo (+) a la izquierda del tipo de elemento de diseño (por ejemplo, form) indica que contiene

elementos de diseño de ese tipo.

La lista de diseño tiene la siguiente funcionalidad:

Haciendo clic en el signo (+) despliega una lista de los elementos existentes en la lista de

diseño. Los cinco primeros elementos se muestran.

Si hay más de cinco elementos, una barra de desplazamiento aparece, se puede navegar con

esta barra a través de los distintos elementos enlistados.

Haciendo clic en un tipo de elemento, por ejemplo form, cargará la lista completa de elementos

al panel de trabajo, el cual está en la parte derecha de la ventana.



Figura 4.3. Panel de Lotus Domino Designer

4.2.4. Ventanas a través de fichas

Las ventanas que se van abriendo en LDD se organizan a través de fichas. La figura 4.4 muestra un

ejemplo de este tipo de ventanas organizadas en fichas.

Figura 4.4. Organización de ventanas por medio de fichas

4.2.5. La carpeta de marcadores (bookmark)

La carpeta de marcadores permite crear carpetas y organizar proyectos dentro de éstas, así se puede

acceder rápidamente a las bases de datos. La figura 4.5 muestra el cuadro de dialogo para crear una

carpeta nueva. Las carpetas se muestran como iconos en la barra de marcadores.

Figura 4.5. Cuadro de dialogo para crear una nueva carpeta



4.2.6. La ventana de propiedades del objeto

La ventana de propiedades, también llamada infoBox es la herramienta más importante para controlar

el funcionamiento de los elementos diseñados. Cada elemento de diseño tiene al menos dos ventanas

para desplegar y mostrar sus propiedades.

1. Propiedades para el documento de diseño. Despliega propiedades que son comunes a todos los

elementos de diseño, por ejemplo para views, forms, pages o cualquier otra.

2. Cada elemento de diseño tiene también una ventana de propiedades específica al tipo de

elemento de diseño. Otros elementos tienen propiedades adicionales para objetos contenidos en

ellos, por ejemplo, una ventana de propiedades para el elemento field contenido en un form.

La ventana de propiedades permite cambiar entre las propiedades de un objeto y otro, es decir,

cuando se ve las propiedades de un objeto, se puede cambiar en esa misma ventana a las propiedades

de otros objetos que se encuentren contenidos en el mismo elemento. Se puede obtener ayuda

presionando la tecla F1 o haciendo clic en el icono correspondiente a la ayuda mientras se encuentra

activa la ventana de propiedades, así se obtendrá ayuda del elemento activo.

4.2.6.1. Ventana de propiedades del documento de diseño

Esta ventana está disponible sólo para el panel de trabajo cuando una lista de elementos de diseño se

despliega sobre ella, como se muestra en la figura 4.6. En la ventana se resaltan las propiedades de un

documento de diseño, la ventana de propiedades muestra cuatro fichas.

Figura 4.6. Propiedades del documento de diseño



4.2.6.2. Ficha de información del documento (info tab)

Esta ficha muestra información relacionada con el documento, por ejemplo, la fecha de creación, la

última fecha de modificación y el usuario que lo modificó, etc. La figura 4.7 muestra la ficha de

información.

4.2.6.3. Ficha para el tipo de campo (Fields tab)

La ficha campo (field tab o icono de forma triangular), muestra los nombres y valores de los campos

que contienen la información de diseño. Esta es una información interna que los desarrolladores

principiantes no tendrán necesidad de ver. Sin embargo, algunas veces es útil mirar el valor de un tipo

usando la ficha de la figura 4.8.

4.2.6.4. Ficha de diseño

La ficha mostrada en la figura 4.9 permite controlar la herencia de un elemento de diseño simple. Se

puede introducir el nombre de una plantilla de la que se quiera heredar el diseño de sus elementos o

seleccionar el checkbox que exente este elemento de ser actualizado cuando el diseño de la base de

datos se actualiza completamente.

Esta ventana también contiene un checkbox para seleccionar que el elemento de diseño se

oculte de un navegador Web, del cliente Notes o un dispositivo móvil. Esto es útil cuando se crean

aplicaciones para múltiples clientes, en donde frecuentemente se requiere otro elemento de diseño para

Figura 4.7. Ficha de información del documento

Figura 4.8. Ficha de campo



diferentes clientes. Para una instancia, se puede tener tres diferentes forms con el mismo nombre, uno

sólo para el cliente Notes, otro para el Web y uno más para el cliente móvil.

Figura 4.9. Ficha de diseño

4.2.6.5. Ficha de identificadores (ID) del documento

Esta ficha muestra el identificador universal (universal ID) de los elementos de diseño, así como el

identificador para note (ID notes). Cada elemento de diseño tiene estos dos ID, los cuales son únicos.

Por lo general esta información no es necesaria para diseñar aplicaciones en Notes. La figura 4.10

muestra la ficha correspondiente a los ID del documento.

4.2.6.6. Propiedades de los elementos de diseño

Para abrir la ventana de propiedades de un elemento de diseño específico, se debe tener un elemento

abierto en el panel de trabajo, no basta con seleccionarlo en el panel que muestra a los elementos de

diseño. La figura 4.11 muestra la ventana de propiedades para un elemento view. Para abrir la ventana

de propiedades de un elemento se pueden utilizar los siguientes métodos:

Presionando Alt + Enter.

Seleccionando el menú diseño (design) y después propiedades (properties).

Figura 4.10. Ficha de ID



Dando clic derecho en el panel de trabajo y después propiedades.

Dando clic en el icono de infoBox que aparece en la barra de herramientas que aparece por

omisión.

Cada elemento de diseño difiere en contenido en el panel de trabajo y tiene un conjunto de

propiedades diferentes asociadas al mismo.

4.2.6.7. Bloqueo de los elementos de diseño

El bloqueo permite resolver el problema de que dos desarrolladores editen al mismo tiempo un mismo

elemento de diseño cuando se trabaja con la misma base de datos.

Existen dos tipos de bloqueo que se pueden especificar:

Bloqueo explícito. Consiste en bloquear un elemento para que nadie más pueda modificarlo

hasta que el desarrollador decida desbloquearlo.

Bloqueo temporal. Cuando se está trabajando con un elemento de diseño, éste se bloquea

temporalmente de manera automática. Esto permite que ningún otro desarrollador pueda

modificar el elemento al mismo tiempo que el actual, eliminando la inconsistencia. Cuando un

elemento se termina de editar y se cierra, se desbloquea automáticamente para que otros

desarrolladores puedan editarlo.

Figura 4.11. Ventana de propiedades de una Vista (View)



4.2.6.8. Vista previa del diseño

Para mostrar la vista previa de una aplicación, se puede utilizar la barra de herramientas señalada en la

figura 4.12 o desde el menú DesignPreview in (Notes/Browser). Estos botones permiten obtener la

vista previa del desarrollo en curso a través del cliente Notes o de un navegador Web.

4.2.6.9. Paneles para programadores

Los paneles para los programadores se constituyen de dos partes:

Info list. Se puede seleccionar una de dos vistas:

a) Vista de objetos (Object view)

Esta vista (panel derecho figura 4.13) permite tener acceso inmediato a cualquier elemento

de diseño de una aplicación, sus eventos y atributos asociados. Un icono identifica el

lenguaje soportado por cada evento del elemento. LDD provee diferentes eventos

programables para manejar el cliente Notes y los eventos para el cliente Web. Cuando un

icono de un evento es una figura vacía, significa que el evento no tiene ningún código

programable. Cuando un icono de evento tiene una figura completa, significa que el evento

tiene código programable. Se puede navegar a través de la lista de objetos dando clic en los

signos (+/-) para expandir o contraer la lista desplegable para un elemento de diseño.

b) Vista de Referencia (Reference View)

Esta vista (panel izquierdo figura 4.13) es similar a la vista de objetos. Provee información

sensitiva al contexto basada en el tipo de programación que se usa. Por ejemplo, si se está

programando en LotusScript, la vista de referencia mostrará información acerca de los

objetos Domino. Se pueden pegar las funciones o métodos en el área de Script, en algunos

casos, con los parámetros. Esta vista debe usarse como una forma rápida para obtener

ayuda sobre programación.

Figura 4.13. Vista de objetos y vista de referencia

Área de Script

Figura 4.12. Barra de herramientas para la vista previa



Dependiendo de la selección que se haga en la vista de objetos, se muestra la ventana

apropiada en el área de script. En la ventana de propiedades de esta área se puede ajustar las

características a la necesidades, por ejemplo: cambiar el formato de texto para identificadores,

palabras claves y comentarios. El área de Script maneja la función de autocompletar, la cual es

útil a la hora de codificar. La figura 4.14 muestra el área de Script.

4.3. Elementos de Domino Designer

Los elementos de diseño de LDD permiten crear aplicaciones variadas para trabajar en ambientes

colaborativos, aplicaciones donde se requiere compartir información. Por ejemplo: repositorios de

documentos, aplicaciones de mensajería, para el flujo de trabajo, entre otras. Los elementos para

construir aplicaciones en LDD se dividen en: principales elementos, elementos de código compartido

(shared code), elementos como recursos compartidos (Shared resources) y otros elementos. A

continuación se describe de manera general a cada uno de estos elementos en la tabla 4.1.

Figura 4.14. Área de Scripts



Principales elementos Elemento Descripción

Base de datos Es una colección de información relacionada que se almacena en un simple archivo. Las aplicaciones de LDD utilizan al menos una base de

datos local o remota. Una base de datos mantiene información acerca del diseño en forma de datos. Estos datos se organizan como

documentos y un documento se define como un objeto que contiene texto, gráficos, video, objetos de audio o cualquier tipo de datos de

texto enriquecido.

Frameset Es una colección de frames que permite estructurar o dividir los sitios Web o las bases de datos Notes.

Frames 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. Los frames son personalizables a través de herramientas. Es posible asociar a un frame una página específica, una

vista, un formulario, Java Applet, componentes ActiveX o alguna URL. Los frames también pueden ser dinámicos, especificando formulas

o macros para calcular lo que se quiere desplegar en el frame.

Páginas (pages) En LDD una página es un elemento de diseño que se usa para desplegar información. A diferencia de un formulario que colecciona

información, las páginas se diseñan para presentar información al usuario. Un page ofrece un nivel de control alternativo para el diseño de

las páginas Web. Es posible diseñar páginas a través de la forma tradicional o con una herramienta HTML WYSIWYG (del inglés, What

You See Is What You Get).

Formularios

(forms)

Un formulario es un framework que permite ingresar y mostrar información en una base de datos. Este elemento es uno de los más

importantes para el diseño de aplicaciones, ya que con base a éste se introducen datos a una base de datos, la cual contiene documentos

creados a través de uno o más formularios.

Vistas (views) Una vista es una lista de documentos de una base de datos. Dependiendo del criterio de selección es posible desplegar todos los documentos

de la base de datos o sólo un conjunto de ellos. Una vista es una tabla de los contenidos de una base de datos. Los documentos se agrupan u

ordenan basándose en sus contenidos. Cada columna listada en una vista representa datos tomados de un solo documento. Cada columna

representa un campo o una combinación de éstos tomados de un documento.

Carpetas

(Folders)

Las carpetas son estructuralmente similares a una vista. Las carpetas listan documentos, pero no tienen un criterio para seleccionarlos. Los

usuarios deciden cuales documentos se almacenan en carpetas.

Elementos de código compartido Agentes

(agents)

Los agentes permiten automatizar tareas en Domino. Son programas independientes que realizan una tarea específica en una base de datos

para el usuario. Por ejemplo: completar documentos, cambiar valores de campos, enviar mensajes de correo, eliminar documentos o realizar

otras acciones como interactuar con aplicaciones externas.

Outline Los elementos outlines se parecen a los mapas de imágenes y navegadores. Proveen una forma de navegar en una aplicación a los usuarios.

No obstante, a diferencia de los mapas de imágenes y navegadores, los outlines permiten mantener una estructura de navegación en un sólo

lugar, similar a un diagrama de jerarquías.

Tabla 4.1. Elementos de diseño de Lotus Domino Designer



1 Sitio del documento: http://www.w3.org/TR/2000/NOTE-SOAP-20000508

2 Sitio del documento: http://www.w3.org/TR/2001/NOTE-wsdl-20010315

3 Sitio del documento: http://www.w3.org/TR/ws-arch

4 Sitio del documento: http://www.w3.org/2002/ws/

Subformularios

(subforms)

Un subformulario provee una manera de evitar el duplicado en el diseño de una sección de un formulario. Los subformularios reducen el

esfuerzo de desarrollo debido a que se pueden mantener grupos de elementos en un lugar y usar el subformulario en varios formularios.

Campos (fields) Un campo es la parte de una aplicación que recolecta datos. Cada campo almacena sólo un tipo de información y el tipo de dato del mismo

define el tipo de información que acepta. Por ejemplo: texto, números, fechas o nombres. Los campos pueden ser de tipo simple o

compartido. Ambos campos tienen las mismas propiedades, la diferencia es la forma en la que se utiliza cada uno. Un campo simple se crea

directamente en un elemento formulario, subformulario o alguna región de diseño. Un campo compartido se comporta igual que uno simple,

pero se crea independientemente de un elemento de diseño. Por esta razón, un campo compartido puede utilizarse en múltiples formularios

y no desaparece al momento de eliminarlo, caso contrario cuando se elimina un formulario con un campo simple. Cuando un cambio ocurre

en un campo compartido, por ejemplo: cambiar una propiedad, el cambio se refleja a todas las ocurrencias del mismo.

Columnas

(columns)

Una columna es el elemento organizador en una vista. Las columnas muestran un tipo de información acerca de los documentos listados.

Por ejemplo: el tema de un documento, el autor o la fecha de creación. Las columnas pueden mostrar el resultado de cálculos u operaciones

siempre y cuando devuelvan un valor del tipo de dato definido para la columna. Una columna puede ser simple o compartida al igual que

las acciones y los campos. Una columna simple se crea y utiliza solamente en una vista y un folder. Las columnas compartidas permiten

crear una columna común para insertarse en múltiples vistas en la misma base de datos. Una columna compartida es un elemento de diseño

que una vez insertado en una vista pasa a ser parte del mismo.

Acciones

(actions)

Un elemento action es código que consiste de una combinación de acciones o una simple acción de Domino. Un elemento action puede

codificarse con el lenguaje de formulas, lenguaje LotusScript, JavaScript o Common JavaScript. Los actions pueden asociarse a un view,

form, subform o page y pueden ser simples o compartidos. Un action simple es aquel que se codifica directamente en alguno de los

elementos de diseño que soportan actions. Un action compartido se codifica independientemente de los elementos de diseño y que puede

por tanto insertarse en múltiples elementos que soporten la utilización de actions compartidos.

Librerías

Script (Script

Libraries)

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

formularios y páginas.

Servicios Web

(Web Services)

Un elemento Web service es una aplicación autónoma basada en XML que puede publicarse e invocarse en el Web. Domino soporta los

Servicios Web como se muestra en los documentos SOAP v1.1 (del inglés Simple Object Access Protocol)1 y WSDL v1.1 (del inglés Web

Services Description Language)2. Para tener una mejor referencia pueden revisarse los documentos de Arquitectura de los Servicios Web

(Web Services Architecture)3 y Actividad de los Servicios Web (Web Services Activity)

4.



Elementos como recursos compartidos Imágenes

(Images)

El recurso de imágenes permite almacenar todas las imágenes que serán usadas en una base de datos. Se recomienda utilizar este recurso en

lugar de pegar o importar una imagen en varios formularios o páginas. Esto permite ganar espacio de almacenamiento, permitiendo a los

clientes llamar una imagen rápidamente y facilitando el mantenimiento en caso de cambiar la imagen en múltiples lugares.

Archivos (files) Este recurso permite compartir archivos importados a la base de datos y utilizarlos en el diseño de las 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. Al igual que las imágenes y hojas de

estilo, un elemento file puede incluirse en un formulario, subformulario, vista o página.

Applet Los Applets de Java también se pueden agregar como un recurso compartido. Si se realiza algún cambio sobre un Applet, sólo necesitará

copiarse como recurso compartido y las aplicaciones podrán volver a utilizarlo normalmente. Los Applets por lo general se usan en los

navegadores Web. También puede utilizarse en el cliente Notes incluyéndolo en un formulario o página. Para crear un Applet se utiliza el

ambiente de programación preferido y después importarlo como recurso compartido en Domino.

Hojas de estilo

(Style sheets)

Las hojas de estilo permiten tener control sobre muchos aspectos en el diseño de páginas Web. Por ejemplo: sobre las ligas, texto, margen,

capas, fuentes, estilo, color, entre otros. Las hojas de estilo se insertan sobre páginas, formularios o subformularios y proveen la misma

funcionalidad que se les conoce en otros lenguajes de programación.

Conexiones de

Datos (Data

Connectios)

Este recurso permite crear conexiones de datos y campos ligados que conectan un formulario a una base de datos externa. Esto permite

tener una integración entre Domino y otras fuentes de datos. Las fuentes de conexión de datos DCR (del inglés, Data Connection Resource)

permiten definir conexiones de fuentes de datos externas. Por ejemplo, una base de datos relacional. También permite utilizar la conexión

para ligar los campos de un formulario a una fuente de datos externa. Los DCR son reutilizables en una aplicación y pueden compartirse

con otras.

Otros elementos en la barra de marcadores (bookmarks) Sinopsis

(Synopsis)

Es una herramienta para generar un reporte detallado de una base de datos específica. Esta herramienta cubre cada componente de una

aplicación en Domino. El reporte detallado se utiliza para propósitos de documentación. Puede elegirse la información necesaria en el

reporte y el tipo de salida que tendrá. Esta salida es personalizable y puede desplegarse en un simple documento o en una base de datos

para su uso posterior.

Navegador

(Navigator)

Un navegador es una interfaz gráfica que permite a los usuarios acceder a vistas, datos de la base de datos de Domino u otras aplicaciones.

Un navegador puede incluir botones gráficos (hotspots), los cuales son áreas programadas donde un usuario puede hacer clic para ejecutar

una acción o invocar algún otro elemento de Domino. Los navegadores pueden utilizarse en el Web insertándolos dentro de un formulario,

subformulario o página.

Recursos de la

base de datos

(Data base

Resources)

Los recursos de base de datos son elementos que definen características, información y eventos propios de la base de datos. Se clasifican

en tres componentes: a) Database icon: el icono de la base de datos se utiliza para identificar a una base de datos rápidamente en la barra

de bookmark; b) Using database y about database: proporciona información a los usuarios acerca de cómo utilizar la base de datos y

sobre el propósito de la misma.



Otros elementos no encontrados en la barra de marcadores (bookmarks) Secciones

(sections)

Representa un área que puede expandirse o colapsarse para mostrar u ocultar los elementos contenidos en esa área. Una sección puede

incluir campos, objetos, regiones de diseño y texto. Las secciones se utilizan para agrupar y organizar elementos en una página o

formulario. Las secciones trabajan bien para presentar grandes cantidades de información de un modo ordenado.

Campos

calculados

(Computer text)

Un campo calculado 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.

Tablas (tables) Representa una tabla de texto enriquecido. Existen cuatro tipos de tablas que pueden crearse en LDD: a) tablas básicas: son tablas con un

numero de columnas y renglones definidos; b) tablas con fichas: son tablas que permiten a los usuarios cambiar renglones haciendo clic

en las fichas que se encuentra en la parte superior de la tabla; c) tablas animadas: son tablas que intercambian renglones en un intervalo

de tiempo que el usuario determina; d) tablas programables: son tablas que intercambian renglones basándose en una acción o un campo

de fórmula.

Hotspot Es un área programada donde ejecuta una acción a través de un simple clic. Para automatizar un hotspot se necesita programarle una

acción. Los hotspots son ser de varios tipos: a) tipo liga: enlaza con otro objeto; b) texto pop up: despliega texto al momento de pasar el

ratón por un elemento; c) tipo botón: se utilizan para llevar a cabo una acción o fórmula, código LotusScript o JavaScript; d) tipo fórmula

pop up: despliega texto basado en los resultados que una fórmula arroje; y e) tipo acción: se utilizan para llevar a cabo un acción o

fórmula, código LotusScript o JavaScript.

Barra de acción

(Action bar)

Una barra de acción es un contenedor de acciones programadas. Éstas se encuentran en formularios, vistas y páginas. Una barra de

acción es una barra horizontal de botones, estos botones pueden contener tanto acciones simples como compartidas.

Entradas Outline

(Outline entry)

Las entradas de los outlines representan una pieza en la estructura de navegación del mismo. Estas entradas pueden ser acciones o

categorías que organizan otras entradas con nivel más profundo en el outline. Una entrada puede ser una liga a un page, un documento,

vista, folder, página Web e incluso otra base de datos Domino.

Button Representa a un tipo de hotspot, el cual se utiliza para llevar a cabo una acción, formula, código LotusScript o JavaScript.


Capítulo 5. Caracterización de Lotus Domino

Designer

El presente capítulo aborda el proceso de desarrollo para crear el lenguaje de modelado. Este capítulo

abarca desde el análisis del dominio de LDD hasta la formalización del DSL para aplicaciones Web

para Notes.

5.1. Estudio de metodologías para analizar dominios de aplicación

El descubrimiento sistemático de objetos que contienen características comunes entre sistemas que

pertenecen a una misma familia y que resuelve un conjunto de problemas que se encuentran dentro de

un dominio en particular es una técnica requerida para tener éxito en el desarrollo de componentes

reutilizables.

El análisis de dominio (AD) es una técnica que se aplica para conocer características comunes

entre objetos. El AD permite observar y examinar un conjunto de sistemas de software relacionados y

proveer un modelo de referencia para describir las características variables y comunes. También puede

proponer un conjunto de arquitecturas para la implementación de nuevos sistemas basados en una

arquitectura genérica que comparte características de sistemas similares.

Capitulo 5. Caracterización de Lotus Domino Designer


En la literatura sobre la reutilización de componentes de software se coincide que a través de

décadas la mejor técnica para reutilizar componentes de software tiene un mayor éxito cuando se aplica

en contextos o dominios de aplicaciones restringidos. Otra coincidencia encontrada es la creación de un

repositorio donde se almacene toda la información que se recabe del dominio en forma sistematizada.

Para llevar a cabo un análisis de dominio y recolectar, almacenar y organizar la información

obtenida del análisis, así como obtener componentes reutilizables que puedan utilizarse para el

desarrollo de aplicaciones en un entorno RAD, es necesario encontrar una técnica que permita

sistematizar el proceso de análisis y encontrar objetos con características comunes dentro de un

dominio de aplicación. Estas características comunes se agrupan en objetos o componentes que pueden

reutilizarse posteriormente para el desarrollo de aplicaciones en un dominio específico.

Para fines de este trabajo de investigación se propone analizar el entorno de Lotus Domino

Designer. Este entorno contiene un conjunto de elementos de diseño que permiten desarrollar

aplicaciones. Es necesario conceptualizar estos elementos en un modelo para establecer la semántica de

los mismos, las relaciones existentes al momento de trabajar conjuntamente con éstos y las

restricciones en determinados casos de uso.

En la página 25 sección 3.5 (método FODA) y página 30 sección 3.7 (método DARE) se

describieron los dos métodos más actuales que se encuentran en la literatura para realizar análisis a un

dominio de aplicación con el objetivo de obtener un conjunto de componentes reutilizables. De estos

métodos y herramientas se ha seleccionado uno para sistematizar toda la información recabada de los

expertos del dominio, documentos y del propio analista del entorno LDD.

Las conclusiones a las que se ha llegado después de haber analizado ambas metodologías son

las siguientes:

DARE es una metodología que apareció hace algunos años, concretamente en 1992. El soporte

que ofrece la metodología fue implementado en 1994 en versiones de C para UNIX y

posteriormente Visual Basic 3.0 para Windows 3.1. Por lo anterior sería ilógico utilizar estas

herramientas para dar soporte a la metodología por ser obsoletas. Una desventaja de DARE es

que la metodología no se encuentra descrita de manera detallada en la literatura disponible,

sino que sólo se habla de las partes que lo conforman y de los productos resultantes de la

metodología en cada una de sus fases.

El método FODA se orienta más a definir de manera general el aspecto funcional de un

sistema. Este método no expone un cambio claro entre cada etapa, ya que una etapa te lleva a

la otra. El soporte existente para este método está obsoleto al igual que en la metodología

DARE, pues se realizó para el sistema operativo UNIX en el año de 1991. Al igual que la

metodología DARE, el método FODA expone de manera abstracta las fases que se tienen que

realizar para el análisis de dominio y no se enfoca en cómo realizarlas de manera detallada.

Por lo anterior, las metodologías DARE y FODA sólo pueden utilizarse para crear un modelo

de referencia sobre las fases que deben de seguirse para realizar un análisis de dominio. La parte

importante de realizar el proceso de cada una de estas fases tendría que ser definido por cada analista

del dominio en base a las necesidades del domino de aplicación y a los resultados que se requieren

obtener del análisis.

Por ejemplo, el resultado de analizar el entorno RAD Lotus Domino Designer es obtener

componentes reutilizables, relaciones y restricciones que pueden darse entre estos componentes. Lo

anterior con la finalidad de crear un modelo del dominio de aplicación y un lenguaje que permita



construir aplicaciones en un nivel conceptual más elevado que el de utilizar el entorno de desarrollo

mismo. Para obtener estos resultados el analista debe enfocar las fases de análisis de algún método

hacia la obtención de estos resultados e inventar o imaginarse el procedimiento que seguirá antes de

empezar cada fase, así como la forma de sistematizar la información.

Desafortunadamente, la metodología FODA no puede aprovecharse en toda su extensión para

caracterizar un ambiente de desarrollo. Algunas de las etapas que FODA utiliza para caracterizar un

conjunto de aplicaciones no son útiles cuando se cuenta con un conjunto de elementos de diseño

definidos, como es el caso de LDD. Cuando se trata de caracterizar un ambiente de desarrollo, no se

trata de obtener un conjunto de elementos de diseño para convertirlos en primitivas de modelado, sino

que, se trata de caracterizar un conjunto de elementos de diseño ya definidos en el ambiente con la

finalidad de obtener características comunes y relaciones que puedan existir entre estos elementos. La

caracterización también tiene la finalidad de abstraer estas características en un modelo de dominio,

creando primitivas de modelado y relaciones que permitan posteriormente utilizarse para modelar una

aplicación antes de empezar su implementación.

Por lo anterior, la metodología FODA no fue utilizada en su totalidad, sino que se ha realizado

una adaptación a la misma. La adaptación consiste en eliminar algunos de los modelos que no son

útiles para analizar el dominio y llevar a cabo la caracterización. La descripción original de las fases de

análisis de dominio de FODA se encuentra en la página 25, sección 3.5. En el siguiente apartado se

describe el proceso de caracterización de LDD a través de la modificación de algunas fases de FODA

para identificar el subconjunto de elementos con los cuales pueden construirse aplicaciones Web en

LDD, así como las relaciones y restricciones de usabilidad entre estos elementos.

5.2. Caracterización de Lotus Domino Designer

Caracterizar el entorno LDD consiste en obtener y definir un conjunto de elementos, sus relaciones y

restricciones existentes, así como las propiedades de las relaciones a través de un análisis de dominio.

Al conjunto de elementos obtenidos se le conoce como primitivas de modelado.

La caracterización que a continuación se presenta se desarrolló a través de la metodología de

análisis de dominio orientado a características FODA. Este método se compone de tres etapas para

analizar dominios de aplicación, pero sólo dos de ellas son factibles: el análisis del contexto y

modelado del dominio. LDD cuenta con un conjunto de elementos para construir los sistemas

pertenecientes a su dominio. Para analizar este entorno de desarrollo no se partió de aplicaciones de

LDD como lo marca el método, sino del conjunto de elementos mencionados anteriormente.

La metodología FODA se modificó de acuerdo a las necesidades que se presentaron en el

transcurso del análisis. A continuación se presenta el proceso de análisis de dominio para caracterizar

el conjunto de componentes de LDD. En este proceso se presenta el desarrollo para las fases de análisis

de contexto y modelado de dominio. En la fase de análisis de contexto se limitó el dominio de

aplicación que se pretende modelar. En la fase de modelado de dominio se definieron los elementos de

diseño, las relaciones, restricciones y propiedades de las relaciones. Como resultado del modelado del

dominio se obtuvo un metamodelo que describe el conjunto de elementos, relaciones y algunas

propiedades.



Análisis

del

contexto

Modelado

del

dominio

FODA

Sintaxis abstracta

Perfil

UML

Sintaxis concreta

Definición

de símbolos

y figuras

DSL

UML

Perfil

UML

Lenguaje de

Dominio Específico

5.3. Proceso de Análisis de Dominio de Lotus Domino Designer

De acuerdo a la metodología FODA presentada por Kang (1990), el análisis de dominio reúne y

representa información de sistemas de software que comparten un conjunto común de datos y

capacidades. Para efectos de este análisis no se recopilaron las aplicaciones pertenecientes al dominio

de LDD como lo marca la metodología. Se analizó directamente el entorno de desarrollo para obtener

un conjunto de primitivas de modelado compuestas de elementos o entidades, relaciones y restricciones

entre los elementos y propiedades de las relaciones.

La figura 5.1 muestra las fases que se desarrollaron para crear el Lenguaje de Dominio

Específico (DSL). En la parte izquierda de la figura se muestra a la sintaxis abstracta. Esta sintaxis se

refiere a la definición de los conceptos, semánticas, reglas, restricciones y todos los elementos que

conforman el lenguaje de modelado (caracterización de LDD). En la parte central de la figura aparece

la sintaxis concreta, aquí se definen las figuras que representan visualmente los elementos que

conforman el lenguaje de modelado. En la parte derecha aparecen los perfiles UML, los cuales se

utilizan para definir de manera formal a los elementos que conforman el lenguaje de modelado y que

utilizan toda la semántica y potencial que UML proporciona.

La sintaxis abstracta se realizó aplicando el método FODA que se divide en dos subfases: a)

análisis del contexto; y b) modelado del dominio. La sintaxis concreta es una fase sencilla debido a que

se definen las figuras que representarán a cada elemento, relación y cualquier otro componente

definido durante el análisis. La tercera y última fase es la formalización del lenguaje de modelado, en

esta fase se especializarán los conceptos de UML para obtener las representaciones ad hoc al entorno

de desarrollo LDD.

A continuación se describe el proceso de análisis de contexto para el entorno de desarrollo

integrado LDD. Este proceso es una adaptación a la metodología FODA para obtener la sintaxis

abstracta. Por esta razón, algunas fases del método original no se incluyen mientras que otras no se

construyeron estrictamente como se marca en [SEI 90].

5.3.1. Análisis del Contexto de Lotus Domino Designer

El propósito de analizar el contexto es definir el alcance del dominio de LDD. Para limitar el contexto

se analizaron previamente los factores externos e internos que intervienen en la toma de decisión para

el desarrollo de un nuevo software. Por ejemplo, si la aplicación será multiplataforma; si será ejecutada

sólo por un cliente en un equipo de cómputo; o, si será ejecutada sólo a través de un navegador Web,

entre otros. Las fases que se realizaron para el análisis del contexto son las que se muestran en la figura

5.2.

Figura 5.1. Fases del proceso para crear un DSL para Lotus Domino Designer



Estas fases se describen brevemente a continuación:

1. Obtener conocimiento del dominio: para tener un conocimiento del dominio se deben

conocer los servicios que ofrecen las aplicaciones de Lotus Note/Domino. También es

necesario conocer el software que hace la función de cliente (navegador Web, Lotus Notes,

Domino Designer, clientes móviles, entre otros) y que se utiliza para tener acceso a los

servicios.

2. Diagrama de Contexto: muestra a las entidades externas que intervienen en el desarrollo de

una aplicación Domino.

3. Diagrama de Estructura: es un diagrama de bloques informal que describe por niveles a un

dominio, en éste se describe una vista general de la aplicabilidad del dominio. También se

describe la funcionalidad de los sistemas; las aplicaciones que proporcionan la funcionalidad y

los componentes básicos para construir dichas aplicaciones.

4. Modelo de Contexto (limitación del alcance del dominio): limita los componentes con los

que se trabajará en el dominio.

El resultado final de un análisis de dominio es un modelo de contexto. En este modelo se

definen los límites del dominio hasta donde se pretenderá modelar el desarrollo de una aplicación en un

dominio determinado.

5.3.1.1. Analizando el dominio de LDD

Para entender el alcance de un dominio, se debe tener conocimiento básico sobre el dominio en un

nivel general que permita entender el ambiente del que forma parte y que se pretende analizar. Este

entendimiento requiere conocer las funcionalidades o servicios que el dominio ofrece y los factores

externos e internos que afectan el desarrollo de aplicaciones en el mismo.

Lotus Notes/Domino es una plataforma integrada de mensajería y servicios de colaboración.

Esta plataforma se encuentra conformada por una gama de herramientas. Entre estas se encuentran tres

tipos de servidores: Domino Messaging Server, Domino Enterprise Server y Domino Utility Server.

Para obtener un mejor conocimiento del dominio del que forma parte Lotus Domino Designer,

en la tabla 5.1 se describen brevemente los servicios más importantes que la plataforma Lotus

Notes/Domino ofrece.

Figura 5.2. Fases del análisis del contexto

Fases del Análisis de Contexto

Diagrama de

Contexto

Conocimiento

del Dominio

Diagrama de

Estructura Modelo de

Contexto



Tabla 5.1. Servicios ofrecidos por Lotus Domino Designer

Servicio Descripción

Almacenamiento

de objetos

La filosofía de la plataforma Domino es que la unidad básica para almacenar y recuperar

información es un documento. Domino trata de imitar el ambiente de trabajo real donde todo

es un documento. Por ejemplo: un libro, una carpeta, un correo, un registro, entre otros, los

cuales poseen un formato de diseño, estructura y reglas. Los documentos en una base de

datos Domino contienen cualquier cantidad de objetos y tipos de datos, incluyendo texto,

texto enriquecido, datos numéricos, estructuras de datos y Applets de Java y ActiveX.

Integración de

directorio

empresarial

Un directorio administra todos los recursos de información de directorio para el servidor y

para la configuración de la red, administración de aplicaciones, administración de la

seguridad, así como el directorio de personas y grupos. El directorio es la base para

administrar y asegurar las aplicaciones de Internet e Intranet.

Seguridad

El modelo de seguridad de Domino provee autenticación de usuarios, firmas digitales,

control de acceso flexible y encriptación. La seguridad de Domino habilita la extensión de

aplicaciones en una intranet, así como un diseñador de bases de datos. Con esta extensión se

controla a quien accede a una aplicación. Domino tiene diferentes niveles de seguridad: a

nivel de dominio; a nivel de servidores; a nivel de base de datos; a nivel de documentos; y de

campos. Estos niveles de seguridad permiten incorporar otros mecanismos comunes de

autentificación utilizados en otro tipo de aplicaciones, así como certificados de seguridad.

Estos niveles de seguridad también permiten utilizar diferentes estándares de seguridad. Por

ejemplo, el estándar de encriptación de contraseñas (encriptado de 128 bits).

Sincronización y

distribución

automática

Para maximizar la disponibilidad de los grupos de trabajo y de las aplicaciones de

mensajería, el servidor Domino Enterprise habilita la agrupación de hasta seis servidores

para proveer escalabilidad y protección ante fallas. La tecnología de reposición en tiempo

real mantiene a los servidores agrupados y sincronizados.

Mensajería

Un sistema de mensajería cliente-servidor con calendario y planificador habilita a los grupos

o individuos para enviar y compartir información. Los Agentes de transferencia de mensajes

MTA (del inglés Message Transfer Agents) extienden el sistema uniformemente a

SMTP/MIME, x.400 y ambientes de mensajería cc:Mail. El servicio de mensajería de

Domino provee un servidor simple que da soporte a una variedad de clientes de correo: Post

Office Protocol V3(POP3), Internet Message Access Protocol V4 (IMAP), Message

Aplication Programing Interface (MAPI) y el cliente de Lotus Notes.

Servidor Web

Lotus Domino provee un servidor de aplicación integrado que se utiliza como host de sitios

Web que pueden ser accedidos por navegadores Web, clientes Notes y clientes móviles.

También funciona almacenando páginas en el sistema de archivos o en una base de datos

domino que es accedida por los diferentes clientes. Cuando un navegador Web requiere de

una página almacenada en una base de datos Domino, éste traduce el documento en un

HTML. Cuando requiere de un archivo HTML, Domino lo lee directamente del sistema de

archivos y el servidor Web utiliza el protocolo HTTP para transferir información al

navegador Web.

Flujo de trabajo

Permite la automatización de flujos de trabajo para simular procesos de negocio dentro de

las aplicaciones. Estas automatizaciones distribuyen, dirigen y rastrean documentos de

acuerdo a los procesos definidos en las aplicaciones. El flujo de trabajo habilita coordinar

actividades de negocios a través de una organización con los clientes, compañeros y

proveedores.

Agentes

Los agentes permiten automatizar tareas o procesos que se realizan frecuentemente,

eliminando tareas repetitivas. Los agentes pueden lanzarse por un tiempo determinado o por

eventos en una aplicación. Los agentes pueden ejecutarse en los servidores Domino o en los

clientes Lotus Notes.



Modelo de

objetos de

Domino

Domino ofrece un modelo unificado para acceder a sus objetos a través de clases, utilizando

LotusScript o Java. Esto permite cambiar entre lenguajes de programación sin tener que

aprender nuevas formas de programar para Domino.

Desarrollo

rápido de

aplicaciones

LDD es un cliente de propósito general caracterizado por un ambiente de desarrollo

integrado (IDE, del inglés Integrated Development Environment) que provee acceso fácil a

todas las características del servidor Domino. Este ambiente permite crear aplicaciones

terminadas casi en su totalidad en tiempos relativamente cortos, comparado contra otras

plataformas de desarrollo de aplicaciones para ambientes colaborativos, de flujo de trabajo y

mensajería. Una de las características importantes es que el IDE cuenta con una interfaz

gráfica WYSIWYG (del inglés What You See Is What You Get). Visualmente se arman

tablas, botones, textos, formularios, vistas, entre otras cosas. El código fuente que representa

cada uno de estos componentes no es accesible como en otros entornos de desarrollo.

Generar

aplicaciones

multiplataforma

Las aplicaciones que se construyen a través de LDD, así como las herramientas que vienen

integradas con la familia Lotus Notes/Domino pueden ejecutarse en Solaris, Windows,

Linux y HPix.

Integración de

datos PIM

(Personal

Information

Management)

Tanto el ambiente de desarrollo como los lenguajes de programación de LDD permiten tener

acceso fácil a la agenda, correo, tareas y calendario. El acceso es para realizar consultas a

estas aplicaciones u operaciones con ellas. Un ejemplo del poder de integración de estos

componentes a nuevas aplicaciones es que con una sola instrucción se programa el envío de

un correo electrónico o una entrada a la agenda. La integración se facilita debido a que los

PIM son aplicaciones nativas de Lotus Notes/Domino.

Ambientes que

permiten

programar en

diferentes

lenguajes de

programación

En LDD se puede programar en el lenguaje nativo de Domino, en Java, LotusScript,

lenguaje de fórmula, lenguaje de comandos y JavaScript.

Exportación e

importación de

datos

Esta característica permite trabajar de manera natural con datos estructurados de tipo XML

(del inglés Extend Markup Language). Permite exportar información en archivos separados

por comas; exportar bases de datos DB2; u otras bases de datos relacionales; entre otras

alternativas de exportación e importación de datos.

Búsquedas

En Domino existen mecanismos prefabricados que permiten facilitar la búsqueda de

información en una base de datos de Domino. Se pueden realizar búsquedas a través de

formularios que ya existen en una base de datos. La consulta se compara con una

instrucción de búsqueda SQL, con la diferencia de que el formulario prefabricado no permite

ver el código fuente utilizado para realizar dicha consulta, sino que se realiza a través de la

interfaz que proporciona.

Otros Servicios

Lotus Domino ofrece aplicaciones pre-construidas de tipo administración documental, foros,

grupos de trabajo, salas de reuniones, portales de Internet, aplicaciones de Web 2.0, entre

otras.

Cabe mencionar que un servidor Domino no es lo mismo que un servidor de archivos. Un

servidor de archivos provee acceso a recursos compartidos como impresoras, aplicaciones y también

administra la actividad en una red. Domino es un servidor de procesos a nivel de aplicación que provee

servicios necesarios para una administración efectiva de comunicaciones y aplicaciones [Tuli 02].

Lotus Notes/Domino cuenta con una variedad de servicios disponibles para diferentes

necesidades. Estos servicios disponen de varios clientes, cada uno diseñado para resolver necesidades

específicas, los clientes se muestran en la tabla 5.2.



Tabla 5.2. Clientes para Domino

Cliente Descripción

Lotus Notes

Es un conjunto de aplicaciones de mensajería integrada y de software para trabajo colaborativo

tanto para Internet como para una Intranet. El cliente Notes puede utilizarse para enviar y

recibir correo electrónico, para anotar citas, navegar en el Web, contribuir a los foros de

discusión y aprovechar la página de bienvenida para rastrear información importante de los

usuarios diariamente. También se puede utilizar Notes para crear bases de datos o para buscar

algunas existentes, así como acceder a las aplicaciones hechas para Notes. Lotus Notes posee

algunas otras características como el bloqueo de documentos. Esta característica permite que

nadie pueda ver un documento sin la autorización del autor o de la persona que lo bloqueo. La

barra de marcadores permite crear y acceder a ligas que apuntan a elementos de Notes. Por

ejemplo: vistas, bases de datos, documentos o a sitios de Internet.

Domino

Designer

Este entorno de desarrollo se utiliza para crear aplicaciones Domino. El ambiente posee un

conjunto de elementos de diseño que se reutilizan una y otra vez para crear diferentes

aplicaciones de mensajería, compartición de documentos y flujo de trabajo con capacidades de

seguridad. Las aplicaciones de LDD pueden ser accedidas por los clientes Notes, navegadores

Web y dispositivos móviles.

Domino

Administrator

Permite administrar tareas, usuarios, archivos y servidores. Todas estas tareas de

administración se pueden llevar a cabo en una misma herramienta que posee una interfaz de

usuario amigable.

Clientes

Móviles

Ofrecen acceso al correo electrónico, calendarios, directorios y aplicaciones basadas en

Domino a través de dispositivos inalámbricos como PDAs y teléfonos habilitados para el

servicio de Internet.

Acceso Web

iNotes

Provee a los usuarios de acceso al correo Notes a través del navegador y a las características de

calendario y planificador de Notes. Por tanto, Es posible que los usuarios envíen y reciban

correos, ver sus calendarios e invitar a personas a los foros, entre otras cosas. No obstante, los

usuarios no pueden acceder a las bases de datos de Domino como lo hacen a sus archivos de

correo. Además de las tareas comunes de mensajería, un usuario iNotes Web Access sincroniza

información de su libreta personal de direcciones con información en su lista de contactos.

iNotes para

Microsoft

Outlook

Permite conectar a los archivos de correo Notes a través de Microsoft Outlook. Las

características familiares de Microsoft Outlook tienen soporte, incluyendo texto enriquecido,

carpetas e integración con aplicaciones de Microsoft Office.

Otros clientes

POP3/IMAP

iNotes tiene soporte para la mayoría de los estándares de mensajería en Internet. Esto significa

que se puede acceder al correo electrónico utilizando un cliente basado en estándares de

terceros.

Como se mostró en la tabla 5.1 y tabla 5.2, el Desarrollo Rápido de Aplicaciones RAD (del

inglés, Rapid Application Development) es uno de los servicios que Lotus Notes/Domino ofrece. Con

el desarrollo es posible acceder a todas las características de los tres servidores de Domino. Lotus

Domino Designer es el cliente sobre el que se pretende desarrollar un modelo de dominio que permita

modelar aplicaciones para Lotus Notes/Domino.

La figura 5.3 muestra un diagrama general de la arquitectura de Lotus Notes/Domino. En la

parte superior de la figura se muestran el conjunto de servidores disponibles, a la derecha se muestran

los clientes que pueden acceder a los servidores. En la parte baja de la figura se muestran algunas de

las principales funcionalidades (servicios) que ofrece esta plataforma a través de los distintos clientes.

Marcado con un círculo rojo punteado se muestra al entorno de desarrollo LDD, así como el servicio

que ofrece, el Desarrollo Rápido de Aplicaciones (RAD).



5.3.1.2. Diagrama de Contexto

El diagrama de contexto generalmente es un diagrama de flujo de datos que muestra flujos entre una

aplicación dentro del dominio y otras entidades y abstracciones con las cuales se comunica [Krut 96].

Para el análisis del entorno de desarrollo LDD, el diagrama de contexto muestra a las entidades

externas que intervienen en el desarrollo de una aplicación Domino.

Para desarrollar aplicaciones Domino se necesita tomar en cuenta un conjunto de factores que

impactan directamente en la toma de decisiones sobre el rumbo que tomará el desarrollo de un

proyecto. Estos factores no afectan directamente para construir una aplicación en LDD, sino que

inciden más en condiciones como la portabilidad, interoperabilidad, funcionalidad y eficiencia en la

ejecución de un producto de software. Además, estos factores no siempre representan código fuente en

una aplicación.

Cuando se empieza a diseñar y codificar, no siempre se conoce el estado de afectación de los

factores externos sobre los elementos para construir sistemas en LDD, sino que se conoce una vez

implantada una aplicación. Los principales factores que afectan el desarrollo de aplicaciones se

muestran en la figura 5.4.

Figura 5.3. Arquitectura general de Lotus Notes Domino

Lotus

Notes/Domino

Servicios ofrecidos por Lotus Notes/Domino

Almacenamiento

de objetos

Seguridad

Integración de

directorio

Mensajería Servidor Web

Flujo de trabajo Agentes

RAD

Modelo de objetos

de Domino

Aplicaciones

Multiplataforma

Búsquedas

Exportar e importar

datos

Programar en

diversos lenguajes

Integración de PIM

Sincronización y

distribución automática

Servidores de Domino

Domino

Utility

Domino

Enterprise

Domino

Messaging

iNotes for Outlook

Domino Administrator

Clientes POP/IMAP

iNotes Web Access

Clientes móviles

Domino Designer

Lotus Notes

Clientes Lotus

Notes/Domino



Los factores externos no fueron considerados dentro del desarrollo de este trabajo de

investigación debido a que no se conoce el grado de afectación sobre los elementos de diseño

utilizados en el desarrollo de una aplicación Domino.

5.3.1.3. Diagrama de Estructura

Es un diagrama de bloques informal que describe un dominio por niveles. En este diagrama se describe

una vista general de la aplicabilidad del dominio [Krut 96].

El diagrama de estructura consta de tres niveles para el dominio de LDD. En la capa de más

alto nivel se describen las funcionalidades que el dominio ofrece, mientras que en la capa de más bajo

nivel se describe el alcance del dominio (ver figura 5.5).

En la primera capa se muestran los servicios de aplicaciones en el dominio. LDD da la

posibilidad de crear aplicaciones que integren funcionalidades PIM, aplicaciones de flujo de trabajo, de

administración de documentos, de trabajo colaborativo, así como aplicaciones Web. En la segunda

capa aparecen los servicios o funcionalidades de las aplicaciones que engloban a las categorías de la

primera capa, las funcionalidades son las siguientes:

a) Las PIM permiten administrar información personal y estar en constante comunicación a través

de los servicios de mensajería, correo electrónico, agenda y calendario.

b) Las aplicaciones para el flujo de trabajo permiten automatizar procesos empresariales. Por

ejemplo, solicitar un permiso para un periodo vacacional. Esta solicitud tiene un proceso de

llenado, envío a recursos humanos, modificación de la nomina, entre otros. Este tipo de

procesos son automatizados a través de Domino.

c) La administración de documentos permite tener un control sobre el ciclo de vida de los

documentos. Por ejemplo, si un documento está en revisión; si está siendo utilizado por varias

personas; si esta liberado; aprobado; o, en su versión final.

Figura 5.4. Diagrama de contexto, factores externos

que impactan el desarrollo de aplicaciones en LDD



d) El trabajo colaborativo se refiere a aplicaciones virtuales que apoyan en la compartición de

información, asignación de tareas, seguimiento de actividades, tener una agenda de reuniones,

discutir temas en foros, entre otros. El trabajo virtual se realiza a través de medios digitales,

como correo electrónico y mensajería; sistemas electrónicos de conferencias y audio

conferencias; grupos de planificación; diagramas de procesos de flujo de trabajo; herramientas

de análisis; y manejo de documentos en grupo.

e) Los portales Web permiten la autentificación de usuarios; el manejo de aplicaciones

empresariales; la exposición de información de la empresa; el acceso a aplicaciones en una

intranet; administrar la seguridad de un dominio; administrar los roles y perfiles del personal;

publicar automáticamente información; difundir a través de boletines y correos; entre otras

funciones.

En la tercera y última capa aparecen los elementos de diseño necesarios para implementar cada

una de las aplicaciones que proporcionan las funcionalidades de la segunda capa. Las capas de más alto

nivel muestran los servicios ofrecidos por las aplicaciones. Estos servicios se mantienen cuando se

realizan cambios en los ambientes operativos donde funcionan, mientras que las capas de más bajo

nivel si cambian cuando los ambientes operativos necesitan ser modificados. El diagrama de estructura

de la figura 5.5 muestra el dominio de aplicación de Lotus/Notes Domino en los tres niveles o capas

que lo constituyen.

La tabla 5.3 (pág. 67) contiene a los elementos de diseño nativos de Domino para construir

aplicaciones. Esta tabla se construyó en base a un sondeo de seis aplicaciones desarrolladas por un

grupo de desarrolladores en LDD del Instituto de Investigaciones Eléctricas (IIE). Se eligieron seis

Figura 5.5. Diagrama de estructura del dominio de Lotus

Notes/Domino



tipos de sistemas diferentes para contabilizar la cantidad y los tipos de elementos utilizados en la

construcción de dichos sistemas.

El gráfico 5.1 permite ver cuáles elementos tienen más ocurrencia en la construcción de

aplicaciones Domino. El elemento form es el contenedor de elementos más importante en LDD. Este

elemento aparece 361 ocasiones entre las seis aplicaciones que se sondearon, mientras que el elemento

image aparece como el más utilizado con 674 elementos de este tipo. El gráfico es engañoso mostrando

más elementos del tipo form, view, image y files; pero en realidad la cifra disparada para images y files

es relativa debido a que su uso es común en las aplicaciones Domino, no obstante esto no resta

relevancia a estos elementos. Otros elementos destacables por su usabilidad son pages y actions, cada

uno con 159 y 192 elementos respectivamente. Esto corresponde el 6.39% y 7.71% de la totalidad de

elementos. El resultado completo de la contabilización se muestra en el gráfico 5.1.

0

100

200

300

400

500

600

700

Fram

eset

s

Pag

es

Form

s

Vie

ws

Fold

ers

Age

nts

Web

Serv

ices

Ou

tlin

es

Sub

Form

s

Fiel

ds

Co

lum

ns

Act

ion

s

Scri

pt

Lib

rari

es

Imag

es

File

s

Ap

ple

ts

Styl

e Sh

eets

Dat

a co

nn

ecti

on

s

Ico

n

Usi

ng

Ab

ou

t

Dat

abas

e Sc

rip

t

Nav

igat

ors

56

159

361

268

7

222

0 12

9249

15

192

62

674

274

031

0 6 3 6 0 0

Can

tid

ad d

e e

lem

en

tos

par

a se

is a

plic

acio

ne

s

Elementos

Incidencia de los elementos de diseño en las aplicaciones de LDD

Gráfico 5.1. Incidencia de los elementos en las aplicaciones domino



Elementos de diseño

Aplicaciones

Portal ServiceDesk Minutas Address Book Domino Web

Access Discussion

Notes & Web Total %

Framesets 17 3.85% 0 0.00% 2 0.60% 7 3.76% 26 3.54% 4 3.36% 56 2.25%

Pages 55 12.47% 53 7.86% 12 3.59% 4 2.15% 21 2.86% 14 11.76% 159 6.39%

Forms 76 17.23% 62 9.20% 62 18.56% 45 24.19% 98 13.33% 18 15.13% 361 14.50%

Views 51 11.56% 69 10.24% 51 15.27% 35 18.82% 50 6.80% 12 10.08% 268 10.77%

Shar

ed

co

de

Folders 0 0.00% 0 0.00% 0 0.00% 0 0.00% 6 0.82% 1 0.84% 7 0.28%

Agents 36 8.16% 70 10.39% 42 12.57% 7 3.76% 50 6.80% 17 14.29% 222 8.92%

WebServices 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00%

Outlines 1 0.23% 0 0.00% 0 0.00% 2 1.08% 7 0.95% 2 1.68% 12 0.48%

SubForms 8 1.81% 3 0.45% 6 1.80% 16 8.60% 53 7.21% 6 5.04% 92 3.70%

Fields 5 1.13% 4 0.59% 3 0.90% 25 13.44% 1 0.14% 11 9.24% 49 1.97%

Columns 0 0.00% 0 0.00% 0 0.00% 15 8.06% 0 0.00% 0 0.00% 15 0.60%

Actions 12 2.72% 0 0.00% 2 0.60% 0 0.00% 155 21.09% 23 19.33% 192 7.71%

Shar

ed

re

sou

rce

s Script Libraries 12 2.72% 16 2.37% 6 1.80% 8 4.30% 18 2.45% 2 1.68% 62 2.49%

Images 146 33.11% 130 19.29% 126 37.72% 19 10.22% 247 33.61% 6 5.04% 674 27.08%

Files 11 2.49% 257 38.13% 6 1.80% 0 0.00% 0 0.00% 0 0.00% 274 11.01%

Applets 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00%

Style Sheets 9 2.04% 8 1.19% 14 4.19% 0 0.00% 0 0.00% 0 0.00% 31 1.25%

Oth

er

Data connections 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00%

Icon 1 0.23% 1 0.15% 1 0.30% 1 0.54% 1 0.14% 1 0.84% 6 0.24%

Using 0 0.00% 0 0.00% 0 0.00% 1 0.54% 1 0.14% 1 0.84% 3 0.12%

About 1 0.23% 1 0.15% 1 0.30% 1 0.54% 1 0.14% 1 0.84% 6 0.24%

Database Script 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00%

Navigators 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00% 0 0.00%

441 100.00% 674 100.00% 334 100.00% 186 100.00% 735 100.00% 119 100.00% 2489 100.00%

Tabla 5.3. Incidencia de los elementos en las aplicaciones de Lotus Domino Designer



5.3.1.4. Limitando el alcance del dominio

En la sección 5.3.1.1 (pág. 59) se describieron a los servicios ofrecidos por Lotus Notes/Domino en un

nivel que permite tener un panorama general de las distintas funcionalidades obtenidas al crear

aplicaciones. Lotus Notes/Domino ofrece una extensa variedad de servicios para trabajar

colaborativamente, también ofrece diferentes clientes donde las aplicaciones se ejecutan. Los clientes

varían de acuerdo a la plataforma utilizada. Por ejemplo, clientes para aplicaciones Web (navegadores),

clientes para dispositivos móviles (PDA), entre otros.

Las entidades externas que intervienen en el desarrollo de aplicaciones Domino son otros

factores que implican un análisis sobre las características que una aplicación deberá tener. Estas

características van desde el tipo de sistema operativo donde se implantará la aplicación hasta el cliente

donde se ejecutará. Como se ve en la sección 5.3.1.2 (pág. 63), son varios los factores que intervienen

en la toma de decisión sobre las características que una aplicación Domino debe tener.

Uno de los propósitos de este proyecto de investigación es obtener un conjunto de primitivas

de modelado que permitan modelar conceptualmente a las aplicaciones que se pretendan desarrollar en

LDD. Como se mostró en el diagrama de estructura (ver figura 5.5, pág.65), la capa más alta muestra

de manera abstracta el conjunto general de aplicaciones que se pueden desarrollar. En la capa central se

muestra la funcionalidad general de las aplicaciones de la primera capa, mientras que en la capa final

se muestran los elementos de diseño necesarios para desarrollar este conjunto de aplicaciones. Los

elementos de diseño son la base para desarrollar aplicaciones Domino y necesitan ser analizados para

convertirse en primitivas de modelado. El análisis consiste en encontrar atributos comunes entre los

elementos de diseño y en crear abstracciones que permitan agrupar características o entidades, así

como restricciones que puedan existir al momento de utilizar un elemento de diseño con otro.

El modelo de contexto mostrado en la figura 5.6 muestra en el nivel más externo a los servicios

ofrecidos por Lotus Notes/Domino. Estos servicios se ofrecen a través de un conjunto de aplicaciones,

estas aplicaciones se muestran de manera general en el segundo nivel anidado (aplicaciones Lotus

Notes/Domino). El tercer y último nivel anidado muestra a los elementos de diseño básicos utilizados

en el desarrollo de aplicaciones Domino. Este nivel fue analizado para obtener un conjunto de

primitivas de modelado, relaciones y restricciones entre los elementos de diseño. El análisis de los

elementos de diseño, sus características, así como la obtención de las primitivas de modelado se

muestran en la siguiente sección.

Figura 5.6. Limitando el alcance para el análisis del dominio

Servicios ofrecidos por Lotus Notes/Domino Servicios/Funcionalidades

Almacenamiento de objetos

Mensajería

Flujo de trabajo

Integración de directorio

Aplicaciones multiplataforma

Automatización de procesos

empresariales

Administración general de

documentos

Administración de

información personal

…

Tipo de aplicación

PIM

Workflow

Document

Management

Groupware

Portal Web

…

Aplicaciones de Lotus Notes/Domino

Lotus Domino Designer

Elementos de diseño

forms

pages

Views

fields

…



5.3.2. Modelado de Dominio de Lotus Domino Designer

El propósito de modelar el dominio de LDD es obtener un conjunto de primitivas de modelado, las

relaciones y restricciones existentes entre estas primitiva. Las fases que se han utilizado para modelar

el dominio de LDD son las que se muestran en la figura 5.7.

Las fases del modelado de dominio se describen a continuación:

1. Definir los elementos a analizar. Consiste en definir el conjunto de elementos para los que el

modelado tendrá efecto. Debe realizarse una descripción de cada elemento en esta fase.

2. Modelado de características de cada elemento. Consiste en hacer un diagrama de

características de cada elemento. El diagrama mostrará cuales elementos pueden relacionarse

entre sí, no obstante este diagrama sólo muestra un tipo de relación. El diagrama de

características da una noción sobre si un elemento relacionado es opcional u obligatorio al

momento de utilizarse con otros elementos.

3. Encontrar y definir tipos de relaciones. Consiste en realizar un análisis sobre la manera en

que los elementos se relacionan. En esta fase es posible encontrar abstracciones debido a que

algunos elementos contienen características similares que permiten construir una

generalización. Para esta fase pueden especializarse algunas relaciones existentes o utilizarlas

sin ningún cambio.

4. Encontrar y definir tipos de restricciones. Consiste en realizar un nuevo análisis en busca de

restricciones entre elementos. Las restricciones pueden ser de funcionalidad, conectividad,

usabilidad u otras que puedan encontrarse durante el análisis.

5. Crear metamodelo. Para definir el metamodelo se debe tener a los elementos definidos, los

cuales se convertirán en instancias una vez que se especifiquen modelos con él. En el

metamodelo no sólo se muestran los elementos definidos, sino la relación que existe entre cada

tipo de elemento. Para definir el metamodelo se debe basar en el análisis para encontrar las

relaciones entre elementos. El metamodelo también muestra a simple vista algunas

propiedades de las relaciones, por ejemplo la multiplicidad.

5.3.2.1. Elementos de Domino Designer

Los elementos de diseño de LDD se muestran en la tabla 5.4 (pág. 70). Estos elementos son los que se

analizaron para encontrar concordancias y variantes para definir primitivas generales y especializadas

que permitan modelar aplicaciones Web realizadas en el entorno de desarrollo LDD.

Figura 5.7. Fases del modelado de dominio de Lotus Domino Designer

Fases del Modelado del Dominio

Encontrar y

definir

relaciones

Encontrar y

definir

restricciones

Crear

metamodelo

Definición

de

elementos

Modelado de

características



Los elementos están divididos en cuatro secciones: principales elementos, elementos de código

compartido, recursos compartidos y otros elementos. Los elementos de la primera columna de la tabla

5.4 se utilizan en el desarrollo de aplicaciones constantemente. La mayoría de éstos contienen a los

elementos de las categorías restantes, incluso los principales elementos se pueden contener entre ellos

mismos.

Tabla 5.4. Elementos utilizados en el desarrollo de aplicaciones

Elementos de diseño de la barra de marcadores (bookmarks) de LDD

Principales

elementos

Elementos de código

compartido (shared

code)

Recursos compartidos

(Shared Resources)

Otros elementos

Form Agent Image Navigator

View Web Service Applet

Page Outline Style Sheet

Frameset Subform File

Folder Field

Data base Column

Action

Script Library

Además de los elementos mostrados en la tabla 5.4, existen otros que no aparecen

explícitamente en la barra de marcadores de LDD. Estos elementos se encuentran en la barra de menús

que se habilita para cada elemento sobre el que se quiere trabajar. Así, varios de estos elementos

también son importantes debido a que son de uso común en el desarrollo de aplicaciones Web de

Domino. Por esta razón, estos elementos deben contemplarse para el análisis. La tabla 5.5 muestra a los

elementos que no aparecen en la barra de marcadores, pero que son constantemente utilizados en el

desarrollo de aplicaciones Web en LDD.

Tabla 5.5. Otros elementos de diseño de LDD

Otros elementos de diseño de LDD

Hotspot

Section

Computer Text

Table

Outline Entry

Action Bar

Button

La descripción de cada elemento mostrado en la tabla 5.4 y tabla 5.5 se encuentra en la página

51 en la tabla 4.1 (elementos de diseño de LDD).

5.3.2.2. Modelo de características de Lotus Domino Designer

El modelo de características es un conjunto de características jerárquicamente organizadas. Es también

una notación y una aproximación para modelar concordancias y variantes de una familia de productos.

En la sección 3.6 (modelado de características) de la página 29 se encuentra una referencia más

completa sobre la forma original de este tipo de modelado.

El enfoque que se propone para definir el modelo de características de LDD se basa en los

elementos de diseño mostrados en el diagrama de estructura (ver figura 5.5, pág. 65). Estos elementos

son la base para generar las aplicaciones de Lotus Domino Designer y es a través de estas aplicaciones

que se obtienen los servicios descritos en la tabla 5.1 (servicios ofrecidos por LDD) en la página 60.



Por lo tanto, el diagrama de características realizado para LDD se enfoca en mostrar cuales son

los elementos de diseño que pueden relacionarse con otros elementos. El diagrama describe si un

elemento de diseño necesita obligatoria, alternativa u opcionalmente a los elementos de diseño

restantes. La relación existente entre un elemento y otro se conocerá como “contiene a”.

A continuación se describen los tipos de elementos en los que es posible clasificar a los

elementos de diseño de LDD, posteriormente se describe en un diagrama de características a cada

elemento junto con los elementos que pueden relacionarse con el mismo. El diagrama consiste en

determinar si un elemento necesita de manera obligatoria, alternativa u opcional a los elementos de

diseño restantes. Los elementos que no se encuentran en el diagrama de características de determinado

elemento no tienen ninguna relación directa con el elemento principal que se encuentra en la raíz del

diagrama.

5.3.2.2.1. Elementos Contenedores y Contenidos

En LDD se distingue principalmente entre dos tipos de elementos de diseño, los elementos

contenedores y los elementos contenidos. A continuación se define cada uno de ellos.

1. Elementos contenedores. Estos elementos se caracterizan por ser los principales en el diseño

de aplicaciones Domino. Un elemento contenedor es un elemento que puede contener a otros

elementos para construir un sistema. La contención no es literal, se refiere a que otros

elementos pueden adherirse encima del contenedor para darle más funcionalidad. Por ejemplo,

a un elemento form puede adherírsele un elemento view o field por mencionar algunos; al

elemento form se le conoce entonces como contenedor mientras que a view y field como

elementos contenidos. Cabe mencionar que algunos elementos contenedores también pueden

ser contenidos en algún momento. Los elementos contenedores aparecen en la tabla 5.6.

Tabla 5.6. Elementos que realizan la función de contenedores en LDD

Elementos contendedores

Form Subform

View Table

Page Section

Frameset Outline

Action Bar Navigator

Folder Action

Outline

2. Elementos contenidos. Los elementos contenidos constituyen la totalidad de los elementos de

LDD. Estos elementos se caracterizan por no tener la capacidad de contener a otros elementos,

no obstante los elementos contenedores son una excepción al ser al mismo tiempo elementos

contenidos. Los elementos contenedores por lo tanto son también contenidos, el resto de los

contenidos se muestran en la tabla 5.7.

Tabla 5.7. Elementos que realizan la función de contenidos en LDD

Elementos contenidos

Agent Web Services

Field Hotspot

Column Style Sheet

Script Library Button

Image Files

Applet Text

Computer text Outline Entry



5.3.2.2.2. Elemento Base de Datos

La base de datos no es propiamente un elemento de diseño de aplicaciones. La base de datos es el

contenedor de la totalidad de los elementos de diseño de Lotus Domino Designer. La figura 5.8

muestra a los principales elementos de LDD, estos elementos pueden utilizarse sin necesidad de

insertarse en otros para ser utilizados. Los elementos form, page y frameset son los principales

contenedores del resto de elementos de diseño. El elemento agent es código que se ejecuta al momento

de su invocación, mientras que el elemento view es sólo un contenedor de documentos.

5.3.2.2.3. Elemento Form

El form es el elemento más importante de LDD debido a que en él se pueden insertar la mayoría de los

elementos con los que se dispone. Un form es el elemento básico para el diseño de interfaces, a través

de éstas se registra información en las bases de datos. El diagrama de la figura 5.9 representa a los

elementos que pueden contenerse en un elemento form y que tienen algún tipo de relación con el

mismo.

5.3.2.2.4. Elemento View

Los views son contenedores de documentos, por esta razón sólo aparecen los colums y actions

invocados a través de la barra de acciones. Cada renglón de un view contiene datos pertenecientes a un

documento simple. Cada column listada en un view representa datos de un campo o una combinación

de éstos tomados de un documento. Cuando se utiliza un view para cierta funcionalidad en una

aplicación, automáticamente aparece un column por omisión. Esta es la razón de la relación obligatoria

para el elemento column. El diagrama de la figura 5.10 muestra a los únicos elementos de diseño que

un view puede contener: columns y action bars.

Figura 5.8. Principales elementos de una base de

datos Domino

Figura 5.9. Elementos relacionados con un form

Data base

Form Agent Pages Frameset View

Agents Action Bar

View

s

Folder

s

Outlines Subform Style

Sheets

Fields Script

Libraries

Images Applets

Navigators

Form

Hotspots

Sections

Computer text Files

Button

Table



5.3.2.2.5. Elemento Page

Los pages se utilizan para presentar información. Ofrecen una alternativa para el diseño de

aplicaciones en el Web a través de una herramienta que provee una interfaz gráfica. Los pages tienen

relaciones también con diferentes elementos al igual que los forms. Es muy común incluir views en un

page para agregar presentación de contenido dinámico. El diagrama de la figura 5.11 representa a los

elementos que pueden insertarse en un page.

5.3.2.2.6. Elemento Frameset

Los frameset no son más que un elemento contenedor de frames. Los frameset dividen una página Web

a través de frames. Un frame puede contener una página web, un documento PDF o algunos elementos

de diseño de Lotus Domino. Un frame puede contener forms, pages, views, folders, links, navigators,

URL e incluso a otros frameset. La figura 5.12 muestra los elementos que un frameset y un frame

puede contener para diseñar páginas web.

Figura 5.10. Elementos relacionados con un view

Figura 5.11. Elementos con los que se relaciona el elemento page

Figura 5.12. Elementos relacionados con los elementos frameset y frame

View

Column Action Bar

Script

Libraries

Action

Bar

View

s Folder

s Agents

Outline Images

Navigators Button

Page

Hotspots

Sections Table Computer

Text

Files Style Sheet

Applets

Frameset

Frame

Views Pages Folders Navigators Form Frameset

Frame



5.3.2.2.7. Elemento Action Bar

Los action bars aparecen en forms, pages y views. Los action bars son un elemento agrupador de

actions. Los actions pueden contener agents u otras operaciones, los cuales permiten automatizar

tareas. La figura 5.13 muestra que un action bar necesita obligatoriamente a los actions para existir

como elemento, mientras que los actions pueden o no contener algún agente que automatice una tarea.

Por ejemplo guardar, actualizar o abrir un documento.

5.3.2.2.8. Elemento Folder

Un folder es un contenedor de documentos al igual que un view. La diferencia entre folder y view es

que un view puede seleccionar el tipo de documentos a mostrar de acuerdo a una cadena de consulta,

mientras que un folder no puede seleccionar documentos de acuerdo a un criterio. La figura 5.14

muestra a los elementos que un folder puede contener: columns y action bar.

5.3.2.2.9. Elemento Tabla (table)

Los tables son elementos agrupadores y contienen a varios elementos. La figura 5.15 muestra a los

elementos que se puede insertar en un table.

Figura 5.13. Elementos relacionados con un action bar y un

action

Figura 5.14. Elementos relacionados con un folder

Figura 5.15. Elementos relacionados con una table

Folder

Column Action Bar

Action Bar

Actions Agents

Actions

View

s

Folder

s


Sheets

Fields Script

Libraries Images Applets

Navigators

Table

Hotspots Sections

Computer text Files

Button

Table



5.3.2.2.10. Elemento Sección (section)

Un elemento section es al igual que los tables un agrupador. Un section puede contener a los mismos

elementos que una table, incluso a otros sections. La figura 5.16 muestra a los elementos que se pueden

insertar en un section.

5.3.2.2.11. Otros elementos contenedores

Los outlines sólo pueden contener elementos outline entry. Un entry puede invocar como una liga a

cualquier elemento de diseño disponible en LDD. Los outlines pueden contener a cuantos entry se

deseen para la navegación en una aplicación. Por esta razón se muestra en la figura 5.17 a un entry

como elemento que puede contener un outline. El elemento navigator es un elemento que permite

hacer mapas de navegación a través de ligas que permiten acceder a otros elementos internos o

externos a Domino. Las ligas se crean a través de hotspot. Por esta razón en la figura 5.17 se muestra a

los hotspot como el elemento que un navegador puede contener.

5.3.2.3. Relaciones entre elementos de Lotus Domino Designer

El modelo de características definido en la sección anterior (sección 5.3.2.2) utilizó para cada

elemento la relación contiene a. Esta relación aplicada a los elementos de LDD es ambigua debido a

que los elementos poseen relaciones donde un elemento es “parte de”. Por este motivo la relación

“contiene a” debe complementarse con otro tipo de relaciones que especifiquen una relación

“todo/parte”.

Existen tipos de relaciones definidas donde se especifica que un elemento es parte de otro.

Estas relaciones poseen propiedades como la multiplicidad que indica cuantos elementos de un tipo

puede relacionarse con otro o reflexividad que indica si un elemento puede relacionarse con él mismo.

Figura 5.16. Elementos relacionados con un section

Figura 5.17. Elementos relacionados con un outline

y un navigator

Navigator

Hostspot

Outline

Outline Entry

View

s

Folder

s


Sheets

Fields Script

Libraries Images Applets

Navigators

Section

Hotspots Sections

Computer text Files

Button

Table



Las relaciones de UML son tipos de relaciones que se utilizan para especificar si un elemento

es dependiente de otro; si es una especialización, generalización, asociación, agregación o

composición. Además, estas relaciones poseen varias propiedades que se utilizan para restringir una

relación. Para definir las relaciones en LDD se utilizará como base a las relaciones de UML. Estas

relaciones permiten especificar las relaciones necesarias para las primitivas de modelado que se

definieron. A continuación se describen las relaciones de contención, contención reflexiva, agregación

y composición que se utilizarán entre las primitivas de modelado de LDD.

A. Relación de contenció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 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.

Notación de la relación de contención

Una relación de contención se dibuja como una línea sólida conectando dos objetos. La contención

se indica con un círculo pequeño ahuecado que se añade al final del enlace. El círculo se dibuja en

el objeto que hace la función de contenedor como se muestra en la figura 5.18.

B. Relación de contención reflexiva

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 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 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.

Notación de la relación de contención reflexiva

La contención reflexiva se dibuja como una línea sólida conectado dos objetos. La contención se

indica con un círculo pequeño con un asterisco en el centro que se añade al final del enlace. El

círculo con asterisco se dibuja en el objeto que hace la función de contenedor como se muestra en

la figura 5.19.

Objeto

contenedor Objeto

contenido

Indicador de contención

*

Objeto

contenedor

Objeto

contenedor

Indicador de contención reflexiva

Figura 5.18. Relación de contención, esquema general

Figura 5.19. Relación de conteción reflexiva, esquema general



Objeto

contenedor

Objeto

contenido

Indicador de agregación

Objeto

contenedor

Objeto

contenido

Indicador de composición

C. Relación de agregació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. Es una 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ón o la parte que constituye al todo (contenido).

Notación de la relación de agregación

La agregación se representa por una línea sólida conectando a dos objetos, es decir, una relación

binaria. Tomando como base a [OMG 03], 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 5.20.

D. Relación de composició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 [OMG 03].

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.

Notación de la relación de composición

La composición se representa por una línea sólida conectando a dos objetos, es decir, una relación

binaria. Tomando como base a [OMG 03] la composición se indica con un diamante relleno que se

añade al final del enlace. El diamante se dibuja en la clase que es el contenedor como se muestra en

la figura 5.21.

Figura 5.20. Relación de agregación, esquema general

Figura 5.21. Relación de composición, esquema general



5.3.2.4. 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.

A. Multiplicidad

Tabla 5.8. 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.

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.

B. Propagación de borrado

Tabla 5.9. 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 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).

C. Reflexividad

Tabla 5.10. 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.



D. Valores fijos de las relaciones definidas

Para completar la semántica de las relaciones, se especifica el valor de las propiedades introducidas en

el apartado 5.3.2.4 (características de las relaciones) para cada una de las relaciones. De esta manera

cada relación contiene ciertas propiedades definidas. En la tabla 5.11 se muestran los valores de las

propiedades definidas anteriormente. El símbolo ∗ indica que una propiedad puede tomar cualquier

valor. Para cada relación (columna) la tabla muestra los valores de las propiedades.

Tabla 5.11. 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

5.3.2.5. Definición del metamodelo

Los elementos, relaciones y atributos descritos en las secciones anteriores forman un modelo de

representación. Esta descripción se puede convertir en explícita si se define un metamodelo, es decir un

modelo de información para describir modelos. La forma de llevarlo a cabo es realizando un análisis

sobre las relaciones que involucran a cada elemento. La información obtenida puede representarse en

un modelo expresado en términos de sus elementos, atributos y relaciones.

El modelo definido para LDD consta de dos partes. La primera de ellas es un modelo que

categoriza a los principales elementos contenedores, contenedores secundarios y no contenedores. Los

principales contenedores que aparecen con un diagrama de paquete en la figura 5.22 son elementos que

es posible ejecutar en una aplicación sin la 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 contendor, no puede entrar en esta clasificación.

Figura 5.22. Principales elementos

contenedores de LDD



La figura 5.23 muestra a 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.

La figura 5.24 muestra a los elementos que no son contendores, éstos sólo pueden estar

contenidos tanto en contenedores principales como secundarios.

El segundo modelo es el metamodelo de la figura 5.25 que muestra a los elementos y

relaciones. Éste metamodelo permite especificar nuevos modelos. No obstante, hace falta definir las

restricciones para relacionar un elemento con otro, pero el modelo de características mostrado en la

sección 5.3.2.2 de la pág. 70 permite ver la usabilidad entre elementos. Por ejemplo, un elemento view

debe contener al menos a un elemento column; y un navigator puede contener a un elemento hotspot,

Figura 5.23. Elementos contendores secundarios

Figura 5.24. Elementos no contendores



entre otros. Este tipo de relaciones son las que se pretende mostrar a través del metamodelo, además

también se pueden observar propiedades como la multiplicidad.

Para definir el metamodelo se tomaron los elementos definidos en el análisis de contexto, así

como las relaciones encontradas para cada elemento en términos de usabilidad.

El metamodelo de la figura 5.25 no muestra a todos los elementos que LDD tiene para la

construcción de aplicaciones Web, sino a los más comunes y usables. Las relaciones son las que se dan

de manera natural al construir aplicaciones. Cabe mencionar que existen relaciones que no se dan de

manera natural porque el desarrollador necesita realizar alguna artimaña para empotrar un elemento

sobre otro o realizar alguna función específica con algún elemento.

Como cabecera del metamodelo se muestra al elemento base de datos. Éste es un elemento que

colecciona información relacionada y que 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 almacenará la estructura de 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 es posible mostrar información en un page o en un frameset.

El metamodelo de la figura 5.25 representa entonces a los elementos analizados y obtenidos

como resultado del análisis del contexto y el modelado del dominio de LDD. También representa las

relaciones más comunes entre los elementos que utiliza LDD.



Figura 5.25. Metamodelo de LDD



La figura 5.26 muestra la posición en la que se encuentran los elementos de LDD dentro de la

estructura de Lotus Notes/Domino.

5.4. Aplicando una técnica de modelado visual

Para representar los elementos de modelado y las relaciones que han sido obtenidas en las secciones

anteriores, se ha elegido especializar el Lenguaje de Modelado Unificado (UML) a través de los

Perfiles UML.

El lenguaje de modelado UML 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 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 [HECKEL 03] y [FUENTES] 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.

La OMG específica dos posibilidades a la hora de definir lenguajes para dominios específicos:

se construye un nuevo lenguaje (alternativa de UML) o se extiende 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 que se denominan Perfiles UML.

En este trabajo se ha elegido la opción de extender UML utilizando los mecanismos de

extensión del mismo. 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 (tagged values). El perfil

UML Lotus Domino Designer para Web 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.

Éste perfil se define en el anexo A.

Figura 5.26. Posición en la estructura de Lotus Notes/Domino de los elementos de diseño


Capítulo 6. Pruebas

6.1. Introducción

El perfil de Lotus Domino Designer para aplicaciones Web fue probado a través de una herramienta

con soporte de UML y específicamente para los perfiles UML. El perfil se implementó como un

prototipo en la herramienta de modelado Enterprise Architect de la compañía Sparx System en su

versión de evaluación 7.1.

6.2. Demostración del lenguaje

Las características que el lenguaje proporciona se describen a través de ejemplos. Existen algunos

puntos que deben remarcarse respecto al contexto y al propósito sobre el cual se desarrollan los

modelos para Lotus Domino Designer, los puntos son los siguientes:

Con el desarrollo de un DSL para el entorno Lotus Domino Designer se intenta que los

programadores de este entorno entren al mundo formal de la ingeniería de software. Se debe

recordar que el paradigma de programación de LDD es diferente al tradicional Orientado a

Capitulo 6. Pruebas


Objetos (OO). Por este motivo los programadores que conocen este paradigma están

acostumbrados a utilizar el diseño que proporcionan los diagramas de clase, así como los

conceptos de herencia y polimorfismo. Cuando se utilizan estos conceptos con un paradigma

diferente al OO, por ejemplo el de LDD, los programadores no entienden con facilidad los

modelos utilizados por los diseñadores, puesto que éstos se encuentran por lo general en

diagramas de clase y con una interpretación propia del diseñador. Esta interpretación es

diferente a la interpretación original de los diagramas de clase y por tanto es entendida sólo por

quien la diseña.

El propósito de los modelos creados con el DSL para Domino es mostrar la estructura de una

aplicación Domino, esta estructura se encuentra basada en componentes o entidades que

constituyen cierta funcionalidad. Los modelos no pretenden ser un diseño detallado sino una

guía con la cual el desarrollador visualizará los componentes necesarios para desarrollar cierta

funcionalidad. No obstante, estos modelos tienen los suficientes elementos poder llegar a tener

modelos con diseño detallado.

Los modelos son para la etapa de diseño de la arquitectura, estos surgen de las funciones

especificadas en los casos de uso. Los modelos pretenden ser una complementación para que el

programador tenga los componentes básicos con los cuales desarrollará la funcionalidad

especificada en los casos de uso y documentos de requerimientos.

6.2.1. Características del lenguaje

Las características que el DSL proporciona se describen a continuación:

Representación intuitiva para el diseñador. Los modelos que se realizaban anteriormente sin

el DSL como el de la figura 6.1 carecían de un lenguaje que fuera intuitivo para el diseñador.

Los diagramas de clase no presentaban sino cajas con el nombre del objeto como título y un

conjunto de propiedades que tenían que agregarse cada vez que se realizaba un nuevo

diagrama.

Los modelos realizados con el DSL propuesto en esta tesis proporcionan una simbología para

representar a cada objeto del ambiente de desarrollo. Esta simbología es la misma que aparece

en el entorno de Lotus Domino Designer, permitiendo eliminar ambigüedades respecto a la

interpretación de un símbolo. En la figura 6.1 no se conoce el tipo de elemento de LDD que

está representando cada clase, el diseñador necesitaría implementar alguna artimaña para

identificar cada elemento, de esta manera las entidades de clase no representan adecuadamente

Figura 6.1. Diagrama de clases que trataba de representar la arquitectura de una aplicación Domino

Capitulo 6. Pruebas


a los elementos de clase y aunque en UML se utilizan las notas, éste no es un mecanismo

adecuado.

La notación del DSL para LDD permite que los diseñadores se familiaricen fácilmente con los

objetos del lenguaje puesto que la representación visual con una simbología apropiada es más

intuitiva cuando se diseñan y reconocen entidades.

Otra desventaja de los diagramas anteriores con respecto al DSL, como el de la figura 6.1, es

que no se utilizan las propiedades de LDD. Algunas propiedades eran inventadas o

representaban la funcionalidad de otra entidad. Por ejemplo, la función “Publicar” del elemento

CalidadWeb (ver figura 6.1) representa una operación que el elemento Action de LDD debe

ejecutar. Con esta representación no hay manera de saber cómo implementar la funcionalidad

del método “publicar{}” , no se sabe si se tiene que implementar con un boton, liga, agente o

cualquier otro elemento de LDD. Esta forma de utilizar los métodos de una clase se debe a la

carencia de una entidad que represente por si misma al elemento Action de LDD.

Las entidades especificadas en el DSL para Domino representan por sí mismas a los elementos

que deben utilizarse en el desarrollo de cierta funcionalidad, puesto que cada entidad tiene una

notación visual y un conjunto de propiedades. Aunado a esto, se cuenta con un conjunto de

relaciones estructurales entre los elementos que indican la forma en que se encuentran

relacionados los mismos.

En la figura 6.2 aparece un diagrama que ejemplifica la simbología del lenguaje propuesto en

esta tesis, así como una serie de propiedades analizadas, seleccionadas y establecidas para cada

entidad. También se puede apreciar el conjunto de entidades con la simbología representativa

de cada una.

Capitulo 6. Pruebas


Figura 6.2. Diagrama ejemplificando la notación y simbología del DSL

Capitulo 6. Pruebas


Entidades de diseño de Domino caracterizadas. Anteriormente, los diseñadores no contaban

con un conjunto de objetos definidos ni sus relaciones. La interpretación de los diagramas, así

como la funcionalidad de las relaciones quedaba ambigua puesto que no tenían una semántica

especificada y cada diagrama utilizaba relaciones definidas en el momento de su uso, así como

la interpretación del mismo.

En la figura 6.3 se puede apreciar que todas las relaciones entre las entidades son de tipo

“«uses»” de UML, esto se debe a que las relaciones apropiadas no existen y por lo tanto se

tiene que improvisar a la hora de hacer los diagramas. Estas relaciones no especifican si

invocan código o si un elemento es parte estructural de otro. Así, se considera que utilizar las

relaciones de esta manera no tiene mucho significado a la hora de interpretar un diagrama.

Respecto a las entidades, en la figura 6.4 se pueden apreciar algunos de los objetos

improvisados al igual que las relaciones. Estos objetos tratan de describir a través de una

simbología no estandarizada las distintas entidades que el entorno de LDD maneja, pero para

su identificación es necesario agregar el nombre del tipo de elemento que representa.

Figura 6.3. Representación de las relaciones de UML más utilizadas en diagramas anteriores

Figura 6.4. Diseño de las entidades en modelos anteriores

Capitulo 6. Pruebas


Con el DSL para Domino, se tiene un conjunto de relaciones para definir la estructura de una

aplicación. El desarrollo en Domino se da empotrando objetos, esto quiere decir que una

entidad puede contener a uno o a varios objetos. Para tratar este tipo de relación entre

componentes, se creó la relación “«containment»”, la cual indica que un objeto se encuentra

empotrado o contenido dentro de otro.

Algunos ejemplos realizados con el DSL para Domino de este tipo de relación se muestran en

la figura 6.5. Aquí se observa que el formulario de acceso principal ServiciosF se encuentra

conformado por cuatro entidades principales (estilos.css, comitesDirectivosV,

LectorCookiesSF y actionbar.js), estas entidades están contenidas literalmente en el

formulario, por esta razón se utiliza la relación “«containment»” que indica este hecho.

También se observa que la entidad GenerarGrupoRector se relaciona con el agente

CreaEspacioComite a través de la relación “«uses»”, esta relación se utiliza para indicar que

una entidad esta invocando a otra a través de código fuente. Las relaciones de tipo

“«composition»” indican que los componentes al final de la relación forman parte estructural

del elemento que lo contiene. Por ejemplo, si la vista ComiteDirectivosV fuese eliminada, se

eliminarían en cascada las columnas que se relacionan a ésta a través de la relación de

composición, caso contrario ocurriría con el formulario CreaComiteF, el cual se invoca a

través de código fuente, esta es la razón de su relación “«uses»”. La figura 6.5 no muestra el

conjunto de propiedades por cuestiones de espacio.

Figura 6.5. Uso de las relaciones containment, composition y uses

Capitulo 6. Pruebas


Con diagramas como los que se muestran en la figura 6.2 y figura 6.5 se obtiene un lenguaje

con una representación visual ad hoc a las entidades de desarrollo de LDD. Como se mencionó

anteriormente, esta representación permite al diseñador y desarrollador familiarizarse

fácilmente con los objetos manejados. El conjunto de relaciones permite establecer un mejor

entendimiento de la relación estructural existente entre componentes, permitiendo también

establecer un mejor medio de comunicación entre el diseñador y desarrollador.

Las propiedades especificadas ayudan a establecer condiciones que el desarrollador debe tomar

en cuenta cuando está desarrollado una aplicación. La ventaja de tener un conjunto de

propiedades establecidas es que se tendrán modelos más completos.

Puente entre el diseñador y desarrollador. Los modelos realizados con el DSL pretenden

establecer una mejor comunicación entre el diseñador y el desarrollador. Esta comunicación se

da a través de modelos que proporcionan una mejor semántica con entidades visualmente

entendibles por los usuarios y características específicas de cada entidad de LDD. Cabe

mencionar que los modelos no son diseño detallado, sino que éstos modelos son la estructura

necesaria que el desarrollador debe utilizar para implementar cierta funcionalidad especificada

en los documentos de casos de uso y requerimientos. Así, los modelos realizados con el DSL

enriquecen a estos documentos y establece un mejor puente de comunicación entre diseño e

implementación.

Completez, correctez y no ambigüedad. El DSL presentado en el anexo A se desarrolló a

través de un análisis del entorno de desarrollo Lotus Domino Designer. Una de las etapas de

este análisis fue realizar un sondeo con la ayuda de los expertos en LDD sobre las entidades

que más se utilizan en la construcción de aplicaciones (ver tabla 5.3. Incidencia de los

elementos en las aplicaciones de Lotus Domino Designer, pág. 67). Como resultado del sondeo

se obtuvieron los componentes más utilizados en el desarrollo. De los 30 elementos

presentados en la tabla 4.1 (elementos de diseño de Lotus Domino Designer, pág. 51), 29

fueron caracterizados, de los cuales 27 son entidades de Domino y 2 son relaciones

encontradas durante el análisis. Lo anterior representa el 90% de la totalidad de elementos, por

esta razón se puede concluir que el DSL se encuentra completo.

En lo que respecta a la correctez, el conjunto de entidades fue definido en base a un análisis

junto con los expertos de Lotus Domino Designer para determinar el conjunto de relaciones

existentes entre elementos, así como las propiedades de cada entidad. Por esta razón se puede

Figura 6.6. DSL actuando como puente de comunicación entre diseñador y desarrollador

Diseñador Desarrollador

Comunicación

DSL

Capitulo 6. Pruebas


decir que el conjunto de relaciones utilizadas entre las entidades representa correctamente la

relación existente puesto que estas relaciones no fueron inventadas, siguen un conjunto de

reglas de diseño del entorno de desarrollo obtenidas de un análisis con expertos en el dominio.

La ambigüedad se mide con base a que una entidad debe tener sólo una representación o

entendimiento ante los usuarios que la utilizan. Basándose en esta aserción, la simbología

utilizada por el DSL se encuentra basada en los símbolos representativos de cada entidad en el

entorno de LDD. De esta manera se puede decir que ningún elemento puede tener una

representación equivoca ante un conocedor del ambiente de desarrollo.

6.3. Modelado del portal SIGCO

Para demostrar que el lenguaje puede utilizarse en el modelado de aplicaciones Domino, se propuso

realizar algunos modelos para un portal que se encuentra desarrollado en la Gerencia de Sistemas

Informáticos (GSI) en el Instituto de Investigaciones Eléctricas, el portal se denomina Sistema

Institucional para la Gestión del Conocimiento (SIGCO), Comunidades de Práctica. La página inicial

del portal aparece en la figura 6.7.

El prototipo realizado para probar que el lenguaje puede utilizarse en el modelado de

aplicaciones Domino se realizó en la herramienta de modelado UML Enterprise Architect en su versión

de evaluación 7.1. Este prototipo tiene implementadas las entidades y propiedades de cada entidad,

pero no el conjunto de restricciones o reglas de modelado, debido a las limitantes de la herramienta

sobre la cual se implemento. Así, los modelos fueron realizados por un experto en el desarrollo

Domino, de esta manera no se necesita el conjunto de reglas puesto que conoce el ambiente de

desarrollo en general. Los modelos que a continuación se muestran no presentan el conjunto de

propiedades de cada entidad por cuestiones de espacio en cada modelo.

Figura 6.7. Página inicial del portal SIGCO

Capitulo 6. Pruebas


Las aplicaciones de este portal se encuentran conformadas por seis repositorios o bases de

datos. Las aplicaciones disponibles son: portal, repositorio de temas gráficos, administración

organizacional, gestión integral de comités, foros de comités de especialistas, administración de

contenidos y difusión corporativa como se muestra en la figura 6.8.

La aplicación utilizada para realizar modelos de prueba es Comunidades de Practica. El

diagrama de la figura 6.9 muestra las bases de datos por las cuales se encuentra conformado el portal

SIGCO.

Figura 6.9. Arquitectura general del portal

Figura 6.8. Aplicaciones disponibles en el portal SIGCO

Capitulo 6. Pruebas


La aplicación Comunidades de Practica utiliza a la base de datos Comités de Especialistas V3.

La figura 6.10 muestra que esta base de datos es utilizada por la base de datos principal Portal. La base

de datos Comités de Especialistas V3 es la que se utilizó para continuar realizando diversos diagramas

de esta aplicación.

Para navegar dentro de la aplicación Servicios de Comités ubicado en la base de datos Comités

de Especialistas V3 se necesita tener alguno de los dos roles disponibles: administrador o coordinador.

Estos roles permiten acceder a distintas funcionalidades a través de los elementos de Domino.

En la figura 6.11 aparecen los dos roles que pueden acceder a las funcionalidades de esta

aplicación. Las funciones para el rol de coordinador también aparecen en esta figura, las funciones

posibles para el rol de coordinador son tres: creación y edición de comunidades de práctica, creación y

edición de grupos de trabajo y eliminación de comités. Las funciones posibles para el rol de

administrador son dos: configuración de la aplicación y categorías de comunidades de práctica.

En los diagramas que se muestran posteriormente se describe la estructura en términos de los

componentes de LDD que debe llevar cada una de estas funcionalidades.

Figura 6.10. Arquitectura de la base de datos Comunidades de práctica

Figura 6.11. Roles para los usuarios de la aplicación y funciones para ambos roles

Capitulo 6. Pruebas


La figura 6.12 muestra la arquitectura de navegación de la interfaz para los roles coordinador y

administrador. Esta arquitectura está indicando de manera general cuales son los componentes

necesarios para que ambos roles puedan acceder a sus respectivas funciones. Por ejemplo, el diseñador

ha especificado que ambos roles deben acceder a sus funciones a través de un formulario que llevará

por nombre ServiciosF, este será el principal acceso para cada rol. También indica que este formulario

tendrá que estructurarse de la siguiente manera: se compone de un campo, un subformulario, una barra

de acciones a través de una librería de java Script y una hoja de estilo. El formulario también hace uso

de dos formularios para complementar su funcionalidad: CategoriasComitesAdminF y

ConfoguraciónF.

Los formularios CategoriasComitesAdminF y ConfiguraciónF también cuentan con una

arquitectura compuesta de otros elementos. Aquí sólo aparecen como elementos de ServiciosF puesto

que la idea principal es mostrar el esquema principal de navegación de los usuarios a través del

conjunto de elementos.

El rol de coordinador tiene una arquitectura asociada a la funcionalidad a la cual éste tiene

acceso. El diagrama de la figura 6.13 muestra la arquitectura general para el coordinador. Esta figura

muestra que un usuario coordinador usa al elemento ServiciosF para utilizar a alguna de las tres

Figura 6.12. Diagrama correspondiente a la arquitectura de navegación de la base

de datos Foros de Comités.

Capitulo 6. Pruebas


funcionalidades que aparecen en la figura 6.11. Estas tres funcionalidades a su vez tienen una cierta

arquitectura que permite al usuario utilizarla. Por ejemplo, un usuario coordinador utiliza el elemento

vista ComitesDirectivosV para crear un comité a través del formulario CreaComiteF. Este formulario

se encuentra compuesto de dos vistas (ComitesPorClaveAliasV y CategoriasComitesV) y de una barra

de acciones la cual contiene a la acción GenerarGrupoRector y que a su vez utiliza al agente

CreaEspacioComite. De esta manera se encuentra conformada la arquitectura general necesaria para el

rol coordinador acceda a sus tres funcionalidades básicas. Cada funcionalidad debe especificarse a

través de sus propios elementos estructurales.

Figura 6.13. Arquitectura general de coordinador de comités

Capitulo 6. Pruebas


Cuando el rol de coordinador utiliza la función Creación y Edición de Comunidades de

Práctica mostrado en la figura 6.11, está utilizando el caso de uso “Creación de una Copr” (creación

de una comunidad de practica), el cual corresponde a la vista central ComitesDirectivosV mostrado en

la figura 6.13 y a las pantallas de la figura 6.14.

Figura 6.14. Pantallas correspondientes a la creación de un comité de práctica

Capitulo 6. Pruebas


Los elementos estructurales para implementar la funcionalidad correspondiente a este caso de

uso aparecen en la figura 6.15. La figura muestra los elementos que un coordinador debe utilizar para

crear la funcionalidad especificada en el caso de uso y en su documento de requerimientos y que

permiten crear una comunidad de práctica.

Figura 6.15. Diagrama correspondiente al CU creación de una Copr

Capitulo 6. Pruebas


Cuando el rol de coordinador utiliza la función Eliminación de Comités mostrado en la figura

6.11, está utilizando el caso de uso “Eliminar una Copr” (eliminación de una comunidad de practica),

el cual corresponde al formulario AdministraComitesF mostrado en la figura 6.13 y a las pantallas de la

figura 6.16.

Figura 6.16. Pantallas correspondientes a la eliminación de un comité de práctica

Capitulo 6. Pruebas


Los elementos estructurales para implementar la funcionalidad correspondiente al caso de uso

eliminar un Copr aparecen en la figura 6.17. Este diagrama muestra que para desarrollar esta

funcionalidad de utilizar al formulario AdminstraComitesF para iniciar el proceso de eliminación del

comité. Este elemento debe componerse de la vista Comités de Especialistas y de un Subformulario

Campos_RecursosSF. Esta vista a su vez contiene dos subformularios: AltaComiteF y

ComiteEliminadoF. El primero de estos se compone de una barra de acciones, la cual contiene a la

acción eliminar comité.

Figura 6.17. Diagrama correspondiente al CU eliminación de un Copr

Capitulo 6. Pruebas


Cuando el rol de coordinador utiliza la función Creación y Edición de Grupos de Trabajo

mostrado en la figura 6.11, está utilizando los casos de uso Dar de alta los grupos de trabajo, Dar de

baja los grupos de trabajo y Editar los grupos de trabajo, los cuales corresponden a la vista Grupos

deTrabajoV mostrado en la figura 6.13 y a las pantallas de la figura 6.18.

Figura 6.18. Pantallas correspondientes a la creación, edición y eliminación de grupos de trabajo

Capitulo 6. Pruebas


Los elementos estructurales para implementar la funcionalidad correspondiente a los casos de

uso de la figura anterior aparecen en la figura 6.19. Este diagrama muestra que un coordinador utiliza

al formulario ServiciosF para acceder a la opción Creación y Edición de Grupos de trabajo mostrado

en la figura 6.11. Este formulario hace uso de la vista GruposTrabajoV para llamar al formulario

CreaGrupoF y generar un nuevo grupo. Esta vista se encuentra conformada por cuatro columnas y el

formulario CreaGrupoF se conforma de una tabla con los campos correspondientes donde se capturará

información. Para generar el grupo, el formulario hace uso del agente Crea Espacio Grupo invocado a

través de la acción Generar Grupo contenida en la barra de acciones. Cuando requiere editar o eliminar

un grupo se utiliza la misma arquitectura con la diferencia del agente al cual se llama de acuerdo a

funcionalidad requerida.

Figura 6.19. Diagrama correspondiente a los caso de uso crear, editar y eliminar grupos

Capitulo 6. Pruebas


Cuando se utiliza el rol de administrador y se accede a la Configuración de comités de

especialistas (configuración de la aplicación) mostrado en la figura 6.11, se accede a la pantalla de la

figura 6.20. En ésta se puede modificar la configuración de las bases de datos y la URL de acceso a la

misma. También aparecen las opciones Guardar y Calcular.

Figura 6.20. Pantalla correspondiente a la configuración de comités de especialistas

Capitulo 6. Pruebas


El diagrama de la figura 6.21 muestra a las entidades que el administrador utiliza durante la

configuración de comités de especialistas. En la figura se muestra que para guardar la configuración el

usuario utiliza a la acción Guardar contenida en la barra de acciones que se encuentra en el formulario

ConfiguraciónF. Para utilizar el botón calcular el usuario invoca a la acción Calcular contenida en la

misma barra de acciones.

La configuración de comités de especialistas contiene más tablas y campos que no aparecen en

la figura 6.21. Debido a que son bastantes los campos incluidos en la pantalla de la figura 6.20, estos

campos y tablas no aparecen por cuestiones de espacio en este esquema.

Figura 6.21. Diagrama correspondiente a la configuración de comités de especialistas

Capitulo 6. Pruebas


Cuando el rol de administrador accede a la opción Categorías de comunidades de práctica

mostrada en la figura 6.11, se accede a las pantallas de la figura 6.22. En ésta se puede crear, editar y

eliminar una categoría.

Figura 6.22. Creación, edición y eliminación de una categoría de un comité

Capitulo 6. Pruebas


La estructura correspondiente a esta parte de la aplicación y que proporciona la funcionalidad

de administrar las categorías de comités se muestra en la figura 6.23. Un administrador utiliza el

formulario ServiciosF para acceder al formulario CategoriasComitesAdminF mostrado en la parte

superior de la figura 6.22. Este formulario se encuentra conformado por la vista CategoriasComitesV,

el subformulario Campos_RecursosSF y una barra con las acciones Eliminar y NuevaCategoria. Esta

última acción utiliza al formulario CategoriasComitéF para crear y editar una categoría a través de las

acciones Guardar y Editar. Para eliminar una categoría sólo hay que utilizar la acción eliminar, la cual

llama al agente Eliminardocumento.

Figura 6.23. Diagrama estructural para crear, editar y eliminar una categoría


Capítulo 7. Conclusiones

El presente capítulo describe las conclusiones obtenidas durante el desarrollo de esta tesis y los trabajos

futuros para complementar este trabajo.

7.1. Conclusiones

La conclusión más importante a la que se ha llegado después de haber realizado el lenguaje de

modelado para el dominio de Lotus Domino Designer es la siguiente:

Se cumplieron los dos objetivos presentados en la pág. 16:

o El primer objetivo fue caracterizar los elementos de Lotus Domino Designer

realizando una búsqueda, selección y definición del conjunto de elementos, relaciones

y restricciones que el lenguaje de modelado para LDD requiere, así como la

simbología correspondiente a cada uno de ellos.

Capitulo 7. Conclusiones


o El segundo y más importante objetivo cumplido fue que se creó un lenguaje de

modelado con el resultado de caracteriza LDD. El lenguaje se construyó formalizando

las entidades a través de un Perfil UML, el cual ofrece la especialización de entidades

en conceptos más específicos acorde a un dominio.

Durante el desarrollo del DSL se llego a otras conclusiones importantes que a continuación se

mencionan:

La metodología FODA es una recopilación de varios métodos para realizar análisis de

dominios. No obstante, aun se encuentra lejos de estar a la altura para realizar un análisis de

dominio de acuerdo a las necesidades actuales por los avances en las tecnologías de desarrollo.

En este trabajo se presentó el análisis de dominio para definir la sintaxis abstracta de LDD a

través del método FODA, el cual se adaptó de acuerdo a las necesidades que el análisis

requirió para el entorno LDD. El análisis arrojó un conjunto de elementos con los que se

construyen sistemas del dominio de Lotus Notes/Domino, un conjunto de relaciones y las

propiedades de las mismas.

Definir un lenguaje de modelado no es una tarea trivial. En la actualidad el uso de una

metodología formal para encontrar y definir primitivas de modelado de un entorno de

desarrollo no es muy clara. A pesar de la cantidad de lenguajes de modelado para dominios

específicos que existen en la literatura, las herramientas actuales que permiten definir estos

lenguajes se centran en el uso de la herramienta, quedando a un lado la parte de análisis,

búsqueda y definición de las primitivas de modelado y por tanto la metodología de análisis.

El Lenguaje de Modelado Unificado a través de los Perfiles UML posee un gran potencial al

permitir utilizar todas sus entidades en el modelado junto con las entidades especializadas que

conforman a un perfil UML.

Lotus Domino Designer es una herramienta de desarrollo compleja. Las aplicaciones

construidas en este entorno poseen un conjunto de relaciones entre sus elementos que pueden

ser complicadas, puesto que desde código fuente nativo de Domino o JavaScript se puede

invocar a cualquier componente de Domino o realizar cualquier funcionalidad como guardar,

actualizar o eliminar un documento.

Los diagramas obtenidos en el modelado del portal SIGCO no son intuitivos para usuarios no

capacitados en el desarrollo de aplicaciones Domino. Así, es recomendable que el modelador

tenga conocimientos en el desarrollo de aplicaciones para Lotus Notes/Domino antes de querer

utilizar una herramienta con soporte para el lenguaje definido en el anexo A.

Las herramientas actuales con soporte para UML y específicamente para los perfiles UML

carecen de un lenguaje de restricciones ejecutable que permita restringir en tiempo de diseño

los modelos generados por algún perfil. Estas herramientas cuentan con el Lenguaje de

Restricción de Objetos OCL (del inglés Object Constraint Language), este lenguaje es textual

y no restringe relaciones o propiedades en tiempo de ejecución, por lo que no es de mucha

utilidad al momento de modelar.

Es difícil para un desarrollador sin experiencia en el modelado aprender un lenguaje de

propósito general como UML y aplicarlo en un dominio particular para el cual no fue

realizado. Entender a la perfección la variedad de diagramas de este lenguaje toma cierto

tiempo y más aplicarlos en un dominio específico. Por lo general los desarrolladores buscan los



diagramas adecuados para tratar de representar situaciones, estructuras, parámetros o procesos,

pero esto no es fácil cuando no se tiene experiencia. Es aquí donde entra el potencial de un

DSL, permitiendo el manejo de conceptos específicos sobre los objetos y la semántica utilizada

por un entorno determinado. Esto permite que el desarrollador se familiarice fácilmente con el

manejo de estos conceptos puesto que conoce el dominio sobre el cual trabajan los mismos.

El potencial de diseño quedará definido por la herramienta que le dé soporte al lenguaje. La

viveza y agilidad del desarrollador de la herramienta podrá dar más potencial al DSL

facilitando aun más la forma de modelado por las facilidades que la herramienta podría

presentar para realizar modelos.

Es necesario implementar una entidad que maneje todo lo relacionado con el código fuente de

las aplicaciones Domino, puesto que existe funcionalidad que se logra a través de código.

También es necesario analizar cómo integrar esta entidad en el DSL y el tipo de relación que se

manejará con las distintas entidades que ya se encuentran definidas.

El analista del dominio debe conocer profundamente el sistema de programación que un

entorno utiliza ya que el programador puede utilizar su destreza para saltar reglas o estándares

de programación y aparentar que cierta funcionalidad se da de cierta manera y en realidad no

funciona así. Por lo tanto, es importante conocer todas las variantes que pueden presentarse

durante el desarrollo de una aplicación con la finalidad de que se realice un buen análisis.

Respecto a las herramientas que auxilian en el desarrollo de lenguajes de modelado se

concluye que en su mayoría no tienen soporte para realizar un análisis al dominio sobre el

cual se requiere obtener un conjunto de componentes reutilizables. Estas herramientas

tienen documentación sobre como introducir e implementar el lenguaje en la herramienta,

pero el usuario debe tener construido el conjunto de entidades, relaciones y restricciones

previamente.

En la actualidad no existe una técnica definida para representar gráficamente el conjunto

de elementos que pertenecen a un lenguaje de modelado. La representación para cada

elemento se define en base a la funcionalidad que maneja dentro del ambiente en el que se

encuentra.

7.2. Aportaciones

Las aportaciones que este trabajo de investigación ha realizado se describen a continuación:

Se logró construir un lenguaje de modelado que permite crear modelos estructurales de

aplicaciones Domino. En la actualidad no existe un lenguaje que trate de describir de

manera adecuada como se estructura una aplicación dentro del paradigma que Lotus

Domino Designer utiliza para construir aplicaciones

El método utilizado para realizar la caracterización puede utilizarse como referencia para

construir una metodología adecuada que permita obtener componentes reutilizables. Los

métodos actuales encontrados en la literatura se crearon hace más de diez años. La

tecnología ha avanzado bastante en ese tiempo, por lo que las exigencias han cambiado y

es necesario contar con una metodología que guíe en el proceso de análisis.



El DSL pretende introducir a los diseñadores de software en el mundo formal de la

ingeniería de software para Lotus Domino Designer, tratando de complementar los

modelos actuales con un modelo más representativo y con características propias del

entorno de desarrollo.

El lenguaje puede utilizarse para construir una herramienta que dé soporte al mismo y que

facilite el diseño conceptual de aplicaciones Domino. Esta herramienta beneficiará a los

ingenieros de software de LDD puesto que en la actualidad no existe una herramienta que

se especialice en el modelado de sistemas para la plataforma Domino.

7.3. Trabajos futuros

Los trabajos que pueden o deben realizarse sobre la especificación de este lenguaje son los

siguientes:

Implementar una herramienta con soporte al lenguaje. La especificación presentada en el anexo

A debe tener una herramienta que dé soporte a las entidades, relaciones y restricciones. Esta

herramienta deberá complementarse con otros componentes de UML como los actores y

relaciones de usabilidad, entre otros para que el lenguaje se enriquezca con el potencial de

UML.

Implementación del elemento código. Puede agregarse un elemento código a los elementos del

lenguaje con el fin de modelar las interacciones y llamadas entre componentes que se realizan

a través de código nativo de Dominio o JavaScript. Para realizar esta actividad debe analizarse

el código fuente de las aplicaciones para determinar la manera en que debe de utilizarse este

elemento en el modelado conceptual.

Puede obtenerse una metodología para analizar dominios de aplicación si se analizan las

metodologías existentes con el fin de obtener componentes reutilizables. Los métodos actúales

para la obtención de entidades reutilizables se encuentran obsoletos, por lo que sería

conveniente trabajar en el desarrollo de un método.

7.4. Publicaciones

Durante la elaboración de esta tesis se publicó y presentó el siguiente artículo de investigación en la

ciudad de Mazatlán Sinaloa durante el Congreso Internacional de Informática Aplicada 2008 (CIIA),

evento organizado por la Facultad de Informática de la Universidad Autónoma de Sinaloa.

Artículo: Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo

Rápido de Aplicaciones.

Autores: L.I. Jesús Guillermo Rivera Parra, M.C. Hugo Estrada Esquivel, Dr. Máximo López

Sánchez y M.C. Isaac Alberto Parra Ramírez.

Lugar y fecha: Culiacán y Mazatlán, Sinaloa del 21 al 25 de abril del 2008.


Anexo A. Perfil UML para Lotus Domino Designer

A1. 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, así como 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 mapeado a una notación UML, especializando los conceptos como clases a estereotipos con sus respectivos

nombres y atributos.



a. 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 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 form

quien 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.

b. 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 Web de LDD. Un ejemplo de la estructura de un documento se

da a través del form mostrado en la figura a1. En ésta se muestra a un 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. Este form también cuenta con una barra de acciones (action bar), la cual tiene cuatro acciones (actions)

disponibles.

Figura A1. Etapa de diseño de un elemento form en el entorno LDD



En la actualidad, no es posible expresar a través de un lenguaje de modelado la estructura que tienen las

aplicaciones Web desarrolladas en el entorno de desarrollo Lotus Domino Designer. Esto se debe a que la

mayoría de los lenguajes modelan código fuente debido a que son orientados a objetos y a que LDD no es un

entorno tradicional orientado al desarrollo a través de bases de datos relacionales y al código fuente orientado a

objetos.

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. El form que aparece en la figura a1 puede

modelarse considerando el Perfil UML que se especifica posteriormente en este documento como se muestra en

la figura a2.

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.

Figura A2. Diagrama representado con el perfil UML para el form mostrado en la figura a1



A2. Desarrollo del Perfil UML para Lotus Domino Designer

Para desarrollar el Perfil para LDD se seguirá el método propuesto en la sección 3.10.2 (pág. 39) 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 siguiente subsección se describe de manera general el

metamodelo de LDD para el desarrollo de aplicaciones Web.

a. Metamodelo de Lotus Domino Designer

Para el caso del entorno de desarrollo LDD, 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 a3 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.

b. Definición del perfil

Continuando con el método de Lidia Fuentes en el punto dos de la sección 3.10.2 (pág. 39), la cual 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.

Figura A3. Metamodelo de Lotus Domino Designer



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.

Tabla A.1. Estereotipos definidos para Lotus Domino Designer

Nombre en el

metamodelo

Nombre

del Estereotipo

Meta-clase

base en UML Descripción Imagen asociada

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.

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. Script Library <<script library>> 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.

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 elemento View. 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 listados

en un View o Folder. Son un

componente estructural de los

mismos.

Button <<button>> Class



i. Metamodelo Virtual (MV)

El Metamodelo Virtual (MV) es un modelo formal de un conjunto de extensiones de UML expresadas en

notación UML [RATIONAL 01]. 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 en la figura a3. Cada uno de los

elementos que conforman el metamodelo de la figura a3 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.

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.

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

<<Reflexive

Contention>>

Aggregation Relación similar a la

“<<contention>>”, se diferencia en

que sólo se utiliza para relacionar

elementos del mismo tipo.

<<containment>>

<<ReflexiveContainment>>

Figura A4. Clasificación de los estereotipos de LDD



Los principales contenedores que aparecen en el diagrama de paquete principal containers en la figura

a4 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. 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 empotrar un elemento sobre otro o 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 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 de la figura a 5 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 es la transición entre el metamodelo de la figura a3 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.



A 5. Metamodelo de Lotus Domino Designer con notación UML



ii. Representación de los estereotipos

El MV representa a un estereotipo como una clase estereotipada «stereotype». Por ejemplo, una clase

estereotipada «Form» representa a un elemento cuyo proveedor es el elemento 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.

En la figura a6 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 enumeración VersioningForm corresponde a las opciones posibles para la propiedad Versioning del

estereotipo Form.

Figura A6. Extendiendo al metaelemento Class



La figura a7 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 A7. Continuación de la extensión del metaelemento Class



La figura a8 muestra a los estereotipos field y 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.




La figura a9 muestra a los estereotipos view, column y folder extendiendo a la metaclase Class. También

se muestran sus valores etiquetados (atributos del estereotipo) y algunas clases de tipo «enumeration»





La figura a10 muestra a los estereotipos file, image, applet y stylesheet extendiendo a la metaclase

Component. También se muestran sus valores etiquetados (atributos del estereotipo) y algunas clases de tipo


Figura A10. Extendiendo al metaelemento Component



La figura a11 muestra a los estereotipos outline, computerText, outlineEntry y hotspot extendiendo a la

metaclase Class. También se muestran sus valores etiquetados (atributos del estereotipo) y algunas clases de tipo





La figura a12 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»





La figura a13 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.




La figura a14 muestra a los estereotipos contention y reflexivecontention extendiendo a la metaclase

Aggregation.

iii. 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.

1. 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 debido a que debe encabezar la raíz en los modelos. 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 estereotipos que pueden relacionarse a éste

son: forms, views, pages, agent y frameset.

Elementos que pueden contenerlo Ningún estereotipo puede hacer uso de éste para relacionarlo como elemento que está contenido

en otro. La única excepción es invocar a un elemento que está contenido en otra base de datos.

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.

Figura A14. Extendiendo al metaelemento Aggregation



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 Bases de Datos 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

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 documento acerca de.

OpenDesignatedFrameset: string

Valor string que permite especificar el frameset que se lanzará al momento de

abrir la BD.

OpenDesignatedPage: string

Valor string que permite especificar el page que se lanzará al momento de abrir la

BD.

OpenDesignatedNavigator: string

Valor string que permite especificar el navigator que 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.

Imagen asociada al elemento

2. Estereotipo «Form»

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.

Elementos que pueden contenerlo 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

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 ocultará si el valor de esta propiedad es true.

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. Las opciones disponibles son:



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

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.

DesHTMLTag_cription: string



Restricciones

La propiedad CreateVersions sólo puede utilizarse cuando no se elige el valor por defecto None

de la propiedad Versioning.




3. 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


Este estereotipo puede relacionarse directamente y contener a los siguientes estereotipos: table,

section, actionbar, view, folder, computertext, file, outline, subform, stylesheet, field,

scriptlibrary, images, applet, navigator, hotspot y button.

Elementos que pueden contenerlo 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.




4. 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.


frame.

Valores Etiquetados

Name: String

Valor string que representa el nombre del frameset.

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 elemento ID 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

Este elemento no tiene restricciones en el uso de sus propiedades.




5. 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


Este estereotipo puede relacionarse directamente y contener a los siguientes estereotipos:

frameset, form, view, folder, page y navigator.

Elementos que pueden contenerlo 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 Type o 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.

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.


Web.

HTMLTag_Id: string













Description: string



Restricciones



6. 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



applet, file, hotspot, actionbar, view, agent, folder, section, table, button, outline, image,

scriplibrary, navigator, stylesheet y computertext.


frame.

Valores Etiquetados

Name: string

Valor string que representa el nombre del estereotipo page.

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

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


Description: string



Restricciones

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


7. 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.

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes 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

Tipo de dato que permite comportarse al field como una lista de opción múltiple a

través de casillas de selección.

RadioButton

Tipo de dato que permite comportarse al field como una lista de opción múltiple

donde sólo puede elegirse una de ellas a través de botones de radio.

Listbox


múltiple a través de una caja de texto que contiene dos botones (arriba-abajo)

para navegar a través de la lista.

Combobox


múltiple a través de una caja de texto que contiene 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:

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 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

Valor booleano que indica que este elemento se ocultará al utilizar un cliente del

tipo navegador Web.

Mobile: boolean= false


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


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

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


Web.

HTMLTag_Id: string













Description: 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,

HideParagraphIfFormulaIsTrue y Formula sólo están disponibles cuando la propiedad shared

tiene un valor de false.

Cuando el valor de la propiedad HideParagraphFrom es NotesR4.6orLater sólo pueden

utilizarse las opciones OpenedForReading y OpenedForEditing de la propiedad

HideWhenDocumentIs.


8. 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

lenguaje JavaScript 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.

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes 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.


Valor booleano que indica si el estereotipo es compartido o simple. Un 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


clientes de los cuales puede ocultarse un elemento son:

NotesR4.6orLater: boolean = false



WebBrowser: boolean = false

Valor booleano que indica que un elemento se ocultará al utilizar un cliente del

tipo navegador Web.

Mobile: boolean = false


móvil.

HideActionWhenDocumentIs: WhenDocumentIsOptions












previsualización.




HideActionIfFormulaIsTrue: boolean = false



Formula: string




Description: string


desempeña este elemento.

Restricciones

Sólo están disponibles los valores PreviewedForReading, OpenedForReading,

PreviewedForEditing y OpenedForEditing en la propiedad HideActionWhenDocumentIs.


9. 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



column y actionbar.

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes 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

Opción que permite seleccionar el tipo de view. Esta propiedad puede tener los

siguientes valores: Operation e Interface.

Style: ViewStyle = StandardOutline

Permite seleccionar el estilo del view. Los valores posibles son:

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 determinar el estado inicial en el que se muestra una vista

cuando esta se abre por primera vez y se encuentra dividida. Las categorías pueden

aparecer colapsadas o desplegadas, elegir valor true para que las categorías aparezcan

colapsadas.

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.

Un nuevo view debe contener al menos a un elemento column simple al momento de su

creación.

Las propiedades CollapseAllWhenDBisFirstOpened, RowHeight y

ShowResponseDocumentsInAhierarchy no están disponibles cuando se elige la opción calendar

de la propiedad Style.




10. Estereotipo «Folder»

Descripción

Un folder es 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



column y actionbar.


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

Opción que permite seleccionar el tipo de folder. Esta propiedad puede tener los

siguientes valores: Operation e Interface

Style: ViewStyle = standardOutiline

Permite seleccionar el estilo del folder. Los valores posibles son:

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 jerárquica.

CollapseAllWhenDBisFirstOpened: boolean = false

Valor booleano utilizado para determinar el estado inicial en el que se muestra una vista

cuando esta se abre por primera vez y se encuentra dividida. Las categorías pueden

aparecer colapsadas o desplegadas, elegir valor true para que las categorías aparezcan

colapsadas.

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


Un nuevo folder debe contener al menos a un elemento column simple al momento de su

creación.

Las propiedades CollapseAllWhenDBisFirstOpened, RowHeight y

ShowResponseDocumentsInAhierarchy no están disponibles cuando se elige la opción calendar

de la propiedad Style.


11. 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 views o folders en la misma BD.


Class

Relaciones


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

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes estereotipos: view y

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.


Valor booleano que indica si el estereotipo es compartido o simple. Un column simple es

aquel que se diseña directamente en un view o folder. Una columna compartida 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

Valor booleano que permite desplegar iconos en vez de texto en una columna para hacer

que ésta sea distintiva.

ShowResponsesOnly: boolean = false

Valor booleano que permite configurar una columna para mostrar las respuestas de los

usuarios cuando la vista se utilizan para mostrar una discusión.

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

Determina si una columna será del tipo estándar o categorizada.

StandardType

Se utiliza cuando se necesita una columna normal en una vista.

CategorizedType

Tipo de columna que se utiliza cuando la vista esta categorizada.

ShowMultipleValuesAsSeparateEntries: boolean = true

Si una columna ordenada despliega valores provenientes de una lista de valores

múltiples, é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 forma 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.

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


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


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



Restricciones

La propiedad ShowTwistieWhenRowIsExpandable no aplica cuando el elemento view en el que

se encuentra contenido la columna es de tipo calendar.

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.




12. 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




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

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


Permite que los usuarios tengan acceso al archivo. Para que un usuario tenga acceso, el


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



13. Estereotipo «Image»

Descripción

Representa a una imagen externa que se almacena en la BD.


Component

Relaciones




subform y page.

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 usuario tenga acceso, el


Description: string



Restricciones





14. Estereotipo «Stylesheet»

Descripción

Representa a una hoja de estilo importada en la BD.


Component

Relaciones




subform y page.

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


Description: string



Restricciones





15. Estereotipo «Applet»

Descripción

Representa a un Applet de Java importado a la BD.


Component

Relaciones


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

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes estereotipos: form, page,

subform, table y section.

Valores Etiquetados

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



16. 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.



Elementos que pueden contenerlo 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.


Permite que los usuarios tengan acceso al outline. Para que un usuario tenga acceso, el


Description: string



Restricciones

Un outline no puede estar contenido en un table o section al menos que estos estén



17. 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



Elementos que pueden contenerlo 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

Valor string que se utiliza para especificar el frame invocado al seleccionar el

outlineEntry.




Valor string que representa el tipo de contenido que desplegará el outlineEntry. Existen

cuatro tipos de contenidos que pueden elegirse:

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



NamedElement

Opción que se utiliza para especificar que el outlineEntry abrirá el elemento



Link

Opción que se utiliza para especificar que el outlineEntry 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

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 Type o una fórmula

que lanzará otro contenido, dirección o elemento de LDD.









tipo navegador Web.



móvil.















Embedded: boolean = false







previsualización.







HideParagraphIfFormulaIsTrue: boolean = false



Formula: string


Description: string



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.



HideWhenDocumentIs.


18. 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




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:

Link

Opción que se utiliza para especificar que el tipo de hotspot es Link Hotspot. Este

tipo de opción permite crear una liga a un documento, view, DB, URL u otros.

Action

Opción que se utiliza para especificar que el tipo de hotspot es Action Hotspot.

Este tipo de opción permite crear una acción programada utilizando alguno de los

lenguajes soportados por LDD.

Rectangle

Opción que se utiliza para especificar que el tipo de hotspot es Rectangle

Hotspot. 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

Opción que se utiliza para especificar que el tipo de hotspot es 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

Opción que se utiliza para especificar que el tipo de hotspot es 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.


Valor string que representa el tipo de contenido que desplegará el 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



NamedElement

Opción que se utiliza para especificar que el hotspot abrirá el elemento





Link

Opción que se utiliza para especificar que el hotspot abrirá un documento o

elemento view especificado en la propiedad value.

Frame: string

Valor string que se utiliza para especificar el frame invocado al seleccionar el hotspost.


Web.

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

Valor string que se utiliza para especificar la liga hacia el tipo de 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 estos estén contenidos

en un form, subform o page.

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.


19. 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.


Class

Relaciones




subform, page, table y section.

Valores Etiquetados

Value: string

Valor string que representa la etiqueta del campo calculado.











tipo navegador Web.



móvil.













Embedded: Boolean = false







previsualización.







HideIfFormulaIsTrue: boolean = false



Formula: string



Web.



HTMLTag_Id: string











Description: string



Restricciones



HideWhenDocumentIs.

Un computertext no puede estar contenido en un table o section al menos que estos estén



20. 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


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


subform, page, frame, table y section.



Valores Etiquetados

Name: string

Valor string que representa el nombre del navigator.

Description: string



Restricciones

Un navigator no puede estar contenido en un table o section al menos que estos estén


Un navigator sólo puede contener a hotspots del tipo: rectangle, polygon y circle.


21. 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


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


subform, page, table y section.

Valores Etiquetados

Name: string

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











tipo navegador Web.


Valor booleano que indica que este elemento se ocultará al utilizar un cliente móvil.




















previsualización.










Formula: string



Web.

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 Common JavaScript.

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.

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 estos estén contenidos

en un form, subform o page.



HideWhenDocumentIs.


22. Estereotipo «Agent»

Descripción

Representa a un elemento Agent en LDD. Estos elementos permiten automatizar tareas en Domino. Son

programas independientes que realizan una tarea específica en una BD.


Class



Relaciones


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


form, subform, action, y page.

Valores Etiquetados

Name: string

Valor string que representa el nombre del agent.

Type: AgentType= shared

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.



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

Opción que permite especificar que el agente se ejecutará sobre todos los

documentos de la BD.

AllUnreadDocumentsInView

Opción que permite especificar que el agente se ejecutará solamente sobre todos

los documentos sin leer de un view.

AllDocumentInView


documentos de un view.

AllSelectedDocument


documentos seleccionados.

None

Opción que permite especificar que el agente no se ejecutará sobre ningún

documento.

OnEventType: OnEventTypeOptions = ActionMenuSelection

Propiedad que permite especificar que el agente se iniciará cuando ocurra cierto evento.

Los eventos posibles son:

ActionMenuSelection

Opción que permite al usuario activar el agente.

AgentListSelection

Opción que se utiliza para determinar que el agente sólo podrá ser llamado por

otro agente.

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

Opción que permite especificar que el agente se ejecutará diariamente. Esta

opción se encuentra ligada a la propiedad StartRunningAgentAt.

Weekly

Opción que permite especificar que el agente se ejecutará semanalmente. Esta

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

Montly

Opción que permite especificar que el agente se ejecutará mensualmente. Esta

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

Never

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 string utilizado 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 string utilizado 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

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 TriggerOnSchedule no 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 propiedad OnEventType.

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

MoreThanOnceADay de 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 StartRunningAgentAtTime só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 propiedad

OnScheduleType.

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 ChooseServerWhenAgentIsEnable

tiene un valor true.


23. 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


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


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.




24. 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.


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

Permite que una tabla tome los márgenes completos de un documento de

izquierda a derecha.

FixedWith

Permite fijar un tamaño para cada columna de la tabla.

Type: TableType = 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.


25. 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.




subform, page.

Valores Etiquetados

Title: 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.









tipo navegador Web.



móvil.




















previsualización.












Formula: string


Description: string



Restricciones

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

page.



HideWhenDocumentIs.


26. 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


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

Elementos que pueden contenerlo Este estereotipo puede estar relacionado y contenido en los siguientes 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

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:

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

ingles), 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: string

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.


27. Estereotipo «ScriptLibrary»

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.


subform y page.



Valores Etiquetados

Name: string

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

Language: 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



28. 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.


Aggregation

Valores Etiquetados

Para ver los atributos de esta relación ver la sección A4.

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 figura a15 muestra un ejemplo de la notación para esta relación en UML.



Etiqueta identificadora de contención

«Containment» «stereotype»

contenedor


«stereotype»

contenido

Etiqueta identificadora de contención reflexiva

«ReflexiveContainment»


«stereotype»

contenedor

«stereotype»

contenedor

contenido

29. Estereotipo «Reflexive 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.

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.


Aggregation

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 figura a16 muestra un ejemplo de la notación para esta relación en UML.

A3. 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 A2.b.iii.28 (Contention pág. 175) y A2.b.iii.29 (Reflexive contention pág.

176). 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 en la tabla a.5. Esto quiere decir que estas dos relaciones también

podrán utilizarse para modelar aplicaciones Domino con la misma semántica de estas relaciones.

Figura A15. Notación para la relación de contención

Figura A16. Notación para la relación de contención reflexiva




«stereotype»

contenedor

«stereotype»

contenido

Indicador de composición

«stereotype»

contenedor «stereotype»

contenido

Figura A18. Relación de composición, esquema general

a. 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. Es una 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ón o la parte que

constituye al todo (contenido).


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

relaciones.

Valores etiquetados


Notación La agregación se representa por una línea sólida conectando a dos objetos, es decir, una relación binaria.

Tomando como base a [OMG 07], 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.

b. 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 [OMG 07].

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.

Valores etiquetados


Notación

La composición se representa por una línea sólida conectando a dos objetos, es decir, una relación

binaria. Tomando como base a [OMG 03] la composición se indica con un diamante relleno que se

añade al final del enlace. El diamante se dibuja en la clase que es el contenedor como se muestra en la

figura a18.

Figura A17. Relación de agregación, esquema general



A4. 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.

a. Multiplicity

Tabla A.2. 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.

b. Delete Propagation

Tabla A.3. 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 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.

Definida sobre association-end. 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).

c. Reflexivity

Tabla A.4. 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.

Definida sobre association-end. 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.



d. 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

A4 para cada una de las relaciones. De esta manera cada relación contiene ciertas propiedades definidas. La tabla

a.5 muestran los valores de las propiedades definidas anteriormente. El símbolo ∗ indica que una propiedad puede

tomar cualquier valor. Para cada relación (columna) la tabla muestra los valores de las propiedades.

Tabla A.5. 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

Referencias


Referencias [COHEN 92] COHEN, SHOLOM G., ET AL; “Application of Feature-Oriented Domain Analysis to the

Army Movement Control Domain” (CMU/SEI-91-TR-28, ADA256590). Pittsburgh, PA:

Software Engineering Institute, Carnegie Mellon University, 1992.

[COMER 90] COMER, E.R.; “Domain analysis: a system approach to software reuse”; Digital

Avionics Systems Conference, 1990. Proceedings. IEEE/AIAA/NASA 9th; 15-18 Oct.

1990 Paginas:224-229.

[CREAT 07] CREATIVE DATA;”Rapid Application Development – Development Methodology

(RAD)”; Ultima fecha de consulta: 17 de abril del 2007.

Fuente: http://www.credata.com/research/rad.html

[CRUZ 01] CRUZ MARIN, MIRNA; “Descripción visual del dominio de los sistemas en tiempo

real”; Tesis de Maestría, Departamento de Ciencias Computacionales, Centro Nacional de

Investigación y Desarrollo Tecnológico. Agosto del 2001.

[DARE 98] FRAKES W., PRIETO D.R., FOX C.; “DARE: Domain Analysis and Reuse

Environment”; Reporte técnico por ARPA/US Army Missile Command under SBIR,

Contract DAAH01-93-R302. Annals of Software Engineering 5 (1998). Páginas 125-141.

[DON 05] D. S. BATORY; “Feature models, grammars, and propositional formulas”; In Software

Product Lines, 9th

International Conference, SPLC 2005; Rennes, France, Septiembre 26-

29 del 2005; Proceedings, volume 3714 of Lecture Notes in Computer Science, paginas 7–

20. Springer, 2005.

[DSL 07] LANGLOIS B., CONSUELA-ELENA J., JOUENNE E.; “DSL Classification”; The 7th

OOPSLA Workshop on Domain-Specific Modeling; Montreal, Canada, 2007.

[Eclipse] FUNDACIÓN ECLIPSE; http://www.eclipse.org/

[Eclipse-1] FUNDACIÓN ECLIPSE; “Eclipse Modeling Project Proposal”; última fecha de consulta

20/10/2007; Fuente: http://www.eclipse.org/proposals/modeling/

[Eclipse-2] FUNDACIÓN ECLIPSE; “Generating an EMF Model”; 18 de junio del 2007; última

fecha de consulta: 21/10/2007.

Fuente: http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.emf.doc/

tutorials/clibmod/clibmod.html

[EMF 03] BUDINSKY F., STEINBERG D., MERKS E., ELLERSICK R., J. GROSE T.; “Eclipse

Modeling Framework: A Developer's Guide”; Addison Wesley; 11 de agosto del 2003.

[EMP] FUNDACIÓN ECLIPSE; Fuente: http://www.eclipse.org/modeling/

[EPS 05] GRUP DE RECERCA EN INTERACCIÓ PERSONA-ORDINADOR (GRIHO); “Modelo

de Proceso de la Ingeniería de la usabilidad y de la accesibilidad (MPIu+a)”; Escuela

Politécnica Superior (EPS), departamento de Informática e Ingeniería Industrial;

Copryright © GRIHO, 2005; Fecha de consulta: abril del 2007.

Fuente: http://griho.udl.es/mpiua/modelosmyc.htm

[FOF 07] C/O FOUNDATIONS OF SUCCESs; “Medidas de Éxito”; Capítulo 3, Diseñe un modelo

conceptual basado en las condiciones locales del sitio; Maryland USA; Fecha de consulta:

Marzo 2007.

Fuente: http://fosonline.org/images/Documents/Medidas/PDF4Tracy/d77927.pdf;

Referencias


[FUENTES] LIDIA FUENTES Y ANTONIO VALLECILLO. “Una introducción a los perfiles UML”.

Depto. de Lenguajes y Ciencias de la Computación, Universidad de Málaga, España.

[FUENTES 02] FUENTES L., VALLECILLO A. Y TROYA J.M.; “Using UML Profiles for Documenting

Web-Based Application Frameworks”; Annals of Software Engineering, 13:249–264,

2002.

[GUERRERO 07] GUERRERO L.A.; “Análisis y diseño orientado a objetos”; Universidad de Chile,

Departamento de Ciencias de la Computación; Fecha de consulta: abril del 2007. Fuente:

http://www.dcc.uchile.cl/~luguerre/cc40b/clase4.html

[GARCIA 06] GARCÍA M. J. J., GÓMEZ P. P., SÁNCHEZ, R. O.; “Herramientas de Metamodelado:

DSL Tools vs MetaEdit+”; Depto. De Informática y Sistemas, Facultad de Informática,

Universidad de Murcia; Septiembre del 2006.

[GMF] FUNDACIÓN ECLIPSE. http://www.eclipse.org/gmf/

[GMF-2] ECLIPSEPEDIA - THE ECLIPSE.ORG WIKI.

Fuente: http://wiki.eclipse.org/index.php/GMF_Tutorial

[HOLIB 93] ROBERT HOLIBAUGH; “Join Integrated Avionics Working Group (JIAWG) JODA

(Object Oriented Domain Analysis Method”; Special Report CMU/SEI-92-SR-3; Ver.

3.1.; Preparado por Software Engineering Institute; Carnegie Mellon University; Pittsburg,

Pennsylvania; Noviembre de 1993.

[HECKEL 03] HECKEL R., LOHMANN M., THÖNE S.; “Towards a UML Profile for Service-Oriented

Architectures”.

http://www.hwswworld.com/downloads/9_28_05_e/MDAFA-2003-FinalVersion.pdf

[IVES 99] TEAMSTUDIO DESIGNSYSTEM; “Software Engineering with Lotus Notes and

Domino”; Ives Development Inc.; White Paper; Edition 2; 1999.

Fuente: http://www.teamstudio.com.

[IBM 07] IBM; “Lotus Domino Designer”; fecha de consulta: mayo del 2007.

Fuente: www.ibm.com.mx

[JUHA 01] JUHA-PEKKA TOLVANEN; “Into the domain of speed”; Embedded Systems, Octubre

del 2001; 5 págs.

[JUHA 06] JUHA-PEKKA T.; “Creating a Domain-Specific Modeling Language for an Existing

Framework”; MetaCase 2006; Fuente: http://www.metacase.com.

[KRUT 93] ROBERT W. KRUT; “Integrating 001 Tool Support into the Feature-Oriented; Domain

Analysis Methodology”; Reporte especial (CMU/SEI-93-TR-34); Preparado por

Department of Computer Sciences; Austin, Texas: university of Texas at Austin; Mayo de

1993.

[KRUT 96] KRUT R., ZALMAN N.; “Domain Analysis Workshop Report for the Automated Prompt

and Response System Domain”; Software Engineering Institute, Pittsburgh,

Pennsylvania; Reporte especial CMU/SEI-96-SR-001; Mayo de 1996.

[MUÑOZ 05] MUÑOZ J., PELECHANO V.; “MDA vs Factorías de Software”; Departamento de

Sistemas Informáticos y Computadores; Universidad Politécnica de Valencia; Septiembre

del 2005.

http://www.hwswworld.com/downloads/9_28_05_e/MDAFA-2003-FinalVersion.pdf

Referencias


[MERNIK 03] MERNIK M., HEERING J., SLOANE A.M.; “When and How to Develop Domain-

Specific Languages”; Centrum voor Wiskunde en Informatica (CWI), Software

Engineering; Reporte SEN-E0309; Diciembre 8 del 2003.

[MetaCase 07] METACASE; “Domain-Specific modeling with MetaEdit+: 10 times faster than

UML”; White Paper, Copyright © 2007 por MetaCase.

Fuente: http://www.metacase.com

[MetaCase 06] METACASE; “The graphical metamodeling example”; MetaCase Document No. GE-4.5;

Copyright © 2006 por MetaCase Oy; 1a Edición, Noviembre del 2006;

[NGOC 07] NGOC BAO BUI, LIMING ZHU, IAN GORTON, YAN LIU; “Benchmark Generation

using Domain Specific Modeling”; Proceedings of the 2007 Australian Software

Engineering Conference (ASWEC'07); © 2007 IEEE Computer Society.

[OMG 01] OBJECT MANAGEMENT GROUP. “Meta Object Facility (MOF) Core Specification “

OMG Available Specification Version 2.0 formal/06-01-01

[OMG 03] OBJECT MANAGEMENT GROUP; “Unified Modeling Language Specification”; marzo

2003, disponible en línea “http://www.omg.org/docs/formal/03-03-01.pdf”, última

consulta el 19 de marzo del 2008.

[OMG 07] OBJECT MANAGEMENT GROUP. “UML 2.1.2 Infrastructure Specification”; OMG

document ptc/07-11-04, 2007.

[OMG-2 07] OBJECT MANAGEMENT GROUP. “UML 2.1.2 Superstructure”, UMG document pct/

07-11-02, 2007.

[PELECHANO 06] PELECHANO V., ALBERT M., MUÑOZ J. CETINA C.; “Building tools for model

driven development. Comparing Microsoft DSL Tools and Eclipse Modeling Plug-ins”;

XV Jornadas de Ingeniería del Software y Base de Datos JISBD 2006; CIMNE,

Barcelona, 2006.

[PRIETO 90] PRIETO DIAZ R.; “Domain Analysis: an introduction”; The Contel Technology Center,

Fairfax VA; ACM SIGSOFT Software Engineering Notes; Volume 15, Issue 2, abril de

1990.

[PRIETO 91] PRIETO, DÍAZ R.; “Reuse Library Process Model”; Technical Report Start Reuse

Library Program, Contract F19628-88-D-0032, Task IS40, Electronic Systems Division,

Air Force Command, USAF, Hanscomb AFB, MA.

[POWELL 04] POWELL A; “Model with the Eclipse Modeling Framework, Part 1: Create UML models

and generate code”; 15 de abril de 2004; ultima fecha de consulta: 20/10/2007.

Fuente: http://www.ibm.com/developerworks/opensource/library/os-ecemf1/

[RATIONAL 01] RATIONAL SOFTWARE CORPORATION.“UML Profile For EJB”. Public Draf,

5/25/2001.

[SEI 90] KANG, KYO C.; COHEN, SHOLOM G.; HESS, JAMES A.; NOVAK, WILLIAM E.; &

PETERSON,A. SPENCER; “Feature-Oriented Domain Analysis (FODA) Feasibility

Study”; (CMU/SEI-90-TR-21, ADA235785); Pittsburgh, Pa., Software Engineering

Institute, Carnegie Mellon University, 1990.

[SEI 07] SOFTWARE ENGINEERING INSTITUTE; “Domain Engineering: A model Based

Approach”; Carnegie Mellon University; Ultima actualización febrero 2007.

Referencias


[SELIC 07] SELIC BRAN; “A Systematic Approach to Domain-Specific Language Design Using

UML”; Proceedings of the 10th IEEE International Symposium on Object and

Component-Oriented Real-Time Distributed Computing (ISORC'07); Copyright © 2007

IEEE Computer Society.

[STEVEN 07] KELLY S., POHJONEN R.; “Interactive Television Applications using MetaEdit+”;

Workshop for the Model-Driven Development Tool Implementers Forum (MDD-TIF07);

Junio del 2007.

[TopCased 07] TOPCASED. Fuente: http://www.topcased.org/

[TULI 02] TULISALO T., CARLSEN R., GUIRARD A., HARTIKAINEN P., McCARTHY G.,

PECLY G.; “Domino Designer 6: A developer’s Handbook”; International Technical

Support Organization, IBM RedBooks; primera edición diciembre de 2002.

Fuente: ibm.com/redbooks

[WALT 07] WALTER MANER; “Rapid Application Development”; Copyright © 1997; Última fecha

de consulta: Abril del 2007;

Fuente: http://csweb.cs.bgsu.edu/maner/domains/RAD.htm#2.

[WikiP 07] WIKIPEDIA, LA ENCICLOPEDIA LIBRE; “Desarrollo Rápido de Aplicaciones”;

Última revisión: 11 de marzo del 2007; Ultima fecha de consulta: 24 de marzo del 2007;

Fuente:http://es.wikipedia.org/w/index.php?title=Desarrollo_r%C3%A1pido_de_

aplicaciones&oldid=7476158

[WikiP-2 07] WIKIPEDIA, LA ENCICLOPEDIA LIBRE; “List of Rapid Application Development

tools”; Última fecha de consulta: 17 de abril del 2007;

Fuente:http://en.wikipedia.org/w/index.php?title=List_of_Rapid_Application

_Development_tools&oldid=121471339

[WikiP-3 07] WIKIPEDIA, LA ENCICLOPEDIA LIBRE; “Domain-Specific Modeling”; Última fecha

de consulta: 20 de junio del 2007;

Fuente: http://en.wikipedia.org/w/index.php?title=Domain- Specific_

Modeling&oldid=133010051

mailto:[email protected]