Programación orientada a características

En programación informática , la programación orientada a características ( FOP ) o el desarrollo de software orientado a características ( FOSD ) es un paradigma de programación para la generación de programas en líneas de productos de software (SPL) y para el desarrollo incremental de programas.

FOSD surgió a partir de diseños basados ​​en capas y niveles de abstracción en protocolos de red y sistemas de bases de datos extensibles a finales de la década de 1980. ^{[ 1 ]} Un programa era una pila de capas. Cada capa añadía funcionalidad a capas previamente compuestas y diferentes composiciones de capas producían diferentes programas. Como era de esperar, existía la necesidad de un lenguaje compacto para expresar tales diseños. El álgebra elemental cumplía con los requisitos: cada capa era una función (una transformación de programa ) que añadía código nuevo a un programa existente para producir un nuevo programa, y ​​el diseño de un programa se modelaba mediante una expresión, es decir, una composición de transformaciones (capas). La figura de la izquierda ilustra el apilamiento de las capas i, j y h (donde h está en la parte inferior e i en la superior). Las notaciones algebraicas i(j(h)), i•j•h e i+j+h se han utilizado para expresar estos diseños.

Con el tiempo, las capas se equipararon a características, donde una característica es un incremento en la funcionalidad del programa. Se reconoció que el paradigma para el diseño y la generación de programas era una consecuencia de la optimización de consultas relacionales, donde los programas de evaluación de consultas se definían como expresiones de álgebra relacional, y la optimización de consultas era la optimización de expresiones. ^{[ 2 ]} Una línea de productos de software es una familia de programas donde cada programa se define por una composición única de características. Desde entonces, FOSD ha evolucionado hacia el estudio de la modularidad de características, herramientas, análisis y técnicas de diseño para apoyar la generación de programas basada en características.

La segunda generación de investigación en FOSD se centró en las interacciones de características, que se originaron en las telecomunicaciones. Posteriormente, se acuñó el término programación orientada a características ; ^{[ 3 ]} este trabajo expuso las interacciones entre capas. Las interacciones requieren que las características se adapten al combinarse con otras características.

Una tercera generación de investigación se centró en el hecho de que cada programa tiene múltiples representaciones (por ejemplo, código fuente, makefiles, documentación, etc.) y que agregar una característica a un programa debería desarrollar cada una de sus representaciones para que todas sean consistentes. Además, algunas representaciones podrían generarse (o derivarse) de otras. En las secciones siguientes, se describen las matemáticas de las tres generaciones más recientes de FOSD, a saber, GenVoca , ^{[ 1 ]} AHEAD , ^{[ 4 ]} y FOMDD ^{[ 5 ] [ 6 ]} , y se proporcionan enlaces a líneas de productos que se han desarrollado utilizando herramientas FOSD. Además, cuatro resultados adicionales que se aplican a todas las generaciones de FOSD son: metamodelos FOSD , cubos de programas FOSD e interacciones de características FOSD.

GenVoca (una combinación de los nombres Genesis y Avoca) ^{[ 1 ]} es un paradigma compositivo para definir programas de líneas de productos. Los programas base son funciones o transformaciones 0-arias llamadas valores :

 f -- programa base con la característica f h -- programa base con la característica h

y las características son funciones/transformaciones unarias que elaboran (modifican, extienden, refinan) un programa:

 i + x -- agrega la característica i al programa x j + x -- agrega la característica j al programa x

donde + denota composición de funciones. El diseño de un programa es una expresión con nombre, por ejemplo:

 p 1 = j + f -- el programa p 1 tiene las características j y f p 2 = j + h -- el programa p 2 tiene las características j y h. p 3 = i + j + h -- El programa p 3 tiene las características i, j y h.

Un modelo GenVoca de un dominio o línea de productos de software es una colección de programas base y funcionalidades (véase Metamodelos y Cubos de Programas ). Los programas (expresiones) que se pueden crear definen una línea de productos. La optimización de expresiones es la optimización del diseño del programa , y ​​la evaluación de expresiones es la generación del programa .

Nota: GenVoca se basa en el desarrollo gradual de programas: un proceso que enfatiza la simplicidad y la comprensibilidad del diseño, fundamentales para la comprensión y la construcción automatizada de programas. Consideremos el programa p ₃ anterior: comienza con el programa base h, luego se agrega la característica j (es decir, la funcionalidad de la característica j se agrega al código fuente de h) y, finalmente, se agrega la característica i (es decir, la funcionalidad de la característica i se agrega al código fuente de j•h).

Nota: no todas las combinaciones de características son significativas. Los modelos de características (que pueden traducirse en fórmulas proposicionales) son representaciones gráficas que definen combinaciones válidas de características. ^{[ 7 ]}

