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

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

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

Elementos requeridos para crearlos (ejemplo: el compilador)

Elementos requeridos para crearlos (ejemplo: el compilador) Generalidades A lo largo del ciclo de vida del proceso de software, los productos de software evolucionan. Desde la concepción del producto y la captura de requisitos inicial hasta la puesta en producción

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

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar

CAPITULO 4. Requerimientos, Análisis y Diseño. El presente capítulo explica los pasos que se realizaron antes de implementar CAPITULO 4 Requerimientos, Análisis y Diseño El presente capítulo explica los pasos que se realizaron antes de implementar el sistema. Para esto, primero se explicarán los requerimientos que fueron solicitados

Más detalles

Capitulo I. Introducción

Capitulo I. Introducción Capitulo I. Introducción 1.1 Descripción del trabajo El ser humano, como todos sabemos tiene la necesidad de comunicarse, de ser escuchado y sobretodo interactuar con los demás seres vivos que lo rodean.

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

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online

Guías _SGO. Gestione administradores, usuarios y grupos de su empresa. Sistema de Gestión Online Guías _SGO Gestione administradores, usuarios y grupos de su empresa Sistema de Gestión Online Índice General 1. Parámetros Generales... 4 1.1 Qué es?... 4 1.2 Consumo por Cuentas... 6 1.3 Días Feriados...

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

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

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

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

Manual del Usuario. Sistema de Help Desk

Manual del Usuario. Sistema de Help Desk Manual del Usuario Sistema de Help Desk Objetivo del Manual El siguiente manual tiene como objetivo proveer la información necesaria para la correcta utilización del sistema Help Desk. Describe los procedimientos

Más detalles

LiLa Portal Guía para profesores

LiLa Portal Guía para profesores Library of Labs Lecturer s Guide LiLa Portal Guía para profesores Se espera que los profesores se encarguen de gestionar el aprendizaje de los alumnos, por lo que su objetivo es seleccionar de la lista

Más detalles

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA

Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Propuesta de Portal de la Red de Laboratorios Virtuales y Remotos de CEA Documento de trabajo elaborado para la Red Temática DocenWeb: Red Temática de Docencia en Control mediante Web (DPI2002-11505-E)

Más detalles

Manual para la utilización de PrestaShop

Manual para la utilización de PrestaShop Manual para la utilización de PrestaShop En este manual mostraremos de forma sencilla y práctica la utilización del Gestor de su Tienda Online mediante Prestashop 1.6, explicaremos todo lo necesario para

Más detalles

REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP

REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP REGISTRO DE PEDIDOS DE CLIENTES MÓDULO DE TOMA DE PEDIDOS E INTEGRACIÓN CON ERP Visual Sale posee módulos especializados para el método de ventas transaccional, donde el pedido de parte de un nuevo cliente

Más detalles

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

Introducción a la Firma Electrónica en MIDAS

Introducción a la Firma Electrónica en MIDAS Introducción a la Firma Electrónica en MIDAS Firma Digital Introducción. El Módulo para la Integración de Documentos y Acceso a los Sistemas(MIDAS) emplea la firma digital como método de aseguramiento

Más detalles

REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS

REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS REGISTRO DE EMPRESAS Y PERSONAS BASE DE INFORMACIÓN DE CLIENTES & CONTACTOS La gestión del asesor comercial se basa en mantener contacto personalizado con un grupo de clientes empresariales o personales.

Más detalles

GUIA DE USO MEJORAS AGENCIA VIRTUAL EMPRESAS

GUIA DE USO MEJORAS AGENCIA VIRTUAL EMPRESAS GUIA DE USO MEJORAS AGENCIA VIRTUAL EMPRESAS Para CONFIAR Cooperativa Financiera es muy importante mantener una constante comunicación con las empresas que cuentan con nuestro servicio de Agencia Virtual

Más detalles

Capitulo 5. Implementación del sistema MDM

Capitulo 5. Implementación del sistema MDM Capitulo 5. Implementación del sistema MDM Una vez que se concluyeron las actividades de análisis y diseño se comenzó la implementación del sistema MDM (Manejador de Documentos de MoProSoft). En este capitulo

Más detalles

CAPÍTULO 3 Servidor de Modelo de Usuario

CAPÍTULO 3 Servidor de Modelo de Usuario CAPÍTULO 3 Servidor de Modelo de Usuario Para el desarrollo del modelado del estudiante se utilizó el servidor de modelo de usuario desarrollado en la Universidad de las Américas Puebla por Rosa G. Paredes

