Fábricas de Software y Líneas de Productos

Universidad de los Andes

1. Técnicas de Implementación de Variabilidad

Esta lectura describe un conjunto de técnicas para implementar la variabilidad en
una línea de productos de software.

1.1. Clasificación de las Técnicas de Implementación de Variabilidad

Una vez establecida la variabilidad que se desea en una Línea de Productos de
Software, es posible utilizar una o más técnicas de implementación de variabilidad.
Existen varios enfoques que pueden usarse [1][2]. Los ingenieros suelen
seleccionar cuál de las técnicas usar de acuerdo con el tiempo de resolución que
se desea aplicar y los tipos de lenguajes y herramientas a usar.

1.1.1. Tiempo de Resolución de Variabilidad

La variabilidad implica decisiones [1]. Al momento de construir uno de los
productos de la línea, los ingenieros de aplicación deciden primero que
características deben hacer parte del producto. La configuración de cada producto
representa esas decisiones. Luego, como parte del desarrollo, es necesario
“resolver esas decisiones”, es decir, es necesario determinar que activos,
componentes, segmentos de código o demás, se deben reutilizar para construir el
producto.

Definición 1. Resolución de decisiones (Binding of decisions)

La actividad de resolver una decisión consiste en determinar e integrar al
producto los activos de la línea que corresponden con la configuración (con las
decisiones) de ese producto particular.

Diferentes técnicas de implementación de la variabilidad permiten diferentes

tiempos de resolución. Por ejemplo, dependiendo de la técnica de
implementación, es posible que la decisión se resuelva al momento de construir el
programa, al momento de compilar o durante la ejecución del programa.

1
 Definición 2. Tiempo de Resolución (Binding time)
Dentro de una línea de productos de software, el tiempo de resolución es el
momento en el ciclo del desarrollo de un producto en donde las decisiones son
resueltas. Dependiendo de la técnica de implementación, es posible que la
decisión deba resolverse siempre en un momento determinado del desarrollo
(p.ej. durante la compilación) o que existan diferentes momentos en donde se
pueda resolver (p.ej. que la misma técnica permita resolver la decisión en
tiempo de compilación y en tiempo de ejecución).

Existen varias clasificaciones de tiempo de resolución. En este módulo usaremos la

clasificación de Apel et al. [1] donde el tiempo de resolución se clasifica en tres: (1)
tiempo de compilación, (2) tiempo de carga del programa y (3) tiempo de
ejecución.

 Variabilidad en tiempo de compilación (compile-time variability), cuando los

activos y las variantes a utilizar en un producto son decididas antes o durante
el proceso de compilación del software. En estos casos, normalmente los
activos seleccionados se incluyen en el programa ejecutable y los que no son
seleccionados no se incluyen en el mismo.
 Variabilidad en tiempo de carga (load-time variability), cuando la variante es
seleccionada al momento de iniciar el programa. Normalmente, el programa
ejecutable incluye todos o varios de los activos y variantes de la línea, pero solo
se activan algunos de ellos de acuerdo con parámetros de línea de comandos
o la configuración del producto, al momento de arrancar el programa.
 Variabilidad en tiempo de ejecución (run-time variability), cuando las
decisiones son resueltas durante la ejecución del programa. Incluso, es posible
que las decisiones (la configuración) cambien en tiempo de ejecución de
acuerdo con el contexto o las opciones que ejecuta el usuario.

Cada uno de los tiempos de resolución puede tener ventajas diferentes [1].
Típicamente, la variabilidad en tiempo de compilación permite un número mayor
de optimizaciones. El compilador puede remover todo el código innecesario y
realizar optimizaciones en tamaño y tiempo de ejecución del programa. Sin
embargo, por otro lado, una vez generado el programa ejecutable, ya no es
posible cambiar las decisiones.

En contraste, la variabilidad en tiempo de carga y en tiempo de ejecución,

permiten cambiar las decisiones (cambiar su configuración) después de compilar
el programa. Normalmente la variabilidad en tiempo de carga es más simple, ya
que al hacer cambios en tiempo de ejecución es necesario asegurarse que la
reconfiguración no afecta el funcionamiento del programa. La variabilidad en

