cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS

Tamaño: px
Comenzar la demostración a partir de la página:

Download "cenidet Centro Nacional de Investigación y Desarrollo Tecnológico Departamento de Ciencias Computacionales TESIS DE MAESTRÍA EN CIENCIAS"

Transcripción

1 cenidet Centro Nacional de Investigación y Desarrollo Tecnológico 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 Cuernavaca, Morelos, México. 5 de diciembre del 2008

2 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

3 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.

4 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.

5 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.

6 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.

7 Índice de contenido Capítulo 1. Introducción... 1 Capítulo 2. Antecedentes Antecedentes de esta investigación Estado del arte Generación de un DSL mediante MetaEdit Definición de un metamodelo mediante MetaEdit Generación de un DSL mediante Microsoft DSL Tool Introducción a DSL Tools Arquitectura de DSL Tools Modelo de Dominio (DomainModel.dsldm) Diseñador (Designer.dsldd) Generación de un DSL mediante Eclipse Modeling Framework (EMF) Eclipse Eclipse Modeling Project (EMP) Eclipse Modeling Framework (EMF) Graphical Modeling Framework (GMF) Tabla de resumen de características Descripción del problema Objetivos General Específicos Justificación y beneficios Justificación Beneficios Metodología de solución Alcances y límites del proyecto Alcances Límites Capítulo 3. Marco teórico Desarrollo Rápido de Aplicaciones Modelado conceptual La ingeniería de dominios Análisis de dominio Método de Análisis de Dominio Orientado a Características (FODA) Fundamentos de la metodología FODA El proceso FODA Análisis de contexto Modelo del dominio Modelado de arquitectura Modelo de características Análisis de Dominio y Ambiente de Reuso (DARE) Libro del dominio Lotus Notes/Domino, un panorama general Lotus Domino Designer (LDD) Lenguaje de Dominio Específico (DSL Domain-Specific Language) Perfiles UML Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones i

8 Razones para elaborar un Perfil UML Elaboración de Perfiles UML Capítulo 4. Análisis de Lotus Domino Designer Estudio del entorno Lotus Domino Designer (LDD) Trabajando en Domino Designer Iniciando Domino Designer LDD como cliente El panel de diseño Ventanas a través de fichas La carpeta de marcadores (bookmark) La ventana de propiedades del objeto Ventana de propiedades del documento de diseño Ficha de información del documento (info tab) Ficha para el tipo de campo (Fields tab) Ficha de diseño Ficha de identificadores (ID) del documento Propiedades de los elementos de diseño Bloqueo de los elementos de diseño Vista previa del diseño Paneles para programadores Elementos de Domino Designer Capítulo 5. Caracterización de Lotus Domino Designer Estudio de metodologías para analizar dominios de aplicación Caracterización de Lotus Domino Designer Proceso de Análisis de Dominio de Lotus Domino Designer Análisis del Contexto de Lotus Domino Designer Analizando el dominio de LDD Diagrama de Contexto Diagrama de Estructura Limitando el alcance del dominio Modelado de Dominio de Lotus Domino Designer Elementos de Domino Designer Modelo de características de Lotus Domino Designer Elementos Contenedores y Contenidos Elemento Base de Datos Elemento Form Elemento View Elemento Page Elemento Frameset Elemento Action Bar Elemento Folder Elemento Tabla (table) Elemento Sección (section) Otros elementos contenedores Relaciones entre elementos de Lotus Domino Designer Características de relaciones de contención, contención reflexiva, agregación y composición Definición del metamodelo Aplicando una técnica de modelado visual Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones ii

9 Capítulo 6. Pruebas Introducción Demostración del lenguaje Características del lenguaje Modelado del portal SIGCO Capítulo 7. Conclusiones Conclusiones Aportaciones Trabajos futuros Publicaciones Anexo A. Perfil UML para Lotus Domino Designer Índice de figuras Figura 2.1. Explorador de solución Figura 2.2. Propiedades de la cardinalidad Figura 2.3. Componentes y modelos usados durante el desarrollo basado en GMF Figura 2.4. Metodología de solución Figura 3.1. Ciclos de desarrollo de software Figura 3.2. Estructura de la metodología FODA Figura 3.3. Notación del diagrama de características Figura 3.4. Diagrama de características para la elección de un automóvil Figura 3.5. Ejemplo del editor con un grupo Figura 3.6. Usuarios de DARE Figura 3.7. Modelo de procesos en DARE Figura 3.8. Editor de Arquitecturas Figura 4.1. Iniciando LDD desde el cliente Lotus Notes Figura 4.2. Personalizando la página de bienvenida de Lotus Domino Designer Figura 4.3. Panel de Lotus Domino Designer Figura 4.4. Organización de ventanas por medio de fichas Figura 4.5. Cuadro de dialogo para crear una nueva carpeta Figura 4.6. Propiedades del documento de diseño Figura 4.7. Ficha de información del documento Figura 4.8. Ficha de campo Figura 4.9. Ficha de diseño Figura Ficha de ID Figura Ventana de propiedades de una Vista (View) Figura Vista de objetos y vista de referencia Figura Barra de herramientas para la vista previa Figura Área de Scripts Figura 5.1. Fases del proceso para crear un DSL para Lotus Domino Designer Figura 5.2. Fases del análisis del contexto Figura 5.3. Arquitectura general de Lotus Notes Domino Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones iii

10 Figura 5.4. Diagrama de contexto, factores externos que impactan el desarrollo de aplicaciones en LDD Figura 5.5. Diagrama de estructura del dominio de Lotus Notes/Domino Figura 5.6. Limitando el alcance para el análisis del dominio Figura 5.7. Fases del modelado de dominio de Lotus Domino Designer Figura 5.8. Principales elementos de una base de datos Domino Figura 5.9. Elementos relacionados con un form Figura Elementos relacionados con un view Figura Elementos con los que se relaciona el elemento page Figura Elementos relacionados con los elementos frameset y frame Figura Elementos relacionados con un action bar y un action Figura Elementos relacionados con un folder Figura Elementos relacionados con una table Figura Elementos relacionados con un section Figura Elementos relacionados con un outline y un navigator Figura Relación de contención, esquema general Figura Relación de conteción reflexiva, esquema general Figura Relación de agregación, esquema general Figura Relación de composición, esquema general Figura Principales elementos contenedores de LDD Figura Elementos contendores secundarios Figura Elementos no contendores Figura Metamodelo de LDD Figura Posición en la estructura de Lotus Notes/Domino de los elementos de diseño 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 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 Figura 6.5. Uso de las relaciones containment, composition y uses Figura 6.6. DSL actuando como puente de comunicación entre diseñador y desarrollador Figura 6.7. Página inicial del portal SIGCO Figura 6.8. Aplicaciones disponibles en el portal SIGCO Figura 6.9. Arquitectura general del portal Figura Arquitectura de la base de datos Comunidades de práctica Figura Roles para los usuarios de la aplicación y funciones para ambos roles Figura Diagrama correspondiente a la arquitectura de navegación de la base de datos Foros de Comités Figura Arquitectura general de coordinador de comités Figura Pantallas correspondientes a la creación de un comité de práctica Figura Diagrama correspondiente al CU creación de una Copr Figura Pantallas correspondientes a la eliminación de un comité de práctica Figura Diagrama correspondiente al CU eliminación de un Copr Figura Pantallas correspondientes a la creación, edición y eliminación de grupos de trabajo Figura Diagrama correspondiente a los caso de uso crear, editar y eliminar grupos Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones iv

11 Figura Pantalla correspondiente a la configuración de comités de especialistas Figura Diagrama correspondiente a la configuración de comités de especialistas Figura Creación, edición y eliminación de una categoría de un comité Figura Diagrama estructural para crear, editar y eliminar una categoría Índice de tablas Tabla 2.1. Resumen de características de las herramientas para crear un DSL Tabla 3.1. Actividades de las fases del método FODA Tabla 3.2. Componentes del libro de dominio Tabla 4.1. Elementos de diseño de Lotus Domino Designer Tabla 5.1. Servicios ofrecidos por Lotus Domino Designer Tabla 5.2. Clientes para Domino Tabla 5.3. Incidencia de los elementos en las aplicaciones de Lotus Domino Designer Tabla 5.4. Elementos utilizados en el desarrollo de aplicaciones Tabla 5.5. Otros elementos de diseño de LDD Tabla 5.6. Elementos que realizan la función de contenedores en LDD Tabla 5.7. Elementos que realizan la función de contenidos en LDD Tabla 5.8. Definición de la propiedad multiplicidad Tabla 5.9. Definición de la propiedad propagación de borrado Tabla Definición de la propiedad reflexividad Tabla Valores fijos para la relaciones Tabla A.1. Estereotipos definidos para Lotus Domino Designer Tabla A.2. Definición de la propiedad multiplicidad Tabla A.3. Definición de la propiedad propagación de borrado Tabla A.4. Definición de la propiedad reflexividad Tabla A.5. Valores fijos para la relaciones Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones v