Más detalles

JavaScript como Orientación a Objetos

JavaScript como Orientación a Objetos Gustavo Lacoste (gustavo@lacosox.org) October 2012 Resumen El objetivo de las siguientes notas es generar una estructura en JavaScript que nos permita reutilizar de manera limpia las funciones creadas

Más detalles

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi

Gestión de Permisos. Bizagi Suite. Copyright 2014 Bizagi Gestión de Permisos Bizagi Suite Gestión de Permisos 1 Tabla de Contenido Gestión de Permisos... 3 Definiciones... 3 Rol... 3 Perfil... 3 Permiso... 3 Módulo... 3 Privilegio... 3 Elementos del Proceso...

Más detalles

Edición de Ofertas Excel Manual de Usuario

Edición de Ofertas Excel Manual de Usuario Edición de Ofertas Excel Manual de Usuario Alfonso XI, 6 28014 Madrid F(+34) 91 524 03 96 www.omie.es Ref. MU_OfertasExcel.docx Versión 4.0 Fecha: 2012-11-26 ÍNDICE 1 INTRODUCCIÓN 3 2 CONSIDERACIONES DE

Más detalles

Catoira Fernando Fullana Pablo Rodriguez Federico [MINERIA DE LA WEB] Proyecto Final - Informe Final

Catoira Fernando Fullana Pablo Rodriguez Federico [MINERIA DE LA WEB] Proyecto Final - Informe Final Catoira Fernando Fullana Pablo Rodriguez Federico [MINERIA DE LA WEB] Proyecto Final - Informe Final INTRODUCCION En principio surgió la idea de un buscador que brinde los resultados en agrupaciones de

Más detalles

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS

ARQUITECTURA DE DISTRIBUCIÓN DE DATOS 4 ARQUITECTURA DE DISTRIBUCIÓN DE DATOS Contenido: Arquitectura de Distribución de Datos 4.1. Transparencia 4.1.1 Transparencia de Localización 4.1.2 Transparencia de Fragmentación 4.1.3 Transparencia

Más detalles

Plataforma e-ducativa Aragonesa. Manual de Administración. Bitácora

Plataforma e-ducativa Aragonesa. Manual de Administración. Bitácora Plataforma e-ducativa Aragonesa Manual de Administración Bitácora ÍNDICE Acceso a la administración de la Bitácora...3 Interfaz Gráfica...3 Publicaciones...4 Cómo Agregar una Publicación...4 Cómo Modificar

Más detalles

Mesa de Ayuda Interna

Mesa de Ayuda Interna Mesa de Ayuda Interna Bizagi Suite Mesa de Ayuda Interna 1 Tabla de Contenido Mesa de Ayuda Interna... 3 Elementos del proceso... 5 Apertura del Caso... 5 Inicio... 5 Abrir Caso... 5 Habilitar Cierre del

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

Patrones de software y refactorización de código

Patrones de software y refactorización de código Patrones de software y refactorización de código Introducción y antecedentes de los patrones de software Los patrones permiten construir sobre la experiencia colectiva de ingenieros de software habilidosos.

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

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN (BPMN) es una notación gráfica que describe la lógica de los pasos de un proceso de Negocio. Esta notación ha sido especialmente diseñada para coordinar la secuencia de los procesos y los mensajes

Más detalles

O C T U B R E 2 0 1 3 SOPORTE CLIENTE. Manual de Usuario Versión 1. VERSIÓN 1 P á g i n a 1

O C T U B R E 2 0 1 3 SOPORTE CLIENTE. Manual de Usuario Versión 1. VERSIÓN 1 P á g i n a 1 SOPORTE CLIENTE Manual de Usuario Versión 1 VERSIÓN 1 P á g i n a 1 Contenido Contenido... 2 INTRODUCCIÓN... 3 DESCRIPCIÓN ACTIVIDADES... 4 1. INICIO... 4 2. REGISTRAR NUEVO CLIENTE... 5 1.1 INGRESO DE

Más detalles

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd

Maxpho Commerce 11. Gestión CSV. Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Maxpho Commerce 11 Gestión CSV Fecha: 20 Septiembre 2011 Versión : 1.1 Autor: Maxpho Ltd Índice general 1 - Introducción... 3 1.1 - El archivo CSV... 3 1.2 - Módulo CSV en Maxpho... 3 1.3 - Módulo CSV