Nota: Una formulación más reciente de GenVoca es simétrica : solo hay un programa base, 0 (el programa vacío), y todas las características son funciones unarias. Esto sugiere la interpretación de que GenVoca compone estructuras de programas por superposición , la idea de que las estructuras complejas se componen superponiendo estructuras más simples. ^{[ 8 ] [ 9 ]} Otra reformulación de GenVoca es como un monoide : un modelo GenVoca es un conjunto de características con una operación de composición (•); la composición es asociativa y hay un elemento identidad (a saber, 1, la función identidad). Aunque todas las composiciones son posibles, no todas son significativas. Esa es la razón de los modelos de características .

Las características de GenVoca se implementaron originalmente utilizando #ifdef feature ... #endiftécnicas de preprocesamiento de C ( ). Una técnica más avanzada, llamada capas mixin , mostró la conexión de las características con diseños basados ​​en la colaboración orientada a objetos.

Las ecuaciones jerárquicas algebraicas para el diseño de aplicaciones ( AHEAD ) ^{[ 4 ]} generalizaron GenVoca de dos maneras. Primero, revelaron la estructura interna de los valores GenVoca como tuplas. Cada programa tiene múltiples representaciones, como el código fuente, la documentación, el código de bytes y los makefiles. Un valor GenVoca es una tupla de representaciones del programa. En una línea de productos de analizadores sintácticos, por ejemplo, un analizador base f se define por su gramática g _f , el código fuente Java s _f y la documentación d _f . El analizador f se modela mediante la tupla f=[g _f , s _f , d _f ]. Cada representación del programa puede tener subrepresentaciones, y estas también pueden tener subrepresentaciones, recursivamente. En general, un valor GenVoca es una tupla de tuplas anidadas que definen una jerarquía de representaciones para un programa en particular.

Ejemplo. Supongamos que las representaciones de terminales son archivos. En AHEAD, la gramática g _f corresponde a un único archivo BNF, el código fuente s _f corresponde a una tupla de archivos Java [c ₁ ...c _n ], y la documentación d _f es una tupla de archivos HTML [h ₁ ...h _k ]. Un valor GenVoca (tuplas anidadas) se puede representar como un grafo dirigido: el grafo para el analizador f se muestra en la figura de la derecha. Las flechas denotan proyecciones, es decir, asignaciones de una tupla a uno de sus componentes. AHEAD implementa las tuplas como directorios de archivos, por lo que f es un directorio que contiene el archivo g _f y los subdirectorios s _f y d _f . De manera similar, el directorio s _f contiene los archivos c ₁ ...c _n , y el directorio df contiene los archivos h ₁ ...h _k .

Nota: Los archivos pueden descomponerse jerárquicamente. Cada clase Java puede descomponerse en una tupla de miembros y otras declaraciones de clase (por ejemplo, bloques de inicialización, etc.). La idea importante aquí es que las matemáticas de AHEAD son recursivas.

En segundo lugar, AHEAD expresa las características como tuplas anidadas de funciones unarias llamadas deltas . Los deltas pueden ser refinamientos de programas (transformaciones que preservan la semántica), extensiones (transformaciones que amplían la semántica) o interacciones (transformaciones que alteran la semántica). Usamos el término neutro "delta" para representar todas estas posibilidades, ya que cada una aparece en FOSD.

Para ilustrarlo, supongamos que la característica j extiende una gramática mediante Δ g _j (se añaden nuevas reglas y tokens), extiende el código fuente mediante Δ s _j (se añaden nuevas clases y miembros y se modifican los métodos existentes) y extiende la documentación mediante Δ d _j . La tupla de deltas para la característica j se modela mediante j=[ Δ g _j , Δ s _j , Δ d _j ], que denominamos tupla delta . Los elementos de las tuplas delta pueden ser a su vez tuplas delta. Ejemplo: Δ s _j representa los cambios que se realizan en cada clase de s _f mediante la característica j, es decir, Δ s _j =[ Δ c ₁ ... Δ c _n ]. Las representaciones de un programa se calculan recursivamente mediante la suma de vectores anidados. Las representaciones para el analizador p ₂ (cuya expresión GenVoca es j+f) son:

 p 2 = j + f -- expresión GenVoca = [ Δ g j , Δ s j , Δ d j ] + [g f , s f , d f ] - sustitución = [ Δ g j +g f , Δ s j +s f , Δ d j +d f ] -- compone tuplas elemento a elemento

Es decir, la gramática de p ₂ es la gramática base compuesta con su extensión ( Δ g _j +g _f ), la fuente de p ₂ es la fuente base compuesta con su extensión ( Δ s _j +s _f ), y así sucesivamente. Como los elementos de las delta tuplas pueden ser a su vez delta tuplas, la composición es recursiva, por ejemplo, Δ s _j +s _f = [ Δ c ₁ ... Δ c _n ]+[c ₁ ...c _n ]=[ Δ c ₁ +c ₁ ... Δ c _n +c _n ]. En resumen, los valores de GenVoca son tuplas anidadas de artefactos de programa, y ​​las características son delta tuplas anidadas, donde + las compone recursivamente mediante la suma de vectores. Esta es la esencia de AHEAD.

