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

Save this PDF as:
 WORD  PNG  TXT  JPG

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

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

Transcripción

1 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á Universidad de los Andes, Bogotá Universidad de los Andes, Bogotá Universidad de los Andes, Bogotá Universidad de los Andes, Bogotá RESUMEN La administración de variabilidad en una línea de producto tiene dos retos fundamentales: (1) la expresión de las características comunes y variables de la línea, y (2) la construcción de aplicaciones que incluyan las características comunes, y un subconjunto de las características variables. En este artículo presentamos una propuesta para administrar la variabilidad durante el proceso de construcción de SPLs usando un enfoque de construcción de líneas de producto basado en modelos (MD- SPL). Para esto separamos conceptos relacionados con SPLs en diferentes dominios y construimos como activos de la línea modelos de rasgos, metamodelos y tres tipos de reglas de transformación para transformar modelos de un dominio origen a diferentes (variables) modelos en un dominio destino. Las reglas nos permiten generar incrementalmente las aplicaciones de acuerdo con una selección de rasgos realizada para cada dominio destino. Así, logramos ampliar el alcance de las SPLs, separar los dominios de manera que se disminuya la complejidad de crear aplicaciones con características variables, y generar aplicaciones automáticamente usando reglas de transformación. Para ilustrar la solución construimos una MD-SPL donde los productos corresponden a ejercicios pedagógicos para la enseñanza de programación de computadores. Categories and Subject Descriptors D.2.13 [Reusable Software]. Reuse models. I.6.5 [Model Development]. General Terms Design, Languages. Keywords Model Driven Architecture, Variability, Software Product Lines, and Model Transformation. 1. INTRODUCCION El rápido avance tecnológico y el cambio constante en los requerimientos del negocio hacen del desarrollo de software una tarea compleja. Encarar esta realidad ha sido motivación de múltiples propuestas que buscan aumentar tanto la calidad del software, como la productividad de los equipos de desarrollo. El principio de dichas propuestas es la reutilización del software a partir de enfoques composicionales y/o generativos [24]. Los enfoques composicionales pretenden la construcción sistemas a partir de la relación de componentes que se encuentran en un depósito común. Los enfoques generativos intentan la construcción de sistemas a partir de la reutilización de procesos y de componentes de generación. Lograr construir aplicaciones reutilizando componentes requiere un enfoque de desarrollo de familias de productos para un dominio específico, en lugar de un enfoque de construcción de aplicaciones independientes [12]. Una familia de productos de software (SPL) se define como un conjunto de sistemas de software que satisfacen necesidades específicas de un segmento del mercado [26]. En un enfoque de desarrollo de SPLs, nuevos productos de la línea son creados reutilizando un conjunto de componentes llamados activos. El principal activo es la arquitectura de los productos, y otros activos adicionales pueden ser especificaciones de requerimientos, modelos de diseño, o componentes de software, entre otros. La creación de activos se realiza en el proceso de ingeniería de dominio. La creación de aplicaciones reutilizando los activos se lleva a cabo durante el proceso de ingeniería de aplicación [10, 22]. Aún cuando los productos de una línea satisfacen necesidades específicas de un dominio determinado, ellos difieren entre si en el conjunto de funcionalidades implementadas en cada uno. Así, todos los productos de una SPL proveen un conjunto de funcionalidades comunes, pero cada producto difiere de los demás en el conjunto de funcionalidades opcionales (variables) que implementa. A la diferencia funcional entre productos de una línea se le conoce como la variabilidad de una SPL [22]. La administración de variabilidad en una SPL puede ser definida como el conjunto de actividades y artefactos necesarios para: (1) expresar las características comunes y variables de una SPL, y (2) construir (componer y/o generar) aplicaciones que incluyan las características comunes, y un subconjunto de las posibles características variables. En una SPL, las características de los productos se relacionan directamente con la funcionalidad que éstos proveen. Actualmente, los modelos de rasgos son un estándar de facto usado como mecanismo para apoyar la administración de la variabilidad. Los modelos de rasgos son artefactos para expresar las características comunes y variables de una familia de productos. En los modelos de rasgos la variabilidad se modela como rasgos de los productos que pueden ser seleccionados de manera particular para cada producto [18]. Así, a partir de la selección de un conjunto de rasgos, usando los activos necesarios, se construyen aplicaciones que incluyen las características comunes, y un subconjunto de las posibles características variables.

2 Por otro lado, un enfoque de reutilización generativa es la arquitectura basada en modelos (MDA) [19]. MDA utiliza los modelos como elementos de primera clase en el desarrollo de aplicaciones, a diferencia de otros paradigmas que los utilizan únicamente como elementos de representación, documentación y comunicación. La idea central de MDA es construir modelos del dominio del problema, independientes de las características inherentes a las plataformas tecnológicas que se puedan utilizar para implementar aplicaciones. Un modelo del dominio del problema se transforma de forma automática en un nuevo modelo que incluye características de una plataforma tecnológica específica haciendo uso de reglas de transformación que permiten la generación de estos nuevos modelos. Los modelos son creados usando los conceptos definidos en un metamodelo. Un metamodelo se crea con base en los conceptos de un dominio, sus relaciones y semántica. Por esta razón los metamodelos son llamados también modelos de dominio [15]. La relación entre un modelo y su metamodelo se define como una relación de conformidad. Así, se dice que un modelo es conforme a su metamodelo [9]. Las reglas de transformación son definidas a nivel de los conceptos del metamodelo. Una regla de transformación típica toma los elementos de un modelo origen, conformes a un concepto del metamodelo origen, y los transforma en elementos de un modelo destino, conformes a conceptos del metamodelo destino [21]. El propósito principal de MDA no es la creación de familias de productos. Sin embargo, la separación de dominios y la naturaleza generativa, hacen de MDA un enfoque de gran utilidad para la creación de SPLs. Esto se logra partiendo de un modelo inicial, y utilizando varios mecanismos de transformación automáticos para obtener las diferentes aplicaciones miembros de una familia de productos. Resultados de recientes investigaciones muestran cómo el uso de MDA y SPLs (MD-SPL) resulta en un enfoque mixto (composicional y generativo) que permite definir procesos de creación de SPLs [15, 25]. Sin embargo, la administración de variabilidad en un enfoque MD-SPL es un área actual de investigación. En este artículo presentamos una propuesta para administrar la variabilidad durante el proceso de construcción de SPLs usando un enfoque MD-SPL. Para esto, nosotros separamos conceptos relacionados con una línea de productos en diferentes dominios. Estos dominios son el dominio de la lógica del negocio, el dominio de arquitectura, y el dominio de la plataforma tecnológica. Esta separación nos permite administrar la variabilidad de las líneas de producto de manera separada para cada dominio. Con el objetivo de expresar las características comunes y variables de las SPLs creamos modelos de rasgos para cada dominio. Para construir aplicaciones definimos metamodelos para cada uno de los dominios presentados. Estos metamodelos son utilizados para construir un amplio conjunto de modelos variables en cada dominio, y de esta forma podemos expresar la variabilidad de un dominio específico. Siguiendo el enfoque MDA, además de los metamodelos, creamos reglas de transformación. Las reglas de transformación típicas son creadas a nivel de los metamodelos, lo que implica que en una transformación aplicada al mismo modelo de origen se obtiene un único modelo destino asociado, sin embargo para crear aplicaciones con características variables es necesario que un mismo modelo pueda ser transformado en modelos destino diferentes según las características variables seleccionadas. Para guiar la generación de modelos variables, definimos tres tipos de reglas de transformación: (1) reglas base, (2) reglas de control, y (3) reglas específicas. Utilizamos las reglas base para generar las características comunes de las SPLs. Las reglas de control se encargan de escoger qué reglas específicas se deben ejecutar según las características esperadas en el modelo destino de la transformación. Las reglas específicas las usamos para generar las diferentes características variables. Por medio de las reglas específicas generamos aplicaciones de una misma familia con funcionalidad diferente según la selección de rasgos sobre el modelo destino realizada por el usuario en el proceso de creación de aplicaciones (ingeniería de aplicación) de la SPL. De esta forma, utilizando metamodelos, reglas de transformación, y modelos de rasgos, logramos ampliar el alcance de una SPL, y separar los dominios de manera que se disminuya la complejidad de crear aplicaciones con características variables en cada dominio. Sin embargo, las aplicaciones que generamos no son del todo completas. Ya que algunos requerimientos funcionales no se generan como parte de los procesos automáticos de transformación, nosotros complementamos las aplicaciones manualmente como parte del proceso de ingeniería de aplicación. Ilustramos esta propuesta con una SPL para el proyecto Cupi2 [11]. Para el proceso de construcción nosotros utilizamos GMF [6] como ambiente de modelado, AMW [2] como herramienta para hacer entrelazado de modelos, y ATL [3] como lenguaje de transformación de modelos. El artículo está organizado de la siguiente manera. La sección 2 presenta el contexto de aplicación que nos permitirá ilustrar la propuesta sobre un ejemplo concreto. La sección 3 y 4 presenta el problema de administrar variabilidad en una MD-SPL y la solución propuesta para resolverlo, ilustrados con una línea de producto. En la sección 5 explicamos brevemente la implementación realizada. La sección 6 presenta una comparación de nuestro trabajo con algunos trabajos relacionados y por último presentamos las conclusiones y esbozamos los trabajos futuros. 2. CONTEXTO DE APLICACIÓN Como escenario de ilustración creamos una SPL para el proyecto Cupi2 [11]. Este es un proyecto del grupo de construcción de software de la Universidad de los Andes, que propone una nueva forma de enseñar la programación de computadores. La estrategia seguida para la enseñanza de programación se basa en que los estudiantes utilicen ejemplos y ejercicios de aplicaciones completas, en lugar de solo construir secciones de código. Una aplicación completa incluye la descripción del problema, los requerimientos funcionales, los requerimientos de interfaz usuario, el diseño, las pruebas unitarias, y el código que implementa la solución. Las aplicaciones utilizadas como ejemplo para los ejercicios de aprendizaje están clasificadas por niveles. Para cada nivel se selecciona los conceptos que se quiere enseñar. Estos conceptos están alineados con uno o varios ejes temáticos. Por ejemplo, el nivel 7 incluye, entre otras temáticas, la enseñanza de algoritmos para manejo de colecciones como búsquedas y ordenamientos. Así, el objetivo de una aplicación de nivel 7 es