Más detalles

Diseño orientado a los objetos

Diseño orientado a los objetos Diseño orientado a los objetos El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. A diferencia

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

IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS

IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS IDEA DE NEGOCIO EDUGER LOGISTIC GERMAN EDUARDO BALSERO MORALES PROFESOR: GERARDO ANDRES ARCOS CELIS CORPORACIÓN UNIVERSITARIA IBEROAMERICANA TECNOLOGIA EN LOGISTICA INFORMATICA BOGOTA D.C. 2013 INTRODUCCIÓN

Más detalles

Mesa de Ayuda Interna

Mesa de Ayuda Interna Mesa de Ayuda Interna Documento de Construcción Mesa de Ayuda Interna 1 Tabla de Contenido Proceso De Mesa De Ayuda Interna... 2 Diagrama Del Proceso... 3 Modelo De Datos... 4 Entidades Del Sistema...

Más detalles

INDICE. 1. Introducción... 4. 2. El panel Entities view... 5. 3. El panel grafico... 6. 4. Barra de botones... 6. 4.1. Botones de Behavior...

INDICE. 1. Introducción... 4. 2. El panel Entities view... 5. 3. El panel grafico... 6. 4. Barra de botones... 6. 4.1. Botones de Behavior... MANUAL DE USUARIO INDICE 1. Introducción... 4 2. El panel Entities view... 5 3. El panel grafico... 6 4. Barra de botones... 6 4.1. Botones de Behavior... 7 4.2. Botones de In-agents... 8 4.3. Botones

Más detalles

MANUAL DE PRACTICUM12 PARA CENTROS EDUCATIVOS ÁMBITO MÁSTER

MANUAL DE PRACTICUM12 PARA CENTROS EDUCATIVOS ÁMBITO MÁSTER MANUAL DE PRACTICUM12 PARA CENTROS EDUCATIVOS ÁMBITO MÁSTER Centros educativos de la Comunidad de Madrid que deseen ser centros de prácticas de los alumnos del Máster en Profesorado de ESO y Bachillerato,

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

Introducción. Metadatos

Introducción. Metadatos Introducción La red crece por momentos las necesidades que parecían cubiertas hace relativamente poco tiempo empiezan a quedarse obsoletas. Deben buscarse nuevas soluciones que dinamicen los sistemas de

Más detalles

Guía de instalación de la carpeta Datos de IslaWin

Guía de instalación de la carpeta Datos de IslaWin Guía de instalación de la carpeta Datos de IslaWin Para IslaWin Gestión CS, Classic o Pyme a partir de la revisión 7.00 (Revisión: 10/11/2011) Contenido Introducción... 3 Acerca de este documento... 3

Más detalles

Figura 4.1 Clasificación de los lenguajes de bases de datos

Figura 4.1 Clasificación de los lenguajes de bases de datos 1 Colección de Tesis Digitales Universidad de las Américas Puebla Romero Martínez, Modesto Este capítulo describen los distintos lenguajes para bases de datos, la forma en que se puede escribir un lenguaje

Más detalles

Adelacu Ltda. www.adelacu.com Fono +562-218-4749. Graballo+ Agosto de 2007. Graballo+ - Descripción funcional - 1 -

Adelacu Ltda. www.adelacu.com Fono +562-218-4749. Graballo+ Agosto de 2007. Graballo+ - Descripción funcional - 1 - Graballo+ Agosto de 2007-1 - Índice Índice...2 Introducción...3 Características...4 DESCRIPCIÓN GENERAL...4 COMPONENTES Y CARACTERÍSTICAS DE LA SOLUCIÓN...5 Recepción de requerimientos...5 Atención de

Más detalles

Introducción a la extensión de scripting en gvsig 2.0

Introducción a la extensión de scripting en gvsig 2.0 Introducción a la extensión de scripting en gvsig 2.0 2012 gvsig Association Este documento se distribuye con la licencia Creative Commons 1 2 Índice de contenido 1 Introducción... 3 Instalación de la

Más detalles

Gestión de Oportunidades

Gestión de Oportunidades Gestión de Oportunidades Bizagi Suite Gestión de Oportunidades 1 Tabla de Contenido CRM Gestión de Oportunidades de Negocio... 4 Elementos del Proceso... 5 Registrar Oportunidad... 5 Habilitar Alarma y

