Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación

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

Download "Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación"

Transcripción

1 Modelos de Decisión Como Mecanismo de Composición de Reglas de Transformación Andres Romero y Hugo Arboleda Universidad de Los Andes, Cra. 1 N 18A 10, Bogotá, Colombia Resumen El proceso de derivación de productos en las Líneas de Productos de Software Dirigidas por Modelos (MD-SPL) se basa en reglas de transformación que permiten transformar un modelo del dominio origen en un modelo del dominio destino. Para derivar un producto de la línea, se debe ejecutar un conjunto de reglas de transformación en un orden específico. Tanto las reglas de transformación como su orden de ejecución, dependen de los variantes seleccionados en la configuración del producto que se quiere derivar. La mayoría de propuestas al proceso de derivación acoplan los variantes con las reglas de transformación, lo que genera problemas de mantenibilidad y evolución. En este artículo se propone un modelo de decisión como mecanismo de composición de reglas de transformación. Este modelo relaciona variantes con reglas de transformación, especificando el conjunto y orden de reglas de transformación que deben ser ejecutadas para derivar un producto dada su configuración. El modelo de decisión propuesto es independiente de un lenguaje de transformación particular lo que permite expresar de manera general la estrategia de composición de reglas de transformación. Key words: Líneas de Productos de Software, Desarrollo Dirigido por Modelos, Modelos de Decisión, Composición de reglas de transformación. 1. Introducción Las Líneas de Productos de Software Dirigidas por Modelos (MD-SPL) son un enfoque de desarrollo de software que combina las ventajas del desarrollo dirigido por modelos y la ingeniería de líneas de productos de software. En las MD-SPL los productos son creados a partir de la reutilización de activos base [1], entre los cuales se encuentran los modelos y reglas de transformación. Las líneas de productos tienen variantes, los cuales definen las posibles características que pueden tener los productos de la línea. En consecuencia, los activos base que componen la línea son personalizados y configurados de acuerdo con variantes seleccionados de una configuración, que define un producto particular de la línea [2]. El proceso de derivación de productos en las MD-SPL se realiza de manera incremental; se parte de un modelo inicial que es transformado a cada uno de los dominios que componen el sistema; al final, un modelo representando el dominio del lenguaje de programación es transformado a texto, i.e., al lenguaje de

2 2 Romero et al. programación correspondiente. Cada uno de estos dominios es descrito por un metamodelo y representa una preocupación del sistema: arquitectura, plataforma, lenguaje, etc. La transformación entre modelos se realiza a través de reglas de transformación, que toman elementos del dominio origen y los transforman en elementos del dominio destino. Los mecanismos de composición de reglas de transformación tienen como objetivo especificar el conjunto y orden de reglas de transformación que derivan un producto para una configuración en particular. Aproximaciones a la composición de reglas de transformación (e.g. [3,4,5]) se centran en el uso de funcionalidades específicas que proveen los lenguajes de transformación. Lo anterior conlleva a problemas de portabilidad de las estrategias de composición de un lenguaje de transformación a otro; limitando la composición de reglas de transformación al conjunto de funcionalidades que puede procesar cada motor de transformación. En este artículo se propone el uso de un modelo de decisión como mecanismo de soporte para la composición de reglas de transformación. Nuestro modelo de decisión relaciona variantes con reglas de transformación, especificando el conjunto y orden de ejecución de reglas de transformación que deben ser aplicadas en la derivación de un producto, dependiendo de los variantes seleccionados en la configuración. El modelo de decisión representa a alto nivel la composición de reglas de transformación, sin incluir detalles específicos de funcionalidades que ofrecen los lenguajes de transformación. Esta representación por ser abstracta no puede ejecutarse directamente sobre un motor de transformación, en consecuencia, se debe transformar el modelo de decisión a estrategias de composición concretas sobre los lenguajes de transformación, las cuales pueden ser ejecutadas sobre un motor de transformación en particular. A modo de ejemplo presentamos el uso del modelo de decisión sobre los lenguajes de transformación Xtend [6] y ATL [7], los cuales presentan estrategias de composición diferentes. Este artículo se encuentra organizado de la siguiente manera, el capitulo 2 explica los conceptos de los modelos de decisión y las aproximaciones relacionadas con la composición de reglas de transformación. El capitulo 3 introduce un caso de estudio que servirá para explicar la estrategia de solución. En el capítulo 4 se explica la estrategia de solución propuesta, se explica el uso de los modelos de decisión y el proceso de derivación de productos mediante el uso de este mecanismo. El capítulo 5 muestra cómo el modelo de decisión puede ser transformado a estrategias concretas de composición sobre dos lenguajes de transformación diferentes: Xtend y ATL. Por último, el capítulo 6 presenta conclusiones y trabajo futuro. 2. Contexto A continuación se realizará una breve descripción de los modelos de decisión, resumiendo sus principales conceptos. Los modelos de decisión serán utilizados para componer reglas de transformación, expresando esta composición de manera independiente de la plataforma. Adicionalmente, exploraremos los conceptos y

3 Modelos de Decisión como Estrategia de Composición 3 aproximaciones a la composición de reglas de transformación, que ayudaran a ejemplificar los problemas propuestos en este artículo Modelos de decisión Los modelos de decisión son modelos que capturan la variabilidad de una línea de productos en términos de decisiones abiertas y posibles resoluciones [8]. Las decisiones son puntos que requieren de la intervención de un usuario durante el proceso de derivación, para personalizar los activos de un producto. Estas decisiones se encuentran dadas en términos de los variantes de la línea. Las resoluciones son las opciones que se tienen como solución a una decisión, estas resoluciones tienen efectos, que indican las acciones específicas que se deben realizar para configurar un activo. Los modelos de decisión reducen la brecha que existe entre la variabilidad a nivel conceptual y la variabilidad a nivel de implementación. Esto se logra a través de la relación de variantes con elementos concretos de configuración de activos, en nuestro caso reglas de transformación. Los modelos de decisión han sido ampliamente usados en las líneas de producto [9,4,10], guiando el proceso de derivación de productos Composición de reglas de transformación La composición de reglas de transformación consiste en agrupar y ordenar conjuntos de reglas de transformación permitiendo derivar un producto específico de la línea, dependiendo de los variantes que han sido seleccionados en una configuración. Diferentes enfoques para componer reglas de transformación buscan mejorar el proceso de derivación de productos mediante aportes en mantenibilidad, escalabilidad y reusabilidad de las reglas de transformación (e.g. [3,5,4]). Wagelaar [3] clasifica los métodos de composición de reglas de transformación en dos clases: métodos de composición interna y métodos de composición externa. La composición interna permite componer dos reglas de transformación en una nueva regla de transformación. La composición externa encadena una secuencia de reglas de transformación, usando los modelos de salida de una regla de transformación como modelos de entrada para otra regla de transformación. Oldevik [5] propone los diagramas de actividades de UML2 como un método de composición externa de reglas de transformación. En estos diagramas, las actividades representan las transformaciones que deben llevarse a cabo para derivar un producto. Estas actividades se encuentran anotadas mediante estereotipos, representando de este modo el tipo de transformación que se debe realizar (i.e. modelo a modelo, modelo a texto, etc.). En esta aproximación un producto es derivado mediante la ejecución de las actividades que componen el flujo, en donde cada actividad recibe un modelo de entrada y genera un modelo de salida. Esta aproximación no ofrece mecanismos de composición interna, los cuales son útiles para configurar activos de acuerdo con variantes seleccionados en una configuración.