3 facilitar el aprendizaje de manejo de este tipo de estructuras de datos. Una característica importante es que el código utilizado para resolver un problema de un nivel sólo incluye las temáticas de los niveles anteriores y las propias del mismo nivel. El proyecto Cupi2 necesita la construcción semestral de varias aplicaciones ejemplo por cada nivel. Dado que en total son 18 niveles, la complejidad de la tarea es bastante alta y, además, durante la construcción manual de los programas, es posible inyectar defectos que se reflejan en el código fuente que manipula el estudiante, lo cual puede causar inconvenientes en el proyecto, dado que se debe garantizar la más alta calidad en estas aplicaciones. 2.1 Identificación de características comunes de los ejemplos Cupi2 El proyecto Cupi2 abarca diferentes temáticas de cursos de programación. Las temáticas están organizadas en niveles, y cada nivel tiene asociados ejemplos y ejercicios para facilitar la enseñanza/aprendizaje de dichas temáticas. En adelante trabajaremos sobre los ejemplos de Cupi2. Todos los ejemplos tienen en común que son aplicaciones monousuario sin requerimientos no funcionales complejos. Todos los ejemplos son desarrollados usando la misma plataforma tecnológica, en este caso Java. Todos los ejemplos se estructuran por tres componentes: el mundo, la interfaz de usuario, y las pruebas. El componente del mundo implementa los conceptos de la lógica del negocio, sus atributos y relaciones. El componente de la interfaz de usuario implementa la visualización de la información y la interacción entre el usuario y el componente del mundo. El componente de las pruebas implementa las pruebas unitarias de la funcionalidad ofrecida por el componente del mundo. En nuestra línea de producto hemos dejado de lado el componente de pruebas unitarias y hemos limitado el posible conjunto de aplicaciones que queremos desarrollar, con el fin de identificar un número manejable de características comunes y variables Características comunes del componente del mundo Los conceptos del mundo y sus relaciones pueden ser representados y manipulados funcionalmente por medio de estructuras de datos de tipo agrupación. Las agrupaciones siempre tienen un elemento principal, que agrupa los demás elementos del mundo. Las figuras 1a y 1b presentan dos ejemplos de modelos en el dominio de la lógica de negocio donde sus elementos están relacionados por medio de agrupaciones. En el primer caso se presenta un modelo para una aplicación de una tienda de discos virtual que maneja canciones en formato mp3. En este modelo, se tienen elementos como Discotienda y Disco. Las relaciones de agrupación muestran que el elemento Discotienda contiene un grupo de Discos, y cada Disco a su vez contiene un grupo de Canciones. En el segundo caso se presenta un modelo para una aplicación de una exposición de automóviles. En este ejemplo, se tiene el elemento ExposicionAutomoviles que agrupa elementos Automóvil. Todos los elementos del mundo tienen un conjunto de atributos, y se relacionan con otros elementos del mundo. Finalmente, de manera común en todas las aplicaciones de la línea de producto cada elemento del mundo es responsable de hacer persistir su información. Figura 1. Modelos de los ejemplos de la Tienda de Discos y la Exposición de Automóviles Características comunes del componente de interfaz de usuario Las interfaces gráficas de usuario manejan la funcionalidad de paneles, listas, listas desplegables, etiquetas, cuadros de texto, botones, imágenes, botones de radio y cajas de chequeo. Todos los elementos gráficos de la interfaz de usuario se agrupan en vistas de diferente tipo, cada una con responsabilidades claramente definidas. Hay dos tipos de vistas que son obligatorias para cualquier aplicación de ejemplo de Cupi2: (1) la vista principal, y (2) la vista de extensión. La vista principal comunica el componente del mundo con las demás vistas y agrupa todas las demás vistas de la interfaz gráfica. La vista de extensión contiene botones que el estudiante puede usar para acceder a nuevas funcionalidades que se agreguen como parte de la aplicación de ejemplo. 2.2 Identificación de características variables en los ejemplos Cupi2 De la misma forma que se identifican características comunes a todos los ejemplos, existen otras que varían para cada ejemplo particular. Las características variables de los ejemplos Cupi2 están relacionadas básicamente con la organización de las vistas incluidas en las interfaces de usuario y los algoritmos utilizados para administrar las agrupaciones Características variables del componente del mundo En el componente del mundo se encuentran elementos variables relacionados con los tipos de estructuras de datos, los algoritmos que las manipulan y los servicios utilizados para hacer persistir las diferentes agrupaciones. Las estructuras de datos que representan las agrupaciones pueden ser contenedores de tamaño fijo, contenedores de tamaño variables o estructuras lineales como listas simples o doblemente enlazadas. Cada tipo de estructura de datos puede ser manipulada usando diferentes algoritmos. Por ejemplo, es posible manipular una estructura de datos con algoritmos diferentes para hacer recorridos, inserción, búsqueda y ordenamiento, entre otros servicios.

4 Por otra parte, para hacer persistir la información de los elementos del mundo se pueden implementar diferentes funcionalidades para administrar archivos planos, o estructuras soportadas por las diferentes plataformas tecnológicas como las estructuras creadas al serializar objetos de Java. Por ejemplo, en el caso de la exposición de automóviles, se puede crear un archivo plano donde se escriben los datos de cada uno de los automóviles que existan en la estructura de datos agrupación residente en memoria. También es posible serializar cada objeto utilizando métodos propios de Java. La selección de un método o el otro depende del nivel del ejemplo y los temas asociados que se deseen enseñar Características variables del componente de interfaz de usuario No existe una forma única de representar los elementos del mundo en términos de componentes gráficos. El usuario puede seleccionar uno o varios tipos de vistas para representar la información de un elemento del mundo. Con propósitos pedagógicos, cada uno de los tipos de vistas posibles que se utilizan en los ejemplos tiene definido un conjunto de responsabilidades particulares que el desarrollador puede utilizar para representar su mundo particular. Las responsabilidades de cada tipo de vista se presentan a continuación: Vista Principal Este tipo de vista agrupa a las demás vistas. A través una vista principal se realiza la comunicación entre el componente del mundo y el componente de la interfaz de usuario Vista de Extensión Este tipo de vista se utiliza para agregar funcionalidad a las aplicaciones. Las vistas de extensión tienen un conjunto de botones, y funcionalidades asociados a cada botón. Sin embargo, en un principio las funcionalidades sólo son responsables de desplegar un mensaje de notificación. Las nuevas funcionalidades o extensiones que se hagan a las funcionalidades existentes se realizan manualmente por el estudiante a partir de las instrucciones del profesor como parte de los ejercicios de enseñanza de programación Vista de Conjunto Este tipo de vista se encarga de presentar un conjunto de elementos de agrupaciones por medio del uso de componentes como listas o tablas. Adicionalmente puede ofrecer servicios que manipulen el orden de presentación de los elementos dentro de la agrupación Vista de Búsqueda Este tipo de vista se utiliza para ingresar parámetros a partir de los cuales se realizan búsquedas sobre una agrupación de elementos. Típicamente contiene un cuadro de texto para introducir el parámetro usado para realizar la búsqueda, y un botón de confirmación Vista de Información Este tipo de vista se utiliza para mostrar la información particular asociada a los atributos de un elemento del mundo del problema. Además de información alfanumérica, esta vista también puede mostrar imágenes asociadas a los elementos Vista de Agregación Este tipo de vista se utiliza para ingresar información particular asociada a los atributos de nuevos elementos del mundo del problema. Sus componentes son similares a los de la vista de información, pero ésta utiliza cuadros de texto y botones de confirmación para recopilar la información ingresada por el usuario de la aplicación. En la Figura 2 se muestra un ejemplo de una posible interfaz de usuario para el ejemplo de la tienda de discos. Sobre esta interfaz se pueden ver cuatro tipos de vistas diferentes: dos vistas de información para mostrar los datos de los discos y de las canciones, una vista de extensión con botones para agregar nuevas funcionalidades al ejemplo, una vista de agregación para introducir los datos de una canción nueva y finalmente una vista principal que agrupa a todas las vistas. Figura 2. Ejemplo de interfaz de usuario para el ejemplo de la tienda de discos 3. PROCESO DE INGENIERÍA DE DOMINIO El proceso de ingeniería de dominio es el responsable de la creación de activos necesarios para el desarrollo de SPLs. Los activos de una línea son los componentes que conforman la arquitectura de la línea, especificaciones de requerimientos, modelos de diseño ó componentes de software, entre otros [10, 22]. En esta sección presentamos el conjunto de activos necesarios para ilustrar nuestra propuesta de administración de variabilidad en SPLs usando MDA, en el contexto de aplicaciones ejemplo para el proyecto Cupi2. Estos activos son: (1) modelos de rasgos, (2) metamodelos, y (3) reglas de transformación. Para la creación de activos de la línea, separamos conceptos relacionados con una SPL en diferentes dominios. Estos dominios son el dominio de la lógica del negocio, el dominio de la arquitectura que incluye la interfaz gráfica de usuario (GUI) y el dominio de la plataforma tecnológica. Está separación nos permite administrar la variabilidad de las líneas de producto de manera aislada para cada dominio. Es decir, podemos expresar las características comunes y variables de cada dominio, para luego construir aplicaciones con características variables en cada uno de los dominios permitiéndonos una mayor flexibilidad y simplicidad. Nuestra estrategia general para la creación de diferentes aplicaciones de la línea, de acuerdo con el enfoque MDA, se basa en la transformación automática de modelos hasta obtener aplicaciones. Así, partimos de un modelo origen en el dominio de