Más detalles

Introducción a Moodle

Introducción a Moodle Instituto la Américas de Nayarit Ing. Elías Portugal Luna Qué es Moodle? Moodle es una aplicación web de tipo Ambiente Educativo Virtual, un sistema de gestión de cursos, de distribución libre, que ayuda

Más detalles

QUE ES COMLINE MENSAJES? QUE TIPO DE MENSAJES PROCESA COMLINE MENSAJES?

QUE ES COMLINE MENSAJES? QUE TIPO DE MENSAJES PROCESA COMLINE MENSAJES? QUE ES COMLINE MENSAJES? Comline Mensajes es una plataforma flexible, ágil y oportuna, que permite el envío MASIVO de MENSAJES DE TEXTO (SMS). Comline Mensajes integra su tecnología a los centros de recepción

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

1.4.1.2. Resumen... 1.4.2. ÁREA DE FACTURACIÓN::INFORMES::Pedidos...27 1.4.2.1. Detalle... 1.4.2.2. Resumen... 1.4.3. ÁREA DE

1.4.1.2. Resumen... 1.4.2. ÁREA DE FACTURACIÓN::INFORMES::Pedidos...27 1.4.2.1. Detalle... 1.4.2.2. Resumen... 1.4.3. ÁREA DE MANUAL DE USUARIO DE ABANQ 1 Índice de contenido 1 ÁREA DE FACTURACIÓN......4 1.1 ÁREA DE FACTURACIÓN::PRINCIPAL...4 1.1.1. ÁREA DE FACTURACIÓN::PRINCIPAL::EMPRESA...4 1.1.1.1. ÁREA DE FACTURACIÓN::PRINCIPAL::EMPRESA::General...4

Más detalles

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS

MANUAL DE USUARIO APLICACIÓN SYSACTIVOS MANUAL DE USUARIO APLICACIÓN SYSACTIVOS Autor Edwar Orlando Amaya Diaz Analista de Desarrollo y Soporte Produce Sistemas y Soluciones Integradas S.A.S Versión 1.0 Fecha de Publicación 19 Diciembre 2014

Más detalles

CURSO COORDINADOR INNOVADOR

CURSO COORDINADOR INNOVADOR CURSO COORDINADOR INNOVADOR PRESENTACIÓN La tarea que el Ministerio de Educación se propone a través de Enlaces, en relación al aseguramiento del adecuado uso de los recursos, con el fin de lograr un impacto

Más detalles

MANUAL TRAMITACIÓN PROCEDIMIENTO

MANUAL TRAMITACIÓN PROCEDIMIENTO MANUAL TRAMITACIÓN PROCEDIMIENTO GESTIÓN ACADÉMICA: EXPEDICIÓN DE CERTIFICACIONES ACADÉMICAS Índice 1.- Introducción...3 2.- Esquema de tramitación...4 3.- Tramitación...5 Paso 1. Acceder al Escritorio

Más detalles

Descubra las novedades de EasyProf 3.0! Cambios en la filosofía de trabajo

Descubra las novedades de EasyProf 3.0! Cambios en la filosofía de trabajo Descubra las novedades de EasyProf 3.0! EasyProf 3.0 incorpora potentes mejoras y funcionalidades que le permitirá crear sus propios contenidos con mayor facilidad y rapidez. Con EasyProf 3.0 podrá crear

Más detalles

Seven ERP Guía De Referencia - Imágenes

Seven ERP Guía De Referencia - Imágenes Seven ERP Guía De Referencia - Imágenes Digital WARE Ltda. Calle 72 # 12-65 P.2 Bogotá, Colombia 2004 Digital Ware, Ltda. Todos Los Derechos Reservados Toda la documentación utilizada en Seven ERP está

Más detalles

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales

Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Metodología Orientada a Objetos Clave 43100007 Maestría en Sistemas Computacionales Modulo 03 UML: Vista de Casos de Uso Artefacto: Actores Catedrático MSC. Jose Juan Aviña Grimaldo e-mail josejuan_avina@gmail.com

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

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN

Hacer Realidad BPM en su Organización ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN ADOPTAR BPM A PARTIR DE UN PROYECTO O NECESIDAD DE AUTOMATIZACIÓN OBJETIVOS GENERALES 1. Identificar, diseñar, automatizar y habilitar la mejora continua de los procesos relacionados a la necesidad o proyecto