12 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 1

13 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 2

14 Capitulo 1. Introducción 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 3

15 Capitulo 1. Introducción 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 4

16 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 5

17 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 6

18 Capitulo 2. Antecedentes 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 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 La última versión al tiempo de esta escritura es la 4.5 de Noviembre del 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+: Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 7

19 Capitulo 2. Antecedentes 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 8

20 Capitulo 2. Antecedentes 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 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] 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 9

21 Capitulo 2. Antecedentes 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 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. Figura 2.1. Explorador de solución 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 10

22 Capitulo 2. Antecedentes 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 Figura 2.2. Propiedades de la cardinalidad 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] 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 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 Eclipse Eclipse fue desarrollado originalmente por la International Business Machines Corporation (IBM) como sucesor de la familia de herramientas VisualAge en noviembre del 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]. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 11

23 Capitulo 2. Antecedentes 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 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) 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]. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 12

24 Capitulo 2. Antecedentes 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 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 13

25 Capitulo 2. Antecedentes 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 (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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 14

26 Capitulo 2. Antecedentes 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 Si (GMF) NO (editar fichero Si (editor simbol) concreta XML) Nivel de personalización Alto Bajo Alto del aspecto gráfico del DSL 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, Por el líder del MetaCase Lenguaje utilizado para restricciones Lenguaje utilizado para generación de código Potencia lenguaje para restricciones Representación de los metatipos Intel, Borland, Nokia, etc.) mercado Microsoft OCL C# Lenguaje de informes (propietario) Java C# (o Visual Basic) y etiquetas Lenguaje de informes propietario Muy Alta Muy alta (C#) Media, necesidad de usar un lenguaje externo en ocasiones Objetos Etiquetas en un archivo XML Objetos Almacenamiento del metamodelo Archivo (.ecore) Archivo Repositorio (Base de datos) Facilidad de manejo del Media Baja Alta editor de DSL 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) Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 15

27 Capitulo 2. Antecedentes 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 Objetivos 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 16

28 Capitulo 2. Antecedentes 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 Justificación y beneficios 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 17

29 Capitulo 2. Antecedentes 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 18

30 Capitulo 2. Antecedentes 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 19

31 Capitulo 2. Antecedentes Figura 2.4. Metodología de solución 2.7. Alcances y límites del proyecto 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 20

32 Capitulo 2. Antecedentes 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 21

33 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) 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 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]. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 22

34 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. Figura 3.1. Ciclos de desarrollo de software. 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 23

35 Capitulo 3. Marco teórico 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] 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 24

36 Capitulo 3. Marco teórico 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 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] Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 25

37 Capitulo 3. Marco teórico 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] 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 26

38 Capitulo 3. Marco teórico Figura 3.2. Estructura de la metodología FODA Fuente: [SEI90] Tabla 3.1. Actividades de las fases del método FODA Fase Entrada Actividades Productos Análisis del Sistemas Operativos, estándares Análisis de contexto Modelo de contexto Contexto 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 Modelado de Dominio Análisis funcional Modelo funcional Tecnología del dominio, modelo de contexto, modelo de características, modelo de información, requerimientos 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) Fuente: [SEI90] 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]. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 27

39 Capitulo 3. Marco teórico 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] 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]. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 28

40 Capitulo 3. Marco teórico 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 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] 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. Y alternativo O obligatorio opcional Figura 3.3. Notación del diagrama de características Fuente: [DON 05] 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 29

41 Capitulo 3. Marco teórico 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. Característica obligatoria Automóvil Característica opcional Transmisión Caballos de fuerza Aire acondicionado Regla de composición: aire acondicionado Característica requiere más de 100 caballos de fuerza. alternativa Manual Ambos Automática Principal razón: manual es más eficiente en el combustible. Figura 3.4. Diagrama de características para la elección de un automóvil Fuente: [SEI 90] 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 30

42 Capitulo 3. Marco teórico 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 Part 2: Vocabulary Analysis Part 3: Architecture Analysis 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 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 31

43 Capitulo 3. Marco teórico 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. Figura 3.5. Ejemplo del editor con un grupo Fuente: [DARE 98] 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 32

44 Capitulo 3. Marco teórico Figura 3.6. Usuarios de DARE 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 33

45 Capitulo 3. Marco teórico Figura 3.7. Modelo de procesos en 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.8. Editor de Arquitecturas Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 34

46 Capitulo 3. Marco teórico 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 35

47 Capitulo 3. Marco teórico 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 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] 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: Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 36

48 Capitulo 3. Marco teórico 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 37

49 Capitulo 3. Marco teórico 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 [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 [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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 38

50 Capitulo 3. Marco teórico 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 [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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 39

51 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 40

52 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 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) 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 Windows Programas Lotus Application Domino Designer (o simplemente dar clic en el icono de LDD sobre el escritorio de Windows). Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 41

53 Capitulo 4. Análisis de Lotus Domino Designer Figura 4.1. Iniciando LDD desde el cliente Lotus Notes 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 42

54 Capitulo 4. Análisis de Lotus Domino Designer Figura 4.2. Personalizando la página de bienvenida de Lotus Domino Designer 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 43

55 Capitulo 4. Análisis de Lotus Domino Designer Figura 4.3. Panel de Lotus Domino Designer 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 44

56 Capitulo 4. Análisis de Lotus Domino Designer 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 45

57 Capitulo 4. Análisis de Lotus Domino Designer 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. Figura 4.7. Ficha de información del documento 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 Ficha de diseño Figura 4.8. Ficha de campo 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 46

58 Capitulo 4. Análisis de Lotus Domino Designer 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 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 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. Figura Ficha de ID Seleccionando el menú diseño (design) y después propiedades (properties). Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 47

59 Capitulo 4. Análisis de Lotus Domino Designer 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. Figura Ventana de propiedades de una Vista (View) 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 48

60 Capitulo 4. Análisis de Lotus Domino Designer 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ú Design Preview 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. Figura Barra de herramientas para la vista previa 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 Vista de objetos y vista de referencia Área de Script Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 49

61 Capitulo 4. Análisis de Lotus Domino Designer 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. Figura Área de Scripts 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 50

62 Capitulo 4. Análisis de Lotus Domino Designer Elemento Base de datos Frameset Frames Páginas (pages) Formularios (forms) Vistas (views) Carpetas (Folders) Agentes (agents) Outline Tabla 4.1. Elementos de diseño de Lotus Domino Designer Principales elementos Descripción 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. Es una colección de frames que permite estructurar o dividir los sitios Web o las bases de datos Notes. 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. 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). 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. 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. 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 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. 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 51

63 Capitulo 4. Análisis de Lotus Domino Designer Subformularios (subforms) Campos (fields) Columnas (columns) Acciones (actions) Librerías Script (Script Libraries) Servicios Web (Web Services) 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. 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. 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. 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. 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. 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. 1 Sitio del documento: 2 Sitio del documento: 3 Sitio del documento: 4 Sitio del documento: Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 52

64 Capitulo 4. Análisis de Lotus Domino Designer Imágenes (Images) Archivos (files) Applet Hojas de estilo (Style sheets) Conexiones de Datos (Data Connectios) Sinopsis (Synopsis) Navegador (Navigator) Recursos de la base de datos (Data base Resources) Elementos como recursos compartidos 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. 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. 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. 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. 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) 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. 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. 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 53

65 Capitulo 4. Análisis de Lotus Domino Designer Secciones (sections) Campos calculados (Computer text) Tablas (tables) Hotspot Barra de acción (Action bar) Entradas Outline (Outline entry) Button Otros elementos no encontrados en la barra de marcadores (bookmarks) 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. 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. 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. 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. 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. 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. Representa a un tipo de hotspot, el cual se utiliza para llevar a cabo una acción, formula, código LotusScript o JavaScript. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 54