2
tiempo de ejecución normalmente se relaciona también con técnicas de
Programación orientada a Contexto y Sistemas Autoadministrados (self-* systems).

1.1.2. Tipos de tecnologías para Implementar Variabilidad

Definición 3. Tipo de Tecnología de Implementación de Variabilidad
El tipo de tecnología para implementar la variabilidad es el lenguaje de
programación, elementos del lenguaje de programación o herramientas
adicionales que son utilizadas para construir los activos de la línea y derivar los
productos a partir de estos activos.

Las técnicas de implementación de variabilidad pueden clasificarse de acuerdo

con tipo de tecnología que usan. De acuerdo a Apel et al. [1], las técnicas pueden
clasificarse si los mecanismos de implementación: (1) están basados en el
lenguaje, o (2) están basados en herramientas.

 Aproximaciones basadas en el lenguaje (language-based approaches), son las

técnicas que usan mecanismos que provee el lenguaje.
 Aproximaciones basadas en herramientas (tool-based approaches), técnicas
que usan una o más herramientas externas para implementar o representar
las características en el código y controlar la derivación del producto.

Por ejemplo, entre las aproximaciones basadas en el lenguaje, es posible usar

condiciones (del tipo “if”) para implementar variabilidad en tiempo de carga o en
tiempo de ejecución. Esta solución no requiere ninguna herramienta adicional y
basta con el uso del compilador del lenguaje.

Como ejemplo de las aproximaciones basadas en herramientas, es posible

mencionar aquellas que usan preprocesadores. Un preprocesador es una
herramienta que revisa el código fuente y realiza ajustes a los programas antes de
la compilación. Estas herramientas son usadas, por ejemplo, en el código fuente
de Linux en C para incluir o excluir partes del programa de acuerdo con la
configuración definida para el kernel. El código fuente de Linux incluye
instrucciones del tipo “#ifdef“, que son revisadas por el preprocesador.

Entre las aproximaciones basadas en herramientas podemos mencionar algunas

que se usan cuando se implementan los activos usando componentes de
software. Normalmente, los componentes se construyen por separado y cada uno
de los productos incluyen un archivo que define cuáles componentes deben ser
incluidos y combinados. Por ejemplo, en tecnologías como SCA y Maven es posible

3
usar archivos “*.composite” y “pom.xml”, respectivamente, para especificar los
componentes que deben incluirse en un producto específico.

1.1.3. Tipos de representación de la Variabilidad

Definición 4. Tipo de Representación de la Variabilidad
El tipo de representación de la variabilidad es el esquema utilizado para
representar y delimitar cada una de las características y variantes en el código
fuente y para indicar la forma como los productos se generan a partir de las
características señaladas en la configuración de un producto.

Diferentes técnicas de implementación de variabilidad pueden delimitar las

características de forma diferente. Por ejemplo, mientras algunas técnicas definen
todas las características en el mismo código fuente, otras construyen cada activo
por separado y luego las combinan. De acuerdo con Apel et al. [1], la
representación de la variabilidad se puede clasificar en: (1) técnicas basadas en
anotaciones y (2) técnicas basadas en composición.

 Aproximaciones basadas en anotaciones (annotation-based approaches),

técnicas en donde todas las características hacen parte de la misma base de
código. En estas técnicas, el código está anotado para señalar que partes
hacen parte de cada característica.
 Aproximaciones basadas en composición (composition-based approaches),
son las técnicas en donde el código que pertenece a una característica o
combinación de características está definida en un archivo, contenedor o
módulo aparte. Cada producto se construye combinando estos componentes.

Un ejemplo de aproximación basada en anotaciones son los programas que

implementan la variabilidad usando preprocesadores. Por ejemplo, en el sistema
operativo Linux, el código en C incluye todas las opciones. El procesador revisa el
código fuente para incluir y excluir parte del código de acuerdo con las
características seleccionadas para un producto determinado.

Un ejemplo de aproximación basada en composición son los sistemas que se