5 la lógica de negocio, y lo transformamos en un modelo destino en el dominio de la arquitectura; luego, partimos del modelo generado en el dominio de la arquitectura, y lo transformamos en un modelo destino en el dominio de la plataforma tecnológica; finalmente, transformamos a código fuente el modelo de plataforma tecnológica que ya incluye las características de lógica de negocio y de arquitectura. Para poder desarrollar aplicaciones siguiendo esta estrategia, definimos modelos de rasgos para expresar las características comunes y variables de cada dominio destino. Así, creamos modelos de rasgos para el dominio de la arquitectura, y el dominio de la plataforma tecnológica. Cada modelo de rasgos se concentra en expresar características propias del dominio particular. La Figura 3 presenta de manera general el proceso de ingeniería de dominio. opcionales. Un nodo solitario es obligatorio cuando representa un rasgo común a todos los productos, mientras que un nodo solitario es opcional cuando representa un rasgo relevante a por lo menos un producto. Un nodo conjunto puede agrupar nodos obligatorios, y opcionales, o nodos alternativos. Cuando los nodos son alternativos sólo uno de ellos puede ser seleccionado. Definimos modelos de rasgos para expresar las características comunes y variables de las diferentes aplicaciones de las SPLs. Sin embargo, cada modelo de rasgos se concentra en expresar características propias de las aplicaciones en un dominio particular. Para esto, en nuestra propuesta construimos modelos de rasgos para representar las características comunes y variables de los modelos destino de una transformación en un dominio determinado. En la SPL de las aplicaciones ejemplo del proyecto Cupi2 existen dos dominios que en el proceso de generación de aplicaciones se convierten en dominios destino, uno es el dominio de la arquitectura, y el otro es el dominio de la plataforma tecnológica. La notación que utilizamos para representar los modelos de rasgos es la definida en [12]. La figura 4 presenta un subconjunto del modelo de rasgos para el dominio de la arquitectura. Estos rasgos están relacionados con las características comunes y variables de la interfaz de usuario identificadas en la sección 2. Este modelo contiene el nodo Interfaz, un nodo solitario obligatorio y a la vez un nodo conjunto. Como nodo conjunto, el nodo Interfaz agrupa el nodo obligatorio Vista Principal y los nodos opcionales Vista Conjunto, Vista Agregación y Vista Información. Figura 3. Proceso de Ingeniería de Dominio Como parte de los activos de la línea, para la generación de aplicaciones, creamos metamodelos para cada uno de los dominios presentados, y tres tipos de reglas de transformación para transformar modelos en cada dominio origen, a modelos en su respectivo domino destino. Como se dijo antes, estos tipos de reglas son: (1) reglas base, (2) reglas de control, y (3) reglas específicas. Las primeras reglas corresponden a reglas de transformación escritas de forma declarativa, y son utilizadas para generar las características comunes de las SPLs. Las reglas de control se implementan de forma mixta (declarativa e imperativa), y se encargan de escoger qué reglas específicas se deben ejecutar. Las reglas de transformación específicas se implementan de forma imperativa y son las encargadas de generar los elementos necesarios de acuerdo con las características esperadas en el modelo destino de la transformación. 3.1 Modelos de rasgos Un modelo de rasgos expresa características de los productos de una línea y es utilizado para representar las similitudes y diferencias entre ellos. Los rasgos pueden ser obligatorios, opcionales o alternativos. Los rasgos obligatorios son características comunes a todos los productos, y los rasgos opcionales y alternativos varían entre uno y otro producto [16]. Un diagrama de rasgos es un árbol cuyos nodos representan rasgos. Los nodos pueden ser de tres tipos: nodo raíz, nodo conjunto o nodo solitario. El nodo raíz es el nodo principal del diagrama y siempre está presente. Un nodo conjunto agrupa otros nodos y un nodo solitario es aquel que por definición no está agrupado. Los nodos solitarios pueden ser obligatorios u Figura 4. Modelo de rasgos para el dominio de arquitectura Cupi2 De manera complementaria la figura 5 presenta un subconjunto del modelo de rasgos para el dominio de la plataforma tecnológica (Java). En las figuras 4 y 5 se puede ver el nodo raíz de los diagrama de rasgos, que para este caso se ha nombrado como el nombre del proyecto: Cupi2. Este modelo contiene el nodo Contenedora, un nodo solitario obligatorio que a la vez es conjunto. Como nodo conjunto, el nodo Contenedora agrupa los nodos alternativos ArrayList y Vector, que al ser nodos alternativos significa que el usuario sólo puede seleccionar uno de ellos.

6 Figura 5. Modelo de rasgos para el dominio de la plataforma tecnológica Cupi2 La figura 6 presenta la relación que existe entre los dos modelos de rasgos. Estas relaciones implican que los nodos que el usuario puede seleccionar en el modelo de rasgos indican características funcionales de cada aplicación de la SPL, algunas de ellas asociadas directamente con la selección de estructuras de datos particulares por implementar. Este es el caso de seleccionar un rasgo que implique el uso de un Vector o de un Arraylist. Para la creación de la SPL para el proyecto Cupi2 definimos como activos tres metamodelos: el metamodelo de la lógica del negocio, de la arquitectura y de la plataforma tecnológica. Cada metamodelo incluye conceptos abstractos de un dominio diferente de la SPL. Así, el metamodelo de la lógica del negocio sólo incluye los conceptos esenciales del mundo del problema en los ejemplos Cupi2; el metamodelo de la arquitectura incluye los conceptos del metamodelo de lógica del negocio transformados, junto con los conceptos de la arquitectura incluida la interfaz de usuario; finalmente, el metamodelo de la plataforma tecnológica incluye los conceptos del metamodelo de arquitectura ya transformados junto con los conceptos propios del lenguaje como por ejemplo paquetes, clases, métodos y atributos. De acuerdo con las características comunes y variables identificadas en la sección precedente, en las siguientes secciones presentamos los metamodelos de la lógica del negocio y de la arquitectura Metamodelo de la lógica del negocio El metamodelo de la lógica del negocio presentado en la Figura 7 incluye conceptos abstractos para los niveles 7 y 8 de los ejemplos de Cupi2. En términos generales, estos ejemplos describen un conjunto de elementos relacionados entre sí a través de estructuras de agrupamiento. Por ejemplo, si se habla de un problema para una exposición de automóviles, se dice que un elemento Exposición agrupa a un conjunto de Automóviles. Además cada elemento puede tener un conjunto de atributos que lo caractericen. Por ejemplo, es posible que el elemento Automóvil tenga un atributo que represente el año de fabricación, este atributo puede usarse para construir un servicio de ordenamiento por año de fabricación. Figura 6. Modelo de rasgos para el dominio de arquitectura y de plataforma tecnológica para la SPL del proyecto Cupi2 Esta relación permite ver cómo de manera complementaria la variabilidad de una SPL se puede representar por diferentes modelos de rasgos relacionados. 3.2 Metamodelos Un metamodelo se crea con base en los conceptos de un dominio, sus relaciones y semántica. Así como los modelos de rasgos permiten expresar características comunes y variables de un conjunto de aplicaciones, los metamodelos permiten expresar características comunes y variables de un dominio. Esto se logra abstrayendo los conceptos de un dominio, sus propiedades, y sus relaciones. Los modelos creados conformes a un metamodelo representan una instancia particular del dominio, con un conjunto de características específicas. Figura 7. Metamodelo de la lógica del negocio En la Figura 7 se presentan los conceptos Agrupador y Elemento, y la relación de agregación entre ellos. También se presenta el concepto AtributoCupi2 y los atributos que caracterizaran este concepto del mundo de acuerdo con los requerimientos particulares de las aplicaciones que se construirán. Por ejemplo, se presenta el atributo escomparable que una vez instanciado, indica que el AtributoCupi2 que posee la propiedad de ser comparable tiene un tratamiento especial en el momento de construir los algoritmos de búsqueda o de ordenamiento que sobre él se realicen.

7 presenta el concepto de Vista, una Vista a la vez puede tener un conjunto de Componentes y un conjunto de Servicios. Los Componentes se especializan en dos tipos, Componentes de Interacción y de Visualización. Los Componentes de Interacción son Componentes visuales mediante los cuales el usuario puede invocar algún tipo de funcionalidad. Algunos ejemplos de Componentes de Interacción pueden ser botones, listas o listas desplegables. Por otro lado, los Componentes de Visualización se usan para mostrar la información propia del ejemplo al usuario. Algunos ejemplos de estos Componentes son las etiquetas, los cuadros de texto o los cuadros de mensajes. Figura 8. Modelo e instancia de un elemento del modelo para el ejemplo Exposición de Automóviles Los modelos conformes al metamodelo de la lógica del negocio, utilizan sus conceptos para expresar las características propias de una instancia del dominio que representan. En la figura 8a se presenta el ejemplo de un modelo para construir la aplicación de exposición de automóviles. En este modelo se utiliza el estereotipo Agrupador, Simple, Atributo y AtributoCupi2 para indicar la relación de conformidad entre elementos del modelo y del metamodelo. El elemento ExposicionAutomoviles es conforme al elemento Agrupador que fue definido en el metamodelo. De acuerdo con la definición del elemento Agrupador, un concepto de este tipo debe agrupar un conjunto de otros elementos. En el caso del ejemplo, estos elementos son Automóvil. Cada Automóvil a su vez contiene un conjunto de Atributo y de AtributoCupi2. En la Figura 8b, se presentan un ejemplo de datos específicos que puede tomar una instancia del modelo para el elemento imagen de tipo AtributoCupi Metamodelo de Arquitectura El metamodelo de arquitectura esta relacionado con conceptos de diseño de los ejemplos Cupi2, este metamodelo no incluye decisiones de implementación sobre una plataforma tecnológica específica. Para facilitar la representación, definimos un metamodelo de arquitectura para los conceptos relacionados con la lógica del negocio y otro con los conceptos de la interfaz usuario. El metamodelo de arquitectura de la lógica del negocio introduce el concepto de Servicio. Los servicios son necesarios para manipular las estructuras de datos del ejemplo. Por otro lado, la interfaz de usuario incluye los conceptos de elementos gráficos y de interacción que serán parte de la interfaz gráfica de usuario de la aplicación generada. De esta manera, un modelo conforme al metamodelo de arquitectura, posee todos los elementos estructurales y gráficos a partir de los cuales se puede proceder con la especificación de la plataforma tecnológica y la generación del código fuente. La Figura 9 presenta un subconjunto del metamodelo de interfaz de usuario. Este metamodelo busca la generalización de los conceptos encontrados en los distintos tipos de vistas descritos en la sección 2. Como elemento principal se Figura 9. Metamodelo de Interfaz La Figura 10 presenta un modelo conforme al metamodelo de interfaz de usuario de la arquitectura. De la misma manera que en la figura 8, utilizamos estereotipos para mostrar la relación de conformidad de los elementos del modelo con el metamodelo. Figura 10. Modelo para el ejemplo Exposición de Automóviles conforme al metamodelo de arquitectura de interfaz de usuario En este caso se tienen cuatro elementos diferentes conformes al elemento Vista del metamodelo. Cada Vista a su vez tiene un conjunto de componentes específicos de acuerdo con sus responsabilidades específicas. El elemento PrincipalExposición es la Vista principal y contiene a las demás Vistas. La Vista ConjuntoAutomoviles se encarga de mostrar al grupo de automóviles contenidos por la estructura de datos de la aplicación