Las ideas presentadas anteriormente exponen concretamente dos principios de FOSD. El Principio de Uniformidad establece que todos los artefactos del programa se tratan y modifican de la misma manera (esto se evidencia en las diferencias entre los distintos tipos de artefactos). El Principio de Escalabilidad establece que todos los niveles de abstracción se tratan de forma uniforme (esto da lugar al anidamiento jerárquico de tuplas).

La implementación original de AHEAD es el conjunto de herramientas AHEAD y el lenguaje Jak, que exhibe los principios de uniformidad y escalabilidad. Las herramientas de próxima generación incluyen CIDE ^{[ 10 ]} y FeatureHouse ^{[ 11 ] .}

El diseño orientado a modelos y basado en características ( FOMDD ) ^{[ 5 ] [ 6 ]} combina las ideas de AHEAD con el diseño dirigido por modelos ( MDD ) (también conocido como arquitectura dirigida por modelos ( MDA )). Las funciones de AHEAD capturan la actualización secuencial de los artefactos del programa cuando se agrega una característica a un programa. Pero existen otras relaciones funcionales entre los artefactos del programa que expresan derivaciones. Por ejemplo, la relación entre una gramática g _f y su fuente de analizador s _f está definida por una herramienta de compilación, por ejemplo, javacc. De manera similar, la relación entre la fuente Java s _f y su código de bytes b _f está definida por el compilador javac. Un diagrama de conmutación expresa estas relaciones. Los objetos son representaciones del programa, las flechas hacia abajo son derivaciones y las flechas horizontales son deltas. La figura de la derecha muestra el diagrama de conmutación para el programa p ₃ = i+j+h = [g ₃ ,s ₃ ,b ₃ ].

Una propiedad fundamental de un diagrama de conmutación es que todos los caminos entre dos objetos son equivalentes. Por ejemplo, una forma de derivar el código de bytes b ₃ del analizador p ₃ (objeto inferior derecho en la figura de la derecha) a partir de la gramática g _h del analizador h (objeto superior izquierdo) es derivar el código de bytes b _h y refinarlo a b ₃ , mientras que otra forma refina g _h a g ₃ y luego deriva b ₃ , donde + representa la composición delta y () es la aplicación de una función o herramienta:

b ₃ = Δ b _j + Δ b _i + javacc ( javac ( g _h ) ) = javac ( javacc ( Δ g _i + Δ g _j + g _h ) )

Hay${\displaystyle {\tbinom {4}{2}}}$Posibles rutas para derivar el código de bytes b ₃ del analizador p ₃ a partir de la gramática g _h del analizador h. Cada ruta representa un metaprograma cuya ejecución genera el objeto objetivo (b ₃ ) a partir del objeto inicial (g _f ). Existe una optimización potencial: recorrer cada flecha de un diagrama de conmutación tiene un coste. La ruta más barata (es decir, la más corta) entre dos objetos en un diagrama de conmutación es una geodésica , que representa el metaprograma más eficiente que produce el objeto objetivo a partir de un objeto dado.

Nota: Una “métrica de costo” no tiene por qué ser un valor monetario; el costo puede medirse en tiempo de producción, requisitos de memoria máximos o totales, consumo de energía o alguna métrica informal como “facilidad de explicación”, o una combinación de las anteriores (por ejemplo, optimización multiobjetivo ). El concepto de geodésica es general y debe entenderse y apreciarse desde este contexto más amplio.

Nota: Es posible que haya m objetos iniciales y n objetos finales en una geodésica; cuando m=1 y n>1, se trata del problema del árbol de Steiner dirigido , que es NP-difícil.

Los diagramas de conmutación son importantes por al menos dos razones: (1) existe la posibilidad de optimizar la generación de artefactos (p. ej., geodésicas) y (2) especifican diferentes maneras de construir un objeto objetivo a partir de un objeto inicial. ^{[ 5 ] [ 12 ]} Una ruta a través de un diagrama corresponde a una cadena de herramientas: para que un modelo FOMDD sea consistente, debe probarse (o demostrarse mediante pruebas) que todas las cadenas de herramientas que mapean un objeto a otro producen resultados equivalentes. Si este no es el caso, entonces hay un error en una o más de las herramientas o el modelo FOMDD es incorrecto.

Nota: las ideas anteriores se inspiraron en la teoría de categorías . ^{[ 5 ] [ 6 ]}

• Protocolos de red
• Sistemas de bases de datos extensibles
• Estructuras de datos
• Simulador de apoyo de fuego distribuido del ejército
• Compilador del sistema de producción
• Línea de productos gráficos
• Preprocesadores Java extensibles
• Portlets web
• Aplicaciones SVG

• Metamodelos FOSD : líneas de productos de líneas de productos
• origami FOSD
• Cubos del programa FOSD : líneas de productos multidimensionales
• Lenguaje de programación de muy alto nivel