pueden extender usando plug-ins. Por ejemplo, entornos de desarrollo como
Eclipse y Netbeans, pueden ser configurados para incluir plug-ins diferentes. Dos
usuarios pueden tener dos instancias del mismo entorno con funcionalidades
completamente diferentes. Normalmente, cada plug-in está localizado en código
fuente y archivos ejecutables por aparte y se combinan solo al momento de
ejecutar la aplicación.

4
Uno de los principales retos de las aproximaciones basadas en composición es
mantener las correspondencias (el mapping) entre las características, el espacio
del problema, y las unidades de composición, el espacio de soluciones. Aunque
idealmente se puede tener una correspondencia uno-a-uno, en muchas ocasiones
no es tan simple y una misma característica puede requerir más una unidad de
composición. Además, es posible que ciertas combinaciones de características
requieran combinaciones diferentes de esas unidades.

Otra forma de ver las diferencias entre anotación y composición es que las
aproximaciones basadas en anotaciones soportan variabilidad negativa, donde el
código es removida por demanda, mientras las técnicas basadas en composición
soportan variabilidad positiva, donde las unidades de composición son agregadas
y/o combinadas por demanda. Igualmente, se dice que las técnicas basadas en
anotaciones hacen una separación virtual de las preocupaciones, mientras las
técnicas basadas en composición hacen una separación física de las
preocupaciones. La Tabla 1 describe algunas de estas diferencias.

Tabla 1. Algunas diferencias entre los tipos de representación de variabilidad

Técnicas basadas en Técnicas basadas en
anotaciones composición
Ubicación de las En la misma base de código En unidades de composición
características separadas
Tipo de separación Separación virtual Separación física
de preocupaciones
Identificación de Anotaciones que señalan el Correspondencias (mapeo)
código de cada código por característica entre características y
característica unidades de composición.
Tipo de derivación Variabilidad negativa, Variabilidad positiva: agrega
remueve código por unidades por demanda
demanda

En la práctica, una misma línea de productos puede combinar diferentes técnicas

de implementación de variabilidad. Es posible que, mientras una parte de las
decisiones se implemente usando técnicas basadas en anotaciones, otra se
implemente a través de composición.

5
1.2. Técnicas de Implementación de Variabilidad
Existen una gran variedad de técnicas que se pueden emplear para implementar
la variabilidad de una línea de productos [1][2]. A continuación, se describen
algunas de las técnicas más representativas.

1.2.1. Clonar y desarrollar por aparte (clone and own)

La forma más fácil de producir una variante de un determinado producto de
software es copiar un producto existente y modificarlo para adoptar los nuevos
requisitos. Este enfoque se conoce como “clone and own”[3].

Las empresas que aplican este tipo de técnicas buscan aprovechar herramientas
de control de versiones (como SVN o Git) para reducir el esfuerzo de desarrollo.
Por ejemplo, si en uno de los productos una funcionalidad es desarrollada o un
error es corregido, estas empresas podrían usar estas herramientas para aislar las
modificaciones (generando una diferencia, diff) e intentar hacer los cambios en
otro producto (aplicando un parche, patch). Lamentablemente, es posible que esto
no sea posible y se requiera escribir el código de nuevo en cada producto.

En realidad, muchos autores no consideran “clonar y desarrollar por aparte” una

técnica de implementación apropiada para líneas de productos de software. Note
que las LPS se basan en construir todos los productos a partir de los mismos
activos y con el mismo proceso de desarrollo. La técnica de “clone and own”
representa el tipo de prácticas que pueden llevar a repetir trabajo y a no reutilizar
código que se buscan reemplazar con la ingeniería de líneas de producto.

Definición 5. Clonar y desarrollar por aparte (clone and own)

La estrategia de clonar y desarrollar por aparte consiste en crear copias del
código fuente para cada producto o cliente y realizar cambios en todas las
copias. Esta estrategia intenta usar herramientas de control de versiones para
replicar los cambios en un producto en los otros. Sin embargo, eso no siempre
es posible. Esta estrategia que puede generar problemas en el mantenimiento
de las aplicaciones.

6
 1.2.2. Parámetros y Condiciones en el Código Fuente