8 ejemplo. Esta Vista tiene un componente de interacción de tipo Lista para mostrar el conjunto de automóviles. El Botón ordenarpormodelo está asociado con los servicios de ordenamiento sobre la lista de automóviles. La Vista BusquedaAutomóvil brinda al usuario la posibilidad de buscar un automóvil en específico a partir del nombre. Por último, la Vista InformaciónAutómovil, tiene un conjunto de Etiquetas para visualizar cada uno de los atributos del Automóvil. 3.3 Modelos de entrelazado y reglas de Transformación Nuestra estrategia general, para la creación de aplicaciones de la línea, se basa en la transformación de modelos hasta obtener aplicaciones. Así, partimos de un modelo origen en el dominio de la lógica de negocio, y lo transformamos hasta obtener código fuente que incluye características de lógica de negocio, de plataforma tecnológica y de arquitectura. Las reglas de transformación típicas son definidas a nivel de los conceptos de los metamodelos. Una regla de transformación toma los elementos de un modelo origen, conformes a un concepto del metamodelo origen, y los transforma en elementos de un modelo destino, conformes a un concepto del metamodelo destino. Esto implica que en una transformación todo modelo tiene un único modelo destino asociado. Sin embargo, para crear aplicaciones con características variables es necesario que un mismo modelo pueda ser transformado en modelos destino diferentes. Para la generación de aplicaciones de la SPL definimos tres tipos de reglas de transformación, las cuales transforman modelos de los dominios origen, en modelos del domino destino, permitiendo generar diferentes modelos destino a partir de un mismo modelo de origen según la funcionalidad deseada. Estos tipos de reglas son: (1) reglas base, (2) reglas de control, y (3) reglas específicas. Para diseñar estas reglas de transformación creamos modelos de entrelazado que permiten relacionar elementos de varios modelos [14]. Los modelos de entrelazado que creamos como parte del proceso de ingeniería de dominio incluyen todas las relaciones entre los elementos de cada metamodelo origen y su respectivo modelo de rasgos destino. Así identificamos los elementos del metamodelo origen que se transforman siempre en los mismos elementos del metamodelo destino, para los cuales creamos reglas base, y los que pueden ser transformados de forma diferente (variable), para los que creamos reglas de control y reglas específicas. De esta forma construimos reglas base para generar las características comunes de la línea, y reglas de control y específicas para generar las características variables. La Figura 11 ilustra un modelo de entrelazado entre un metamodelo de lógica de negocio y los rasgos de la arquitectura. En la figura el enlace entre Agrupador y el rasgo obligatorio VistaPrincipal indica que para un elemento de tipo Agrupador siempre se crea una Vista Conjunto. Para este enlace creamos una regla base. Los enlaces entre Agrupador y los rasgos alternativos Serializacion y Archivos, indican que un elemento de tipo Agrupador puede implementar su persistencia de las dos diferentes formas. Para estos enlaces creamos una regla de control y dos reglas específica. Los enlaces entre el elemento Simple y los rasgos opcionales VistaInformacion, VistaConjunto y VistaAgregacion, indican que un elemento de tipo Simple se puede transformar en cualquiera de las tres vistas. Para estos enlaces creamos otra regla de control y tres reglas específica más. Figura 11. Modelo de entrelazado entre el metamodelo de lógica de negocio y el modelo de rasgos de la arquitectura Nosotros implementamos las reglas base de forma declarativa, y las reglas específicas de forma imperativa. Las reglas imperativas pueden ser ejecutadas muchas veces en un proceso de transformación con parámetros diferentes. Las reglas de control son implementadas de forma mixta, es decir, tienen una parte declarativa y una parte imperativa. Las reglas de control determinan qué reglas específicas deben ejecutarse según las características variables deseadas para el modelo destino de la transformación. En el Listado 1 presentamos un ejemplo de reglas base, de control y específicas. La regla vistaprincipal es una regla base. El patrón origen se define en las líneas (2-3) y el patrón destino en las líneas (4-6). La regla vistaprincipal consulta el modelo de la lógica de negocio en busca de los elementos conformes al concepto Agrupador (línea 3) de encontrarse alguno, se crea una Vista Principal (línea 5). Siguiendo con nuestro ejemplo de la tienda de discos, se crea una Vistaprincipal a partir del elemento Discotienda. Para el ejemplo de una Exposición de vehículos, se crea una Vista principal asociada a ExposiciónVehículo. La regla vistaconjunto es una regla de control. En las líneas 7-14 se define la parte declarativa y en las líneas la parte imperativa. La regla vistaconjunto busca en el modelo de entrelazado aquellos enlaces que tenga como rasgo Vista Conjunto (línea 9). De acuerdo con el modelo de entrelazado presentado en la figura 9, la regla encuentra que existe un enlace entre Disco y VistaConjunto, entonces se recupera el elemento Disco del modelo de la lógica de negocio (línea 11), crea una Vista (línea 14) e invoca la regla imperativa addcomponente (16). La regla addcomponente es una regla especifica. En la línea 19 se aprecia el nombre de la regla y sus parámetros, en las líneas se aprecia el patrón destino y en las líneas se aprecian sentencias imperativas. Cuando ésta regla es invocada desde la regla de control se crea un componente de tipo Visualizacion (línea 21), se le asigna al componente el tipo del parámetro, en este caso lista (línea 22), y se agrega el componente a la Vista creada (línea 25).

9 Listado 1. Reglas de transformación base, de control e imperativas 4. INGENIERÍA DE APLICACIÓN El proceso de ingeniería de aplicación es el responsable de la creación de productos de la SPL usando los activos construidos en el proceso de ingeniería de dominio [10, 22]. Como presentamos antes, nuestra estrategia general para la creación de aplicaciones de la línea se basa en la transformación de modelos hasta obtener aplicaciones. Así, nosotros partimos de un modelo fuente en el dominio de la lógica de negocio, y lo transformamos hasta obtener código fuente con características de la lógica de negocio, de arquitectura, y de plataforma tecnológica. El proceso general de ingeniería de aplicación es presentado en la Figura 12. lógica de negocio. Los modelos conformes al metamodelo de la lógica del negocio utilizan sus conceptos para expresar las características propias de una instancia del dominio que representan. Un ejemplo de este modelo es el presentado previamente en la Figura 8a. 4.2 Modelo de entrelazado entre modelos origen y rasgos del dominio destino Para la generación de modelos con rasgos particulares en el dominio destino es necesario hacer la selección de rasgos deseados. Para esto creamos modelos de entrelazado entre los elementos de modelos conformes a un metamodelo origen y los elementos del modelo de rasgos destino. La selección de rasgos sobre el modelo de entrelazado nos permite determinar el conjunto de reglas de transformación necesarias para generar el modelo destino deseado. En estos modelos de entrelazado las relaciones están restringidas por el entrelazado realizado en el proceso de ingeniería de dominio. Por ejemplo, en el modelo de entrelazado del proceso de ingeniería de dominio se puede ver que es posible transformar los elementos conformes al elemento Agrupador del metamodelo origen, en una Vista de Información o en una Vista Conjunto. Así, en el modelo de entrelazado del proceso de ingeniería de aplicación, cada elemento conforme al elemento Agrupador se entrelaza con uno de los dos posibles destinos: Vista de Información o Vista Conjunto. En la Figura 13 se presenta un modelo de entrelazado para este ejemplo. Figura 12. Proceso de Ingeniería de Aplicación 4.1 Modelo de lógica de negocio Como se puede ver en la figura 12, la primera actividad de este proceso es la creación de un modelo conforme al metamodelo de Figura 13. Modelo de entrelazado entre un modelo de lógica de negocio y el modelo de rasgos de arquitectura La figura 13 presenta enlaces que tienen como origen elementos del modelo de la lógica de negocio y como destino rasgos de arquitectura. En la figura se puede ver la relación entre el elemento Discotienda y el rasgo Vista información, y el enlace entre el elemento Disco y el rasgo Vista conjunto. Esta selección de rasgos y asociación con elementos del modelo de la lógica de negocio genera una interfaz de usuario con una Vista información, la cual contiene etiquetas y cuadros de texto asociados a los atributos de Discotienda, y una Vista Conjunto que agrupa los nombre de los Discos en una lista. Por otro lado el enlace entre Discotienda y el rasgo Serialización, impide que haya un enlace