66 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 55

67 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 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 56

68 Capitulo 5. Caracterización de Lotus Domino Designer 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 57

69 Capitulo 5. Caracterización de Lotus Domino Designer 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. FODA UML Lenguaje de Dominio Específico Análisis del contexto Modelado del dominio Definición de símbolos y figuras Perfil Perfil UML UML DSL Sintaxis abstracta Sintaxis concreta Figura 5.1. Fases del proceso para crear un DSL para Lotus Domino Designer 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] 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 58

70 Capitulo 5. Caracterización de Lotus Domino Designer Fases del Análisis de Contexto Conocimiento del Dominio Diagrama de Contexto Diagrama de Estructura Modelo de Contexto Figura 5.2. Fases del análisis del contexto 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 59

71 Capitulo 5. Caracterización de Lotus Domino Designer Servicio Almacenamiento de objetos Integración de directorio empresarial Seguridad Sincronización y distribución automática Mensajería Servidor Web Flujo de trabajo Agentes Tabla 5.1. Servicios ofrecidos por Lotus Domino Designer Descripción 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. 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. 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). 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. 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. 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. 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. 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 60

72 Capitulo 5. Caracterización de Lotus Domino Designer Modelo de objetos de Domino Desarrollo rápido de aplicaciones Generar aplicaciones multiplataforma Integración de datos PIM (Personal Information Management) Ambientes que permiten programar en diferentes lenguajes de programación Exportación e importación de datos Búsquedas Otros Servicios 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. 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. 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. 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. En LDD se puede programar en el lenguaje nativo de Domino, en Java, LotusScript, lenguaje de fórmula, lenguaje de comandos y JavaScript. 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. 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. 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 61

73 Capitulo 5. Caracterización de Lotus Domino Designer Cliente Lotus Notes Domino Designer Domino Administrator Clientes Móviles Acceso Web inotes inotes para Microsoft Outlook Otros clientes POP3/IMAP Tabla 5.2. Clientes para Domino Descripción 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. 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. 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. 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. 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. 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. 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). Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 62

74 Capitulo 5. Caracterización de Lotus Domino Designer Servidores de Domino Clientes Lotus Notes/Domino Lotus Notes Domino Designer Domino Messaging Domino Enterprise Domino Utility Clientes móviles inotes Web Access Lotus Notes/Domino Clientes POP/IMAP Domino Administrator inotes for Outlook Servicios ofrecidos por Lotus Notes/Domino Almacenamiento de objetos Seguridad Servidor Web Mensajería Exportar e importar datos Integración de directorio Flujo de trabajo Modelo de objetos de Domino Agentes Integración de PIM RAD Aplicaciones Multiplataforma Programar en diversos lenguajes Búsquedas Sincronización y distribución automática Figura 5.3. Arquitectura general de Lotus Notes Domino 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 63

75 Capitulo 5. Caracterización de Lotus Domino Designer 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 Diagrama de Estructura Figura 5.4. Diagrama de contexto, factores externos que impactan el desarrollo de aplicaciones en LDD 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 64

76 Capitulo 5. Caracterización de Lotus Domino Designer 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. Figura 5.5. Diagrama de estructura del dominio de Lotus Notes/Domino 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 65

77 Framesets Pages Forms Views Folders Agents WebServices Outlines SubForms Fields Columns Actions Script Libraries Images Files Applets Style Sheets Data connections Icon Using About Database Script Navigators Cantidad de elementos para seis aplicaciones Capitulo 5. Caracterización de Lotus Domino Designer 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. Incidencia de los elementos de diseño en las aplicaciones de LDD Elementos Gráfico 5.1. Incidencia de los elementos en las aplicaciones domino Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 66

78 Other Shared resources Shared code Capitulo 5. Caracterización de Lotus Domino Designer Elementos de diseño Tabla 5.3. Incidencia de los elementos en las aplicaciones de Lotus Domino Designer Aplicaciones Portal ServiceDesk Minutas Address Book Domino Web Access Discussion Notes & Web Total % Framesets % % % % % % % Pages % % % % % % % Forms % % % % % % % Views % % % % % % % Folders % % % % % % % Agents % % % % % % % WebServices % % % % % % % Outlines % % % % % % % SubForms % % % % % % % Fields % % % % % % % Columns % % % % % % % Actions % % % % % % % Script Libraries % % % % % % % Images % % % % % % % Files % % % % % % % Applets % % % % % % % Style Sheets % % % % % % % Data connections % % % % % % % Icon % % % % % % % Using % % % % % % % About % % % % % % % Database Script % % % % % % % Navigators % % % % % % % % % % % % % % Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 67