La forma más simple de implementar toda una LPS en el mismo código fuente
puede ser mediante la codificación explícita de la variabilidad usando estructuras
condicionales (p. ej., usando estructuras “if-then-else”). Para activar o desactivar
este código condicional, los programas pueden revisar parámetros de tiempo de
ejecución (es decir, argumentos que se pasan por la línea de comandos) o archivos
de texto que contienen la configuración del producto. También es posible usar
constantes globales en los programas. Cuando se usa esta estrategia, el código
está habilitado o modificado en función de los parámetros dados, y la variabilidad
se resuelve en tiempo de ejecución.

Definición 6. Uso de Parámetros

La técnica de uso de parámetros consiste en leer la configuración del programa al
momento de iniciar la ejecución del programa. La configuración se lee de los
argumentos pasados en la línea de comandos o de un archivo de configuración
predefinido.
Clasificación:
 Resolución de decisiones en tiempo de carga
 Tecnología: basada en el lenguaje, usa condiciones del tipo if-then-
else
 Representación por anotaciones, todas las características en la misma
base de código.

1.2.3. Patrones de Diseño y Programación Orientada a Objetos

Uno de los inconvenientes del uso de parámetros es que el código de las
características resulta disperso a través de todo el código. Además, las condiciones
quedan “quemadas” en el código. En el desarrollo orientado a objetos esto se
considera una mala práctica. Existen varios autores que han propuesto patrones
de diseño que permiten organizar mejor el código [4] y, por ejemplo, lograr
desacoplar las diferentes variantes del programa en clases y paquetes de clases
aparte [5].

En particular, existen patrones de diseño como Observador, Método-Plantilla,

Estrategia y Decorador que permiten crear variantes de la misma estructura o del
mismo algoritmo y seleccionar una de estas alternativas en tiempo de ejecución.
Existen varias propuestas que usan estos patrones para diseñar e implementar los
activos de la línea de productos.

7
 Definición 7. Uso de Patrones de Diseño
La técnica de uso de patrones de diseño consiste en crear un diseño orientado a
objetos para toda la línea de productos, usando patrones como Decorador y
Estrategia para implementar las características que son opcionales o que hacen
parte de grupos alternativos. Normalmente, el uso de patrones requiere
también del uso de parámetros ya que las clases a utilizar se determinan a
partir de parámetros obtenidos a través de argumentos de la línea de
comandos o archivos de configuración.
Clasificación:
 Normalmente, resolución de decisiones en tiempo de carga. Existen
algunas herramientas que soportan la implementación de algunos
patrones (p.ej. agregando decoradores) en tiempo de compilación. Sin
embargo, no es tan frecuente.
 Tecnología: basada en el lenguaje, usa clases en lenguajes orientados a
objetos
 Representación por composición, todas las características se construyen
usando clases aparte que se combinan o reemplazan de acuerdo con la
configuración de la aplicación.

1.2.4. Frameworks
En lenguajes orientados a objetos como Java, otra técnica muy popular es el uso
de Frameworks o Marcos de Trabajo. Un Framework es un conjunto de clases
incompleto, que puede ser extendido y personalizado para un propósito
específico [6]. En lugar de construir toda la aplicación desde cero, los
desarrolladores solo construyen “lo que hace falta”. El Framework constituye una
base reutilizable para la implementación de todos los productos.

Los Frameworks proveen puntos explícitos de extensión, llamados hot spots, donde
los desarrolladores pueden agregar su código. A menudo, estas extensiones se
conocen como plug-ins, cuando se pueden seleccionar cuáles extensiones se
deben incluir en un producto. En el desarrollo de LPS, el ideal podría ser construir
un plug-in para cada una de las características. Sin embargo, esto no siempre es
posible.

8
 Definición 8. Uso de Frameworks
La técnica de uso de frameworks consiste en desarrollar los activos y líneas de
producto creando extensiones y plug-ins para un framework existente. Un
framework es un conjunto de clases que (1) representa un diseño abstracto para
soluciones a problemas similares y (2) soporta el reuso a un mayor nivel de
granularidad que las clases. Los framework están abiertos a extensiones en
puntos específicos conocidos como hot spots.
Clasificación:
 Normalmente, resolución de decisiones en tiempo de carga. Existen