4 4 Romero et al. Wagelaar [3] propone un método de composición interna de reglas de transformación escritas en ATL (ATLAS Transformation Language) [7] llamado superimposición de módulos. Un módulo de transformación es una agrupación de reglas de transformación que transforman un modelo de un dominio a otro. En esta aproximación las reglas de transformación de un módulo son sobre impuestas por reglas de transformación de otro módulo. El resultado de la superimposición es un nuevo módulo de transformación, que contiene la unión de reglas de transformación de los módulos sobre impuestos. En caso que existan reglas de transformación con el mismo nombre entre los módulos a sobre imponer, se realiza un proceso de sobre escritura, en donde el contenido de la regla original es cambiado por el contenido de la regla sobre impuesta. Esta propuesta de composición de reglas de transformación no ofrece mecanismos de composición externa y tampoco especifica cómo es el proceso de derivación de un producto de la línea a través de la sobre imposición de módulos, dependiendo de los variantes seleccionados en una configuración. Groher y Voelter [6] proponen el uso de aspectos en el desarrollo de las líneas de productos orientadas por modelos. De este modo los aspectos interceptan llamados a reglas de transformación y adicionan comportamiento. Estos aspectos se relacionan con variantes, condicionando el entretejido de los aspectos al estado de los variantes en la configuración a derivar. Arboleda y Colegas [4] proponen modelos de decisión como método de composición interna y externa para reglas de transformación, escritas en los lenguajes de transformación Xtend y Xpand de oaw (openarchitectureware) [11]. La composición interna se realiza usando los aspectos propuestos por Groher y Voelter. Adicionalmente, el modelo de decisión especifica la secuencia de modelos de transformación que deben ser ejecutados para derivar un producto, la salida de un modelo de transformación es pasada como entrada al siguiente modelo de transformación. La propuesta de Arboleda y Colegas a diferencia de las anteriores, permite componer reglas de transformación a nivel externo e interno, sin embargo su estrategia de composición se basa en funcionalidades específicas de los lenguajes de transformación de oaw. Lo cual implica que la estrategia de composición no pueda ser utilizada en otros lenguajes de transformación diferentes como por ejemplo ATL. Las anteriores aproximaciones a la composición de reglas de transformación presentan propuestas de composición diferentes, algunas utilizan aspectos, otras sobre escriben reglas de transformación, etc. Esto se debe a que los métodos de composición se encuentran limitados a las funcionalidades de cada uno de los lenguajes de transformación. En consecuencia es difícil migrar la estrategia de composición entre lenguajes de transformación, puesto que, las estrategias de composición están dadas en términos de funcionalidades específicas de los lenguajes de transformación. El modelo de decisión propuesto en este artículo es una generalización del trabajo realizado en [4], en el que se busca expresar de manera general un método de composición que no acople las reglas de transformación con variantes y que pueda ser utilizado sobre cualquier lenguaje de reglas de transformación.

5 3. Ejemplo Ilustrativo Modelos de Decisión como Estrategia de Composición 5 A modo de ejemplo ilustrativo introduciremos el caso de estudio del administrador de colecciones [4], el cual es una línea de productos basada en los principios de la ingeniería dirigida por modelos (MDE). Esta línea de productos permite derivar productos que manejan colecciones de entidades. Un producto (Figura 1 (a)) que se puede derivar de esta línea puede ser un colegio que administra colecciones de estudiantes, los cuales tienen un código, nombre, dirección y correo. Otro producto que se podría derivar de esta línea puede ser una tienda de discos (Figura 1 (b)) que administra colecciones de discos de música, los cuales pueden tener un nombre, artista, género y fecha de lanzamiento. Figura 1. Ejemplos de productos derivados de la línea de productos del administrador de colecciones. La línea de productos del administrador de colecciones tiene varios puntos de variación, permitiendo derivar productos con características particulares. Los puntos de variación definen características puntuales del producto que pueden variar, las posibles opciones que puede tomar un punto de variación son llamadas variantes. Por ejemplo el caso de estudio del administrador de colecciones tiene un punto de variación para el tipo de vista de información, la cual muestra la información de las entidades de la colección. Este punto de variación tiene dos variantes (Single y Grid) que definen el tipo de vista de información. Una vista de información de tipo Single (Figura 1 (a)) muestra la información de una sola

6 6 Romero et al. entidad. La vista de información de tipo Grid (Figura 1 (b)) muestra en una tabla la información de todas las entidades que tiene la colección. En esta línea de productos utilizamos tres metamodelos para representar los dominios del sistema. El metamodelo del espacio del problema (ProblemSpaceMetamodel) representa el dominio de negocio y permite especificar la entidad que va a ser administrada. El metamodelo del núcleo (KernelMetamodel) representa a bajo nivel la entidad a administrar y las operaciones que se pueden llevar a cabo sobre el administrador de colecciones. El metamodelo de interfaz gráfica de usuario (GuiMetamodel) representa las vistas con las que podrá interactuar un usuario para realizar operaciones sobre el sistema. Figura 2. Proceso de derivación en el caso de estudio del administrador de colleciones. La Figura 2 presenta de manera general el proceso de derivación en la línea de productos del administrador de colecciones. El proceso de derivación se realiza de manera incremental partiendo de un modelo del espacio del problema (ProblemSpaceModel). A este modelo se le aplican dos transformaciones de modelo a modelo. Una para convertir el modelo del espacio del problema a modelo del núcleo (KernelModel) y la otra para convertirlo a modelo de interfaz gráfica de usuario (GuiModel). A cada uno de estos modelos generados ( KernelModel, GuiModel ) se le aplica una transformación de modelo a texto, generando de este modo el código fuente del producto. La transformación del modelo del espacio del problema al modelo de interfaz gráfica se encuentra compuesto por cuatro reglas de transformación: ps2gui, createinformationview, creategridinformationview y createsingleinformationview. La regla de transformación ps2gui transforma los elementos del modelo del espacio del problema a elementos del modelo de interfaz gráfica. La regla de transformación createinformationview crea la vista de información en el modelo GUI, esta vista muestra la información de las entidades en la colección. La regla de transformación creategridinformationview