79 Capitulo 5. Caracterización de Lotus Domino Designer Limitando el alcance del dominio En la sección (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 (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. 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 Aplicaciones de Lotus Notes/Domino Tipo de aplicación PIM Workflow Document Management Groupware Portal Web Lotus Domino Designer Elementos de diseño forms pages Views fields Figura 5.6. Limitando el alcance para el análisis del dominio Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 68

80 Capitulo 5. Caracterización de Lotus Domino Designer 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. Fases del Modelado del Dominio Definición de elementos Modelado de características Encontrar y definir relaciones Encontrar y definir restricciones Crear metamodelo Figura 5.7. Fases del modelado de dominio de Lotus Domino Designer 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 69

81 Capitulo 5. Caracterización de Lotus Domino Designer 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. Principales elementos Tabla 5.4. Elementos utilizados en el desarrollo de aplicaciones Elementos de diseño de la barra de marcadores (bookmarks) de LDD Elementos de código Recursos compartidos Otros elementos compartido (shared (Shared Resources) code) Form Agent Image Navigator View Web Service Applet Page Outline Style Sheet Frameset Subform File Folder Data base Field 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) 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 70

82 Capitulo 5. Caracterización de Lotus Domino Designer 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 71

83 Capitulo 5. Caracterización de Lotus Domino Designer 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. Data base Elemento Form Form Pages Agent Frameset View Figura 5.8. Principales elementos de una base de datos Domino 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. Form Table Sections Button Action Bar View s Agents Folder Outlines Subform Style s Sheets Computer text Files Hotspots Navigators Fields Script Images Applets Libraries Figura 5.9. Elementos relacionados con un form 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 72

84 Capitulo 5. Caracterización de Lotus Domino Designer View Column Action Bar Figura Elementos relacionados con un view 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. Page Applets Files Hotspots Action Bar View s Agents Folder Outline s Sections Table Button Images Script Libraries Navigators Style Sheet Computer Text Figura Elementos con los que se relaciona el elemento page 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. Frameset Frame Frame Form Views Pages Folders Navigators Frameset Figura Elementos relacionados con los elementos frameset y frame Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 73

85 Capitulo 5. Caracterización de Lotus Domino Designer 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. Action Bar Actions Actions Agents Elemento Folder Figura Elementos relacionados con un action bar y un action 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. Folder Column Action Bar Elemento Tabla (table) Figura Elementos relacionados con un folder 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. Table Button Navigators Hotspots Folder Outlines Subform Style Fields Script Images Applets Table Sections s Sheets Libraries View Computer text Files s Figura Elementos relacionados con una table Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 74

86 Capitulo 5. Caracterización de Lotus Domino Designer 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. Section Button Navigators Hotspots Folder Outlines Subform Style Fields Script Images Applets Table Sections s Sheets Libraries View Computer text Files s Figura Elementos relacionados con un section 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. Outline Navigator Outline Entry Hostspot Figura Elementos relacionados con un outline y un navigator Relaciones entre elementos de Lotus Domino Designer El modelo de características definido en la sección anterior (sección ) 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 75

87 Capitulo 5. Caracterización de Lotus Domino Designer 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 Objeto contenedor Indicador de contención Figura Relación de contención, esquema general Objeto contenido 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 Objeto contenedor * Indicador de contención reflexiva Objeto contenedor Figura Relación de conteción reflexiva, esquema general Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 76

88 Capitulo 5. Caracterización de Lotus Domino Designer 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 Objeto contenedor Indicador de agregación Objeto contenido Figura Relación de agregación, esquema general 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 Objeto contenedor Indicador de composición Figura Relación de composición, esquema general Objeto contenido Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 77

89 Capitulo 5. Caracterización de Lotus Domino Designer 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 Definición Nomenclatura Valores UML relacionados Tabla 5.8. Definición de la propiedad multiplicidad 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. Low association-end, Upp association-end 1, 0 1, 0 *, 1 * 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 Definición Nomenclatura Valores UML relacionados Tabla 5.9. Definición de la propiedad propagación de borrado 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. DP association-end Restrictivo Cascada Cascada restrictiva 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 Definición Nomenclatura Valores UML relacionados Tabla Definición de la propiedad reflexividad 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. RF relationship Reflexiva No reflexiva Una característica de relaciones de agregación y composición: [ ] la instancia forma un grafo dirigido, no cíclico. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 78

90 Capitulo 5. Caracterización de Lotus Domino Designer 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 (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 Valores fijos para la relaciones Propiedad/Relación Contención Contención Agregación Composición reflexiva Multiplicidad * * * (1,1 *) Propagación de * * Cascada restrictiva Cascada borrado Reflexividad No reflexiva * No reflexiva No reflexiva 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 Principales elementos contenedores de LDD Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 79

91 Capitulo 5. Caracterización de Lotus Domino Designer 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. Figura Elementos contendores secundarios La figura 5.24 muestra a los elementos que no son contendores, éstos sólo pueden estar contenidos tanto en contenedores principales como secundarios. Figura Elementos no contendores 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 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, Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 80

92 Capitulo 5. Caracterización de Lotus Domino Designer 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 81

93 Capitulo 5. Caracterización de Lotus Domino Designer Figura Metamodelo de LDD Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 82

94 Capitulo 5. Caracterización de Lotus Domino Designer 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. Figura Posición en la estructura de Lotus Notes/Domino de los elementos de diseño 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 83

95 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 84

96 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 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. Figura 6.1. Diagrama de clases que trataba de representar la arquitectura de una aplicación Domino 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 85

97 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 86

98 Capitulo 6. Pruebas Figura 6.2. Diagrama ejemplificando la notación y simbología del DSL Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 87

99 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. Figura 6.3. Representación de las relaciones de UML más utilizadas en diagramas anteriores 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.4. Diseño de las entidades en modelos anteriores Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 88

100 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 89

101 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. DSL Comunicación Diseñador Desarrollador Figura 6.6. DSL actuando como puente de comunicación entre diseñador y desarrollador 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 90

102 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 91

103 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. Figura 6.8. Aplicaciones disponibles en el portal SIGCO 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 92

104 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. Figura Arquitectura de la base de datos Comunidades de práctica 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 Roles para los usuarios de la aplicación y funciones para ambos roles Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 93

105 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. Figura Diagrama correspondiente a la arquitectura de navegación de la base de datos Foros de Comités. 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 94

106 Capitulo 6. Pruebas funcionalidades que aparecen en la figura 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 Arquitectura general de coordinador de comités Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 95

107 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 Figura Pantallas correspondientes a la creación de un comité de práctica Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 96

108 Capitulo 6. Pruebas Los elementos estructurales para implementar la funcionalidad correspondiente a este caso de uso aparecen en la figura 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 Diagrama correspondiente al CU creación de una Copr Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 97

109 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 Figura Pantallas correspondientes a la eliminación de un comité de práctica Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 98

110 Capitulo 6. Pruebas Los elementos estructurales para implementar la funcionalidad correspondiente al caso de uso eliminar un Copr aparecen en la figura 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 Diagrama correspondiente al CU eliminación de un Copr Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 99

111 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 Figura Pantallas correspondientes a la creación, edición y eliminación de grupos de trabajo Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 100

112 Capitulo 6. Pruebas Los elementos estructurales para implementar la funcionalidad correspondiente a los casos de uso de la figura anterior aparecen en la figura 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 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 Diagrama correspondiente a los caso de uso crear, editar y eliminar grupos Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 101

113 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 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 Pantalla correspondiente a la configuración de comités de especialistas Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 102

114 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. Figura Diagrama correspondiente a la configuración de comités de especialistas La configuración de comités de especialistas contiene más tablas y campos que no aparecen en la figura 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 103

115 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 En ésta se puede crear, editar y eliminar una categoría. Figura Creación, edición y eliminación de una categoría de un comité Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 104

116 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 Un administrador utiliza el formulario ServiciosF para acceder al formulario CategoriasComitesAdminF mostrado en la parte superior de la figura 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 Diagrama estructural para crear, editar y eliminar una categoría Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 105

117 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 106

118 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 107

119 Capitulo 7. Conclusiones 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 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 108

120 Capitulo 7. Conclusiones 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 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 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 109

121 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 110

122 Anexo A. Perfil UML para Lotus Domino Designer 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 111

123 Anexo A. Perfil UML para Lotus Domino Designer 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. Figura A2. Diagrama representado con el perfil UML para el form mostrado en la figura a1 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 112

124 Anexo A. Perfil UML para Lotus Domino Designer 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 (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. Figura A3. Metamodelo de Lotus Domino Designer b. Definición del perfil Continuando con el método de Lidia Fuentes en el punto dos de la sección (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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 113

125 Anexo A. Perfil UML para 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 Nombre Meta-clase metamodelo del Estereotipo base en UML Descripción Data Base <<database>> Class Representa a la base de datos que contiene a todos los elementos para construir aplicaciones en LDD. Imagen asociada 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 114

126 Anexo A. Perfil UML para Lotus Domino Designer 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 115

127 Anexo A. Perfil UML para Lotus Domino Designer 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>> 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. Figura A4. Clasificación de los estereotipos de LDD Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 116

128 Anexo A. Perfil UML para Lotus Domino Designer 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 117

129 Anexo A. Perfil UML para Lotus Domino Designer A 5. Metamodelo de Lotus Domino Designer con notación UML Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 118

130 Anexo A. Perfil UML para Lotus Domino Designer 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 119

131 Anexo A. Perfil UML para Lotus Domino Designer 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 Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 120

132 Anexo A. Perfil UML para Lotus Domino Designer 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. Figura A8. Continuación de la extensión del metaelemento Class Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 121

133 Anexo A. Perfil UML para Lotus Domino Designer 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» correspondientes a propiedades de los estereotipos. Figura A9. Continuación de la extensión del metaelemento Class Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 122

134 Anexo A. Perfil UML para Lotus Domino Designer 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 «enumeration» correspondientes a propiedades de los estereotipos. Figura A10. Extendiendo al metaelemento Component Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 123

135 Anexo A. Perfil UML para Lotus Domino Designer 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 «enumeration» correspondientes a propiedades de los estereotipos. Figura A11. Continuación de la extensión del metaelemento Class Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 124

136 Anexo A. Perfil UML para Lotus Domino Designer 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» correspondientes a propiedades de los estereotipos. Figura A12. Continuación de la extensión del metaelemento Class Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 125

137 Anexo A. Perfil UML para Lotus Domino Designer 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. Figura A13. Continuación de la extensión del metaelemento Class Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 126

138 Anexo A. Perfil UML para Lotus Domino Designer La figura a14 muestra a los estereotipos contention y reflexivecontention extendiendo a la metaclase Aggregation. Figura A14. Extendiendo al metaelemento 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. Definición de un Lenguaje de Dominio Específico para un Entorno de Desarrollo Rápido de Aplicaciones 127

Programación orientada a

Programación orientada a Programación orientada a objetos con Java Pedro Corcuera Dpto. Matemática Aplicada y Ciencias de la Computación Universidad de Cantabria corcuerp@unican.es Objetivos Presentar los conceptos de la programación

Más detalles

"Módulo OOWS para StarUML" INTRODUCCIÓN

Módulo OOWS para StarUML INTRODUCCIÓN UNA HERRAMIENTA PARA DIAGRAMAS OOWS: "Módulo OOWS para StarUML" Richard Medina Z. Universidad de Concepción, Chile INTRODUCCIÓN Una herramienta CASE (Computer Aided Software Engineering,

Más detalles

GENERACIÓN DE APLICACIONES MEDIANTE LENGUAJES ESPECIFICOS DE DOMINIO

GENERACIÓN DE APLICACIONES MEDIANTE LENGUAJES ESPECIFICOS DE DOMINIO WICC 2012 626 GENERACIÓN DE APLICACIONES MEDIANTE LENGUAJES ESPECIFICOS DE DOMINIO 1. A.Cortez, C.Naveda 1. Consejo de Investigaciones (CIUDA) UDA. 2. Instituto de Investigaciones Facultad de Ciencias

Más detalles

Administración de Variabilidad en una línea de producto basada en modelos

Administración de Variabilidad en una línea de producto basada en modelos Administración de Variabilidad en una línea de producto basada en modelos Kelly Garcés Carlos Parra Hugo Arboleda Andres Yie Rubby Casallas Universidad de los Andes, Bogotá k-garces @uniandes.edu.co Universidad

Más detalles

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado

Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado Ingeniería de Software con UML Unified Modeling Language Lenguaje Unificado de Modelado 1. Introducción Unified Modeling Languaje Fuente: Booch- Jacobson-Rumbauch y diversos sitios Internet, entre otros:

Más detalles

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio

SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio SET (Software Engineering Tutor). Una herramienta para la construcción guiada de modelos de dominio Arturo Cepeda Pérez, Sergio Bravo Martín, Francisco José García Peñalvo Universidad de Salamanca, Facultad

Más detalles

BASES DE DATOS. Ivon Tarazona Oriana Gomez

BASES DE DATOS. Ivon Tarazona Oriana Gomez BASES DE DATOS Ivon Tarazona Oriana Gomez Introducción Introducción Ventajas e (Unified Modeling Language) Es un lenguaje usado para especificar, visualizar y documentar los diferentes aspectos relativos

Más detalles

Iván Ruiz Rube Departamento de Ingeniería Informática Escuela Superior de Ingeniería Universidad de Cádiz

Iván Ruiz Rube Departamento de Ingeniería Informática Escuela Superior de Ingeniería Universidad de Cádiz Procesadores de Lenguajes 2 Lenguajes Específicos de Dominio Curso 2013-2014 Iván Ruiz Rube Departamento de Ingeniería Informática Escuela Superior de Ingeniería Universidad de Cádiz 17/10/13 PL2 - Lenguajes

Más detalles

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio

Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio Cómo usar MDE para obtener Modelos de Simulación a partir de Modelos de Negocio M. Teresa García 1, Mercedes Ruiz 1 y Cristina Vicente-Chicote 2 1 Departamento de Lenguajes y Sistemas Informáticos Universidad

Más detalles

Diseñando Transformaciones de Modelos CIM / PIM: desde un enfoque de negocio hacia un enfoque de sistema

Diseñando Transformaciones de Modelos CIM / PIM: desde un enfoque de negocio hacia un enfoque de sistema Diseñando Transformaciones de Modelos CIM / PIM: desde un enfoque de negocio hacia un enfoque de sistema Cecilia Ariste 1, Julieta Ponisio 1, Leopoldo Nahuel 1,2, Roxana Giandini 1,2 1 Laboratorio de Innovaciones

Más detalles

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura

Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Metodología de Ingeniería del Software para el desarrollo y mantenimiento de sistemas de información del Gobierno de Extremadura Página 1 de 23 Índice del Documento 1.- Introducción... Página 4 2.- Propuesta

Más detalles

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado

Diseño lógico de sistemas aplicando el lenguaje de modelado unificado Diseño lógico de sistemas aplicando el lenguaje de modelado unificado No. De Registro CGPI: 20061221. Director del proyecto: Roberto De Luna Caballero. Profesores participantes: M. en C Fabiola Ocampo

Más detalles

Vicente Pelechano. Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia

Vicente Pelechano. Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Vicente Pelechano Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Contenido Qué es el Metamodelado?. Sintaxis Abstracta Metaniveles vs. Niveles de Abstracción MOF

Más detalles

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA

CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA CICLO SUPERIOR DESARROLLO DE APLICACIONES MULTIPLATAFORMA PROGRAMACIÓN DIDACTICA ANUAL Parte específica del módulo: 0485. Programación Departamento de Familia Profesional de Informática Curso: 2014-15

Más detalles

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática

La Necesidad de Modelar. Diseño de Software Avanzado Departamento de Informática La Necesidad de Modelar Analogía Arquitectónica Tiene sentido poner ladrillos sin hacer antes los planos? El modelo, los planos, ayuda a afrontar la complejidad del proyecto. Cuál es el lenguaje adecuado

Más detalles

Componente para la transformación a estándares de modelos de procesos de negocio. Modelos de la BPMS Oracle

Componente para la transformación a estándares de modelos de procesos de negocio. Modelos de la BPMS Oracle Instituto Superior Politécnico José Antonio Echeverría Facultad de Ingeniería Informática Componente para la transformación a estándares de modelos de procesos de negocio. Modelos de la BPMS Oracle Informe

Más detalles

CAPÍTULO 3 VISUAL BASIC

CAPÍTULO 3 VISUAL BASIC CAPÍTULO 3 VISUAL BASIC 3.1 Visual Basic Microsoft Visual Basic es la actual y mejor representación del viejo lenguaje BASIC, le proporciona un sistema completo para el desarrollo de aplicaciones para

Más detalles

Generación de código para Hibernate desde modelos UML

Generación de código para Hibernate desde modelos UML Generación de código para Hibernate desde modelos UML Alejandro Nogueiro Mariscal Ingeniería Técnica en Informática de Sistemas, Universidad de Cádiz 24 de Septiembre 2012 1 / 35 Índice 1 Motivación y

Más detalles

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es

Tema 5: El Lenguaje Unificado de Modelado. Departamento de Lenguajes y Sistemas Informáticos II www.kybele.urjc.es Tema 5: El Lenguaje Unificado de Modelado Departamento de Lenguajes y Sistemas Informáticos II Contenidos Introducción Diagramas de UML Modelado de la parte estática Modelado de la parte dinámica Las 4+1

Más detalles

Perfil UML para el desarrollo de aplicaciones WAP

Perfil UML para el desarrollo de aplicaciones WAP Perfil UML para el desarrollo de aplicaciones WAP Ricardo Soto D., Mauricio Camara J. Escuela de Ingeniería Informática, Pontificia Universidad Católica de Valparaíso, Chile E-mail: ricardo.soto@ucv.cl,

Más detalles

Programación en Capas.

Programación en Capas. Programación en Capas. Ricardo J. Vargas Del Valle Universidad de Costa Rica, Ciencias de Computación e Informática, San José, Costa Rica, 506 ricvargas@gmail.com Juan P. Maltés Granados Universidad de

Más detalles

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software

UML El Lenguaje de Modelado Unificado. Maestría en Ingeniería de Software UML El Lenguaje de Modelado Unificado Maestría en Ingeniería de Software Agenda Model Driven Architecture (MDA) Unified Model Language (UML) Object Constraint Language (OCL) Patrones Conclusiones Contenido

Más detalles

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP

Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Transformación de Procesos de Desarrollo de Software Tipo SPEM a Procesos Workflow. Una Propuesta de Caso de Estudio: SmallRUP Fabio A. Zorzan 1, Daniel Riesco 2, Nora Szasz 3 CONTEXTO La línea de investigación

Más detalles

INTERPRETACIÓN DINÁMICA DE MÚLTIPLES LENGUAJES DE DOMINIO ESPECÍFICO

INTERPRETACIÓN DINÁMICA DE MÚLTIPLES LENGUAJES DE DOMINIO ESPECÍFICO INTERPRETACIÓN DINÁMICA DE MÚLTIPLES LENGUAJES DE DOMINIO ESPECÍFICO Héctor A. FLOREZ FERNANDEZ Facultad Tecnológica, Universidad Distrital Francisco Jose de Caldas haflorezf@udistrital.edu.co Bogotá,

Más detalles

http://www.cem.itesm.mx/extension/ms

http://www.cem.itesm.mx/extension/ms Diplomado Programación orientada a objetos con Java y UML Las empresas necesitan contar con sistemas de información modernos, ágiles y de calidad para alcanzar sus objetivos y ser cada vez más competitivos

Más detalles

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT

Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Transformación de Procesos BPMN a su Implementación en BPEL utilizando QVT Fabio A. Zorzan 1, Daniel Riesco 2 CONTEXTO La línea de investigación presentada en este trabajo se desarrolla en el marco del

Más detalles

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow

Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Mejora en la Administración de Procesos de Desarrollo de Software Tipo SPEM Automatizados Bajo Workflow Fabio A. Zorzan 1 y Daniel Riesco 2 Resumen Esta línea de investigación pretende aportar a la mejora

Más detalles

TEMA 1.-Programación orientada a objetos (POO) Objetivo

TEMA 1.-Programación orientada a objetos (POO) Objetivo CURSO DE UML Dotar al alumno de los fundamentos de la programación orientada a objetos (POO, a partir de ahora), definir las características básicas del lenguaje de modelado unificado (Unified Modeling

Más detalles

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM Fabio A. Zorzan y Daniel Riesco Resumen Esta línea de investigación propone una alternativa para lograr la automatización de la gestión

Más detalles

ESCUELA POLITÉCNICA NACIONAL Ingeniería en Sistemas APLICACIONES EN AMBIENTES LIBRES

ESCUELA POLITÉCNICA NACIONAL Ingeniería en Sistemas APLICACIONES EN AMBIENTES LIBRES Integrantes: GRUPO: 4 - Marcela Balseca Fecha: 04/05/2012 - Patricia Gálvez - Lilian Guamán S. - Diego Hallo ALTERNATIVAS DE SOFTWARE LIBRE PARA PROYECTOS DE DESARROLLO La cantidad de alternativas libres

Más detalles

Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C.

Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C. UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Nombre del Proyecto: Página web GAQSA S.A de C.V. (Módulo de laboratorios) Nombre de la Empresa: Ganaderos Asociados de Querétaro S.A de C.V (GAQSA) Memoria que como

Más detalles

COLEGIO DE BACHILLERES ELABORADO POR: ING. IVETT ZARZA HIDALGO Y LIC. CLAUDIA HERNÀNDEZ ALPÍZAR PROFA. DE INFORMATICA Y DE CECAT-INFORMATICA

COLEGIO DE BACHILLERES ELABORADO POR: ING. IVETT ZARZA HIDALGO Y LIC. CLAUDIA HERNÀNDEZ ALPÍZAR PROFA. DE INFORMATICA Y DE CECAT-INFORMATICA Visual Basic.NET es la última versión del sistema de desarrollo Visual Basic. Antes de empezar a crear aplicaciones en Visual Basic.NET, le será útil conocer y entender algunos conceptos básicos de.net.

Más detalles

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes

Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Adaptación y Configuración de Procesos de Software Tailoring and Configuration of Software Processes Rodolfo Villarroel Acevedo 1* 1 Pontificia Universidad Católica de Valparaíso. Avenida Brasil 2241,

Más detalles

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team

Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Modelado de relaciones existentes en un equipo de proyecto de software Modeling relationships in a software project team Rafael Rodríguez-Puente 1, Eliana B. Ril-Valentin 2 1 Departamento de Técnicas de

Más detalles

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio).

1 GLOSARIO. Actor: Es un consumidor (usa) del servicio (persona, sistema o servicio). 1 GLOSARIO A continuación se definen, en orden alfabético, los conceptos básicos que se han abordado a lo largo del desarrollo de la metodología para la gestión de requisitos bajo la Arquitectura Orientada

Más detalles

Programador Java Página 1 de 7 Escuela de Sistemas y Tecnologías BIOS

Programador Java Página 1 de 7 Escuela de Sistemas y Tecnologías BIOS Programador Java Página 1 de 7 Escuela de Sistemas y Tecnologías BIOS PROGRAMADOR JAVA INTRODUCCIÓN El programador Java es un especialista en construir soluciones empresariales utilizando tecnologías Java

Más detalles

Integración de UML y Lenguajes de Modelado Específicos de Dominio Mediante la Generación Automática de Perfiles UML

Integración de UML y Lenguajes de Modelado Específicos de Dominio Mediante la Generación Automática de Perfiles UML Integración de UML y Lenguajes de Modelado Específicos de Dominio Mediante la Generación Automática de Perfiles UML Tesis de Máster en Ingeniería del Software, Métodos Formales y Sistemas de Información

Más detalles

IBM Rational Software Architect/Modeler

IBM Rational Software Architect/Modeler IBM Software Group IBM Rational Software Architect/Modeler Arquitectura y Diseño de Aplicaciones UML 2.0 Ana López-Mancisidor - IBM Software Development Tools Ana.lopez@es.ibm.com 2004 IBM Corporation

Más detalles

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL

DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Página 1 de 21 CUALIFICACIÓN DESARROLLO DE APLICACIONES CON TECNOLOGÍAS WEB PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC154_3 Versión 5 Situación RD 1087/2005 Actualización

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software MSDN Ingeniería de Software...1 Ingeniería del Software_/_ Ingeniería y Programación...1 Análisis de Requerimientos...2 Especificación...3 Diseño...4 Desarrollo en Equipo...5 Mantenimiento...6

Más detalles

Evaluación de entornos integrados de desarrollo 1. Funciones de un entorno de desarrollo

Evaluación de entornos integrados de desarrollo 1. Funciones de un entorno de desarrollo Tema 3 Evaluación de entornos integrados de desarrollo 1. Funciones de un entorno de desarrollo Un entorno de desarrollo integrado (en inglés integrated development environment o IDE) es un programa informático

Más detalles

Capítulo III. Análisis y diseño.

Capítulo III. Análisis y diseño. Capítulo III. Análisis y diseño. 3.1 Análisis. El análisis es el intermediario entre los requisitos del sistema y el diseño, esta sección definiremos el análisis con una serie de modelos técnicos del sistema,

Más detalles

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el

desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el Capitulo II. Análisis de herramientas y tecnologías de desarrollo. Dentro del desarrollo de la tesis el proceso de modelado del sistema fue hecho con el lenguaje de Modelo de Objetos llamado UML (Unified

Más detalles

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola

BPMN vs UML. Los Requerimientos y el Modelo del Negocio. Autor: Norberto Figuerola BPMN vs UML Autor: Norberto Figuerola Los Requerimientos y el Modelo del Negocio Normalmente, siempre que iniciamos un esfuerzo de desarrollo de software éste tiene como objetivo automatizar procesos del

Más detalles

Bienvenidos a la presentación: Introducción a conceptos básicos de programación.

Bienvenidos a la presentación: Introducción a conceptos básicos de programación. Bienvenidos a la presentación: Introducción a conceptos básicos de programación. 1 Los programas de computadora son una serie de instrucciones que le dicen a una computadora qué hacer exactamente. Los

Más detalles

SOFTWARE PROJECT MANAGEMENT PLAN

SOFTWARE PROJECT MANAGEMENT PLAN SOFTWARE PROJECT MANAGEMENT PLAN HERRAMIENTA PARA LA ADMINISTRACIÓN DE REQUERIMIENTOS DE LOS PROYECTOS DE LAS ASIGNATURAS DE INGENIERÍA Y ARQUITECTURA DE SOFTWARE DE LA PONTIFICIA UNIVERSIDAD JAVERIANA.

Más detalles

Entidad Formadora: Plan Local De Formación Convocatoria 2010

Entidad Formadora: Plan Local De Formación Convocatoria 2010 Entidad Formadora: Enterprise Architect Comenzando Puede iniciar Enterprise Architect desde el ícono que se creó en su escritorio de Windows durante la instalación, o alternativamente: 1. Abrir el menú

Más detalles

Introducción a WebMathematica

Introducción a WebMathematica Introducción a WebMathematica WebMathematica es una nueva tecnología que permite la generación de contenido web dinámico con Mathematica. Se integra en Mathematica a través de un servidor web. WebMathematica

Más detalles

GLOSARIO DE TÉRMINOS

GLOSARIO DE TÉRMINOS MINISTERIO DE EDUCACIÓN, CULTURA Y DEPORTE SECRETARÍA DE ESTADO DE EDUCACIÓN, FORMACIÓN PROFESIONAL Y UNIVERSIDADES DIRECCIÓN GENERAL DE FORMACIÓN PROFESIONAL INSTITUTO NACIONAL DE LAS CUALIFICACIONES

Más detalles

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta

Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta Gerencia de Procesos de Negocio (Business Process Management, BPM). Lic. Patricia Palacios Zuleta (Business Process Management, BPM). La Gerencia de los Procesos del Negocio: Se define como: "integración

Más detalles

Christian Bolívar Moya Calderón

Christian Bolívar Moya Calderón UNIVERSIDAD SAN FRANCISCO DE QUITO Software Orientado a Sistemas de Control HMI/Scada usando Recursos Libres y de Código Abierto, desarrollado sobre Plataforma Linux Christian Bolívar Moya Calderón Tesis

Más detalles

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web

Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web Metodología y Framework para el Desarrollo de Aplicaciones Científicas con Computación de Alto Rendimiento a través de Servicios Web J.Corral-García, D.Cortés-Polo, C.Gómez-Martín, J.L.González-Sánchez

Más detalles

INGENIAS: Desarrollo dirigido por modelos de SMA

INGENIAS: Desarrollo dirigido por modelos de SMA INGENIAS: Desarrollo dirigido por modelos de SMA Juan Pavón Mestras jpavon@pdi.ucm.es Dep. de Ingeniería del Software e Inteligencia Artificial Universidad Complutense Madrid http://grasia.fdi.ucm.es Objetivo

Más detalles

Arquitectura de Aplicaciones

Arquitectura de Aplicaciones 1 Capítulo 13: Arquitectura de aplicaciones. - Sommerville Contenidos del capítulo 13.1 Sistemas de procesamiento de datos 13.2 Sistemas de procesamiento de transacciones 13.3 Sistemas de procesamiento

Más detalles

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos

Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Trabajo de Grado Análisis comparativo de Lenguajes Notacionales para Modelado de Procesos Autora: Vasquez Pilar María Directora: Dra. Giandini Roxana Codirectora: Mg. Bazán Patricia Agenda Introducción.

Más detalles

Universidad Autónoma de Madrid

Universidad Autónoma de Madrid Universidad Autónoma de Madrid Escuela Politécnica Superior Máster I 2 TIC Trabajo de Fin de Máster Descripción de las actividades de una propuesta de Metodología de Desarrollo de Software Dirigida por

Más detalles

Integrando UML y DSL en el enfoque MDA

Integrando UML y DSL en el enfoque MDA Integrando UML y DSL en el enfoque MDA Daniel Giulianelli 1, Claudia Pons 2, Rocío Rodríguez 1 Pablo Vera 1, Víctor Fernandez 1 1 Universidad Nacional de La Matanza Departamento de Ingeniería e Investigaciones

Más detalles

Capitulo III. Diseño del Sistema.

Capitulo III. Diseño del Sistema. Capitulo III. Diseño del Sistema. Para el desarrollo del sistema en la presente tesis se utilizo el paradigma orientado a objetos utilizando el lenguaje Java en su versión 1.2. Por medio de este lenguaje

Más detalles

CAPÍTULO 5. DESARROLLO Y PRUEBAS

CAPÍTULO 5. DESARROLLO Y PRUEBAS CAPÍTULO 5. DESARROLLO Y PRUEBAS 5.1 Introducción a las Tecnologías 5.1.1 Herramientas 5.1.1.1 SQL Server Es un sistema que sirve para la gestión de base de datos basado en un modelo relacional. Así mismo

Más detalles

Herramientas de Software que posibilitan el BPM

Herramientas de Software que posibilitan el BPM Qué es BPM? BPM (Business Process Management) no es solamente una tecnología, sino en términos generales, una disciplina gerencial que trata a los procesos como bienes tangibles que contribuyen al desempeño

Más detalles

Una Arquitectura para una Herramienta de Patrones de Diseño

Una Arquitectura para una Herramienta de Patrones de Diseño Una Arquitectura para una Herramienta de Patrones de Diseño José Sáez Martínez 1, Jesús García Molina, Pedro J. Jiménez García Departamento de Informática, Lenguajes y Sistemas. Campus de Espinardo C.P.

Más detalles

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto.

En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICES En el siguiente apartado se detallan ciertos conceptos que ayudan a comprender en mayor medida el Proyecto. APÉNDICE 1. Herramientas Las herramientas que se usaron en el análisis, desarrollo

Más detalles

Análisis del Sistema de Información

Análisis del Sistema de Información Análisis del Sistema de Información ÍNDICE DESCRIPCIÓN Y OBJETIVOS... 2 ACTIVIDAD ASI 1: DEFINICIÓN DEL SISTEMA... 6 Tarea ASI 1.1: Determinación del Alcance del Sistema... 6 Tarea ASI 1.2: Identificación

Más detalles

Migración de datos automática a partir de la información de los esquemas conceptuales 1

Migración de datos automática a partir de la información de los esquemas conceptuales 1 Migración de datos automática a partir de la información de los esquemas conceptuales 1 J.Pérez 1, J.A.Carsí 1, I.Ramos 1, V.Anaya 1, J.Silva 1, Departamento de Sistemas Informáticos y Computación Universidad

Más detalles

Hacia la Integración de Técnicas de Pruebas en Metodologías Dirigidas por Modelos para SOA

Hacia la Integración de Técnicas de Pruebas en Metodologías Dirigidas por Modelos para SOA Hacia la Integración de Técnicas de Pruebas en Metodologías Dirigidas por Modelos para SOA Antonio García Domínguez Inmaculada Medina Bulo Mariano Marcos Bárcena Universidad de Cádiz Escuela Superior de

Más detalles

Ingeniería de Software

Ingeniería de Software Ingeniería de Software Agustín J. González ElO329: Diseño y Programación Orientados a Objeto Adaptado de: http://www.dsic.upv.es/~uml http://inst.eecs.berkeley.edu/~cs169/ entre otras fuentes. Definiciones

Más detalles

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1

IWG-101: Introducción a la Ingeniería. Departamento de Informática, UTFSM 1 IWG-101: Introducción a la Ingeniería Departamento de Informática, UTFSM 1 Introducción a UML Historia Potencialidades Diagramas soportados UML en el proceso de desarrollo de SW. Introducción a UML Necesidad

Más detalles

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un

(Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un (Integrated Development Environment) Herramienta de soporte para el desarrollo de sotfware: Editor (escribir y editar programas); un compilador/intérprete y un depurador (localización de errores lógicos).

Más detalles

Ingeniería inversa de GUIs

Ingeniería inversa de GUIs Ingeniería inversa de GUIs Existen numerosos sistemas en funcionamiento que fueron desarrollados en los años 90 utilizando entornos RAD (Rapid Application Development), tales como Delphi, Visual Basic

Más detalles

MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO

MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS DE DOMINIO XV Jornadas de Ingeniería del Software y Bases de Datos JISBD 2006 José Riquelme - Pere Botella (Eds) CIMNE, Barcelona, 2006 MCGEN: UN ENTORNO PARA LA GENERACIÓN AUTOMÁTICA DE COMPILADORES DE MODELOS ESPECÍFICOS

Más detalles

TECNICO PREVIO EVALUACION DE SOFTWARE ADQUISICION DE LICENCIA DE SOFTWARE PARA EL DESARROLLO DE SISTEMAS PARA EL MINISTERIO DE DEFENSA

TECNICO PREVIO EVALUACION DE SOFTWARE ADQUISICION DE LICENCIA DE SOFTWARE PARA EL DESARROLLO DE SISTEMAS PARA EL MINISTERIO DE DEFENSA INFORME TECNICO PREVIO EVALUACION DE SOFTWARE Nº 00 /20-/SG/B/01 22 de Marzo 20 INFORME TECNICO PREVIO EVALUACION DE SOFTWARE ADQUISICION DE LICENCIA DE SOFTWARE PARA EL DESARROLLO DE SISTEMAS PARA EL

Más detalles

Índice de contenido. Transformaciones entre modelos de Bases de Datos temporales en el contexto MDA

Índice de contenido. Transformaciones entre modelos de Bases de Datos temporales en el contexto MDA Índice de contenido Agradecimientos...5 Introducción...6 Capítulo 1...8 1. Conceptos generales...8 1.1 Desarrollo dirigido por modelos...8 1.1.1 Model Driven Development(MDD)...9 1.1.2 El Object Management

Más detalles

Boyeros, La Habana, Cuba, lcabrerag@uci.cu

Boyeros, La Habana, Cuba, lcabrerag@uci.cu EXTENSIÓN DE VISUAL PARADIGM FOR UML PARA EL DESARROLLO DIRIGIDO POR MODELOS DE APLICACIONES DE GESTIÓN DE INFORMACIÓN Visual Paradigm for UML extension for Model-Driven Development of information management

Más detalles

Capítulo 1 Introducción

Capítulo 1 Introducción Capítulo 1 Introducción Dentro de los muchos campos que abarca la universidad para la investigación científica, se encuentra el de los Sistemas de Información Geográfica (SIG). Para ello, cuenta con el

Más detalles

HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI

HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI HERRAMIENTA WEB PARA LA ELABORACIÓN DE TEST BAJO LA ESPECIFICACIÓN IMS-QTI Muñoz-Bouchard J.P., y Álvarez-González L.A. jp.knap@gmail.com@gmail.com, lalvarez@inf.uach.cl Grupo de Investigación en Tecnologías

Más detalles

INTRODUCCIÓN AL WEB. Pag. 1 de 10

INTRODUCCIÓN AL WEB. Pag. 1 de 10 INTRODUCCIÓN AL WEB La World Wide Web o simplemente WWW o Web es uno de los métodos más importantes de comunicación que existe en Internet. Consiste en un sistema de información basado en Hipertexto (texto

Más detalles

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software

Técnica para reusar artefactos de análisis y diseño en el modelamiento de software Revista de Investigación ULASALLE, Rev Inv ULASALLE, Número 1, 2012 (67-78) Universidad La Salle Arequipa, Perú Técnica para reusar artefactos de análisis y diseño en el modelamiento de software 1 Percy

Más detalles

APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES

APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES APLICATIVO WEB PARA LA ADMINISTRACIÓN DE LABORATORIOS Y SEGUIMIENTO DOCENTE EN UNISARC JUAN DAVID LÓPEZ MORALES CORPORACIÓN UNIVERSITARIA SANTA ROSA DE CABAL CIENCIAS Y TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN

Más detalles

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020)

CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) CARTA DESCRIPTIVA (FORMATO MODELO EDUCATIVO UACJ VISIÓN 2020) I. Identificadores de la asignatura Instituto: IIT Modalidad: Presencial Departamento: Materia: Eléctrica y Computación Programación II Créditos:

Más detalles

Enterprise Analyst: Taller de Bautizo

Enterprise Analyst: Taller de Bautizo Enterprise Analyst: Taller de Bautizo Metas Entender la Necesidad de Ejecutar los Modelos Desarrollar un caso usando UML tradicional Identificar los problemas de UML Conocer la Herramienta Enterprise Analyst

Más detalles

Programación Visual con. Gambas

Programación Visual con. Gambas Programación Visual con Gambas Juan Matías Olmos 2010 1 CAPITULO I Programación y Lenguajes de Programación Un programa informático es un conjunto de instrucciones que una vez ejecutadas realizarán una

Más detalles

Sistema de Control Domótico

Sistema de Control Domótico UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO EN ELECTRÓNICA Y AUTOMATICA PROYECTO FIN DE CARRERA Sistema de Control Domótico a través del bus USB Directores:

Más detalles

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software

Fundamentos de Ingeniería del Software. Capítulo 11. Reutilización del software Fundamentos de Ingeniería del Software Capítulo 11. Reutilización del software Reutilización del software. Estructura 1. Reutilización del software 2. Beneficios de la reutilización 3. Dificultades para

Más detalles

Capítulo I. Marco Teórico

Capítulo I. Marco Teórico 1 Capítulo I. Marco Teórico 1. Justificación Hoy en día existe una gran diversidad de aplicaciones que corren sobre la World Wide Web (WWW o Web), y cada una orientada a un fin en particular, el cuál depende

Más detalles

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento

OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen Keywords Historia del Surgimiento OMG UML 2.0 Marcando un hito en el desarrollo de software Resumen A través de este artículo se ofrece un panorama amplio y de alto nivel sobre la especificación y los diferentes diagramas del Lenguaje

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.1 UML: Introducción PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Técnica de modelado de objetos (I) El modelado orientado a objetos es una técnica de especificación semiformal para

Más detalles

Introducción a Javato

Introducción a Javato Introducción a Javato Fº. Javier Pereñiguez Steria Iberica 20/02/2008 Índice Introducción Arquitectura Ejemplo arquitectura Plataforma Desarrollo Ejemplo de entorno de desarrollo Vías futuras Casos de

Más detalles

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de

GLOSARIO. Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de GLOSARIO Análisis Bottom-Up: Técnica utilizada en tareas de ingeniería inversa la cual parte de una descripción de bajo nivel (código fuente) para generar descripciones con un mayor grado de abstracción.

Más detalles

GESTOR DE RECURSOS HUMANOS TELEFONOS DE MÉXICO.

GESTOR DE RECURSOS HUMANOS TELEFONOS DE MÉXICO. UNIVERSIDAD TECNOLÓGICA DE QUERÉTARO Voluntad. Conocimiento. Servicio. GESTOR DE RECURSOS HUMANOS TELEFONOS DE MÉXICO. Reporte de Estadía para obtener el Título de Técnico Superior Universitario en Tecnologías

Más detalles

Cuándo estoy listo para pasar a producción?

Cuándo estoy listo para pasar a producción? IBM Software Expo 2006. Madrid 23 de Mayo Cuándo estoy listo para pasar a producción? antonio.alonso @ es.ibm.com IBM Software 2005 IBM Corporation Agenda IBM Software Expo 2006. Madrid, 23 de mayo La

Más detalles

Anexo 4 Documento de Arquitectura

Anexo 4 Documento de Arquitectura Anexo 4 Documento de Arquitectura 1. Introducción El anexo se describe el propósito y alcance referentes al proyecto correspondiente al documento de arquitectura. 2. Propósito El propósito del anexo de

Más detalles

UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS

UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS UNA EXPERIENCIA PRÁCTICA DE INTEGRACIÓN DE SISTEMAS HETEROGÉNEOS DIRIGIDA POR MODELOS Gerente de Informática de Diputación IZFE, S.A. (Diputación Foral de Gipuzkoa) Analista IZFE, S.A. (Diputación Foral

Más detalles

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización

CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL. Nivel 3. Versión 5 Situación RD 1201/2007 Actualización Página 1 de 16 CUALIFICACIÓN SISTEMAS DE GESTIÓN DE INFORMACIÓN PROFESIONAL Familia Profesional Informática y Comunicaciones Nivel 3 Código IFC304_3 Versión 5 Situación RD 1201/2007 Actualización Competencia

Más detalles

El Proceso Unificado de Desarrollo de Software

El Proceso Unificado de Desarrollo de Software El Proceso de Desarrollo de Software Ciclos de vida Métodos de desarrollo de software El Proceso Unificado de Desarrollo de Software 1 Fases principales del desarrollo de software Captura de requisitos:

Más detalles

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos

UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos 2.1. Principios básicos del Modelado de Objetos UNIDAD 2: Abstracción del Mundo real Al Paradigma Orientado a Objetos Hoy en día muchos de los procesos que intervienen en un negocio o empresa y que resuelven

Más detalles

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga

Programación Orientada a Objetos Profr. Pedro Pablo Mayorga Actividad 2 Unidad 1 Ciclo de vida del software y Diseño Orientado a Objetos Ciclo de Vida del Software Un modelo de ciclo de vida define el estado de las fases a través de las cuales se mueve un proyecto

Más detalles

Herramienta para el modelado de flujos de tareas y traducción al álgebra de tareas

Herramienta para el modelado de flujos de tareas y traducción al álgebra de tareas Herramienta para el modelado de flujos de tareas y traducción al álgebra de tareas José Angel Quintanar Morales Laboratorio de Investigación y Desarrollo de Ingeniería de Software Universidad Tecnológica

Más detalles

Collaborative Lifecycle Management

Collaborative Lifecycle Management Collaborative Lifecycle Management IBM Rational Software Portafolio.. Documentación Técnica... COLLABORATIVE LIFECYCLE MANAGEMENT La solución de IBM Rational para la Gestión del Ciclo de Vida Colaborativo

Más detalles

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI

DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI DESARROLLO DE COMPONENTES PARA LA INTEGRACIÓN DEL PORTAL CORPORATIVO DEL CITI CON LA BPMS BIZAGI Informe de Práctica Profesional de 4to Año, Ingeniería Informática Autor: Manuel Alejandro Aguilar Díaz

Más detalles

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc).

plataforma específica de desarrollo, limitaciones del recurso físico disponible, limitaciones del sistema a actualizar, etc). REVISIÓN CONCEPTOS, METODOLOGÍAS Y HERRAMIENTAS SOPORTE EN INGENIERÍA MARLON MÚJICA Estudiante de Ingeniería de Sistemas Universidad Industrial de Santander mujica@cidlisuis.org COLOMBIA EDWIN LOGREIRA

Más detalles