algunos framework que soportan la resolución de variabilidad en tiempo
de compilación.
 Tecnología: basada en el lenguaje, usa clases en lenguajes orientados a
objetos
 Representación por composición, todas las características se construyen
usando extensiones o plug-ins aparte que se combinan o reemplazan
de acuerdo con la configuración de la aplicación.

1.2.5. Componentes y Servicios

Otra técnica ampliamente utilizada es el uso de componentes y servicios (p.ej.
servicios web y microservicios) [1]. En estas técnicas, el software es construido a
través de unidades modulares y reutilizables. En los componentes, (1) la
funcionalidad se ofrece a través de interfaces de programación (a través de APIs) y
(2) la implementación interna es encapsulada. Cualquier programa puede usar un
componente solo conociendo su interfaz, sin requerir conocimiento sobre su
funcionamiento interno. En el desarrollo basado en componentes, el software se
construye componiendo (composing) o enlazando unos componentes con otros.

Los servicios pueden verse como una forma especial de componentes que pueden
funcionar remotamente [1]. En los servicios, normalmente la funcionalidad se
ofrece a través de interfaces de programación (APIs) sobre protocolos de
comunicación específicos. De esta forma, por ejemplo, es posible usar servicios
que proveen empresas externas como Google o Twitter, sin importar que
lenguajes de programación o que plataformas ellos usan. Normalmente, cuando
se integran servicios que funcionan en locaciones o que son proveídos por varias
empresas, se dice que se están orquestando servicios. Aunque existen varias
diferencias que pueden ser significativas entre componentes y servicios, para
efectos de la discusión inicial, no haremos una mayor distinción entre ellos.

El desarrollo de LPS basado en componentes es similar al desarrollo de LPS

usando plug-ins. Básicamente, el ideal es lograr desarrollar un componente o
servicio por cada característica. Sin embargo, a diferencia de los frameworks donde

9
la aplicación funciona siguiendo un diseño preestablecido, el desarrollo basado en
componentes reutiliza los componentes, pero no tiene un esquema de
funcionamiento pre-definido. Se requiere de código pegamento (glue code) que
conecte y haga interactuar los componentes.

Definición 9. Uso de Componentes y Servicios

La técnica de uso de componentes y servicios consiste en desarrollar los activos
como componentes y servicios individuales, y desarrollar los productos
mediante la composición o la orquestación de estos componentes y servicios.
Clasificación:
 Dependiendo de la plataforma y el lenguaje, puede ser resolución de
decisiones en tiempo de carga o en tiempo de compilación.
 Dependiendo de la plataforma y el lenguaje, puede ser tecnología:
basada en el lenguaje o basada en herramientas.
 Representación por composición, todas las características se construyen
usando componentes o servicios aparte que se componen o se
orquestan de acuerdo con la configuración de la aplicación.

1.2.6. Herramientas de Construcción (Build)

Otra de las opciones de implementación de variabilidad es mediante el uso de
herramientas de construcción. Herramientas especializadas como make, ant o
maven, permiten definir un proceso de construcción del software. Este proceso
puede definir parámetros de compilación, seleccionar librerías, componer
componentes y/o incluir pasos adicionales durante el proceso de construcción. En
muchas ocasiones es posible incluir variabilidad en los procesos de construcción y,
de acuerdo con algún tipo de configuración, producir un producto diferente.

Definición 10. Uso de Herramientas de Construcción

La técnica de uso de herramientas de construcción consiste en utilizar las
funcionalidades de estas herramientas para introducir variabilidad en tiempo de
compilación. Básicamente, la línea de productos puede usar parámetros de
estas herramientas de construcción o diferentes scripts con la definición del
proceso para construir varios productos a partir de los mismos activos y base de
código.
Clasificación:
 Resolución de decisiones en tiempo de carga o en tiempo de compilación.
 Tecnología basada en herramientas.
 Típicamente usa representación por composición, donde las