Más detalles

Guía Práctica para el Uso del Servicio de Software Zoho CRM

Guía Práctica para el Uso del Servicio de Software Zoho CRM Guía Práctica para el Uso del Servicio de Software Zoho CRM Parte 3 Administración de Roles y Perfiles Uso de la Funcionalidad de Cuentas Uso de la Funcionalidad de Contactos Desarrollado por Mind Andina

Más detalles

Funcionalidades Software PROYECTOS GotelGest.Net Software para la gestión de Proyectos GotelGest.Net

Funcionalidades Software PROYECTOS GotelGest.Net Software para la gestión de Proyectos GotelGest.Net 2012 Funcionalidades Software PROYECTOS GotelGest.Net Software para la gestión de Proyectos GotelGest.Net Servinet Sistemas y Comunicación S.L. www.softwaregestionproyectos.com Última Revisión: Febrero

Más detalles

Capítulo 1 Documentos HTML5

Capítulo 1 Documentos HTML5 Capítulo 1 Documentos HTML5 1.1 Componentes básicos HTML5 provee básicamente tres características: estructura, estilo y funcionalidad. Nunca fue declarado oficialmente pero, incluso cuando algunas APIs

Más detalles

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema

Capítulo 2. Planteamiento del problema. Capítulo 2 Planteamiento del problema Capítulo2 Planteamientodelproblema 38 2.1Antecedentesycontextodelproyecto En lo que respecta a los antecedentes del proyecto, se describe inicialmente el contexto donde se utiliza el producto de software.

Más detalles

Guía rápida de la Oficina Virtual (Solicit@V5) Área Web y Administración Electrónica

Guía rápida de la Oficina Virtual (Solicit@V5) Área Web y Administración Electrónica Guía rápida de la Oficina Virtual (Solicit@V5) Área Web y Administración Electrónica HOJA DE CONTROL Título Nombre del Fichero Autores Guía rápida de la Oficina Virtual (Solicit@V5) UHU_GuiaRapidaSolicita_V5.pdf

Más detalles

Guía Práctica para el Uso del Servicio de Software Zoho CRM

Guía Práctica para el Uso del Servicio de Software Zoho CRM Guía Práctica para el Uso del Servicio de Software Zoho CRM Parte 4 Modificación de las Listas Estándar del Sistema Modificación del Menú Principal del Sistema Importación de información al Sistema Adición

Más detalles

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología

Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología Ciclo de vida y Metodologías para el desarrollo de SW Definición de la metodología La metodología para el desarrollo de software es un modo sistemático de realizar, gestionar y administrar un proyecto

Más detalles

Guía de referencia para mytnt. mytnt. C.I.T Tecnología Aplicada al Cliente cit.es@tnt.com - 902111248

Guía de referencia para mytnt. mytnt. C.I.T Tecnología Aplicada al Cliente cit.es@tnt.com - 902111248 mytnt Índice A mytnt B Acceder a MyTNT por primera vez B.1 Registro en mytnt B.1.1 Registro en mytnt con cuenta TNT B.1.2 Registro en mytnt sin cuenta TNT C Menú principal de MyTNT 1 MODIFICAR CONFIGURACIÓN

Más detalles

Capítulo 9. Archivos de sintaxis

Capítulo 9. Archivos de sintaxis Capítulo 9 Archivos de sintaxis El SPSS permite generar y editar archivos de texto con sintaxis SPSS, es decir, archivos de texto con instrucciones de programación en un lenguaje propio del SPSS. Esta

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

MANUAL DE AYUDA MODULO TALLAS Y COLORES

MANUAL DE AYUDA MODULO TALLAS Y COLORES MANUAL DE AYUDA MODULO TALLAS Y COLORES Fecha última revisión: Enero 2010 Índice TALLAS Y COLORES... 3 1. Introducción... 3 CONFIGURACIÓN PARÁMETROS TC (Tallas y Colores)... 3 2. Módulos Visibles... 3

Más detalles

Tabla de contenido. Avenida El Dorado Nº 70 16 Bogotá Colombia T +57 1 4270999 T +57 1 4254700 www.logyca.com

Tabla de contenido. Avenida El Dorado Nº 70 16 Bogotá Colombia T +57 1 4270999 T +57 1 4254700 www.logyca.com Tabla de contenido Tabla de contenido... 1 Introducción... 2 1. Inicio... 3 2. Ventas e Inventarios... 4 2.1 Empresas... 4 2.2 Descargas Programadas... 5 3. Reportes... 17 3.1 Reporte de Mercados... 17