7 Modelos de Decisión como Estrategia de Composición 7 crea una vista de información, en donde la información de todas las entidades de la colección es mostrada mediante una tabla. La regla de transformación createsingleinformationview crea una vista de información en la cual se muestra la información de una entidad. La ejecución de las reglas de transformación que crean los elementos variables de la línea depende de los variantes seleccionados en la configuración por derivar. Por ejemplo, la regla de transformación createsingleinformationview será aplicada en el proceso de transformación solo si el variante Single se encuentra seleccionado en la configuración. Esto mismo sucede con la regla de transformación creategridinformationview, cuya ejecución depende de la selección del variante Grid. 4. Estrategia Global de solución Nuestro modelo de decisión permite componer reglas de transformación a nivel externo e interno, especificando el conjunto y orden de reglas de transformación que deben ser aplicadas para derivar un producto particular de la línea. Este modelo de decisión por ser una abstracción no puede ser ejecutado por un motor de transformación. Sin embargo se pueden definir transformaciones entre el modelo de decisión y estrategias concretas de composición en los lenguajes de transformación, las cuales pueden ser ejecutados por su respectivo motor de transformación. Figura 3. Composición externa por el modelo de decisión. A nivel de composición externa de reglas de transformación el modelo de decisión propuesto permite definir la secuencia de transformaciones que deben aplicarse para derivar un producto de manera incremental. Para cada una de estas transformaciones se puede especificar sus modelos de entrada y salida; los modelos de salida pueden ser utilizados como modelos de entrada para otras

8 8 Romero et al. transformaciones. La Figura 3 presenta un ejemplo de composición externa de reglas de transformación para el caso de estudio del administrador de colecciones (ejemplo ilustrado en la sección anterior). Este ejemplo muestra dos transformaciones: problemspace2gui (transformación de modelo a modelo) y gui2code (transformación de modelo a texto). La primera transformación que se aplica en este ejemplo es problemspace2gui, la cual transforma un modelo del espacio del problema a un modelo GUI, el cual representa La interfaz gráfica con la que interactúa el usuario. La siguiente transformación en ejecutarse es gui2code, la cual recibe el modelo GUI que fue generado por la transformación anterior y convierte este modelo a código fuente. Figura 4. Composición interna por el modelo de decisión. A nivel de composición interna de reglas de transformación, nuestro modelo de decisión permite especificar las reglas de transformación que deben componerse dependiendo del estado de los variantes en la configuración a derivar. La Figura 4 presenta un ejemplo de composición interna para el caso de estudio del administrador de colecciones. En este ejemplo el grupo de transformaciones TransformProblemSpace2gui se encuentra compuesto por dos reglas de transformación: ps2gui y createinformationview. La regla de transformación ps2gui se encarga de transformar un modelo del espacio del problema a un modelo de interfaz gráfica de usuario, adicionalmente, esta regla utiliza la regla de transformación createinformationview para crear la vista de información del sistema. Dado que la vista de información puede variar entre Single y Grid se deben realizar dos procesos de composición de reglas de transformación dependiendo de los variantes seleccionados en la configuración. Por ejemplo, si el variante Grid

9 Modelos de Decisión como Estrategia de Composición 9 se encuentra seleccionado, entonces se deben componer las reglas de transformación del grupo GridViewModule con las reglas de transformación del grupo TransformProblemSpace2gui. Como resultado de la composición de estos dos grupos de reglas de transformación se debe aplicar en algún punto la regla de transformación creategridinformationview, la cual crea una vista de información de tipo Grid Metamodelo de Decisión Hemos creado un metamodelo para guiar la creación de los modelos de decisión, que representa los conceptos de composición interna y externa que deben realizarse para derivar un producto de la línea. La Figura 5 presenta el metamodelo de decisión propuesto. Figura 5. Metamodelo de decisión. Un Modelo de decisión se encuentra compuestos por varios modelos de transformación, los cuales representan las transformaciones entre modelos que deben realizarse en el proceso de derivación de un producto. Los modelos de transformación pueden ser de dos tipos: transformación de modelo a modelo ó transformación de modelo a texto. Las transformaciones de modelo de modelo reciben un modelo de entrada y generan un modelo de salida. Las transformaciones de modelo a texto reciben un modelo de entrada y generan texto a partir de este modelo. El orden en que son aplicados estos modelos de transformación se encuentra definido por las relaciones first (primer modelo de transformación en aplicarse) y next (siguiente modelo de transformación en aplicarse). Para cada modelo de transformación se definen sus modelos de entrada y salida, los modelos de salida son creados por transformaciones de modelo a modelo y pueden ser utilizados como modelos de entrada para otros modelos de transformación.

