La tecnología Frame (FT) es un sistema neutral en cuanto al lenguaje (es decir, procesa varios idiomas) que fabrica software personalizado [1] a partir de bloques de construcción reutilizables y adaptables a máquinas, llamados marcos. FT se utiliza para reducir el tiempo, el esfuerzo y los errores involucrados en el diseño, construcción y evolución de sistemas de software grandes y complejos. Fundamental para FT es su capacidad para detener la proliferación [2] de componentes similares pero sutilmente diferentes, un problema que afecta a la ingeniería de software, para la cual se utilizan construcciones de lenguajes de programación (subrutinas, clases o plantillas/genéricos) o técnicas complementarias como macros y Los 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 (Tecnología de reutilización adaptativa) es una implementación de código abierto y de propósito general de FT. Paul G. Bassett inventó el primer FT para automatizar la edición repetitiva y propensa a errores que implica la adaptación de 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, incluido el modelado de dominios, la recopilación de requisitos, arquitectura y diseño, construcción, pruebas, documentación, puesta a punto y evolución. Comparaciones independientes de FT con enfoques alternativos [11] confirman que el tiempo y los recursos necesarios para construir y mantener sistemas complejos pueden reducirse sustancialmente. Una razón: FT protege a los programadores de las redundancias inherentes al software: FT ha reproducido bibliotecas de objetos COTS a partir de bibliotecas de marcos XVCL equivalentes que son dos tercios más pequeñas y simples; [2] [6] las aplicaciones empresariales personalizadas se especifican y mantienen de forma rutinaria mediante marcos Netron FusionSPC que tienen entre el 5% y el 15% del tamaño de sus archivos fuente ensamblados. [7]
A continuación se presentan dos descripciones informales, seguidas de una definición y explicación más precisas.
Formalmente, un marco es una macro de procedimiento que consta de marco-texto: cero o más líneas de texto (de programa) ordinario y comandos de marco (que son llevados a cabo por el procesador de marcos 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 subconjunto (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 comandos con texto ordinario y emitiendo texto ordinario tal como está. Ejemplos: Reemplaza una invocación por el resultado del procesamiento de la trama invocada; reemplaza una asignación con nada; y una instancia se convierte en el texto ordinario resultante de evaluar la expresión asignada al parámetro de 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 que invocan F , cada uno de los cuales construye un texto diferente. La estructura general del componente forma una semired genérica , [12] en la que cada marco es la raíz de un subconjunto. Por 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 están cada vez 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 subensamblaje de ese marco. [14] En la figura 1, los cuadros F y C entrarían en conflicto si asignan valores diferentes al parámetro p . Entonces, F anula a C , es decir, el procesador de cuadros ignora las asignaciones de C a p y usa los valores de F para p en F y C. De manera similar, J puede anular tanto a F como a C , y así sucesivamente.
El alcance 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 para ese contexto. Sin un análisis del contexto, tales ajustes son en su mayoría implícitos, dispersos y ocultos dentro de las variantes de los componentes. Estas variantes no sólo tienden a proliferar, provocando 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 superior de todo un conjunto 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 subconjunto.
Dada una biblioteca de marcos, los SPC implican lógicamente los programas que construyen; por lo tanto, los SPC reemplazan a los archivos fuente como puntos de control primarios. Es una práctica habitual utilizar plantillas para crear SPC que crean programas y luego utilizar SPC para gestionar 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 copiar y editar textos originales a mano. El tiempo de depuración también se reduce porque la mayoría de los componentes se reutilizan y, 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 copiarlo y completarlo, los programadores convierten una plantilla en un SPC sin tener que recordar qué marcos necesitan, las relaciones de sus componentes o qué detalles normalmente deben personalizarse.
Un lenguaje de dominio específico (FT-DSL) basado en FT es un lenguaje de dominio específico cuya semántica (expresada en código de programa) se ha diseñado en marcos. Un editor FT-DSL típico traduce entre expresiones DSL y un marco que adaptará la semántica del marco para expresar equivalentes de código de programa de las expresiones DSL. Un SPC situado encima de este subconjunto puede especificar en el código del programa cualquier personalización que no se pueda expresar en el lenguaje específico del dominio. Por lo tanto, cuando los usuarios regeneran el código del 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 análisis de dominio, diseño, redacción, prueba y marcos de coevolución junto con los sistemas que construyen. [10] El encuadre 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 arquitectónicos y de aplicación, los estándares corporativos y el deseo de desarrollar un conjunto de activos reutilizables cuyo retorno supere con creces la inversión. (La reutilización se mide dividiendo el tamaño total de las bibliotecas de cuadros por el tamaño total de las construcciones resultantes y/o contando las reutilizaciones de cuadros individuales).
Una biblioteca de marco madura mejora la rentabilidad porque las partes interesadas en un proyecto de software pueden restringir su atención a las novedades de un sistema, dando por sentado la mayor parte de sus componentes y arquitectura robustos. Una biblioteca madura no es estática. Los ingenieros de marcos pueden, utilizando el comando de selección, desarrollar marcos reutilizables indefinidamente, cumpliendo con nuevos requisitos sin necesidad de modificaciones en los programas fabricados a partir de versiones anteriores de marcos. [7]