Más detalles

CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA. BizAgi Process Modeler

CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA. BizAgi Process Modeler CONSTRUCCIÓN DEL PROCESO MESA DE AYUDA INTERNA BizAgi Process Modeler TABLA DE CONTENIDO PROCESO DE MESA DE AYUDA INTERNA... 3 1. DIAGRAMA DEL PROCESO... 4 2. MODELO DE DATOS... 5 ENTIDADES DEL SISTEMA...

Más detalles

PRESENTACIÓN DEL PRODUCTO

PRESENTACIÓN DEL PRODUCTO PRESENTACIÓN DEL PRODUCTO esernet, s.l. Sebastián Elcano, 32 Planta 1 Oficina 22 28012 Madrid Teléfono: 91 433 84 38 -- Fax. 91 141 21 89 www.esernet.com -- esernet@esernet.com 1. Introducción 2. Descripción

Más detalles

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008

Estándares para planes de calidad de software. Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 Estándares para planes de calidad de software Escuela de Ingeniería de Sistemas y Computación Desarrollo de Software II Agosto Diciembre 2008 DIFERENCIA ENTRE PRODUCIR UNA FUNCION Y PRODUCIR UNA FUNCION

Más detalles

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual

Introducción. Ciclo de vida de los Sistemas de Información. Diseño Conceptual Introducción Algunas de las personas que trabajan con SGBD relacionales parecen preguntarse porqué deberían preocuparse del diseño de las bases de datos que utilizan. Después de todo, la mayoría de los

Más detalles

Análisis y diseño del sistema CAPÍTULO 3

Análisis y diseño del sistema CAPÍTULO 3 Análisis y diseño del sistema CAPÍTULO 3 36 CAPÍTULO 3 Análisis y diseño del sistema En este capítulo se pretende realizar un análisis detallado de los requerimientos del software a desarrollar para la

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

Apéndice 5 Manual de usuario de ColeXión. ColeXión 1.0. Manual de usuario

Apéndice 5 Manual de usuario de ColeXión. ColeXión 1.0. Manual de usuario Apéndice 5 Manual de usuario de ColeXión ColeXión 1.0 Manual de usuario Índice 1. Qué es ColeXión?... 2 2. Requerimientos del sistema... 3 3. Instalación de ColeXión... 3 4. Creación de un nuevo esquema...

Más detalles

1 ÍNDICE... 3 Instalación... 4 Proceso de instalación en red... 6 Solicitud de Código de Activación... 11 Activación de Licencia... 14 2 3 REQUERIMIENTOS TÉCNICOS E INSTALACIÓN Requerimientos Técnicos

Más detalles

UAM MANUAL DE EMPRESA. Universidad Autónoma de Madrid

UAM MANUAL DE EMPRESA. Universidad Autónoma de Madrid MANUAL DE EMPRESA Modo de entrar en ÍCARO Para comenzar a subir una oferta de empleo, el acceso es a través del siguiente enlace: http://icaro.uam.es A continuación, aparecerá la página de inicio de la

Más detalles

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable

Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable Capítulo 3 Diseño del Sistema de Administración de Información de Bajo Costo para un Negocio Franquiciable 1. Introducción. El Sistema de Administración de Información de un Negocio Franquiciable (SAINF)

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

MANUAL DE AYUDA HERRAMIENTA DE APROVISIONAMIENTO

MANUAL DE AYUDA HERRAMIENTA DE APROVISIONAMIENTO MANUAL DE AYUDA HERRAMIENTA DE APROVISIONAMIENTO Fecha última revisión: Junio 2011 INDICE DE CONTENIDOS HERRAMIENTA DE APROVISIONAMIENTO... 3 1. QUÉ ES LA HERRAMIENTA DE APROVISIONAMIENTO... 3 HERRAMIENTA

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

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

CMMI (Capability Maturity Model Integrated)

CMMI (Capability Maturity Model Integrated) CMMI (Capability Maturity Model Integrated) El SEI (software engineering institute) a mediados de los 80 desarrolló el CMM (modelo de madurez de la capacidad de software). CMMI: CMM integrado, una mezcla

Más detalles

MEDIA KIT TRAFFICFACTORY.BIZ