10 10 Romero et al. Los conceptos descritos anteriormente son utilizados para representar los mecanismos de composición externa. En el ejemplo presentado en la Figura 3 se observan dos modelos de transformación, uno de modelo a modelo (problemspace2gui) y otro de modelo a texto (gui2code). El modelo de transformación problemspace2gui recibe como entrada un modelo llamado problemspacemodel y genera un modelo guimodel, el cual es pasado como entrada al modelo de transformación gui2code. El orden de estos modelos es definido por las relaciones first y next. Nuestros modelos de transformación se encuentran compuestos por módulos de transformación, los cuales son agrupaciones de reglas de transformación. Cada modelo de transformación tiene un módulo principal y varios módulos variables. El modulo principal siempre se aplica en la derivación de un producto y tiene la responsabilidad de crear los elementos comunes de la línea. Los módulos variables crean los elementos variables y se relacionan con el módulo principal. Los módulos variables tienen asociada una condición de ejecución expresada en términos de los estados (seleccionado, no seleccionado) de los variantes de la línea y determina si el modulo variable va a estar relacionado con su módulo principal. De este modo si la condición de ejecución se resuelve de manera verdadera, las reglas de transformación del módulo variable se relacionaran con las reglas de transformación del módulo principal. En el método de composición interno no se especifica si las reglas de transformación del módulo variable reemplazan o complementan las reglas de transformación del modulo principal. Esta decisión depende de cómo hayan sido diseñadas las reglas de transformación y de las funcionalidades específicas del lenguaje de transformación que se utilice. Los conceptos módulo de transformación y condición de ejecución son utilizados para representar el mecanismo de composición interna en el modelo de decisión. En la figura Figura 4 presentamos un ejemplo de composición interna, para este ejemplo el modelo de transformación problemspace2gui tiene un módulo principal (TransformProblemSpace2gui) y dos módulos variables (GridViewModule y singleviewmodule). Estos módulos variables se encuentran relacionados con el módulo principal. La composición interna de reglas de transformación se realizará siempre y cuando se cumpla la condición de ejecución que tiene asociada cada módulo variable, por ejemplo, en caso que el variante Grid se encuentre seleccionado en la configuración, la condición de ejecución que tiene asociada el módulo variable GridViewModule se resolverá de manera verdadera, lo cual implica que se deben componer las reglas de transformación del módulo principal TransformProblemSpace2gui con las reglas de transformación del módulo variable GridViewModule. 5. Modelo de Decisión sobre Lenguajes de transformación específicos 5.1. Modelo de decisión en OAW oaw (openarchitectureware) [11] es un framework Java para construir aplicaciones utilizando el enfoque de desarrollo de software dirigido por modelos.

11 Modelos de Decisión como Estrategia de Composición 11 Este framework expone una serie de lenguajes y herramientas que permiten: validar modelos, transformar modelos a modelos, transformar modelos a texto, entre muchas otras funcionalidades. Figura 6. Proceso de derivación en OAW La Figura 6 presenta la estrategia general de derivación en este framework usando nuestro modelo de decisión. El modelo de decisión es transformado a un Workflow de oaw el cual define la secuencia de actividades que deben llevarse a cabo para derivar un producto, por ejemplo: cargar modelos, ejecutar reglas de transformación, serializar modelos, etc. Dadas las funcionalidades que ofrecen los workflow, se pueden derivar productos especificando la configuración de estos. Los lenguajes de transformación de oaw soportan aspectos, de este modo se pueden definir reglas de transformación que interceptan otras reglas de transformación. La composición interna de reglas de transformación puede ser definida a través de estos aspectos, de esta manera las reglas de transformación crean los elementos comunes y son interceptadas por aspectos que crean los elementos variables de la línea. La ejecución de estos aspectos depende del estado de los variantes en la configuración a derivar. La estrategia de derivación concreta que se utiliza en este framework a través de modelos de decisión se describe detalladamente en [4]. La Figura 7 presenta el metamodelo de workflows de oaw, que definimos para realizar la transformación del modelo de decisión a representaciones concretas sobre este framework. El proceso de transformación se resume a continuación: Los modelos de transformación junto con sus módulos principales son transformados a componentes invokerule, encargados de invocar reglas de transformación, las cuales pueden ser de tipo modelo de a modelo (M2MTransformation) ó modelo a texto (M2TTransformation). Los módulos variables junto con sus condiciones de ejecución son transformados a componentes ExecuteAspect los cuales se encargan de especificar los aspectos que se ejecutan dependiendo de los variantes seleccionados en la configuración. El elemento Configuration del modelo de decisión se transforma a un elemento LoadConfiguration en el modelo de workflow, especificando la configuración que debe ser cargada para la derivación del producto.

12 12 Romero et al. Figura 7. Metamodelo Workflow de OAW 5.2. Modelo de decisión en ATL En ATL, el proceso de composición y derivación de productos es diferente. El modelo de decisión es transformado a un script ANT [12] dependiendo de la configuración que se desee derivar. Este script ANT tiene una serie de tareas AM3 (ATLAS MegaModel Management) [13], las cuales permiten ejecutar operaciones relacionadas con modelos, por ejemplo: cargar un modelo, invocar reglas de transformación, entre otras. El script de ANT generado contiene las operaciones que deben llevar a cabo para derivar un producto un producto específico. Este proceso de derivación puede observarse en la Figura 8. Figura 8. Proceso de derivación en ATL En ATL la composición externa se realiza a través de las actividades descritas en al archivo ANT, en donde se especifican los modelos de transformación que deben ejecutarse para derivar un producto. La composición interna se realiza mediante la superimposición de módulos, estrategia planteada por Wagelaar en [3]. De este modo las reglas de transformación de un módulo serán reemplazadas por reglas de transformación del módulo sobre impuesto. Esta estrategia de derivación de productos utilizando nuestro modelo de decisión es descrita en más detalle en [14].

13 Modelos de Decisión como Estrategia de Composición 13 Figura 9. Metamodelo ANT La Figura 9 muestra una versión simplificada del metamodelo ANT que se propone en [14]. El modelo de decisión es transformado a un modelo conforme a este metamodelo dependiendo de los variantes que se encuentren seleccionados en la configuración a derivar. Los modelos de transformación junto con su módulo principal pertenecientes al modelo de decisión, son transformados a tareas AM3ATL, las cuales permiten invocar reglas de transformación escritas en ATL. Los módulos variables que serán aplicados en el proceso de derivación son transformados a tareas AM3Superimpose, las cuales representan los módulos que serán sobre impuestos a las reglas de transformación AM3ATL. 6. Conclusiones y Trabajo Futuro En este artículo hemos presentado un modelo de decisión como mecanismo de composición de reglas de transformación. El modelo de decisión propuesto facilita la composición externa e interna de reglas de transformación, determinando el conjunto y orden de reglas de transformación que deben ser aplicadas para derivar un producto específico de la línea, de acuerdo de variantes seleccionados en configuraciones. Los modelos de decisión se expresan en términos de conceptos del dominio de composición de reglas de transformación. De este modo, no se tiene en cuenta funcionalidades específicas de los lenguajes de transformación para expresar composición de reglas de transformación. En consecuencia, Las estrategias de composición que se definan con nuestro modelo de decisión pueden ser llevadas a estrategias de composición concretas sobre cada lenguaje de transformación a través de transformaciones, tal y como se ejemplifico para oaw y ATL. Sin embargo, es necesario explorar cómo integrar los modelos de decisión sobre otros lenguajes de transformación como QVT [15], VIATRA [16], etc. Antes se debía expresar una estrategia de composición diferente por cada lenguaje de transformación, lo cual implicaba problemas de portabilidad para la estrategia de composición formulada. Ahora con el uso de los modelos de