características está en un archivo aparte y la herramienta decide si
incluir o no estos archivos. Algunas herramientas pueden usar
representación por anotaciones.

10
11
 1.2.7. Preprocesamiento y Compilación condicional
Una de las técnicas más utilizadas para implementar la variabilidad es la
compilación condicional usando preprocesadores. Herramientas de
preprocesamiento como el conocido C preprocessor (cpp), usan anotaciones en
forma de “directivas” para señalar fragmentos de código que se deben incluir o
excluir durante la compilación. CPP se utiliza en la mayoría de los proyectos C y C+
+, y se aplica para la variabilidad de productos ampliamente conocidos como
sistemas operativos (p.ej. Linux) y sistemas de bases de datos (p.ej., PostgreSQL y
MySQL).

Existen varias críticas al uso de preprocesadores para la implementación de

variabilidad [1]: Varios autores prefieren una solución donde la variabilidad se
pueda ver en la arquitectura de la solución, como cuando se usan patrones de
diseño, frameworks y componentes [7]. Otros hablan de la dificultad de resolver
algunos problemas de mantenimiento. Sin embargo, el uso de preprocesadores es
muy común y, en años recientes, han surgido muchas herramientas de análisis
estático que potencian el uso de esta técnica.

Definición 11. Uso de Preprocesadores y compilación condicional

La técnica de uso de preprocesadores consiste en anotar el código señalando el
código que se relaciona con cada característica. Luego, antes de compilar el
código, un preprocesador elimina el código de las características que no hacen
parte de la configuración. Se dice que parte del código tiene compilación
condicional ya que se compila solo si la característica correspondiente está
seleccionada.
Clasificación:
 Resolución de decisiones en tiempo de compilación.
 Tecnología basada en herramientas.
 Representación por anotaciones, ya que todas las características están
en la misma base de código.

1.2.8. Programación orientada a características

El objetivo de los framework, componentes y servicios es lograr la separación de
preocupaciones (es decir, que las características se implementen por separado).
Sin embargo, estos enfoques se basan en las interfaces proporcionadas que
utilizan para interactuar entre sí. Eso que hace estos enfoques inflexibles si no se
pueden adaptar las interfaces. La programación orientada a características
(feature-oriented programming. FOP) es un enfoque más flexible que permite
extender programas existente [1][8]. En lugar de implementar interfaces dadas, la

12
programación basadas en características es capaz de refinar el código existente,
por ejemplo, reemplazando un método o introduciendo nuevas clases.

Definición 12. Programación basada en características

La técnica de programación basada en características consiste en usar lenguajes y
herramientas que permiten definir características que “refinan” el código, por
ejemplo, para modificar el código de un método o agregar uno nuevo.
Clasificación:
 Resolución de decisiones en tiempo de compilación. Algunas
herramientas, p.ej., en Java, permiten refinar las clases la primera vez
que estas clases se cargan en memoria. Estas herramientas también
hacen resolución en tiempo de carga.
 Puede usar tecnología basada en lenguajes o basada en herramientas.
 Representación por composición, ya que las características se
construyen en unidades (archivos) separados.

1.2.9. Programación orientada a aspectos

La programación orientada a aspectos tiene un objetivo similar a la programación
orientada a características [9]. En lugar de depender de interfaces, un aspecto
puede directamente cambiar el código existente para realizar la variabilidad. En
contraste con la programación orientada a características, un aspecto puede
implementar cambios transversales (cross-cutting concerns) eficientemente. Un
cambio transversal es un cambio o una extensión a la funcionalidad que afecta a
varias partes de un programa. Por ejemplo, para agregar opciones de auditoría, un
aspecto podría agregar una funcionalidad a todos los métodos y todas las clases
del programa.

Definición 12. Programación basada en aspectos

La técnica de programación basada en aspectos consiste en usar lenguajes y
herramientas que permiten definir aspectos, modificaciones al código, por
ejemplo, para modificar el código de un método o agregar uno nuevo. A
diferencia de las características, los aspectos pueden aplicarse a varias clases a
la vez y pueden implementar cambios transversales (cross-cutting concerns).
Clasificación:
 Resolución de decisiones en tiempo de compilación. Algunas