MEDIA KIT TRAFFICFACTORY.BIZ ES MEDIA KIT Alcance a millones de usuarios Nuestra red le conecta con millones de visitantes únicos, incluyendo a muchos que no encontrará en ningún otro lugar. TrafficFactory es una agencia de publicidad

Más detalles

Capítulo 6. Desarrollo del Software

Capítulo 6. Desarrollo del Software Capítulo 6. Desarrollo del Software Introducción El objetivo principal de la presente tesis como su título lo describe, es la animación de las tramas de comunicación principales de WCDMA. Para lograr dicho

Más detalles

Visión General GXflow. Última actualización: 2009

Visión General GXflow. Última actualización: 2009 Última actualización: 2009 Copyright Artech Consultores S. R. L. 1988-2009. Todos los derechos reservados. Este documento no puede ser reproducido en cualquier medio sin el consentimiento explícito de

Más detalles

INGRESAR CON NÚMERO DE DOCUMENTO Y CONTRASEÑA

INGRESAR CON NÚMERO DE DOCUMENTO Y CONTRASEÑA INGRESAR CON NÚMERO DE DOCUMENTO Y CONTRASEÑA ROL PAQUETES FUNCIONALES QUE SE ACTIVAN AL ROL DE APRENDIZ ROL: APRENDIZ PAQUETE: REGISTRO ESTAS SON LAS OPCIONES QUE TIENE UN APRENDIZ EN LA PARTE DE REGISTRO.

Más detalles

Conceptos Generales en Joomla 1.7.2.

Conceptos Generales en Joomla 1.7.2. 1.- Tipos de usuarios en Joomla! JOOMLA 1.7 USUARIOS. Los usuarios de sitios web de Joomla! pueden dividirse en dos categorías principales: Invitados. Usuarios registrados. Los Invitados son sencillamente

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

CONVERSOR LIBROS DE REGISTRO (IVA IGIC) Agencia Tributaria DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA

CONVERSOR LIBROS DE REGISTRO (IVA IGIC) Agencia Tributaria DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA CONVERSOR LIBROS DE REGISTRO (IVA IGIC) Agencia Tributaria DEPARTAMENTO DE INFORMÁTICA TRIBUTARIA ÍNDICE DEL DOCUMENTO 1. INTRODUCCIÓN...2 1.1. REQUISITOS TÉCNICOS...2 2. DECLARACIONES...3 2.1. CREAR UNA

Más detalles

PANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet. Revisión 1.1 Fecha 2006-08

PANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet. Revisión 1.1 Fecha 2006-08 PANEL DE CONTROL (Zona de Administración) MANUAL DE USO Por conexanet Revisión 1.1 Fecha 2006-08 Índice 1. Acceder 2. Menú 3. Gestión Básica 3.1 Añadir 3.2 Editar 3.3 Eliminar 3.4 Eliminación de registros

Más detalles

Poder Judicial de Costa Rica

Poder Judicial de Costa Rica Poder Judicial de Costa Rica Sistema de Gestión en línea Versión 3.2.0.0 Manual de Usuario PODER JUDICIAL Autor: Dep. Tecnología de la Información Tabla de contenido Sistema de Gestión en Línea, Consulta

Más detalles

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON)

3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1 INGENIERIA DE SOFTWARE ORIENTADO A OBJETOS OOSE (IVAR JACOBSON) 3.1.1 Introducción Este método proporciona un soporte para el diseño creativo de productos de software, inclusive a escala industrial.

Más detalles

ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009)

ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009) JOOMLA! ÍTEMS DEL MENÚ CREACIÓN Y GESTIÓN (Última revisión: lunes, 9 de marzo de 2009) Es necesario comentar que este manual ha sido diseñado en su mayor parte por comunidadjoomla.org. Este manual es una

Más detalles

App para realizar consultas al Sistema de Información Estadística de Castilla y León

App para realizar consultas al Sistema de Información Estadística de Castilla y León App para realizar consultas al Sistema de Información Estadística de Castilla y León Jesús M. Rodríguez Rodríguez rodrodje@jcyl.es Dirección General de Presupuestos y Estadística Consejería de Hacienda

Más detalles

MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn

MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn MANUAL DE USUARIO CMS- PLONE www.trabajo.gob.hn Tegucigalpa M. D. C., Junio de 2009 Que es un CMS Un sistema de administración de contenido (CMS por sus siglas en ingles) es un programa para organizar

Más detalles