14 14 Romero et al. decisión, la estrategia de composición de reglas de transformación se expresa de manera abstracta, y a través de transformaciones se puede obtener de manera automática la estrategia de composición concreta sobre cualquier lenguaje de transformación que se desee. De este modo, nuestro modelo de decisión facilita la portabilidad de las estrategias de composición permitiendo llevar la solución de composición de un lenguaje de transformación a otro. Para trabajo futuro exploraremos las transformaciones que deban realizarse para integrar otros lenguajes de transformación con nuestro modelo de decisión. También trabajaremos en mecanismos de composición de reglas de transformación, cuando existen restricciones entre los variantes de una línea de productos. Por ejemplo, la selección simultánea de dos variantes en una configuración podría implicar una composición de reglas de transformación diferente a la composición de reglas de transformación que se realiza si un solo variante esta seleccionado. Referencias 1. Bosch, J.: Design and use of software architectures: adopting and evolving a product-line approach. ACM Press/Addison-Wesley Publishing Co., New York, NY, USA (2000) 2. Czarnecki, K., Antkiewicz, M.: Mapping features to models: A template approach based on superimposed variants. In Glück, R., Lowry, M.R., eds.: GPCE. Volume 3676 of Lecture Notes in Computer Science., Springer (2005) Wagelaar, D.: Composition techniques for rule-based model transformation languages. In: First International Conference on Theory and Practice of Model Transformations (ICMT). (2008) 4. Arboleda, H., Romero, A., Casallas, R., Royer, J.: Product derivation in a modeldriven software product line using decision models. In: Proceedings of the 12th Iberoamerican Conference on Requirements Engineering and Software Environments, ideas, Medellín, Colombia (April, 2009) 5. Oldevik, J.: Transformation composition modelling framework. (2005) 6. Groher, I., Voelter, M.: Aspect-oriented model-driven software product line engineering. (2008) 7. Jouault, F., Kurtev, I.: Transforming models with atl. In Bruel, J.M., ed.: MoDELS Satellite Events. Volume 3844 of Lecture Notes in Computer Science., Springer (2005) Forster, T., Muthig, D., Pech, D.: Understanding decision models visualization and complexity reduction of software variability. In Heymans, P., Kang, K.C., Metzger, A., Pohl, K., eds.: VaMoS. ICB Research Report (2008) Dhungana, D., Grünbacher, P., Rabiser, R.: Decisionking: A flexible and extensible tool for integrated variability modeling. In Pohl, K., Heymans, P., Kang, K.C., Metzger, A., eds.: VaMoS. Volume of Lero Technical Report. (2007) Atkinson, C., Bayer, J., Muthig, D.: Component-based product line development: the kobra approach. In: Proceedings of the first conference on Software product lines : experience and research directions, Norwell, MA, USA, Kluwer Academic Publishers (2000) OpenArchitectureWare: Openarchitectureware. openarchitectureware.org (2009)

15 Modelos de Decisión como Estrategia de Composición Apache: Ant. (2009) 13. Allilaire, F., Bézivin, J., Jouault, F., Kurtev, I.: Atl - eclipse support for model transformation. In: Proceedings of the Eclipse Technology exchange workshop (etx) at the ECOOP 2006 Conference, Nantes, France (2006) 14. Kling, W.: Using decision models on atl. (2009) 15. Jouault, F., Kurtev, I.: On the architectural alignment of atl and qvt. In: SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA, ACM (2006) Balogh, A., Varró, D.: Advanced model transformation language constructs in the viatra2 framework. In: SAC 06: Proceedings of the 2006 ACM symposium on Applied computing, New York, NY, USA, ACM (2006)

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

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

Más detalles

Modelado de la variabilidad en arquitecturas multicapa

Modelado de la variabilidad en arquitecturas multicapa Modelado de la variabilidad en arquitecturas multicapa José García-Alonso, Joaquín Guillén, Javier Berrocal, and Juan Manuel Murillo Escuela Politécnica, Universidad de Extremadura, Avd. de la Universidad

Más detalles

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

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

Más detalles

Programación orientada a

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

Más detalles

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta

Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Conexión de Reglas de Negocios con Aspectos: estrategias y herramienta Sandra Casas y Cecilia Fuentes Zamorano UARG, Universidad Nacional de la Patagonia Austral Campus Universitario, Piloto Riversa s/n

Más detalles

Departamento de Lenguajes y Sistemas Informáticos

Departamento de Lenguajes y Sistemas Informáticos Departamento de Lenguajes y Sistemas Informáticos Modelo de Requisitos y Modelo de Dominio, Trazabilidad Mediante Modelos os de Weaving José Alfonso Aguilar Calderón Irene Garrigós Jose-Norberto Mazón

Más detalles

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

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

Más detalles

Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales

Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales Construcción y adaptación de Lenguajes de Dominio Específico por usuarios finales Santiago Jácome G. Universidad de las Fuerzas Armadas ESPE, Ecuador Universidad Autónoma de Madrid, España psjacome@espe.edu.ec

Más detalles

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

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

Más detalles

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo: Fase II Posgrado en Ciencias y Tecnologías de la Información Marzo del 2012. 1. Responsables Dra. Angelina

Más detalles

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad

Introducción. El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad El uso de la ingeniería guiada por modelos para el aseguramiento de la calidad Dra. María a José Escalona Cuaresma mjescalona@us.es www.iwt2.org Universidad de Sevilla Grupo de Ingeniería Web y Testing

Más detalles

Desarrollo de Líneas de Productos de Software

Desarrollo de Líneas de Productos de Software Centro Experimental de Ingeniería de Software Departamento de Ciencias de la Computación Facultad de Ciencias Físicas y Matemáticas Universidad de Chile Desarrollo de Líneas de Productos de Software María

