Combinando Modelos de Procesos y Activos Reutilizables en una Transición poco Invasiva hacia las Líneas de Producto de Software Orlando Avila-García, Antonio Estévez García, E. Victor Sánchez Rebull José Luis Roda García Open Canarias, S.L. Universidad de La Laguna Santa Cruz de Tenerife Santa Cruz de Tenerife España España orlando,aestevez,vsanchez@opencanarias.com jlroda@ull.es http://www.opencanarias.com http://www.taro.ull.es Resumen Existen tres modelos de adopción/creación de líneas de producto de software: proactivo, extractivo y reactivo. Mientras los dos primeros pueden implicar costes y tiempo de adopción prohibitivos, el tercero plantea una alternativa con menos costes de adopción, lo que se denomina una transición poco invasica hacia la ingeniería basada en líneas de producto. En este artículo proponemos un método reactivo, basado en la combinación de activos reutilizables y procesos de software. Nuestro método permite la automatización progresiva y distribuida de las tareas de un proceso de software hasta llegar a su completa automatización. 1. Introducción La celebración en 1968 de la conferencia NA- TO sobre Ingeniería del Software marca el nacimiento de dicha disciplina [19]. La principal motivación para su celebración fue la creciente necesidad de producir sistemas de software más grandes, complejos y ables, de una manera más controlada y eciente. Con ello se afrontaba lo que se denominó entonces la crisis del software, la imposibilidad de las tecnologías de software de aquella época para satisfacer las demandas de la industria. En dicha conferencia se trataron temas de diseño, producción, precio, y servicios asociados al software. En el debate abierto sobre la producción de software surgieron dos ideas reveladores: la propuesta por R. W. Bremer, sobre la necesidad de utilizar entornos de producción controlados por maquinaria, lo que fue llamado por primera vez factoría de software [4], y la presentada por M. D. McIlroy, sobre las grandes ventajas que ofrece la creación y ensamblaje de componentes reutilizables [18]. Estas ideas son el exponente de dos importantes principios de factoría: automatización y reutilización, respectivamente. Es importante considerar que desde el principio se tuvo en cuenta que, en el caso del software, no usamos estos principios para producir en masa réplicas exactas de un mismo producto (problema que no existe en el caso del software), sino productos similares o variantes de un mismo producto a bajo coste y en menos tiempo [18]. Numerosas aproximaciones han venido ofreciendo aportaciones sobre estos y otros principios complementarios de factoría aplicados al software [8]. Uno de las aproximaciones más importantes lleva el nombre de Líneas de Producto de Software [7], paradigma enriquecido en los últimos años por la Ingeniería Dirigida por Modelos [24]. Esta aproximación se basa en la idea de producir familias (o variantes similares) de productos de software a partir de un conjunto de activos reutilizables (denomi-
nados assets) de una forma prescrita. Desarrollar un producto de la línea es más una cuestión de ensamblaje y conguración de activos que de creación. Para cada línea de producto debe haber una guía predenida o plan de producción que especica el proceso exacto de obtención de cada producto. Esta aproximación ofrece así tecnologías para llevar a cabo reutilización y automatización en los procesos de software. La dicotomía entre ingeniería de dominio e ingeniería de aplicación es esencial en la aproximación de Líneas de Producto de Software [7]; es más, es la base de cualquier intento de reutilización y automatización en procesos de software [10]. Mientras en la ingeniería de dominio creamos un conjunto de activos para reutilizar y automatizar en un dominio de aplicación especíco, en la ingeniería de aplicación los usamos para producir, en dicho dominio, productos de software de mayor calidad, empleando menos coste y tiempo. En 2002, Krueger propuso la distinción entre tres modelos de adopción/creación de líneas de producto de software [6]: proactivo, extractivo y reactivo. El modelo proactivo es el más clásico; propone un gran esfuerzo e inversión iniciales en una ingeniería de dominio exhaustiva, donde se establece el dominio (o ámbito) exacto de los productos que pertenecerán a la línea, para luego crear los activos a partir de los cuales producirlos. Este modelo, aunque más exhaustivo, puede requerir tiempos y costes de adopción prohibitivos para una empresa; es la llamada barrera de adopción [6, 15]. Un modelo de adopción extractivo plantea la utilización, durante la ingeniería de dominio, de ingeniería inversa de los productos ya existentes en el dominio para obtener conocimiento más preciso sobre éste más rápidamente. Esta aproximación resulta en una reducción considerable de coste y tiempo en el desarrollo de activos (ver un ejemplo en [26]). La tercera alternativa es el modelo de adopción reactivo, en el que no establecemos desde un principio el dominio de la línea de producto, sino que iremos ampliando bajo demanda el ámbito de los productos de la misma, creando los correspondientes activos. Bajo demanda signica que incluiremos nuevos productos a medida que aparezca la necesidad de producirlos. La creación de activos es por tanto más incremental y progresiva que con los modelos de adopción anteriores (ver un ejemplo en [5]). Este tipo de modelo de adopción permite una transición poco invasiva desde una ingeniería de software convencional, centrada en un único producto, a una ingeniería basada en líneas de producto, centrada en la producción de variantes de productos. Estas transiciones poco invasivas ofrecen dos ventajas principales [15]: la rápida consecución del ROI (Return-of- Investment); y la posibilidad de seguir con los procesos de desarrollo normales de la empresa. En este artículo proponemos un método reactivo para realizar una transición poco invasiva hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de producto de software. Para ello, ofrecemos una solución basada en un desarrollo iterativo y desacoplado de activos, que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. En otras palabras, este método permite automatizar la toma de decisiones en los procesos de software a medida que se establece la invarianza de las mismas en el dominio de aplicación en cuestión. Nuestro método se basa en la utilización de dos estándares OMG (Object Management Group) 1 : RAS (Reusable Asset Specication) [21], Especicación de Activos Reutilizables, que permite identicar, describir y empaquetar activos de manera estándar; y SPEM (Software Process Engineering Metamodel) [22], Metamodelo de Ingeniería de Procesos de Software, que dene un lenguaje estándar de modelado de procesos de software. Esta línea de investigación tuvo su origen en un estudio que exploraba las sinergias entre Líneas de Producto de Software, Ingeniería 1 OMG es la misma organización que da soporte a MDA (Model-Driven Architecture) [20], su aproximación a la Ingeniería Dirigida por Modelos [24] (ver sección 2.1)
Dirigida por Modelos e Ingeniería de Procesos de Software [2]. En aquel estudio, establecimos que las líneas de producto de software aplicadas al mantenimiento de familias de modelos facilitan enormemente la Ingeniería Dirigida por Modelos. El presente estudio muestra cómo esta clase de líneas de producto puede ser encapsulada en activos reutilizables, hasta que consiguen automatizar completamente una tarea de desarrollo. En la Sección 2 explicamos la base conceptual de nuestro método. A continuación presentamos un caso de estudio (Sección 3) del método. Finalizamos con un repaso a trabajos relacionados (Seccion 4) y con las conclusiones (Seccion 5). 2. Antecedentes A continuación ofrecemos un repaso a algunas tecnologías en las que se basa nuestro método, en concreto la especicación de activos reutilizables (RAS) y el metamodelo de procesos de software (SPEM). Sin embargo, antes que nada, ofrecemos una perspectiva histórica de la sinergia entre reutilización y automatización, en la que se basa nuestro método. 2.1. Perspectiva Histórica En esta sección repasamos cómo las ideas de reutilización y automatización en los procesos de softare han ido convergiendo a lo largo de la historia hasta llegar a su sinergia en las líneas de producto de software. Esta descripción no trata de ser exhaustiva; sólo trata de ofrecer una introducción a la combinación de activos reutilizables y procesos de software 2. Desde 1968 [19], el término factoría de software ha sido usado para hacer hincapié en diferentes técnicas de factoría [12]: aspectos organizativos, como división del trabajo en roles y especialización; métricas y procesos de software rigurosos y altamente maduros; reutilización, en diferentes etapas de la producción; entornos y herramientas de automatización; entrenamiento y aprendizaje, a través de 2 Para un estudio más en profundidad sobre el concepto de reutilización referirse a [13, 25]; sobre el concepto de automatización ver [8, 10] la gestión del conocimiento; y exibilidad, para producir variantes de los productos. Todas éstas son facetas de la aplicación de ideas de factoría a la producción de software [8]. Aunque estas técnicas no son mutuamente excluyentes, no fue hasta nales del siglo XX que se desarrollaron sus sinergias y las tecnologías necesarias para combinarlarlas efectivamente. Se realizaron importantes estudios sobre los cambios organizativos necesarios para una ecaz implantación de un programa de reutilización [25]. Se estableció que estos cambios pasan por la creación de un nuevo rol, el analista o ingeniero de dominio, encargado de identicar, capturar, empaquetar y organizar, para su posterior reutilización, conocimiento sobre cómo se llevan a cabo las distintas tareas de producción en dominios de aplicación especícos [23]. Los trabajos en metaprogramación empezaron a ofrecer sus frutos aportando nuevas técnicas para crear generadores de aplicaciones y capturar en ellos los secretos de la producción de software en dominios especícos [10]. Se llega así a reveladores estudios sobre reutilización que concluyen que la identicación, conguración (o especialización) e integración de artefactos reutilizables requiere de herramientas de automatización, como generadores de aplicaciones o sistemas de transformación, y del uso de lenguajes de muy alto nivel de abstracción [13, 12]. A nales del siglo XX aparece el concepto de Líneas de Producto de Software [7], formalizando la sinergia entre las diferentes técnicas de fábrica de software. Este paradigma propone la producción de familias (variantes similares) de productos a partir de un conjunto de activos (assets) siguiendo planes de producción predenidos. Los activos reutilizables son artefactos con puntos de variabilidad así como (meta)información y/o procesos asociados que describen cómo especializarlos para diferentes contextos de uso [17]. Por otro lago, se apunta a la importancia de que los planes de producción o procesos de desarrollo altamente precisos, preferiblemente automáticos, tengan tiempos y costes de ejecución predecibles. Más recientemente, la Ingeniería Dirigida por Modelos (Model-Driven Engineering,
MDE) [24] ha venido a ofrecer una prometedora técnica para implementar planes de producción más automáticos y exibles. MDE propone la denición de todo artefacto producido y/o (re)utilizado durante el proceso de desarrollo como un modelo formal, facilitando su manipulación a través de transformaciones. No sólo MDE da soporte a las Líneas de Producto de Software, sino que lo contrario es también cierto. Recientemente han sido presentados estudios sobre las ventajas de utilizar líneas de producto de software para mantener familias de modelos [9, 2, 3] Para nalizar decir que, en la actualidad, de- nimos un activo reutilizable (asset) como la solución a un problema recurrente en el desarrollo de software. Debe tener, preferiblemente, puntos de variabilidad que deben ser con- gurados por el consumidor del activo con el n de congurarlo o especializarlo para un contexto de uso determinado. Para una reutilización efectiva, la (meta)información de conguración del activo debe ser precisa, normalmente en forma de especicación de proceso o secuencia de pasos que pueda ser ejecutada de manera, preferiblemente, automática. 2.2. Modelado de Activos Reutilizables La especicación de activos reutilizables (Reusable Asset Specication, RAS) [21] permite identicar, describir y empaquetar un activo de manera estándar, cumpliendo los requisitos para una reutilización efectiva descritos en la sección anterior. Con RAS, un activo es una colección cohesiva de artefactos; de hecho, se almacena como un chero comprimido que empaqueta un conjunto de cheros, cada uno representando uno de estos artefactos. Un artefacto es cualquier producto de trabajo creado durante un proceso de desarrollo, como casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc., que resuelven problemas recurrentes en el desarrollo de software. Estos artefactos, por lo general, aceptarán cierta variabilidad, por lo que contarán con puntos de variabilidad o extensión que podrán ser congurados para adaptarlos a las características del problema concreto (contexto) donde aplicarlos. Figura 1: Ejemplo de modelo SPEM, donde un rol A ejecuta una tarea, consumiendo (in) el artefacto 1 y produciento (out) el artefacto 2. La tarea tiene asociado un elemento de guía para asistir al rol en su ejecución. La (meta)información que describe el activo es un modelo que conforma con el metamodelo RAS. Este modelo se empaqueta junto al resto de artefactos, dentro del chero comprimido que representa al activo. Este modelo contiene la identicación y clasicación del activo, la descripción de sus artefactos, sus puntos de variabilidad y cómo congurarlos. 2.3. Modelado de Procesos de Software Los procesos de desarrollo de software se han vuelto tan complejos que es necesario el uso de lenguajes formales para modelarlos [11]. SPEM (Software Process Engineering Metamodel) [22] es un lenguaje de modelado estándar que permite describir tales procesos. El metamodelo de SPEM es muy extenso, permitiendo el modelado de muchos aspectos y problemas del proceso de desarrollo. Sin embargo, en este estudio nos centraremos en el modelado de tareas, sin ni siquiera utilizar relaciones de secuencia o prioridad entre las mismas. Las tareas, ejecutadas por roles, consumen artefactos de entrada y producen artefactos de salida (ver Figura 1). Ejemplos de artefactos son modelos de casos de uso, diagramas de clases, código fuente, cheros de conguración XML, etc. Una tarea puede tener asociado elementos de guía que ayuden al rol a desempeñarla. Estos elementos pueden ir desde ejemplos y guías hasta plantillas y activos reutilizables [22, p.126].
Figura 2: Ejemplo de modelo SPEM que describe la fase de análisis de un proceso de software en una empresa X. El analista A es el encargado de estudiar las actas de reunión con el cliente, y crear el diagrama de casos de uso del sistema que cumple con los requerimientos del mismo. El analista B recibe los casos de uso y, según su experiencia, crea el diagrama de clases del sistema. Figura 3: El proceso stándar de la empresa ha sido mejorado mediante la inclusión de un elemento de guía para que se asista en la tarea de creación de casos de uso. 3. Caso de Estudio Supongamos una empresa X que desarrolla software para la administración electrónica. Supongamos que tiene un proceso desarrollo estándar para todos sus proyectos, un extracto (fase de análisis) del cual vemos en la Figura 2 modelado con SPEM. La empresa desea adoptar una aproximación de líneas de producto de software en sus desarrollos, con el n de potenciar la reutilización y automatización en sus procesos de software. En este caso de estudio mostraremos cómo, haciendo uso de nuestro método, la empresa podrá abordar una transición poco invasiva hacia las líneas de producto de software, es decir, sin perturbar la ejecución de sus proyectos de desarrollo. Para facilitar la comprensión del caso de estudio, mostraremos un ejemplo centrado en la fase de análisis (Figura 2). En este ejemplo, el analista A identica y organiza progresivamente en forma de activo RAS el conocimiento sobre la creación de casos de uso en un dominio especíco, para facilitar su reutilización efectiva, hasta llegar a una completa automatización de la tarea. 3.1. Creación del Activo El proceso de software de la Figura 2 es actualizado para contener un elemento de guía, en concreto un activo, que representa el paquete de conocimiento que el analista A va desarrollando sobre la creación de modelos de casos de uso en un dominio especíco (ver Figura 3). A medida que el analista A va encontrando similitudes entre los modelos de casos de uso que va creando en los diferentes proyectos, deberá ir empaquetándolas en el activo. La familia de modelos (o variantes) será organizada en forma de línea de producto de software 3. Para ello, el creador del activo describirá el proceso de conguración del activo como el plan de producción de una línea de producto de software. Téngase en cuenta que el analista A no estará abordando la creación directa de la línea de productos de software de su empresa, sino la creación de una línea de productos para generar la familia de modelos creados habitualmente al desempeñar esa tarea. El procedimiento será el siguiene. Cuando el analista A deba crear un modelo de casos de uso, inspeccionará el activo en busca de un modelo que cubra sus requerimientos. Para ello hará uso de la línea de productos para modelos contenida en el activo. Si ninguno de los miembros de la línea satisface sus necesidades, deberá crear un modelo por su cuenta, a partir del miembro que más se adecúe a ellas. Cuando termine la tarea de creación del modelo, deberá realizar ingeniería de dominio para incluir la nueva variante en la línea de producto, y capturarla así a partir de entonces dentro del activo. A partir de ese momento, el proceso 3 Para más detalles sobre cómo crear líneas de producto de software para mantener familias de modelos ver [3]; para una descripción más completa sobre la implementación de la línea de producto para modelos de casos de uso ver [1].
Figura 4: El ingeniero de dominio, que crea la línea de producto para casos de uso, debe especicar el modelo de cracterísticas de los miembros de la línea, una plantilla de modelos a partir de la cual generarlos, y una transformación de modelos que realice automáticamente tal especialización. de conguración del activo permitirá generar la nueva variante de modelos de casos de uso, para ser aplicada siempre que se repitan las condiciones que originaron su aparición. Es importante tener en cuenta que, como toda línea de productos, ésta que crea el analista debe tener un dominio. En caso contrario, sería muy dicil establecer similitudes entre las variantes de modelos que se desea agrupar, esencial para producirlos a partir de un mismo conjunto de activos. En este caso suponemos que el analista A lleva analizando aplicaciones en el dominio de los sistemas de gestión de solicitudes (en adelante referidos como RMS: Request Management Systems) en la administración electrónica. Ha establecido que muchos de los modelos de casos de uso que sirven para describirlos siguen unos patrones y comparten similitudes. Es por ello que decide automatizar la creación de estos modelos en el dominio RMS. Creación del Proceso de Conguración El analista A deberá ir acomodando las variantes de modelos casos de uso que va creando dentro del activo 4. Para ello deberá llevar 4 No tiene por qué ser el propio creador del produc- Figura 5: Plan de producción de la línea de producto para modelos de casos de uso. El analista tiene que seleccionar una serie de características del modelo de características, en lo que se llama con- guración de características. Esta conguración es la entrada de una transformación de modelos que especializa la plantilla para obtener el modelo de casos de uso. a cabo ingeniería de dominio para crear los activos y plan de producción de la línea de productos para modelos de casos de uso. La Figura 4 muestra en SPEM el proceso a seguir. Por un lado crea el modelo de características que caracteriza la familia de modelos de casos de uso, y una plantilla de modelos a partir de la cual generarlos. Asimismo, crea una transformación de modelos para especializar automáticamente la plantilla cuando queramos obtener un miembro concreto de la línea. La Figura 5 muestra el plan de producción de la línea de producto para modelos de casos de uso en el dominio RMS. Cuando un analista de casos de uso la quiere ejecutar, sólo tiene que seleccionar una serie de características opcionales y alternativas del modelo de características (que dene la familia de modelos), en lo que se llama conguración de características del producto a generar. Esta conguración es la entrada de una transformación de modelos que automáticamente especializa una plantilla de modelos para obtener el modelo de casos de uso concreto deseado. Es preciso notar que este plan de producción será el proceso de conguración del activo de to el que tenga que acomodarlo en el activo. Para ello la organización podría designar un analista de dominio, más experto en la creación de líneas de producto de software [25, 16].
Figura 6: Editor de modelos RAS de nuestro plugin de Eclipse para la manipulación de activos RAS. En la sección solución (solution) se encuentra modelada la descripción de los artefactos contenidos en el activo. En la sección uso (usage) se mantiene la información de las actividades o procesos de conguración del activo para diferentes contextos. En este caso, sólo hay modelada una actividad; en concreto, el plan de producción (modelado en SPEM) de la línea de producto para modelos de casos de uso. casos de uso que está siendo desarrollado. Empaquetado del Activo Siguiendo la especicación RAS, para empaquetar el activo necesitamos realizar varias acciones. En primer lugar, deberemos modelar la (meta)información del activo, incluidos los procesos de conguración que un consumidor del mismo debe ejecutar para obtener soluciones para contextos diferentes. La Figura 6 muestra dicho modelo, que conforma con el metamodelo RAS; este modelo es serializado en un chero con el nombre de manifest.rmd y empaquetado junto al resto de - cheros/artefactos del activo. Figura 7: Vista de navegación de proyectos ras de nuestro plugin de Eclipse para la manipulación de activos RAS. El proyecto es un chero comprimido con una serie de cheros que representan artefactos del activo. El primer artefacto es un directorio, que contiene el resto de artefactos necesarios para ejecutar la línea de producto de modelos de casos de uso: tres artefactos de entrada al proceso (rms.cbfm, rmscbfm2uml.atc, rmsuml_template.uml) más la denición en SPEM del proceso en sí (SPLCasosUsoRMS.spem, Figura 5). El activo también contiene el modelo del activo (manifest.rmd), conteniendo su (meta)información, y el metamodelo de RAS (ras.ecore).
Figura 8: Ejemplo de modelo SPEM que describe la nueva fase de análisis del proceso de la empresa de desarrollo de software objeto de nuestro estudio. La libertad del analista A ha sido restringida, ya que sólo puede seleccionar un miembro de la línea de producto para modelos de casos de uso. La tarea queda así restringida a la mera selección de características que identican el problema que el analista quiere solucionar. La segunda parte del análisis permanece inalterada, con el analista B recibiendo el modelo de casos de uso producido por el analista A. En segundo lugar debemos empaquetar los tres artefactos creados durante la ingeniería de dominio de la Figura 4, junto con la especicación del proceso de conguración, que en este caso es el modelo SPEM de la Figura 5. Dentro del activo, junto a estos cuatro artefactos, empaquetaremos también el modelo del activo (manifest.rmd) así como el metamodelo RAS (ras.ecore). Este último no es necesario, pero es una buena práctica que aumenta la compatibilidad entre herramentas RAS. La Figura 6 muestra el contenido del activo RAS. 3.2. Automatización de la Tarea Hasta ahora, el proceso de desarrollo de la empresa se ha visto modicado únicamente por la inclusión de un elemento de guía, en este caso un activo reutilizable. Al ser modelado como elemento de guía es opcional, es decir, el rol puede hacer o no uso de él cuando ejecuta la tarea. Esto le da la libertad al primero de decidir si alguna de las variantes del activo satisface sus necesidades, es decir, si alguno de los contextos para los que el activo dispone de conguración se asemeja lo suciente a su problema. La gran ventaja de tener los procesos de con- guración del activo descritos con SPEM es que podemos sacarlos y ensamblarlos con planes de producción más amplio. Por ejemplo, la Figura 8 nos muestra cómo el proceso de conguración del activo, que es en realidad el plan de producción de una línea de producto para modelos de casos de uso, ha sido desempaquetado del mismo e integrado en el proceso de software de la empresa. De esta manera, la etapa de creación de casos de uso ha sido sustituida por un plan de producción automático y obligatorio. En esta situación, hemos eliminado la libertad del analista A de decidir si usar o no alguna de las variantes ofrecidas por el activo reutilizable, sino que le obligamos a utilizar una de ellas. Ahora, el analista no puede crear cualquier modelo de casos de uso, sino que únicamente puede seleccionar una de las variantes de la línea seleccionando las características que lo identican. Fíjese que el rol que crea los casos de uso es ahora denominado Analista RMS (ver Figura 8); esto enfatiza el cambio de responsabilidades del analista. Con ello ganamos dos cosas: obligar a seguir patrones y buenas prácticas de modelado que los analistas realizando esa tarea han ido estableciendo progresivamente (mientras se creaba el activo); y centralizar el conocimiento para ayudar a nuevos analistas a aprender a realizar dicha tarea. 4. Trabajos relacionados Una aproximación poco invasiva a la creación de líneas de producto de software es presentada en [14, 5]. Aunque plantea una incorporación incremental de productos a la línea, no plantea la automatización incremental del proceso de desarrollo, ni abordar la reutilización y automatización de tareas de manera desaco-
plada. En esta aproximación, la incorporación de productos a una línea de producto de software es incremental, pero su automatización no lo es; la incorporación de un nuevo producto se aborda creando toda infraestructura necesaria para su generación automática desde el principio. El Desarrollo Basado en Activos (Asset Based Development), en cambio, sí que plantea la creación desacoplada de activos [16]. Sin embargo, hasta la fecha, la combinación de estos activos para automatizar un proceso de software no ha sido aclarada convenientemente. 5. Conclusiones En este artículo proponemos un método reactivo para llevar a cabo transiciones poco invasivas hacia la ingeniería basada en líneas de producto de software. Esta aproximación está pensada para aquellas empresas que quieran automatizar sus procesos de desarrollo, en dominios de aplicación especícos, a través de la creación de líneas de productos de software. El método se basa en un desarrollo iterativo y desacoplado de activos que permite automatizar, progresivamente, las tareas a lo largo del ciclo de desarrollo. Estos activos van capturando el conocimiento de los roles sobre la resolución de problemas en diferentes etapas del desarrollo. Con ello, a la larga se automatiza la toma de decisiones en los procesos de software, a medida que se establece que las mismas son invariantes en dominios de aplicación especícos. Nuestro método se basa en la combinación de RAS (Reusable Asset Specication) [21], especicación de activos reutilizables y SPEM (Software Process Engineering Metamodel) [22], metamodelo de ingeniería de procesos de software. Mediante un ejemplo hemos mostrado cómo la combinación del empaquetado de activos con RAS y el modelado de procesos con SPEM puede llevar a una automatización progresiva de las tareas en el proceso de desarrollo de la empresa. Referencias [1] O. Avila-García and M. D. D. Fabro. AMW use case: Mapping features to models. Technical Report MST-9, Open Canarias, S.L., Apr 2007. [2] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Integrando modelos de procesos y activos reutilizables en una herramienta mda. In JISBD 2006: Proceedings of the XI Jornadas de Ingeniería del Software y Bases de Datos, pages 483488, Barcelona, Spain, Oct 2006. CIMNE. [3] O. Avila-García, A. E. García, V. S. Rebull, and J. L. R. García. Using software product lines to manage model families in model-driven engineering. In SAC 2007: Proceedings of the 2007 ACM Symposium on Applied Computing, track on Model Transformation, pages 10061011. ACM Press, Mar 2007. [4] R. W. Bremer. Machine-controlled production environment. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages 9495. Scientic Aairs Division, NA- TO, 1969. [5] R. Buhrdorf, D. Churchett, and C. W. Krueger. Salion's experience with a reactive software product line approach. In PFE 2003: Software Product-Family Engineering, 5th International Workshop, volume 3014 of LNCS, pages 317322. Springer, Nov 2003. [6] P. Clements and C. W. Krueger. Being proactive pays o / eliminating the adoption barrier. IEEE Software, pages 2831, July/August 2002. [7] P. Clements and L. Northrop. Software Product Lines: Practices and Patterns. Addison Wesley, Aug 2001.
[8] M. A. Cusumano. The software factory: A historical interpretation. IEEE Software, 6(2):2330, 1989. [9] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed variants. In Proceedings of GPCE 2005, volume 3676 of LNCS, pages 422437. Springer- Verlag, 2005. [10] K. Czarnecki and U. Eisenecker. Generative Programming: Methods, Tools, and Applications. Addison-Wesley, 2000. [11] J.-C. Dermiane and F. Oquendo. Key issues and new challenges in software process technology. UPGRADE: The European Journal for the Informatics Professional, V(5):1116, Oct 2004. [12] M. L. Griss. Software reuse: from library to factory. IBM Systems Journal, 32(4):548566, 1993. [13] C. W. Krueger. Software reuse. ACM Comput. Surv., 24(2):131183, 1992. [14] C. W. Krueger. Easing the transition to software mass customization. In PFE '01: Revised Papers from the 4th International Workshop on Software Product- Family Engineering, pages 282293, London, UK, 2002. Springer-Verlag. [15] C. W. Krueger. New methods behind a new generation of software product line successes. Technical Report #200602261, BigLever Software, Inc., Feb 2006. [16] G. Larsen. Model-driven development, assets and reuse. IBM Systems Journal, 45(3), 2006. [17] J. D. McGregor. Product production. Journal of Object Technology, 3(10):89 98, Nov/Dec 2004 2004. [18] M. D. McIlroy. Mass produced software components. In P. Naur and B. Randell, editors, Software Engineering: Report on a conference sponsored by the NA- TO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages 138152. Scientic Aairs Division, NA- TO, 1969. [19] P. Naur and B. Randell, editors. Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October 1968. Scientic Aairs Division, NATO, 1969. [20] OMG. MDA guide version 1.0.1. Technical Report omg/2003-06- 01, Jun 2003. Available at http://www.omg.org/docs/omg/03-06-01.pdf. [21] OMG. Reusable asset specication. Technical Report ptc/04-06-06, Jun 2004. Available at http://www.omg.org/docs/ptc/04-06-06.pdf. [22] OMG. Software Process Engineering Meta-model 2.0. Technical Report ad/06-04-05, Apr 2006. Available at http://www.omg.org/docs/ad/06-04-05.pdf. [23] R. Prieto-Díaz. Domain analysis: an introduction. SIGSOFT Softw. Eng. Notes, 15(2):4754, 1990. [24] D. C. Schmidt. Model-Driven Engineering. IEEE Computer, 39(2):4147, Feb 2006. [25] W. Tracz. Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Addison Wesley, Reading, Massachusetts, USA, 1995. [26] S. Trujillo, D. Batory, and O. Díaz. Feature refactoring a multi-representation program into a product line. In GPCE 2006: Proceedings of the 5th International Conference on Generative Programming and Component Engineering, pages 191200, New York, NY, USA, Oct 2006. ACM Press.