10 entre Discotienda y Archivos, pues Serialización y Archivos son rasgos alternativos. Para la SPL de Cupi2 nosotros realizamos dos operaciones de entrelazado. En la primera se entrelazan modelos de la lógica de negocio con los rasgos de arquitectura, y en la segunda se entrelazan modelos de arquitectura con los rasgos de plataforma tecnológica. 4.3 Configuración y ejecución de reglas de transformación Cuando la selección de rasgos ha sido realizada para un proceso de transformación entre modelos, un conjunto de reglas de transformación son ejecutadas. Este conjunto de reglas de transformación incluye reglas base, reglas de control, y reglas específicas. Cada proceso de transformación tiene como entradas un modelo origen, el conjunto de reglas de transformación, y el modelo de entrelazado entre modelos origen y rasgos del dominio destino; y como salida un modelo destino. Al ejecutarse la transformación se recorren todos los elementos del modelo origen, aplicando las reglas base o de control asociadas a cada uno según sea el caso. Si un elemento esta asociado a una regla base, ésta se ejecuta generando los elementos definidos en la regla. Si un elemento está asociado a una regla de control, se analizan las propiedades del elemento y los rasgos que tiene asociados en el modelo de entrelazado. Según esto se decide qué regla especifica debe ejecutarse. Las reglas especificas reciben como parámetro el elemento y algunos parámetros que permiten producir los elementos deseados para cumplir con la funcionalidad representada por el rasgo. 5. IMPLEMENTACIÓN DE LA SOLUCIÓN En el proceso de ingeniería de dominio para desarrollar la SPL donde creamos aplicaciones específicas de ejemplo como la de la Tienda de Discos, la Exposición de Vehículos, y otras han servido como validación de esta propuesta, se construyeron como activos de la línea modelos de rasgos, metamodelos, y reglas de transformación. Se construyeron modelos de rasgos para el dominio de la arquitectura y de la plataforma tecnológica. Se construyeron metamodelos de la lógica del negocio, de la arquitectura, y de la plataforma tecnológica. Finalmente, se construyeron reglas de transformación base, de control y especificas. Estas reglas de transformación transforman modelos de la lógica del negocio a modelos de arquitectura, y modelos de arquitectura a modelos de la plataforma tecnológica. De manera consolidada el proceso de creación de la aplicación es el siguiente. El desarrollador crea un modelo de la lógica del negocio. Este modelo se entrelaza con el modelo de rasgos de la arquitectura y se aplica la transformación necesaria para obtener un modelo de arquitectura. El modelo de arquitectura generado se entrelaza con el modelo de rasgos de la plataforma tecnológica y se aplica la transformación necesaria para obtener un modelo de plataforma tecnológica. Finalmente, se aplica una transformación basada en plantillas para generar el código fuente (ver Figura 12). Para la implementación de nuestra solución seleccionamos una suite de herramientas plug-ins de Eclipse [4]. Estas se describen a continuación: Un manejador de metamodelos y modelos: esta herramienta debe permitir definir metamodelos y modelos, que sean serializados en formato XMI y seguir los estándares de MOF propuestos por la OMG. Para esto se escogió a EMF [5]. EMF implementa EMOF (Essential MOF), el cual es el subconjunto básico de MOF. Una herramienta gráfica de modelado: Debido a la complejidad en la expresión de los metamodelos se requiere de una herramienta que permita modelar gráficamente. Se escogió GMF como herramienta de modelado. Esta herramienta permite definir metamodelos gráficamente y generar un plug-in que permite crear los modelos conformes a dicho metamodelo [6]. Un lenguaje de transformación de modelo a modelo: Un lenguaje que permita definir transformaciones entre los metamodelos de dos dominios. Se seleccionó ATL como lenguaje de transformación por ser un lenguaje mixto (declarativo e imperativo) compatible con modelos expresados con EMF [3]. Aun cuando ATL no es una implementación de QVT (Query, View, Transformations), el estándar propuesto por la OMG para hacer consultas y transformaciones sobre los modelos y metamodelos, tiene una implementación consistente. Una herramienta de entrelazado entre modelos: Una herramienta que permita mapear o relacionar elementos de dos modelos diferentes, y genere un modelo con la información de estos entrelazados para ser utilizada por las transformaciones automáticas, y que sea compatible con modelos expresados con EMF. Esta herramienta es AMW[2]. Un lenguaje de transformación de modelo a código: Se requiere un lenguaje de transformación que se especialice en la generación de archivos de texto (código, XML, documentación) a partir de modelos. Usamos Acceleo [1] debido a que podemos recibir modelos expresados con EMF, utilizar plantillas para la generación, manejar adecuadamente código no generado. 6. TRABAJOS RELACIONADOS Propuestas para la administración de la variabilidad en SPL plantean principalmente estrategias que se enfocan en administrar la funcionalidad variable de los miembros de las familias de productos. La diferencia entre estas propuestas radica en los activos utilizados para expresar la variabilidad, y para crear aplicaciones (variables) de la SPL en el proceso de ingeniería de aplicación. En esta sección se presenta un consolidado de propuestas para administrar la variabilidad en SPLs. Sin embargo, el objetivo de esta sección no es presentar todo el estado del arte del tema. Algunos trabajos pueden no encontrarse aquí referenciados. El método FODA [16] fue introducido como una estrategia para expresar funcionalidad variable en el proceso de ingeniería de requerimientos a través del uso de modelos de rasgos. La propuesta de FORM [17] complementa la propuesta de FODA para expresar funcionalidad variable en el proceso de diseño de aplicaciones, y prescribe cómo los modelos de rasgos pueden ser usados como base para desarrollar arquitecturas de dominio y componentes para reutilización. En FORM los autores proponen categorizar los rasgos de acuerdo con requerimientos no funcionales, y usan componentes orientados a objetos como activos para crear aplicaciones de la SPL.

11 En AHEAD [8] se propone un modelo de arquitectura para programación orientada a modelos, y una base para programación composicional a gran escala. En AHEAD (Algebraic Hierarchical Equations for Application Design) los modelos de rasgos son usados para expresar variabilidad. Los activos para crear aplicaciones de la SPL son fragmentos de clases y métodos. Los rasgos se asocian con estos activos, y se componen por medio de ecuaciones algebraicas para crear aplicaciones de la SPL. En [7] se presenta una propuesta que tiene como activos clases y aspectos. Para la expresión de la variabilidad, los autores proponen la elaboración de modelos de rasgos. Para la creación de aplicaciones de la SPL se propone: (1) el diseño de una arquitectura flexible aplicando patrones, (2) el diseño de los aspectos correspondientes a los rasgos variables, y (3) la composición entre los aspectos y las clases de negocio. Como se puede ver en los trabajos citados, los modelos de rasgos son un estándar de facto para modelar la variabilidad de las SPLs. Sin embargo, existen otras propuestas de modelos que apuntan a la expresión de esta variabilidad. En [23] se propone un modelado ortogonal de la variabilidad (OVM) para reducir la complejidad de los modelos de rasgos. Los modelos de variabilidad son construidos conformes a un metamodelo general que define los conceptos de variabilidad. A su vez, en [20] se presenta un proceso basado en UML para la expresión de la variabilidad y la definición de mecanismos que permitan la implementación de ésta, es decir, la construcción de aplicaciones de la SPL. Recientes trabajos presentan cómo la Ingeniería Dirigida por Modelos (MDE) es útil en el proceso de administración de la variabilidad en SPLs. En [12] el autor presenta desde una perspectiva global los conceptos básicos del enfoque de Desarrollo de Software Generativo (GSD). Este enfoque apunta a desarrollar familias de productos automatizando la creación de miembros de la familia a partir de especificaciones escritas en lenguajes de dominio específico. Estos lenguajes pueden ser definidos por medio de metamodelado. En [13] se presentan MDA como un mecanismo para expresión de variabilidad que permite aplazar la toma de decisiones sobre el modelo de rasgos. En [25] se utilizan los diferentes niveles de abstracción de MDA como mecanismo para expresar la variabilidad de manera separada para cada dominio que corresponde a una abstracción. Las aplicaciones de la SPL son creadas componiendo elementos de un framework común. En [15] se plantea la reutilización de activos y la ampliación de alcance del manejo de la variabilidad, por medio de el uso de metamodelos en diferentes niveles de abstracción. La composición de las aplicaciones se hace por medio de mapeos entre los conceptos abstractos del negocio y los componentes de bajo nivel. Estas propuestas MD-SPL no utilizan transformaciones como mecanismo para la generación de las diferentes aplicaciones de la SPL En nuestra propuesta nosotros usamos como activos para administrar la variabilidad: (1) modelos de rasgos, (2) metamodelos, y (3) reglas de transformación. Al igual que en algunas de las propuestas anteriores, usamos modelos de rasgos para expresar la variabilidad de las aplicaciones que hacen parte de la SPL. Sin embargo, de acuerdo con nuestra estrategia de generación de aplicaciones de una SPL, nosotros creamos diferentes modelos de rasgos para expresar de manera separada la variabilidad de la línea en cada dominio específico. De manera complementaria a los modelos de rasgos, usamos metamodelos para expresar la variabilidad de los diferentes dominios, ampliando así el alcance de una SPL. Para la creación de aplicaciones usamos una estrategia principalmente generativa. Nosotros generamos automáticamente las aplicaciones con características variables de una SPL usando reglas de transformación aplicadas sobre modelos. En cada proceso de transformación permitimos tomar decisiones de los rasgos seleccionados. Así, dividimos la toma de decisiones sobre los modelo de rasgos, aplazando hasta el último momento las decisiones referentes a plataforma tecnológica. 7. CONCLUSIONES En este artículo hemos presentado una propuesta para administrar la variabilidad durante el proceso de construcción de SPLs usando un enfoque MD-SPL. Para la creación de activos de la línea, hemos separado conceptos relacionados con una SPL en diferentes dominios. Esta separación permite ampliar el alcance de la SPL administrando la variabilidad a nivel de conceptos de cada dominio de forma independiente, al tiempo que se sigue administrando la variabilidad de las aplicaciones de la línea sobre un conjunto bien definido de características funcionales. La estrategia que hemos utilizado para la creación de diferentes aplicaciones de la línea se basa en la transformación automática de un modelo inicial de lógica de negocio en un modelo destino de arquitectura; luego, partimos del modelo de arquitectura, y lo transformamos en un modelo destino de plataforma tecnológica; finalmente, transformamos a código fuente el modelo de plataforma tecnológica que ya incluye las características de lógica de negocio y de arquitectura. De esta forma, solo construimos manualmente el modelo inicial de la lógica del negocio usando conceptos con un alto nivel de abstracción. Posteriormente generamos de forma automática otros modelos por medio de reglas de transformación hasta obtener aplicaciones. Así construimos y usamos reglas de trasformación más sencillas y flexibles que las necesarias para transformar en un solo paso un modelo de lógica de negocio en una aplicación. Dado que las aplicaciones que generamos no son del todo completas al no incluir todos los requerimientos funcionales, parte del trabajo futuro incluye el modelado de todos los requerimientos funcionales como parte de los modelos de lógica de negocio, y la trasformación de los modelos de los requerimientos hasta incluirlos en las aplicaciones completas generadas. Para guiar la generación de aplicaciones con características diferentes (variables) en cada dominio, nosotros creamos metamodelos, modelos de rasgos, modelos de entrelazado y tres tipos diferentes de reglas de transformación: (1) base, (2) de control y (3) específicas. Los modelos de rasgos permiten expresar y seleccionar las características deseadas de una aplicación en un dominio destino específico. Los metamodelos permiten crear un amplio conjunto de modelos (variables) en un dominio particular ampliando el alcance de la SPL. Los modelos de entrelazado entre metamodelos y modelos de rasgos permiten identificar las reglas de transformación necesarias para generar características comunes y variables de las aplicaciones de la línea. Las reglas de transformación base permiten crear aplicaciones con las características comunes de la línea. Las reglas de control y específicas permiten crear aplicaciones con las características

