La tecnología de marcos (FT) es un sistema neutral en cuanto al lenguaje (es decir, procesa varios lenguajes) que fabrica software personalizado [1] a partir de bloques de construcción reutilizables y adaptables a las máquinas, llamados marcos. La FT se utiliza para reducir el tiempo, el esfuerzo y los errores involucrados en el diseño, la construcción y la evolución de sistemas de software grandes y complejos. Fundamental para la FT es su capacidad de detener la proliferación [2] de componentes similares pero sutilmente diferentes, un problema que afecta a la ingeniería de software, para el cual las construcciones de lenguajes de programación (subrutinas, clases o plantillas/genéricos) o las técnicas de complementos como macros y generadores no lograron proporcionar una solución práctica y escalable.
Existen varias implementaciones de FT. Netron Fusion se especializa en la creación de software empresarial y es propietario. ART (Adaptive Reuse Technology) es una implementación de código abierto y de propósito general de FT. Paul G. Bassett inventó la primera FT para automatizar la edición repetitiva y propensa a errores que implica adaptar programas (generados y escritos a mano) a requisitos y contextos cambiantes.
Actualmente existe una literatura sustancial [3] [4] [5] [6] [7] [8] [9] [10] que explica cómo FT puede facilitar la mayoría de los aspectos del ciclo de vida del software, incluyendo el modelado de dominio, la recopilación de requisitos, la arquitectura y el diseño, la construcción, las pruebas, la documentación, el ajuste fino y la evolución. Comparaciones independientes de FT con enfoques alternativos [11] confirman que el tiempo y los recursos necesarios para construir y mantener sistemas complejos se pueden reducir sustancialmente. Una razón: FT protege a los programadores de las redundancias inherentes del software: FT ha reproducido bibliotecas de objetos COTS a partir de bibliotecas de marco XVCL equivalentes que son dos tercios más pequeñas y simples; [2] [6] las aplicaciones comerciales personalizadas se especifican y mantienen rutinariamente mediante marcos Netron FusionSPC que tienen un tamaño del 5% al 15% de sus archivos fuente ensamblados. [7]
A continuación se presentan dos descripciones informales, seguidas de una definición y explicación más precisa.
Formalmente, un marco es una macro de procedimiento que consta de un texto de marco (cero o más líneas de texto (programa) ordinario) y comandos de marco (que son llevados a cabo por el procesador de marco de FT mientras fabrica programas personalizados). Cada marco es a la vez un componente genérico en una jerarquía de subconjuntos anidados y un procedimiento para integrarse con sus marcos de subconjuntos (un proceso recursivo que resuelve conflictos de integración a favor de subconjuntos de nivel superior). Los resultados son documentos personalizados, normalmente módulos fuente compilables.
El procesador transforma el texto del marco reemplazando los comandos con texto ordinario y emitiendo el texto ordinario tal como está. Ejemplos: reemplaza una invocación por el resultado de procesar el marco invocado; reemplaza una asignación por nada; y una instancia se convierte en el texto ordinario resultante de evaluar la expresión asignada del parámetro del marco, que puede ser una concatenación de cadenas, expresiones aritméticas y parámetros de marco anidados.
Invoke establece relaciones de componentes entre marcos. Por ejemplo, en la figura 1: F es el componente de J y C es el subcomponente de J. Por supuesto, muchos componentes pueden invocar el mismo subcomponente, como en I y J invocando a F , cada uno construyendo un texto diferente. La estructura general del componente forma una semired genérica , [12] donde cada marco es la raíz de un subconjunto. Por lo tanto, C es su propio subconjunto; F y C son componentes del subconjunto F , y J , F y C son componentes del subconjunto J. [13]
El alcance del contexto es lo que distingue a FT de otros sistemas de modelado y construcción: cada marco constituye el contexto en el que integra su subconjunto. En los subconjuntos anidados, los niveles inferiores son progresivamente más libres de contexto porque integran menos información. Los conflictos de integración se resuelven a favor del marco más sensible al contexto para asignar o insertar un parámetro: se vuelve de solo lectura para todos los demás marcos en el subconjunto de ese marco. [14] En la figura 1, los marcos F y C entrarían en conflicto si asignaran valores diferentes al parámetro p . Por lo tanto , F anula a C , es decir, el procesador de marcos ignora la (s) asignación(es) de C a p y usa el(los) valor(es) de F para p en F y C . De manera similar, J puede anular tanto F como C , y así sucesivamente.
La delimitación del contexto es importante porque todos los ajustes necesarios para adaptar cualquier número de (sub)componentes a un contexto determinado son explícitos y locales a ese contexto. Sin la delimitación del contexto, dichos ajustes son en su mayoría implícitos, dispersos y ocultos dentro de las variantes de los componentes. Estas variantes no solo tienden a proliferar, lo que causa redundancia y complejidad innecesarias, sino que la evolución del sistema también es innecesariamente difícil y propensa a errores.
Un marco de especificación (SPC) es el marco más alto de un conjunto completo, y por lo tanto el más sensible al contexto. El procesador comienza en un SPC, como L o M en la figura 1, para fabricar un programa o subsistema completo. Si bien en principio un SPC podría personalizar cada detalle, en la práctica un SPC es una pequeña fracción de todo su conjunto porque la mayoría de las excepciones (y excepciones a excepciones, etc.) ya han sido manejadas por varios marcos de subconjuntos.
Dada una biblioteca de marcos, los SPC implican lógicamente los programas que construyen; por lo tanto, los SPC reemplazan los archivos fuente como puntos de control primarios. Es una práctica rutinaria utilizar plantillas para crear SPC que creen programas, y luego utilizar SPC para administrar y desarrollar esos programas indefinidamente. Esta práctica reduce en gran medida la cantidad de detalles que los programadores de aplicaciones deben conocer y administrar. También evita las redundancias, complejidades y errores inherentes a la copia y edición de textos fuente a mano. El tiempo de depuración también se reduce porque la mayoría de los componentes se reutilizan, por lo tanto, se prueban previamente. Los errores tienden a localizarse en los SPC, ya que son los menos probados.
Una plantilla es un SPC arquetípico, con comentarios integrados que explican cómo personalizarlo. Normalmente, hay una pequeña cantidad de tipos de programas, y cada tipo se caracteriza por una plantilla. Al copiarla y completarla, los programadores convierten una plantilla en un SPC sin tener que recordar qué marcos necesitan, sus relaciones de componentes o qué detalles suelen necesitar ser personalizados.
Un lenguaje específico de dominio basado en FT (FT-DSL) es un lenguaje específico de dominio cuya semántica (expresada en código de programa) ha sido diseñada en marcos. Un editor FT-DSL típico traduce entre expresiones DSL y un marco que adaptará la semántica enmarcada para expresar equivalentes en código de programa de las expresiones DSL. Un SPC ubicado sobre este subconjunto puede entonces especificar en código de programa cualquier personalización que no se pueda expresar en el lenguaje específico de dominio. De esta manera, cuando los usuarios regeneran código de programa a partir de expresiones DSL alteradas, las personalizaciones anteriores no se pierden. [15]
La ingeniería de marcos aplica la ingeniería de software a un entorno de tecnología de marcos. Esto incluye el análisis de dominios, el diseño, la escritura, las pruebas y la coevolución de los marcos junto con los sistemas que construyen. [10] La creación de marcos se produce tanto de abajo hacia arriba como de arriba hacia abajo. De abajo hacia arriba, los ingenieros de marcos suelen crear marcos unificando y parametrizando grupos de elementos de programa similares (de cualquier granularidad, desde fragmentos de texto hasta subsistemas) en equivalentes genéricos. El enfoque de arriba hacia abajo combina la experiencia en el dominio con el refinamiento iterativo de prototipos, limitado por los requisitos de la aplicación y la arquitectura, los estándares corporativos y el deseo de desarrollar un conjunto de activos reutilizables cuyo rendimiento supere ampliamente la inversión. (La reutilización se mide dividiendo el tamaño total de las bibliotecas de marcos por el tamaño total de las construcciones resultantes y/o contando las reutilizaciones individuales de los marcos).
Una biblioteca de marcos madura mejora la relación coste-beneficio porque los participantes en un proyecto de software pueden limitar su atención a las novedades de un sistema, dando por sentado el grueso de sus componentes y arquitectura robustos. Una biblioteca madura no es estática. Los ingenieros de marcos pueden, utilizando el comando select, desarrollar marcos reutilizables indefinidamente, cumpliendo con los nuevos requisitos sin necesidad de realizar modificaciones a los programas fabricados a partir de versiones anteriores de los marcos. [7]