herramientas, p.ej., en Java, permiten introducir aspectos la primera vez
las clases se cargan en memoria. Estas herramientas también hacen
resolución en tiempo de carga.
 Puede usar tecnología basada en lenguajes o basada en herramientas.
 Representación por composición, ya que las características se
construyen en unidades (archivos) separados.

13
14
 1.2.10. Clasificación de las Técnicas de Implementación de
Variabilidad
La Tabla 2 presenta la clasificación de las técnicas de implementación de
variabilidad mencionadas arriba.

Tabla 2. Clasificación de algunas técnicas de implementación de variabilidad.

Tiempo de Enlace Tecnología Representación

Tiempo T. De Lenguaje Herramienta Anotación Composición

Compilació Carga o
n Ejecución

Parámetros ✓ ✓ ✓
Patrones de (✓)* ✓ ✓ ✓
Diseño

Frameworks (✓)* ✓ ✓ ✓
Componentes ✓ ✓ ✓ ✓ ✓
Construcción ✓ ✓ (✓)* ✓
(Build)

Preprocesador ✓ ✓ ✓
Feature- ✓ (✓)* ✓ (✓)* ✓
oriented
Programming

Aspect- ✓ (✓)* ✓ (✓)* ✓

oriented
Programming

Es importante mencionar que esta clasificación está basada en el trabajo de Apel

et al. [1]. En su libro, ellos hacen una comparación más extensa de estas y otras
técnicas de implementación, comparando atributos de calidad y consideraciones
para cada uno de ellos.

15
1.3. Para saber más
En el libro de Apel et al. “Feature Oriented Programming”, el capítulo 3 ofrece una
descripción de las diferentes técnicas de implementación de variabilidad en LPS.
Luego, los capítulos el 4 al 7 describen en detalle cada una de ellas.
 S. Apel, D. Batory, C. Kästner, and G. Saake, Feature-Oriented Software
Product Lines. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.

El libro de Meinicke et al. “Mastering Software Variability with FeatureIDE” presenta

técnicas y ejercicios para implementar algunas de estas técnicas de
implementación de variabilidad usando el entorno de desarrollo FeatureIDE.
 J. Meinicke, T. Thüm, R. Schröter, F. Benduhn, T. Leich and G. Saake.
Mastering Software Variability with FeatureIDE. Springer. 2017.

1.4. Referencias
[1] S. Apel, D. Batory, C. Kästner, and G. Saake, Feature-Oriented Software Product
Lines. Berlin, Heidelberg: Springer Berlin Heidelberg, 2013.
[2] J. Meinicke, T. Thüm, R. Schröter, F. Benduhn, T. Leich, and G. Saake, Mastering
Software Variability with FeatureIDE. Cham: Springer International Publishing, 2017.
[3] Y. Dubinsky, J. Rubin, T. Berger, S. Duszynski, M. Becker, and K. Czarnecki, “An
Exploratory Study of Cloning in Industrial Software Product Lines,” in 2013 17th
European Conference on Software Maintenance and Reengineering, 2013, pp. 25–34.
[4] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design patterns : elements of
reusable object-oriented software. Addison-Wesley, 1995.
[5] K. Czarnecki and U. Eisenecker, Generative programming : methods, tools, and
applications. Addison Wesley, 2000.
[6] R. E. Johnson, R. E. Johnson, and B. Foote, “Designing reuseable classes,” J. OBJECT-
ORIENTED Program., 1988.
[7] J. Meinicke, T. Thüm, R. Schröter, F. Benduhn, T. Leich, and G. Saake, Mastering
Software Variability with FeatureIDE. Cham: Springer International Publishing, 2017.
[8] D. Batory and S. O’Malley, “The design and implementation of hierarchical
software systems with reusable components,” ACM Trans. Softw. Eng. Methodol.,
vol. 1, no. 4, pp. 355–398, Oct. 1992.
[9] G. Kiczales et al., “Aspect-oriented programming,” Springer, Berlin, Heidelberg,
1997, pp. 220–242.

16