12 variables de la línea. Finalmente, los modelos de entrelazado entre modelos origen de una transformación y modelos de rasgos del dominio destino de la transformación permiten la ejecución automática de reglas para generar modelos de aplicaciones variables en cada dominio. Así, usando estos diferentes activos se puede administrar la variabilidad de SPLs no solo a nivel de aplicación, sino a nivel de dominio. Esto significa que podemos generar aplicaciones que varían no solo en funcionalidades concretas a nivel de aplicaciones de la línea, sino en conceptos de los diferentes dominios identificados. Actualmente nuestra propuesta se encuentra en validación generando diferentes aplicaciones de la línea. Como futuro trabajo se espera crear SPLs para otros niveles de Cupi2 de manera que se pueda validar los conceptos de esta propuesta en dominios donde la lógica de negocio maneje un número más elevado de conceptos. La construcción de un Plug-in para eclipse que permite la creación de los modelos de entrelazados, la selección de rasgos en cada dominio, y la generación automática de aplicaciones hace parte del trabajo actual como parte de la propuesta. Aun cuando los resultados hasta ahora obtenidos como parte de la implementación de la propuesta son motivadores, existe un amplio número de puntos para trabajar. Algunos de ellos se presentan a continuación. Es necesario profundizar en el tema de separación de dominios, explorando alternativas para separar dominios y para modelar conceptos de cada dominio particular. Como parte del trabajo sobre la expresión conceptual de los diferentes dominios, es necesario trabajar sobre la expresión y transformación de conceptos relativos a requerimientos funcionales de las aplicaciones que se construyen. También es necesario trabajar sobre la construcción de reglas de control y reglas específicas más modulares con base en patrones de transformación mejor definidos. Como parte complementaria a los procesos de transformación, y en general a los procesos de generación de aplicaciones, en esta propuesta la administración de la trazabilidad es un campo completo por explorar. 8. REFERENCES [1] Acceleo. En Línea: Ultima visita 2006 [2] AMW Home Page. En Línea: Ultima visita 2006 [3] ATL Home Page. En Línea: Ultima visita 2006 [4] Eclipse. En Línea: Ultima visita 2006 [5] Eclipse Modeling Framework. En Línea: Ultima visita 2006 [6] Graphical Modeling Framework En Línea: Ultima visita 2006 [7] V. Alves, A. Dantas y P. Borba. AOP-Driven Variability in Product Lines of Pervasive Computing Applications Second International GenerativeProgramming and Component Engineering Conference (GPCE'03), Erfurt, Germany, [8] D. Batory, Feature-oriented programming and the AHEAD tool suite. en International Conference on Software Engineering (ICSE'04), Edinburg, Scotland, [9] J. Bézivin On the Unification Power of Models. Software and Systems Modeling, 4 (2) [10] P. Clements y L. Northrop Software Product Lines: Practices and Patterns. Addison Wesley Professional, [11] Cupi2. Proyecto CUPI2.http:cupi2.uniandes.edu.co. En Línea, Ultima visita Diciembre 2006 [12] K. Czarnecki, Overview of Generative Software Development. en Unconventional Programming Paradigms (UPP'04), Mont Saint-Michel, France, 2004, LNCS [13] S. Deelstra, M. Sinnema, J.v. Gurp y J. Bosch, Model Driven Architecture as Approach to Manage Variability in Software Product Families. en Workshop on Model Driven Architecture: Foundations and Applications (MDAFA'03), Enschede, The Netherlands, [14] M. Didonet Del Fabro, J. Bézivin, F. Jouault, E. Breton y G. Gueltas, AMW: a generic model weaver. en Journées sur l'ingénierie Dirigée par les Modèles (IDM'05), Paris, France, [15] J. Estublier y G. Vega. Reuse and variability in large software applications 13th ACM SIGSOFT ACM Press Lisbon, Portugal [16] K. Kang, S. Cohen, J. Hess, W. Novak y A. Peterson. Feature-Oriented Domain Analysis (FODA) Feasibility Study. CMU/SEI-90-TR-021, T.R. ed., Software Engineering Institute, Carnegie Mellon University, Pittsburgh, Estados Unidos [17] K.C. Kang, S. Kim, J. Lee, K. Kim, E. Shin y M. Huh FORM: A feature-oriented reuse method with domainspecific reference architectures. Annals of Software Engineering [18] J. Lee y D. Muthig Feature-oriented variability management in product line engineering. Communications of the ACM, 49 (12) [19] J. Mukerji y J. Miller. MDA Guide, [20] E.A.d. Oliveira, I.M.S. Gimenes, E.H.M. Huzita y J.C. Maldonado, A variability management process for software product lines. en Conference of the Centre for Advanced Studies on Collaborative research Toronto, Ontario, Canada 2005, [21] O.M.G. OMG. MOF 2.0 Query/Views/Transformations RFP, [22] K. Pohl, G. Böckle y F.J.v.d. Linden Software Product Line Engineering: Foundations, Principles and Techniques. Springer, [23] K. Pohl, F. van der Linden y A. Metzger Software Product Line Variability Management. International Software Product Line Conference [24] J. Sametinger Software engineering with reusable components. Springer, New York, [25] A.L. Santos, A. Lopes y K. Koskimies, An MDA Approach to Variability Management in Product-Line Engineering en Nordic Workshop on UML and Software Modeling (NWUML'06), Grimstad, Norway, [26] S.E.I. SEI. Software Product Lines. En Línea: Ultima visita Diciembre 2006

Desarrollo de Software guiado por los modelos

Desarrollo de Software guiado por los modelos Desarrollo de Software guiado por los modelos Rubby Casallas rcasalla@uniandes.edu.co Universidad de los Andes (57) 1 3394949 Bogotá 1 1 Objetivo de la charla Presentar los conceptos básicos del enfoque

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

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

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México

La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México Licencia La obra se proporciona bajo los términos de esta licencia pública de Sisoft de México S. A de C.V., Está protegida por derechos de autor y / u otras leyes aplicables. Cualquier uso diferente a

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

Análisis de Requisitos

Análisis de Requisitos Análisis de Requisitos Los requisitos determinan lo que hará el sistema y definen restricciones sobre su operación e implementación. El análisis de requisitos es el proceso del estudio de las necesidades

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

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

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición.

Glosario. actividad. 1. (tarea) 2. es un subproceso que no requiere mas descomposición. Glosario Aclaraciones Los conceptos del glosario están ordenados alfabéticamente. Un concepto puede ser un único término como meta o una frase como ambiente de ingeniería de software centrado en procesos.

Más detalles

Xaguar Soluciones BPM BPM

Xaguar Soluciones BPM BPM Xaguar Soluciones BPM BPM XAGUAR e-suite HABILITANDO BPM Los procesos de negocio de las organizaciones reales suelen ser complejos, más aún si se consideran los procesos que involucran a más de una de

Más detalles

Diagrama de Clases. Diagrama de Clases

Diagrama de Clases. Diagrama de Clases Diagrama de Clases 1 Diagrama de Clases El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar

Más detalles

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010

Programación Orientada a Objetos Analista Programador Universitario Plan 2008 Año 2010 INTRODUCCION Los objetos usados en aplicaciones JAVA mantienen su estado y comportamiento mientras la aplicación se halle en ejecución. Generalmente se necesita mantener el estado y comportamiento de los

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

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

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

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

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0)

Especificación de Requisitos del Sistema de Registro y Control de Bienes Muebles de la ULA (ULA_SRCBM, versión 1.0) Proyecto: Actualización del Sistema de Información de Muebles Documento: Especificación de s del Sistema de Registro y Control de Muebles ULA (ULA_SRCBM, versión 1.0) Elaborado por: William J. Montilva

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

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1

Software Reutilizable. Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Software Reutilizable Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 18 Slide 1 Objetivos Para explicar los beneficios del software reutilizable y algunos de sus problemas Para discutir

Más detalles

La importancia del desarrollo para el buen diseño del software

La importancia del desarrollo para el buen diseño del software La importancia del desarrollo para el buen diseño del software RESUMEN N L González Morales. 1 En este ensayo se examinan los temas vistos en clase que son Desarrollo de Orientado a Objetos y Arquitectura

Más detalles

FEATURE MODELING TOOL MANUALES

FEATURE MODELING TOOL MANUALES FEATURE MODELING TOOL MANUALES INDICE Instalación... 3 Procedimiento de instalación... 3 Desinstalación... 4 Guía de Uso... 4 Elementos gráficos del editor... 5 Creación de un proyecto... 8 Abrir un modelo...

Más detalles

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE

PRUEBAS DE SOFTWARE TECNICAS DE PRUEBA DE SOFTWARE PRUEBAS DE SOFTWARE La prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además,

Más detalles

DISEÑO DE COMPONENTES DE SOFTWARE *

DISEÑO DE COMPONENTES DE SOFTWARE * DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP * Resumen del capítulo 10 de libro de [Pressman 2010] V:18-11-2008 (c) P. Gomez-Gil, INAOE.

Más detalles

Simulador de Protocolos de Red a tráves de WEB

Simulador de Protocolos de Red a tráves de WEB Simulador de Protocolos de Red a tráves de WEB Propuesta de Estudio 20071608 Director Ing. Francisco Antonio Polanco Montelongo Resumen Introducción Actualmente, el desarrollo tecnológico a alcanzado niveles

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

UML 2 Iniciación, ejemplos y ejercicios corregidos

UML 2 Iniciación, ejemplos y ejercicios corregidos Ediciones ENI UML 2 Iniciación, ejemplos y ejercicios corregidos (3ª edición) Colección Recursos Informáticos Contenido Contenido 1 Capítulo 1 Introducción 1. Motivaciones de la obra.....................................

Más detalles

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII

GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUÍA Nro. 1 TECNOLOGÍA DE INTERNET. TIII PIII GUIA DISPONIBLE EN: http://preparadorivan.blogspot.com/ - http://preparadormssi.50webs.com/inicio.html La World Wide Web o la Web, es una de las múltiples

Más detalles

Arturo Cepeda Pérez. Software Engineering Tutor

Arturo Cepeda Pérez. Software Engineering Tutor Software Engineering Tutor M A N U A L D E U S U A R I O Tabla de contenidos 1. Software Engineering Tutor... 1 2. Entorno... 2 2.1. Vista Modelo... 3 2.2. Vista Diagrama... 4 2.3. Vista Propiedades...