Más detalles

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo

Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo Modelo para evaluar la Gestión del Valor del Producto Software durante el Ciclo de Desarrollo Posgrado en Ciencias y Tecnologías de la Información Marzo del 2014. 1. Responsables Dra. Angelina Espinoza

Más detalles

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

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

Más detalles

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

INGENIAS: Desarrollo dirigido por modelos de SMA

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

Más detalles

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

AUTOMATIZACION DE PROCESOS DE DESARROLLO DE SOFTWARE DEFINIDOS CON SPEM

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

Más detalles

PROGRAMACIÓN DE LÍNEAS DE PRODUCTOS DE SOFTWARE ORIENTADAS A ASPECTOS

PROGRAMACIÓN DE LÍNEAS DE PRODUCTOS DE SOFTWARE ORIENTADAS A ASPECTOS PROGRAMACIÓN DE LÍNEAS DE PRODUCTOS DE SOFTWARE ORIENTADAS A ASPECTOS P R E S E N T A : I. S. C. A N A F A B I O L A A N Z U R E S R A M Ó N DIRIGEN DR. ULISES JUÁREZ MARTÍNEZ (INSTITUTO TECNOLÓGICO DE

Más detalles

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

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

Más detalles

Una Propuesta Metodológica basada en Taxonomías para el Desarrollo de Sistemas Groupware Interactivos

Una Propuesta Metodológica basada en Taxonomías para el Desarrollo de Sistemas Groupware Interactivos Una Propuesta Metodológica basada en Taxonomías para el Desarrollo de Sistemas Groupware Interactivos William J. Giraldo 2, Ana I. Molina 1, Manuel Ortega 1, César A. Collazos 3 1 Departmento de Sistemas

Más detalles

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

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

Más detalles

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

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

Más detalles

Ingeniería de Software

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

Más detalles

Modelos Workflow: Análisis y Medición. Contexto

Modelos Workflow: Análisis y Medición. Contexto Modelos Workflow: Análisis y Medición M. Peralta, C. Salgado, L. Baigorria, M. Berón, D. Riesco, G. Montejano Departamento de Informática Facultad de Ciencias Físico Matemáticas y Naturales Universidad

Más detalles

Ingeniería de Software: Parte 2

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

Más detalles

Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos

Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos Desarrollo Dirigido por Modelos de Procesos de egocio Colaborativos: Análisis de herramientas para la transformación de modelos Maximiliano Vanzetti CIDISI, Universidad Tecnológica acional-frsf, Lavaisse

Más detalles

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

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

Más detalles

El Proceso Unificado de Desarrollo de Software

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

Más detalles

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

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

Más detalles

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

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra

Introducción. http://www.microsoft.com/spanish/msdn/comunidad/mtj.net/voices/art143.asp - Gráfica tomada del Artículo de José David Parra Si en otros tiempos el factor decisivo de la producción era la tierra y luego lo fue el capital... hoy día el factor decisivo es cada vez más el hombre mismo, es decir, su conocimiento... Juan Pablo II

Más detalles

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0

SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 SPEM 2.0 SOFTWARE & SYSTEMS PROCESS ENGINEERING METAMODEL SPECIFICATION V.20 SPEM 2.0 Metamodelo para modelos de procesos de ingeniería de software y de ingeniería de sistemas. La idea central de SPEM

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

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN

Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Tópicos Avanzados de Análisis y Diseño INGENIERIA DE SOFTWARE ING. MA. MARGARITA LABASTIDA ROLDÁN Proceso de Negocio (Business Process) Conjunto estructurado, medible de actividades para producir un producto.

Más detalles

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8

WebRatio. Otro camino para el BPM. Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 WebRatio Otro camino para el BPM Web Models s.r.l. www.webratio.com contact@webratio.com 1 / 8 El BPM El BPM (Business Process Management) no es solo una tecnología, además a grandes rasgos es una disciplina

Más detalles

Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos

Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos Líneas de Productos de Software Dirigidas por Modelos (MD-SPL): Oportunidades y Retos Andrés Romero y Fabián Ceballos Universidad de los Andes, Cra. 1 No 18A 10, Bogotá, Colombia {aa.romero354, fl.ceballos40}@uniandes.edu.co

Más detalles

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

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

Más detalles

"Módulo OOWS para StarUML" INTRODUCCIÓN

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

Más detalles

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina

BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios. Víctor Mario Cardona Medina BplSoa: Framework para el desarrollo de líneas de procesos de negocios orientadas a servicios Víctor Mario Cardona Medina Universidad Nacional de Colombia Facultad de Ingeniería, Departamento de Ingeniería

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

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

Depto de Cs e Ing. de la Computación Universidad Nacional del Sur

Depto de Cs e Ing. de la Computación Universidad Nacional del Sur Click to add title Mejorando los tiempos de desarrollo Frameworks Diego C. Martínez - DCIC-UNS 2 Patrones de Diseño, según GoF Los patrones de diseño son básicamente descripciones de objetos que se comunican

Más detalles

SERVICIOS: EXPLORACIONES EN SOA y WEB.

SERVICIOS: EXPLORACIONES EN SOA y WEB. SERVICIOS: EXPLORACIONES EN SOA y WEB. López, G. 1 ; Jeder, I 1.; Echeverría, A 1.; Grossi, M.D. 2 ; Servetto, A 2.; Fierro, P. (PhD.) 3 1. Laboratorio de Informática de Gestión - Facultad de Ingeniería.

Más detalles

Una propuesta de implementación para especificaciones de patrones de comportamiento

Una propuesta de implementación para especificaciones de patrones de comportamiento Una propuesta de implementación para especificaciones de patrones de comportamiento Alberto A. Cortez 123, Claudia A. Naveda 12 1 Consejo de Investigaciones -CIUDA, Universidad del Aconcagua, Mendoza,

Más detalles

Diseño Basado en Componentes. Curso 2008/09

Diseño Basado en Componentes. Curso 2008/09 Tabla de contenidos Diseño Basado en Componentes Técnicas relacionadas con Reutilización Introducción: por qué reutilizar?, qué reutilizar? Técnicas: Ingeniería de dominios Líneas de productos (Product-lines)

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

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

Utilidad de las transformaciones modelo-modelo en la generación automática de código

Utilidad de las transformaciones modelo-modelo en la generación automática de código Utilidad de las transformaciones modelo-modelo en la generación automática de código Javier Luis Cánovas Izquierdo, Óscar Sánchez Ramón, Jesús Sánchez Cuadrado, Jesús García Molina Facultad de Informática

Más detalles

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms

Patrones de Alto nivel: Patrones de Arquitectura Patrones de nivel medio: Patrones de Diseño Patrones de bajo nivel: Idioms Patrones Patrones Es una solución reusable de problemas comunes. Los patrones solucionan problemas que existen en muchos niveles de abstracción. desde el análisis hasta el diseño y desde la arquitectura

Más detalles

Tape Mbo e: una Metodología Orientada a Servicios

Tape Mbo e: una Metodología Orientada a Servicios Tape Mbo e: una Metodología Orientada a Servicios Motivación Objetivos Tecnología Estado del Arte Evaluación del Estado del Arte Tape Mb e Ciclo de Vida Roles Disciplinas Ciclo de Vida y Disciplinas Evaluación

Más detalles

Herramientas de Software que posibilitan el BPM

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

Más detalles

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

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

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

Más detalles

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

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

Más detalles

Arquitecturas de Software

Arquitecturas de Software Arquitecturas de Software Ingeniería del Universidad Rey Juan Carlos César Javier Acuña cjacunia@escet.urjc.es Índice Introducción Motivación Definición Pipes and Filters Tipos abstractos de datos y OO

Más detalles

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool

UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA. Documentación de Motivación del Proyecto. JMit. Java Monitoring by Introspection Tool UNIVERSIDAD DE BUENOS AIRES FACULTAD DE INGENIERÍA Documentación de Motivación del Proyecto JMit Java Monitoring by Introspection Tool Alumnos: 84.264 86.097 Tutor: Wachenchauzer, Rosa Graciela Indice

Más detalles

Una Aproximación para Aplicaciones Web: MOWEBA

Una Aproximación para Aplicaciones Web: MOWEBA Una Aproximación para Aplicaciones Web: MOWEBA Magalí González 1,2, Luca Cernuzzi 1, Oscar Pastor 2 1 DEI - Universidad Católica Nuestra Señora de la Asunción Asunción Paraguay 2 DSIC - Universidad Politécnica

Más detalles

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org

Cómo citar el artículo Número completo Más información del artículo Página de la revista en redalyc.org REICIS. Revista Española de Innovación, Calidad e Ingeniería del Software E-ISSN: 1885-4486 reicis@ati.es Asociación de Técnicos de Informática España Pérez Lamancha, Beatriz; Polo, Macario Generación

Más detalles

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com

Conceptos de Orquestador O2 EMPRESAS TUXPAN www.tuxpan.com EMPRESAS TUXPAN www.tuxpan.com AÑO 2007 INDICE DE CONTENIDO 1 Software de Servicios y Orquestación de Procesos 2 1.1.1 Introducción 2 1.1.2 Software de Orquestación como Integrador 3 1.1.3 Automatización

Más detalles

Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es

Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es Metodología y Técnicas en Proyectos software para la Web II-6 para la Ingeniería Web Profesorado: Dra. María José Escalona Cuaresma mjescalona@us.es Dr. José Mariano González Romano mariano@lsi.us.es Programa

Más detalles

O jeto de apre r ndizaje

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

Más detalles

Análisis y Medición de Modelos de Procesos Workflow

Análisis y Medición de Modelos de Procesos Workflow WICC 2012 503 Análisis y Medición de Modelos de Procesos Workflow M. Peralta, C. Salgado, M. Berón, D. Riesco, G. Montejano Departamento de Informática Facultad de Ciencias Físico Matemáticas y Naturales

Más detalles

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

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

Más detalles

Aplicando los principios del DSDM al desarrollo de transformaciones de modelos en ETL

Aplicando los principios del DSDM al desarrollo de transformaciones de modelos en ETL Aplicando los principios del DSDM al desarrollo de transformaciones de modelos en ETL Álvaro Jiménez, Verónica A. Bollati, Juan M. Vara, Esperanza Marcos Grupo de Investigación Kybele, Universidad Rey

Más detalles

VISIÓN GENERAL HERRAMIENTAS COMERCIALES

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

Más detalles

Departamento Organización de Empresas TESIS DOCTORAL. Arquitectura, Metodología y Plataforma Tecnológica para

Departamento Organización de Empresas TESIS DOCTORAL. Arquitectura, Metodología y Plataforma Tecnológica para Departamento Organización de Empresas TESIS DOCTORAL Arquitectura, Metodología y Plataforma Tecnológica para la Ingeniería y Operación de Redes Colaborativas. Una aproximación basada en Servicios Digitales

Más detalles

UML 2 Iniciación, ejemplos y ejercicios corregidos

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

Más detalles

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m.

3. Horario laboral referencial: Lunes Viernes 8:00 a.m. a 6:00 p.m. Arquitecto de Datos 1. Línea de Negocios: Soluciones de Negocios 2. Funciones Específicas: Participar en la realización de las actividades técnicas de actualización y migraciones a versiones mejoradas

Más detalles

Aplicaciones Distribuidas con Visual Studio 2005

Aplicaciones Distribuidas con Visual Studio 2005 Aplicaciones Distribuidas con Visual Studio 2005 24.10.2006 Servicios Profesionales Danysoft Ahora los arquitectos en.net disponen de una versión de Visual Studio especialmente creada para atender sus

Más detalles

Reporte inicial. Metodología

Reporte inicial. Metodología Reporte inicial Este reporte inicial expondrá las decisiones que tomamos al momento de selección de metodología, plantillas y métodos de recabado de evidencia y por qué tomamos dichas decisiones. Metodología

Más detalles

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

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

Más detalles

Framework para el desarrollo ágil de aplicaciones

Framework para el desarrollo ágil de aplicaciones Framework para el desarrollo ágil de aplicaciones 1 Índice INTRODUCCIÓN... 3 QUÉ ES UN FRAMEWORK?... 3 VENTAJAS DE UTILIZAR UN FRAMEWORK... 4 DESVENTAJAS DE UTILIZAR UN FRAMEWORK... 5 CARACTERÍSTICAS DE

Más detalles

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

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

Más detalles

Adopción de un esquema de líneas de productos de Software en HBT. Carlos Andrés Parra Leonardo Giral. Heinsohn Business Technology

Adopción de un esquema de líneas de productos de Software en HBT. Carlos Andrés Parra Leonardo Giral. Heinsohn Business Technology Agenda Adopción de un esquema de líneas de productos de Software en HBT Carlos Andrés Parra Leonardo Giral Heinsohn Business Technology Cámara de Comercio de Bogotá Centro Empresarial Chapinero AGENDA

Más detalles

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

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

Más detalles

2524 Developing XML Web Services Using Microsoft ASP.NET

2524 Developing XML Web Services Using Microsoft ASP.NET 2524 Developing XML Web Services Using Microsoft ASP.NET Introducción La meta de este curso es de proveer a los estudiantes con el conocimiento y habilidades requeridas para desarrollar soluciones basadas

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

Guía de Implementación

Guía de Implementación Guía de Implementación Instalación de Software Tabla de Contenido Información General sobre Implementación de Software Servidor CommNet Windows Clúster de Windows - Servidor Virtual Agente de la Red de

Más detalles

Programación del curso

Programación del curso Ingeniería Software 4º Físicas Programación del curso José M. Drake (drakej@unican.es) Patricia López Martínez ( lopezpa@unican.es ) Computadores y Tiempo Real Santander, 2008 Ingeniería de Programación

Más detalles

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

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

Más detalles

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez

CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS. USB Ing. De Software. Prof. I. C. Martínez CLASE 2: INTRODUCCIÓN A LA ING. DE SOFTWARE. MODELOS DE PROCESOS. MEJORES PRÁCTICAS USB Ing. De Software. Prof. I. C. Martínez Ing. De Software Ingeniería de Software La Ingeniería de Software es la ciencia

Más detalles

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

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

Más detalles

IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución

IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución con fecha de 14 de diciembre de 2010 IBM Rational Software Architect V8.0.1 ofrece nuevos e innovadores enfoques para desarrollar arquitecturas de solución Tabla de contenidos 1 Visión general 1 Fecha

Más detalles

GENERACIÓN DE APLICACIONES MEDIANTE LENGUAJES ESPECIFICOS DE DOMINIO

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

Más detalles

Hacia la Obtención de Procesos de Negocio desde Sistemas de Información Heredados

Hacia la Obtención de Procesos de Negocio desde Sistemas de Información Heredados Hacia la Obtención de Procesos de Negocio desde Sistemas de Información Heredados Alfonso Rodríguez 1, Angélica Caro 1 1 Departamento de Ciencias de la Computación y Tecnologías de la Información Universidad

Más detalles

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML

Ingeniería del Software. Diseño. Diseño en el PUD. Diseño de software. Patrones arquitectónicos. Diseño Orientado a Objetos en UML Diseño Diseño en el PUD Diseño de software Patrones arquitectónicos Diseño Orientado a Objetos en UML 1 Iteración en PUD Planificación de la Iteración Captura de requisitos: Modelo de casos de uso, Modelo

Más detalles

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

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

Más detalles

PROGRAMA DE DOCTORADO

PROGRAMA DE DOCTORADO PROGRAMA DE DOCTORADO Desarrollo de familias de productos de software desde un enfoque generativo DPTO. DE INGENIERÍA DE SOFTWARE Y SISTEMAS INFORMÁTICOS Tema 1 Introducción Autor: Rubén Heradio Gil Índice

Más detalles

CL_50255 Managing Windows Environments with Group Policy

CL_50255 Managing Windows Environments with Group Policy Gold Learning Gold Business Intelligence Silver Data Plataform Managing Windows Environments with Group Policy www.ked.com.mx Por favor no imprimas este documento si no es necesario. Introducción. En este

Más detalles

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él.

PROCESOS SOFTWARE. Según esta estrategia, todo proceso debe planificarse, implantarse y evaluarse, para luego actuar sobre él. PROCESOS SOFTWARE MOTIVACIÓN? Con independencia de la metodología o modelo implementado, es común la estrategia para la mejora continua de la calidad, basada en el Círculo de Deming o Plan, Do, Check,

Más detalles

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS 1. Nombre de la asignatura Desarrollo de

Más detalles

CL_55048 No-Code SharePoint 2013 Workflows with SharePoint Designer 2013 and Visio

CL_55048 No-Code SharePoint 2013 Workflows with SharePoint Designer 2013 and Visio Gold Learning Gold Business Intelligence Silver Data Plataform S No-Code SharePoint 2013 Workflows with SharePoint Designer 2013 and Visio www.ked.com.mx Por favor no imprimas este documento si no es necesario.

Más detalles

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

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

Más detalles

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS

TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS TÉCNICO SUPERIOR UNIVERSITARIO EN TECNOLOGÍAS DE LA INFORMACIÓN Y COMUNICACIÓN AREA SISTEMAS INFORMATICOS HOJA DE ASIGNATURA CON DESGLOSE DE UNIDADES TEMÁTICAS Pág. 1 de 25 1. Nombre de la asignatura Desarrollo

Más detalles

Capítulo 11. Conclusiones y trabajo futuro

Capítulo 11. Conclusiones y trabajo futuro Capítulo 11. Conclusiones y trabajo futuro En esta tesis ha realizado un entorno de desarrollo Web que proporciona herramientas para la mejora de la calidad del código de los desarrolladores. Para conseguir

Más detalles

Un Enfoque para Desarrollar Aplicaciones WEB Basado en Líneas de Producto Dirigidas por Modelos

Un Enfoque para Desarrollar Aplicaciones WEB Basado en Líneas de Producto Dirigidas por Modelos Un Enfoque para Desarrollar Aplicaciones WEB Basado en Líneas de Producto Dirigidas por Modelos Fabián Ceballos, Hugo Arboleda, Rubby Casallas Universidad de los Andes, Cra 1 No 18ª 10, Bogotá Colombia,

Más detalles

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD

MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD MODELO DE EGOVERNMENT PARA LA ADMINISTRACIÓN LOCAL BASADO EN LA INTEROPERABILIDAD Francisco Tous Llull, Antoni Reus Darder, Felip Salas Suau Fundació Illes Balears per la Innovació Tecnològica (IBIT) Parc

Más detalles

CONGRESOS 2012 INTERNACIONALES

CONGRESOS 2012 INTERNACIONALES CONGRESOS 2012 INTERNACIONALES Autores: V. A. Bollati, P. Atzeni, E. Marcos, J.M. Vara Título: Model Management Systems vs. Model Driven Engineering: A Case Study Congreso: Symposium on Applied Computing

Más detalles

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo

Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes de dispositivo Oferta tecnológica: Herramienta software y método para modelar aplicaciones web independientes

Más detalles