Combinando Modelos de Procesos y Activos Reutilizables en una

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.
Santa Cruz de Tenerife
España
orlando,aestevez,vsanchez@opencanarias.com
http://www.opencanarias.com
Universidad de La Laguna
Santa Cruz de Tenerife
España
jlroda@ull.es
http://www.taro.ull.es
Resumen
diseño, producción, precio, y servicios asociados al software. En el debate abierto sobre la
Existen tres modelos de adopción/creación de
producción de software surgieron dos ideas re-
líneas de producto de software: proactivo, ex-
veladores: la propuesta por R. W. Bremer, so-
tractivo y reactivo. Mientras los dos primeros
bre la necesidad de utilizar entornos de pro-
pueden implicar costes y tiempo de adopción
ducción controlados por maquinaria, lo que fue
prohibitivos, el tercero plantea una alternati-
llamado por primera vez factoría de software
va con menos costes de adopción, lo que se
[4], y la presentada por M. D. McIlroy, sobre
denomina una transición poco invasica hacia
las grandes ventajas que ofrece la creación y
la ingeniería basada en líneas de producto. En
ensamblaje de componentes reutilizables [18].
este artículo proponemos un método reactivo,
Estas ideas son el exponente de dos impor-
basado en la combinación de activos reutiliza-
tantes principios de factoría: automatización
bles y procesos de software. Nuestro método
y reutilización, respectivamente. Es importan-
permite la automatización progresiva y distri-
te considerar que desde el principio se tuvo en
buida de las tareas de un proceso de software
cuenta que, en el caso del software, no usamos
hasta llegar a su completa automatización.
estos principios para producir en masa réplicas
exactas de un mismo producto (problema que
1.
Introducción
La celebración en 1968 de la conferencia NA-
no existe en el caso del software), sino productos similares o variantes de un mismo producto
a bajo coste y en menos tiempo [18].
TO sobre Ingeniería del Software marca el na-
Numerosas aproximaciones han venido ofre-
cimiento de dicha disciplina [19]. La principal
ciendo aportaciones sobre estos y otros princi-
motivación para su celebración fue la crecien-
pios complementarios de factoría aplicados al
te necesidad de producir sistemas de software
software [8]. Uno de las aproximaciones más
más grandes, complejos y ables, de una ma-
importantes lleva el nombre de Líneas de Pro-
nera más controlada y eciente. Con ello se
ducto de Software [7], paradigma enriquecido
afrontaba lo que se denominó entonces la cri-
en los últimos años por la Ingeniería Dirigida
sis del software, la imposibilidad de las tecno-
por Modelos [24]. Esta aproximación se basa
logías de software de aquella época para satis-
en la idea de producir familias (o variantes si-
facer las demandas de la industria.
milares) de productos de software a partir de
En dicha conferencia se trataron temas de
un conjunto de activos reutilizables (denomi-
assets ) de una forma prescrita. Desarro-
do los correspondientes activos. Bajo deman-
llar un producto de la línea es más una cues-
da signica que incluiremos nuevos productos
tión de ensamblaje y conguración de activos
a medida que aparezca la necesidad de produ-
que de creación. Para cada línea de produc-
cirlos. La creación de activos es por tanto más
to debe haber una guía predenida o plan de
incremental y progresiva que con los modelos
producción que especica el proceso exacto de
de adopción anteriores (ver un ejemplo en [5]).
nados
obtención de cada producto. Esta aproxima-
Este tipo de modelo de adopción permite
ción ofrece así tecnologías para llevar a cabo
una transición poco invasiva desde una inge-
reutilización y automatización en los procesos
niería de software convencional, centrada en
de software.
un único producto, a una ingeniería basada en
La dicotomía entre ingeniería de dominio e
líneas de producto, centrada en la producción
ingeniería de aplicación es esencial en la apro-
de variantes de productos. Estas transiciones
ximación de Líneas de Producto de Softwa-
poco invasivas ofrecen dos ventajas principales
re [7]; es más, es la base de cualquier intento
[15]: la rápida consecución del ROI (
de reutilización y automatización en procesos
Return-ofInvestment ); y la posibilidad de seguir con los
de software [10]. Mientras en la ingeniería de
procesos de desarrollo normales de la empresa.
dominio creamos un conjunto de activos pa-
En este artículo proponemos un método re-
ra reutilizar y automatizar en un dominio de
activo para realizar una transición poco in-
aplicación especíco, en la ingeniería de aplica-
vasiva hacia la ingeniería basada en líneas de
ción los usamos para producir, en dicho domi-
producto de software. Esta aproximación está
nio, productos de software de mayor calidad,
pensada para aquellas empresas que quieran
empleando menos coste y tiempo.
automatizar sus procesos de desarrollo, en do-
En 2002, Krueger propuso la distinción en-
minios de aplicación especícos, a través de la
tre tres modelos de adopción/creación de lí-
creación de líneas de producto de software. Pa-
neas de producto de software [6]: proactivo,
ra ello, ofrecemos una solución basada en un
extractivo y reactivo.
desarrollo iterativo y desacoplado de activos,
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, crean-
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
Object Management
Reusable Asset Specication )
de dos estándares OMG (
Group )1 :
RAS (
[21], Especicación de Activos Reutilizables,
que permite identicar, describir y empaque-
Sof-
tar activos de manera estándar; y SPEM (
tware 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
la gestión del conocimiento; y exibilidad, pa-
de Software [2]. En aquel estudio, establecimos
ra producir variantes de los productos. Todas
que las líneas de producto de software apli-
éstas son facetas de la aplicación de ideas de
cadas al mantenimiento de familias de mode-
factoría a la producción de software [8].
los facilitan enormemente la Ingeniería Dirigi-
Aunque estas técnicas no son mutuamente
da por Modelos. El presente estudio muestra
excluyentes, no fue hasta nales del siglo XX
cómo esta clase de líneas de producto puede
que se desarrollaron sus sinergias y las tec-
ser encapsulada en activos reutilizables, has-
nologías necesarias para combinarlarlas efec-
ta que consiguen automatizar completamente
tivamente. Se realizaron importantes estudios
una tarea de desarrollo.
sobre los cambios organizativos necesarios pa-
En la Sección 2 explicamos la base concep-
ra una ecaz implantación de un programa de
tual de nuestro método. A continuación pre-
reutilización [25]. Se estableció que estos cam-
sentamos un caso de estudio (Sección 3) del
bios pasan por la creación de un nuevo rol, el
método. Finalizamos con un repaso a trabajos
analista o ingeniero de dominio, encargado de
relacionados (Seccion 4) y con las conclusiones
identicar, capturar, empaquetar y organizar,
(Seccion 5).
para su posterior reutilización, conocimiento
sobre cómo se llevan a cabo las distintas ta-
2.
reas de producción en dominios de aplicación
Antecedentes
especícos [23]. Los trabajos en metaprograA continuación ofrecemos un repaso a algunas
mación empezaron a ofrecer sus frutos apor-
tecnologías en las que se basa nuestro método,
tando nuevas técnicas para crear generadores
en concreto la especicación de activos reutili-
de aplicaciones y capturar en ellos los secre-
zables (RAS) y el metamodelo de procesos de
tos de la producción de software en dominios
software (SPEM). Sin embargo, antes que na-
especícos [10]. Se llega así a reveladores es-
da, ofrecemos una perspectiva histórica de la
tudios sobre reutilización que concluyen que
sinergia entre reutilización y automatización,
la identicación, conguración (o especializa-
en la que se basa nuestro método.
ción) e integración de artefactos reutilizables
requiere de herramientas de automatización,
2.1.
como generadores de aplicaciones o sistemas
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 con-
cepto de reutilización referirse a [13, 25]; sobre el concepto de automatización ver [8, 10]
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 con-
assets )
junto de activos (
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,
da por Modelos (
la
Ingeniería
Dirigi-
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-
asset )
nimos un activo reutilizable (
como la
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.
solución a un problema recurrente en el desarrollo de software. Debe tener, preferiblemente, puntos de variabilidad que deben ser con-
La (meta)información que describe el activo
gurados por el consumidor del activo con el
es un modelo que conforma con el metamodelo
n de congurarlo o especializarlo para un con-
RAS. Este modelo se empaqueta junto al resto
texto de uso determinado. Para una reutiliza-
de artefactos, dentro del chero comprimido
ción efectiva, la (meta)información de congu-
que representa al activo. Este modelo contiene
ración del activo debe ser precisa, normalmen-
la identicación y clasicación del activo, la
te en forma de especicación de proceso o se-
descripción de sus artefactos, sus puntos de
cuencia de pasos que pueda ser ejecutada de
variabilidad y cómo congurarlos.
manera, preferiblemente, automática.
2.3.
2.2.
Modelado de Activos Reutilizables
La especicación de activos reutilizables (
sable Asset Specication,
Reu-
RAS) [21] permite
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].
de manera estándar, cumpliendo los requisitos
Software Process Engineering Metamodel ) [22] es un lenguaje de modelado están-
para una reutilización efectiva descritos en la
dar que permite describir tales procesos.
identicar, describir y empaquetar un activo
SPEM (
sección anterior. Con RAS, un activo es una
El metamodelo de SPEM es muy extenso,
colección cohesiva de artefactos; de hecho, se
permitiendo el modelado de muchos aspec-
almacena como un chero comprimido que em-
tos y problemas del proceso de desarrollo. Sin
paqueta un conjunto de cheros, cada uno re-
embargo, en este estudio nos centraremos en
presentando uno de estos artefactos.
el modelado de tareas, sin ni siquiera utili-
Un artefacto es cualquier producto de tra-
zar relaciones de secuencia o prioridad entre
bajo creado durante un proceso de desarrollo,
las mismas. Las tareas, ejecutadas por roles,
como casos de uso, diagramas de clases, có-
consumen artefactos de entrada y producen
digo fuente, cheros de conguración XML,
artefactos de salida (ver Figura 1). Ejemplos
etc., que resuelven problemas recurrentes en
de artefactos son modelos de casos de uso, dia-
el desarrollo de software. Estos artefactos, por
gramas de clases, código fuente, cheros de
lo general, aceptarán cierta variabilidad, por
conguración XML, etc. Una tarea puede te-
lo que contarán con puntos de variabilidad o
ner asociado elementos de guía que ayuden al
extensión que podrán ser congurados para
rol a desempeñarla. Estos elementos pueden ir
adaptarlos a las características del problema
desde ejemplos y guías hasta plantillas y acti-
concreto (contexto) donde aplicarlos.
vos 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.
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.
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.
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
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
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.
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 conguració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 pro-
de conguración del activo permitirá generar
ductos para modelos de casos de uso. La Figu-
la nueva variante de modelos de casos de uso,
ra 4 muestra en SPEM el proceso a seguir. Por
para ser aplicada siempre que se repitan las
un lado crea el modelo de características que
condiciones que originaron su aparición.
caracteriza la familia de modelos de casos de
Es importante tener en cuenta que, como
uso, y una plantilla de modelos a partir de la
toda línea de productos, ésta que crea el ana-
cual generarlos. Asimismo, crea una transfor-
lista debe tener un dominio. En caso contrario,
mación de modelos para especializar automáti-
sería muy dicil establecer similitudes entre
camente la plantilla cuando queramos obtener
las variantes de modelos que se desea agrupar,
un miembro concreto de la línea.
esencial para producirlos a partir de un mismo
La Figura 5 muestra el plan de producción
conjunto de activos. En este caso suponemos
de la línea de producto para modelos de casos
que el analista A lleva analizando aplicacio-
de uso en el dominio RMS. Cuando un analis-
nes en el dominio de los sistemas de gestión de
ta de casos de uso la quiere ejecutar, sólo tiene
solicitudes (en adelante referidos como RMS:
que seleccionar una serie de características op-
Request Management Systems ) en la adminis-
cionales y alternativas del modelo de caracte-
tración electrónica. Ha establecido que muchos
rísticas (que dene la familia de modelos), en
de los modelos de casos de uso que sirven para
lo que se llama conguración de características
describirlos siguen unos patrones y comparten
del producto a generar. Esta conguración es
similitudes. Es por ello que decide automati-
la entrada de una transformación de modelos
zar la creación de estos modelos en el dominio
que automáticamente especializa una plantilla
RMS.
de modelos para obtener el modelo de casos de
Creación del Proceso de Conguración
uso concreto deseado.
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-
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).
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 conguració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
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.
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
En segundo lugar debemos empaquetar los
tres artefactos creados durante la ingeniería de
dominio de la Figura 4, junto con la especica-
casos de uso es ahora denominado Analista
RMS (ver Figura 8); esto enfatiza el cambio
de responsabilidades del analista.
ción del proceso de conguración, que en este
Con ello ganamos dos cosas: obligar a seguir
caso es el modelo SPEM de la Figura 5. Den-
patrones y buenas prácticas de modelado que
tro del activo, junto a estos cuatro artefactos,
los analistas realizando esa tarea han ido esta-
empaquetaremos también el modelo del activo
bleciendo progresivamente (mientras se creaba
(manifest.rmd) así como el metamodelo RAS
el activo); y centralizar el conocimiento para
(ras.ecore). Este último no es necesario, pero
ayudar a nuevos analistas a aprender a realizar
es una buena práctica que aumenta la compa-
dicha tarea.
tibilidad entre herramentas RAS. La Figura 6
muestra el contenido del activo RAS.
3.2.
Automatización de la Tarea
4.
Traba jos relacionados
Una aproximación poco invasiva a la creación
de líneas de producto de software es presen-
Hasta ahora, el proceso de desarrollo de la em-
tada en [14, 5]. Aunque plantea una incorpo-
presa se ha visto modicado únicamente por
ración incremental de productos a la línea, no
la inclusión de un elemento de guía, en este
plantea la automatización incremental del pro-
caso un activo reutilizable. Al ser modelado
ceso de desarrollo, ni abordar la reutilización
como elemento de guía es opcional, es decir, el
y automatización de tareas de manera desaco-
plada. En esta aproximación, la incorporación
Referencias
de productos a una línea de producto de software es incremental, pero su automatización
[1] O. Avila-García and M. D. D. Fabro.
no lo es; la incorporación de un nuevo producto
AMW use case: Mapping features to mo-
se aborda creando toda infraestructura nece-
dels. Technical Report MST-9, Open Ca-
saria para su generación automática desde el
narias, S.L., Apr 2007.
principio.
El Desarrollo Basado en Activos (
Asset Ba-
sed 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.
[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
JISBD 2006:
Proceedings of the XI Jornadas de Ingeniería del Software y Bases de Datos, paen una herramienta mda. In
ges 483488, Barcelona, Spain, Oct 2006.
CIMNE.
5.
Conclusiones
[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 fami-
producto de software. Esta aproximación está
SAC
2007: Proceedings of the 2007 ACM Symposium on Applied Computing, track on
Model Transformation, pages 10061011.
pensada para aquellas empresas que quieran
ACM Press, Mar 2007.
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
lies in model-driven engineering. In
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 )
[4] R. W. Bremer.
Machine-controlled pro-
duction environment.
In P. Naur and
Software Engineering: Report on a conference sponsored by
the NATO Science Committee, Garmish,
Germany, 7th to 11th October 1968, paB. Randell, editors,
ges 9495. Scientic Aairs Division, NATO, 1969.
[5] R. Buhrdorf, D. Churchett, and C. W.
Krueger.
Salion's experience with a re-
active software product line approach.
PFE 2003: Software Product-Family
Engineering, 5th International Workshop,
volume 3014 of LNCS, pages 317322.
In
Springer, Nov 2003.
[21], especicación de activos reutilizables y
Software Process Engineering Metamodel ) [22], metamodelo de ingeniería de proSPEM (
[6] P. Clements and C. W. Krueger.
IEEE Software, pages 2831,
cesos de software. Mediante un ejemplo hemos
tion barrier.
mostrado cómo la combinación del empaque-
July/August 2002.
tado de activos con RAS y el modelado de pro-
Being
proactive pays o / eliminating the adop-
tización progresiva de las tareas en el proceso
Software Product Lines: Practices and Patterns.
de desarrollo de la empresa.
Addison Wesley, Aug 2001.
cesos con SPEM puede llevar a una automa-
[7] P. Clements and L. Northrop.
[8] M. A. Cusumano. The software factory: A
historical interpretation.
IEEE Software,
6(2):2330, 1989.
[9] K. Czarnecki and M. Antkiewicz.
Map-
ping features to models: A template approach based on superimposed variants.
In
Proceedings of GPCE 2005, volume
LNCS, pages 422437. Springer-
3676 of
Verlag, 2005.
Generative Programming: Methods, Tools, and
Applications. Addison-Wesley, 2000.
[10] K. Czarnecki and U. Eisenecker.
[11] J.-C. Dermiane and F. Oquendo. Key issues and new challenges in software pro-
UPGRADE: The European Journal for the Informatics Professional, V(5):1116, Oct 2004.
cess technology.
[12] M. L. Griss.
Software reuse: from li-
IBM Systems Journal,
brary to factory.
32(4):548566, 1993.
[13] C. W. Krueger.
Software reuse.
ACM
Comput. Surv., 24(2):131183, 1992.
[14] C. W. Krueger.
Easing the transition
PFE
'01: Revised Papers from the 4th International Workshop on Software ProductFamily Engineering, pages 282293, Lon-
to software mass customization. In
don, UK, 2002. Springer-Verlag.
[15] C. W. Krueger.
New methods behind a
138152. Scientic Aairs Division, NATO, 1969.
Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th
October 1968. Scientic Aairs Division,
[19] P. Naur and B. Randell, editors.
NATO, 1969.
[20] OMG.
01,
IBM Systems Journal,
[17] J. D. McGregor.
3(10):89
98, Nov/Dec 2004 2004.
Mass produced softwa-
re components. In P. Naur and B. Ran-
Software Engineering: Report on a conference sponsored by the NATO Science Committee, Garmish, Germany, 7th to 11th October 1968, pages
dell, editors,
at
asset
Technical
06-06,
Jun
Report
2004.
specicaptc/04-
Available
at
http://www.omg.org/docs/ptc/0406-06.pdf.
[22] OMG.
Software
ring
Meta-model
port
ad/06-04-05,
Process
2.0.
Apr
Enginee-
Technical
2006.
Re-
Availa-
ble at http://www.omg.org/docs/ad/0604-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 Enginee-
IEEE Computer,
39(2):4147, Feb
Confessions of a Used Program Salesman: Institutionalizing Software Reuse. Addison Wesley, Reading, Mas-
[25] W. Tracz.
sachusetts, USA, 1995.
Product production.
Journal of Object Technology,
[18] M. D. McIlroy.
Available
Reusable
tion.
2006.
sets and reuse.
1.0.1.
omg/2003-06-
2003.
[21] OMG.
successes. Technical Report #200602261,
45(3), 2006.
Jun
version
06-01.pdf.
new generation of software product line
[16] G. Larsen. Model-driven development, as-
guide
Report
http://www.omg.org/docs/omg/03-
ring.
BigLever Software, Inc., Feb 2006.
MDA
Technical
[26] S. Trujillo, D. Batory, and O. Díaz. Feature refactoring a multi-representation pro-
GPCE 2006:
Proceedings of the 5th International Conference on Generative Programming and
Component Engineering, pages 191200,
gram into a product line. In
New York, NY, USA, Oct 2006. ACM
Press.