Más detalles

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN

Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Transformación de modelos en el proceso de obtención de Modelos Conceptuales partiendo de BPMN Fernández Taurant, Juan Pablo Marciszack, Marcelo Martín Universidad Tecnológica Nacional, Facultad Regional

Más detalles

SPEM - Software & Systems Process Engineering Metamodel Specification

SPEM - Software & Systems Process Engineering Metamodel Specification SPEM - Software & Systems Process Engineering Metamodel Specification 1. ALCANCE: El propósito de éste documento es proporcionar una definición comprensible del meta-modelo de ingeniería de procesos de

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

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO

SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO SISTEMA DE GESTIÓN DE INCIDENCIAS Y REQUERIMIENTOS MESA DE AYUDA SINAT MANUAL DE USUARIO 1 Objetivo del Manual Elaborado por: Revisado por: Aprobado por: Fecha: 13/08/2015 Difusión: Información del Manual

Más detalles

CAPITULO 5 DOCUMENTO DE ESPECIFICACION DE REQUISITOS DEL SOFTWARE

CAPITULO 5 DOCUMENTO DE ESPECIFICACION DE REQUISITOS DEL SOFTWARE CAPITULO 5 DOCUMENTO DE ESPECIFICACION DE REQUISITOS DEL SOFTWARE 1 1. Documento de Especificación de Requisitos del Software Como se menciona en [Pressman, 1998], la especificación de los requisitos del

Más detalles

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes

Arquitectura para análisis de información. Zombi es una arquitectura que proporciona de manera integrada los componentes Capítulo 4 Arquitectura para análisis de información propuesta 4.1 Arquitectura Zombi es una arquitectura que proporciona de manera integrada los componentes necesarios para el análisis de información

Más detalles

Capítulo 5. Implementación y Tecnologías Utilizadas

Capítulo 5. Implementación y Tecnologías Utilizadas Capítulo 5. Implementación y Tecnologías Utilizadas Cada vez más, se está utilizando Flash para desarrollar aplicaciones basadas en Web, pues permite la construcción de ambientes con mayor interacción.

Más detalles

MODELADO DE OBJETOS DE DATOS

MODELADO DE OBJETOS DE DATOS Manual Página Web MODELADO DE OBJETOS DE DATOS MANUALES ESPECIALES Documento: Manual Páginas Web (SemanticWebBuilder). Fecha de Elaboración: Marzo de 2009. INFOTEC CONACYT FIDEICOMISO. Página i Glosario

Más detalles

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS

UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS UNIVERSIDAD CATOLICA DE COLOMBIA FACULTAD DE INGENIERIA DE SISTEMAS CURSO: JAVA BASICO PROFESOR: EMERSON CASTAÑEDA SANABRIA TEMA: Programación Orientada a Objetos OBJETIVOS: Familiarizarse con la Programación

Más detalles

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón

BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS. Dámaso López Aragón BASE DE DATOS: ENFOQUE ORIENTADO A OBJETOS Dámaso López Aragón Introducción En la actualidad, la orientación a objetos es una nueva forma de comprender los problemas y modelar el negocio de una empresa,

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

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos

IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos ZP09-0207, con fecha 2 de junio de 2009 IBM Rational Statemate ayuda a los ingenieros de sistemas a enfrentarse a los retos del mercado de sistemas integrados complejos Índice 1 Resumen de características

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

SIGPRE Sistema de Gestión Presupuestaria

SIGPRE Sistema de Gestión Presupuestaria SIGPRE Sistema de Gestión Presupuestaria Documento de Arquitectura UTN Histórico de Revisiones Fecha Versión Descripción Autor 11/17/2009 1.0 Borrador de la arquitectura Roberto López Hinojosa 12/14/2009

Más detalles

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO

SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO SERVICE ORIENTED ARCHITECTURE (SOA) CONTENIDO Introducción:...1 Service Oriented Architecture...2 Elementos de una Service Oriented Architecture...2 Application frontends...2 Servicios...2 Contrato:...3

Más detalles

Dirección General de Educación Superior Tecnológica

Dirección General de Educación Superior Tecnológica Dirección General de Educación Superior Tecnológica 1. Datos Generales de la asignatura Nombre de la asignatura: Clave de la asignatura: Programación de dispositivos móviles RSM 1205 Créditos (Ht Hp_ créditos):

Más detalles

O jeto de apre r ndizaje

O jeto de apre r ndizaje Herramientas de Gestión para Objetos de Aprendizaje. Plataforma AGORA Victor Hugo Menéndez Domínguez Universidad Autónoma de Yucatán, México :: mdoming@uady.mx Manuel Emilio Prieto Méndez Universidad de

Más detalles

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico

Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Práctica Java POJO de Integración de Sistemas Tienda de Comercio Electrónico Curso académico 2008-2009 1 Introducción La práctica de Integración de Sistemas consistirá en el diseño e implementación de

Más detalles

CONSTRUCCIÓN DE PORTALES

CONSTRUCCIÓN DE PORTALES Curso «Los portales de internet». Fac. Documentación. Universidad de Murcia. 29 CONSTRUCCIÓN DE PORTALES Juan Antonio Pastor Sánchez 1. Introducción La Gestión de los contenidos informativos de los portales

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

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

Curso de Spring Framework

Curso de Spring Framework Todos los Derechos Reservados Global Mentoring 2012 Experiencia y Conocimiento para tu Vida 1 Spring es un proyecto de código abierto (open source), originalmente creado por Rod Johnson y descrito en su

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

VISIÓN GENERAL HERRAMIENTAS COMERCIALES VISIÓN GENERAL El servidor de MS SQL se ha convertido en un estándar en muchas partes de la América corporativa. Puede manejar volúmenes de datos grandes y se integra bien con otros productos de Microsoft.

Más detalles

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens

Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Resumen de la presentación de Tom Baeyens Workflow, BPM y Java Página 1 de 11 1. Introducción Tom Baeyens es el fundador y arquitecto del proyecto de JBoss jbpm, la máquina de workflow

Más detalles

Workflows? Sí, cuántos quiere?

Workflows? Sí, cuántos quiere? Workflows? Sí, cuántos quiere? 12.11.2006 Servicios Profesionales Danysoft Son notables los beneficios que una organización puede obtener gracias al soporte de procesos de negocios que requieran la intervención

Más detalles

Acronis License Server. Guía del usuario

Acronis License Server. Guía del usuario Acronis License Server Guía del usuario TABLA DE CONTENIDO 1. INTRODUCCIÓN... 3 1.1 Generalidades... 3 1.2 Política de licencias... 3 2. SISTEMAS OPERATIVOS COMPATIBLES... 4 3. INSTALACIÓN DE ACRONIS LICENSE

Más detalles

ENTORNO DE UN CURSO. Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos:

ENTORNO DE UN CURSO. Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos: ENTORNO DE UN CURSO Antes de empezar sería conveniente conocer la estructura de Moodle y entender los siguientes conceptos básicos: Cursos Categorías Cuentas de usuario y roles Perfil de usuario En Moodle,

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

"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

arquitectura que maneja. Encontraremos también los diferentes servidores que

arquitectura que maneja. Encontraremos también los diferentes servidores que 3.1 INTRODUCCIÓN A lo largo de este capitulo será descrito ArcIMS, así como las características y arquitectura que maneja. Encontraremos también los diferentes servidores que proporciona ArcIMS, además

Más detalles

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN

INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INSTRUCTIVO PARA LA CUENTA DE PUNTOS FUNCIÓN INDICE Introducción...2 Frontera de la aplicación...3 Cuenta de Puntos Función sin ajustar...3 Funciones de Datos...4 Funciones Transaccionales...4 Mecanismo...5

Más detalles

Estructura de Bases de datos. Leonardo Víquez Acuña

Estructura de Bases de datos. Leonardo Víquez Acuña Estructura de Bases de datos Leonardo Víquez Acuña Lenguajes de Bases de Datos Un sistema de bases de datos proporciona Un lenguaje de definición de datos para especificar el esquema de la base de datos

Más detalles

Unidad 1: Conceptos generales de Sistemas Operativos.

Unidad 1: Conceptos generales de Sistemas Operativos. Unidad 1: Conceptos generales de Sistemas Operativos. Tema 3: Estructura del sistema operativo. 3.1 Componentes del sistema. 3.2 Servicios del sistema operativo. 3.3 Llamadas al sistema. 3.4 Programas

Más detalles

BROWSERSQL VERSIÓN 3.1 TUTORIAL

BROWSERSQL VERSIÓN 3.1 TUTORIAL TUTORIAL LAURA NOUSSAN LETTRY (MENDOZA, ARGENTINA 2011) ÍNDICE CONTENIDOS PÁGINA Introducción 2 Características Funcionales 2 Área de Conexión 3 Área de Ejecución de Sentencias 4 En qué se basa su funcionamiento

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

Objetivo Las personas que realicen el curso aprenderán a:

Objetivo Las personas que realicen el curso aprenderán a: Objetivo Las personas que realicen el curso aprenderán a: Describir el proceso de desarrollo de software orientado a objetos, lo que incluye las metodologías y los flujos de trabajo de la programación

Más detalles

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente

Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente Capítulo 4. Requisitos del modelo para la mejora de la calidad de código fuente En este capítulo definimos los requisitos del modelo para un sistema centrado en la mejora de la calidad del código fuente.

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

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas

PROGRAMACIÓ DIDÁCTICA: Secuanciación, Temporalización y Unidades Didácticas Departamento de Informática PROGRAMACIÓN DIDÁCTICA Curso 11-12 1 CONSEJERÍA DE EDUCACIÓN I.E.S. NERVIÓN Departamento de Informática CICLO FORMATIVO: TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA.

Más detalles

Arquitectura y Diseño de la Solución

Arquitectura y Diseño de la Solución Arquitectura y Diseño de la Solución Recuento de Conceptos importantes Modelamiente / Versionamiento de trámites Vista Conceptual Subsistemas Funcionales Principales Detalle de los subsistemas Vista de

Más detalles

Capítulo 5. Cliente-Servidor.

Capítulo 5. Cliente-Servidor. Capítulo 5. Cliente-Servidor. 5.1 Introducción En este capítulo hablaremos acerca de la arquitectura Cliente-Servidor, ya que para nuestra aplicación utilizamos ésta arquitectura al convertir en un servidor

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

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa.

Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. BASES DE DATOS Una base de datos es una colección de información ordenada e interrelacionada que es de importancia para una empresa. La creación de una base de datos debe ser realizada cuidadosamente procurando

Más detalles

DATOS ESPECÍFICOS DEL CURSO

DATOS ESPECÍFICOS DEL CURSO DATOS ESPECÍFICOS DEL CURSO 14. Denominación del módulo: LA ESTRUCTURA DEL INTERFAZ Y LOS ELEMENTOS DE DISEÑO WEB Y MULTIMEDIA. 15. Objetivo del módulo: Diseñar la estructura del interfaz, identificando

Más detalles

Iniciación y Planificación del Proyecto

Iniciación y Planificación del Proyecto Iniciación y Planificación del Proyecto Para cuando dijo que lo quería??? Ingeniería de Software 2 Iniciación y Planificación del Proyecto 1 Agenda Iniciación del Proyecto: Entradas Iniciación del Proyecto:

Más detalles

ESPECIALIZACIÓN EN GESTIÓN DE BASE DE DATOS GUÍA DIDÁCTICA PARA LA GESTIÓN DE PROYECTOS Código: EGBD-P01-GD01

ESPECIALIZACIÓN EN GESTIÓN DE BASE DE DATOS GUÍA DIDÁCTICA PARA LA GESTIÓN DE PROYECTOS Código: EGBD-P01-GD01 ESPECIALIZACIÓN EN GESTIÓN DE BASE DE DATOS GUÍA DIDÁCTICA PARA LA GESTIÓN DE PROYECTOS Código: EGBD-P01-GD01 1. IDENTIFICACIÓN DE LA GUÍA DIDÁCTICA DISEÑO Y ADMINISTRACIÓN DE UNA BODEGA DE DATOS Nombre

Más detalles

Capítulo 1. Introducción

Capítulo 1. Introducción Capítulo 1. Introducción El WWW es la mayor fuente de imágenes que día a día se va incrementando. Según una encuesta realizada por el Centro de Bibliotecas de Cómputo en Línea (OCLC) en Enero de 2005,

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

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012

TFC J2EE. Aplicación Web para la gestión de facturación de una empresa de cerrajería. Sara Gutiérrez Melero ITIG Junio de 2012 TFC J2EE Aplicación Web para la gestión de facturación de una empresa de cerrajería Sara Gutiérrez Melero ITIG Junio de 2012 Consultor: Jose Juan Rodriguez Índice 1. Introducción Objetivos Planificación

Más detalles

Xaguar Soluciones PORTALES PORTALES

Xaguar Soluciones PORTALES PORTALES Xaguar Soluciones PORTALES PORTALES XAGUAR e-suite HABILITANDO PORTALES La implementación exitosa de integración de aplicaciones colaborativas e iniciativas SOA, BPM, ECM o de integración depende en gran

Más detalles

JAVA EE 5. Arquitectura, conceptos y ejemplos.

JAVA EE 5. Arquitectura, conceptos y ejemplos. JAVA EE 5. Arquitectura, conceptos y ejemplos. INTRODUCCIÓN. MODELO DE LA APLICACIÓN JEE5. El modelo de aplicación Java EE define una arquitectura para implementar servicios como lo hacen las aplicaciones

Más detalles

Manual de requisitos técnicos para la SEDE Electrónica del Ministerio de Economía y Competitividad en I+D+I

Manual de requisitos técnicos para la SEDE Electrónica del Ministerio de Economía y Competitividad en I+D+I Manual de requisitos técnicos para la SEDE Electrónica del Ministerio de Economía y Competitividad en I+D+I Configuraciones técnicas previas de Java y en los navegadores de Internet. Madrid, 24 Abril de

Más detalles

ISO 19103. Lenguaje de Esquema Conceptual

ISO 19103. Lenguaje de Esquema Conceptual ISO 19103 Lenguaje de Esquema Conceptual La ISO 19103 establece normas y guías para la adopción y uso de un Lenguaje de Esquema Conceptual (CSL) para desarrollar modelos o esquemas de información geográfica,

Más detalles

TEMA 1: INTRODUCCIÓN

TEMA 1: INTRODUCCIÓN 1 DISEÑO Y DESARROLLO DE COMPILADORES TEMA 1: INTRODUCCIÓN Qué es un Compilador? Un compilador no es más que un traductor, es decir, un programa que nos permite pasar información de un lenguaje a otro.

Más detalles

Ingeniería de Software en SOA

Ingeniería de Software en SOA Ingeniería de Software en SOA ECSDI LSI-FIB-UPC cbea Curso 2014/2015 ECSDI (LSI-FIB-UPC cbea) Ingeniería de Software en SOA Curso 2014/2015 1 / 51 Índice 1 Directrices para la IS en SOA 2 Modelo de referencia

Más detalles

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso

PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación. II MODELOS y HERRAMIENTAS UML. II.2 UML: Modelado de casos de uso PROGRAMACIÓN ORIENTADA A OBJETOS Master de Computación II MODELOS y HERRAMIENTAS UML 1 1 Modelado de casos de uso (I) Un caso de uso es una técnica de modelado usada para describir lo que debería hacer

Más detalles

Interoperabilidad de Fieldbus

Interoperabilidad de Fieldbus 2002 Emerson Process Management. Todos los derechos reservados. Vea este y otros cursos en línea en www.plantwebuniversity.com. Fieldbus 201 Interoperabilidad de Fieldbus Generalidades Qué es interoperabilidad?

Más detalles

REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO

REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO REQUISITOS PARA LA SOLICITUD DE EVALUACIÓN DE RECURSOS DIGITALES CON FINES DE APRENDIZAJE Y PROMOCIÓN DE LA ORIGINALIDAD DEL MATERIAL EDUCATIVO El Sistema de Universidad Virtual (SUV) se ha enfocado en

Más detalles

En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro

En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro Capitulo 6 Conclusiones y Aplicaciones a Futuro. En nuestro capitulo final, daremos las conclusiones y las aplicaciones a futuro para nuestro sistema. Se darán las conclusiones para cada aspecto del sistema,

Más detalles

Manual de Usuario SMS Inteligente

Manual de Usuario SMS Inteligente Manual de Usuario SMS Inteligente 1 Contenido 1. Introducción... 3 2. Características y requerimientos del equipo de cómputo... 3 3. Requerimientos previos... 3 4. Cómo utilizar el portal... 4 Ingreso

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

El Proyecto Cupi2. Jorge Villalobos Rubby Casallas Marcela Hernández. Mayo 3 2006. Buscando nuevas maneras de enseñar a programar

El Proyecto Cupi2. Jorge Villalobos Rubby Casallas Marcela Hernández. Mayo 3 2006. Buscando nuevas maneras de enseñar a programar El Proyecto Cupi2 Buscando nuevas maneras de enseñar a programar Jorge Villalobos Rubby Casallas Marcela Hernández Ingeniería de Sistemas y Computación Universidad de los Andes Mayo 3 2006 Objetivo Presentar

Más detalles

Evaluación de la Plataforma de Almacenamiento de Información de Múltiples Protocolos Celerra NS20 de EMC

Evaluación de la Plataforma de Almacenamiento de Información de Múltiples Protocolos Celerra NS20 de EMC Evaluación de la Plataforma de Almacenamiento de Información de Múltiples Protocolos Celerra NS20 de EMC Informe elaborado bajo contrato con EMC Corporation Introducción EMC Corporation contrató a Demartek

Más detalles

ESPACIOS GRUPALES DE APRENDIZAJE. Los espacios grupales de aprendizaje son un espacio de trabajo compartido por un

ESPACIOS GRUPALES DE APRENDIZAJE. Los espacios grupales de aprendizaje son un espacio de trabajo compartido por un ESPACIOS GRUPALES DE APRENDIZAJE Los espacios grupales de aprendizaje son un espacio de trabajo compartido por un grupo de usuarios que tienen un mismo perfil en el cual se les facilita la comunicación

Más detalles

3.4. Reload Editor ( Guía de Uso).

3.4. Reload Editor ( Guía de Uso). 3.4. Reload Editor ( Guía de Uso). Anterior 3. Lors Management Siguiente 3.4. Reload Editor ( Guía de Uso). 3.4.1. Preguntas básicas sobre Reload Editor. - Qué hace el programa Reload Editor? RELOAD Editor

Más detalles

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características

SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA. 3.1. Características SISTEMAS DISTRIBUIDOS DE REDES 3.- ESTANDAR CORBA 3.1. Características La tendencia hacia el futuro es el de lograr la integración total de componentes realizados por terceras partes, para lo cual es necesario

Más detalles

Firmar Solicitud. Manual de usuario

Firmar Solicitud. Manual de usuario Firmar Solicitud Manual de usuario Madrid, Marzo de 2014 ÍNDICE 1. INTRODUCCIÓN... 3 2. PANTALLAS... 4 2.1. Login... 4 2.2. Ayuda... 4 2.3. Pantalla de Solicitudes de Registro... 5 2.4. Listado de documentos

Más detalles

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales

Permite compartir recursos en forma coordinada y controlada para resolver problemas en organizaciones multiinstitucionales The Anatomy of the Grid Enabling Scalable Virtual Organization Autores : Ian Foster, Carl Kesselman y Steven Tuecke. 2001 GRIDS y Organizaciones Virtuales Permite compartir recursos en forma coordinada

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

XMLSpy. Manual de usuario. www.ejie.es

XMLSpy. Manual de usuario. www.ejie.es XMLSpy Manual de usuario Fecha: 31/08/2007 Referencia: EJIE S.A. Mediterráneo, 3 Tel. 945 01 73 00* Fax. 945 01 73 01 01010 Vitoria-Gasteiz Posta-kutxatila / Apartado: 809 01080 Vitoria-Gasteiz www.ejie.es

Más detalles

Introducción a la Ingeniería de Software - Examen 20/07/2012

Introducción a la Ingeniería de Software - Examen 20/07/2012 Cada pregunta múltiple opción contestada correctamente tiene un valor de 2,5 puntos. Esta parte consta de 20 preguntas, haciendo un total de 50 puntos. Los ejercicios de desarrollo tienen un valor total

Más detalles