Tecnología de frame

De Wikipedia, la enciclopedia libre

Tecnología de frame (FT) es una lengua-neutro (es decir, procesa varios idiomas) que fabrica software personalizado[1]​ a partir de bloques reutilizables y adaptables a la máquina, llamados frames. 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 el cual se construyen lenguajes de programación (subrutinas, clases o plantillas/genéricos) o técnicas complementarias como Frame y los generadores no pudieron proporcionar una solución práctica y escalable.

Existen varias implementaciones de FT. Netron Fusion se especializa en la construcción de software empresarial y es privado.[3]​ ART (Adaptive Reuse Technology) es una implementación de código abierto de uso general de FT. Paul G. Basset invento el primer FT para automatizar la edición repetitiva y propensa a errores involucrada en la adaptación de programas (generados y escritos a mano) a requisitos y contextos cambiantes.[4]​

Ahora existe una literatura sustancial[5]​[6]​[7]​[8]​[9]​[10]​[11]​[12]​ 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. Las comparaciones independientes de FT con enfoques alternativos[13]​ 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 producido bibliotecas de objetos COTS de bibliotecas de frame XVCL equivalentes que son dos tercios más pequeñas y más simples;[2]​ las aplicaciones empresariales personalizadas se especifican y mantienen de forma rutinaria mediante Netron FusionSPC frames que son del 5% al 15% del tamaño de sus archivos fuente ensamblados.

Frames[editar]

A continuación, hay dos descripciones informales, seguidas de una definición y explicación más precisas.

  1. Un Frame es un componente adaptable en una línea de ensamblaje de software automatizado. Imagine una fábrica de automóviles donde, en lugar de tener para choques, guardafango y otras partes específicas de cada modelo de automóvil, tenemos un para choques genérico y un guarda fangos genéricos, etc. Ahora imagine que estas páginas genéricas podrían clonarse y en forma para adaptarse a cada modelo de automóvil a medida que avanza la línea. Tal fantasía revolucionaría la fabricación; y aunque es imposible para las partes físicas, esto es la que hacen los Frame para el software (y la información en general).
  2. Un Frame es una receta para “cocinar” un texto (de programa). Sus instrucciones dicen como mezclar sus ingredientes (fragmentos de texto de Frame dentro de sí mismo) con los ingredientes de otros Frame. El “Chef” es un procesador de Frame que lleva a cabo las instrucciones, es decir, los comandos de frame, que alteran (agregan, modifican, eliminan) los ingredientes según sea necesario, para adaptarlos a la receta principal.

Formalmente, un Frame es una macro de procedimiento que consiste en texto de Frame: cero o más líneas de texto ordinario (programa) y comandos de Frame (que realiza el procesador de Frame de FT mientras fabrica programas personalizados). Cada Frame es un componente genérico en una jerarquía de subconjuntos anidados y un procedimiento para integrarse con sus Frame de subconjunto (un proceso recursivo que resuelve conflictos de integración en favor de subconjuntos de nivel superior). Los resultados son documentos personalizados, normalmente módulos fuente compilables.

Los comandos principales[editar]

  • Invocar un Frame (una llamada a procedimiento que ocurre en el momento de la construcción, mientras se construyen los textos del programa);
  • Asignar una (lista de) expresión(es) a un parámetro de Frame (una asignación variable de tiempo de construcción);
  • Inserte texto de Frame antes, en lugar de o después de bloques de texto de Frame, etiquetados por expresiones de parámetros;
  • Instanciar un parámetro de Frame (una evaluación de expresión en tiempo de construcción);
  • Seleccionar textos Frame para procesar (una declaración de caso en tiempo de construcción);
  • Iterar un texto de Frame mientras varía ciertos parámetros de Frame (una declaración while de tiempo de construcción).

El procesador transforma el texto del Frame reemplazando comandos con texto ordinario y emitiendo texto ordinario tal como está. Ejemplos: reemplaza una invoke por el resultado del procesamiento del Frame invocado; remplaza una asignación con nada; y una instancia se convierte en el texto ordinario resultante de evaluar la expresión asignada del parámetro de Frame, que puede ser una concatenación de cadenas, expresiones aritméticas y parámetros de Frame anidados.

Relaciones de componentes[editar]

Invoke establece relaciones de componentes entre cuadros. Por ejemplo, en la figura 1: F es el componente de J y C es el subcomponente de J. Por su puesto, muchos componentes pueden invocar el mismo subcomponente, como en I y J invocando F, cada uno construyendo un texto diferente. La estructura general de los componentes forma una semilattice genérica,[14]​ siendo cada Frame la raíz de un subensamblaje. Así, C es un propio subconjunto; F y C son componentes del subconjunto F, y J, F y C son componentes del subconjunto J.[15]​

Alcance del contexto[editar]

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 subensamblaje. En subconjuntos anidados, los niveles inferiores están 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 convierte en solo lectura para todos los demás marcos en el subconjunto de ese frame.[16]​ En la figura 1, los frames 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 trama ignora las asignaciones de C a p, y usa los valores de F para p en F y C. Del mismo modo, J puede anular tanto F como C, y así sucesivamente.

El alcance del contexto es importante porque todos los ajustes necesarios para ajustar cualquier número de (sub) componentes a un contexto dado son explícitos y locales en ese contexto. Sin el alcance del contexto, tales 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, causando redundancia y complejidad innecesarias, sino que la evolución del sistema también es innecesariamente difícil y propensa a errores.

Frames de especificaciones y plantillas[editar]

Un Frame de especificación (SPC) es el Frame superior de un conjunto completo, por lo tanto, el Frame 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 ensamblaje porque la mayoría de las excepciones (y excepciones a excepciones, etc.) ya han sido manejadas por varios Frame de subconjunto.

Dada una biblioteca de Frame, los SPC implican lógicamente los programas que construyen; así, los SPC reemplazan los archivos fuente como puntos de control primarios. Es una práctica habitual usar plantillas para crear SPC que crean programas, luego usar 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 incrustados que explican cómo personalizarlo. Por lo general, hay una pequeña cantidad de tipos de programas, cada uno de los cuales se caracteriza por una plantilla. Al copiarlo y completarlo, los programadores convierten una plantilla en un SPC sin tener que recordar qué cuadros necesitan, sus relaciones de componentes o qué detalles normalmente necesitan ser personalizados.

Lenguajes Específicos de dominio basados en frame[editar]

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) se ha diseñado en frames. Un editor FT-DSL típico se traduce entre expresiones DSL y una trama que adaptará la semántica enmarcada para expresar equivalentes de código de programa de las expresiones DSL. Un SPC sentado encima de este subensamblaje puede especificar en el código del programa cualquier personalización inexpresable 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, no se pierden las personalizaciones anteriores.[17]​

Ingeniería de marco[editar]

La ingeniería de cuadros aplica la ingeniería de software a un entorno de tecnología de cuadros. Esto incluye análisis de dominio, diseño, escritura, prueba y co-evolución de marcos junto con los sistemas que construyen.[12]​ El encuadre ocurre de abajo hacia arriba y 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 a 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 aplicación y arquitectura, los estándares corporativos y el deseo de desarrollar un conjunto de activos reutilizables cuyo rendimiento exceda en gran medida la inversión. (La reutilización se mide dividiendo el tamaño total de las bibliotecas de marcos en el tamaño total de las construcciones resultantes, y / o contando las reutilizaciones de marcos individuales).

Una biblioteca de frames madura mejora la rentabilidad porque los interesados en proyectos 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 cuadros pueden, utilizando el comando de selección, desarrollar cuadros reutilizables indefinidamente, cumpliendo nuevos requisitos sin necesidad de modificaciones en los programas fabricados a partir de versiones anteriores de cuadros.[9]​

Referencias[editar]

  1. ↑ Software is emphasized here; but given the appropriate frames, FT can assemble any kind of documents: technical and end-user manuals, UML models, test cases, legal contracts, bills-of-materials, etc.
  2. ↑ a b S.Jarzabek and S.Li, "Eliminating Redundancies with a 'Composition and Adaptation' Meta-Programming Technique," Proc. European Software Eng. Conf./ACM/SIGSOFT Symp. Foundations of Software Engineering, (ESEC/FSE 03), ACM Press, 2003, pp. 237–246; received the ACM Distinguished Paper Award
  3. ↑ «Welcome to Netron Inc.». www.netron.com. Consultado el 9 de octubre de 2020. 
  4. ↑ «Progress». Progress (en inglés). Consultado el 9 de octubre de 2020. 
  5. ↑ P.G.Bassett "Frame-Based Software Engineering", IEEE Software, July 1987, pp. 9 -16
  6. ↑ «C.Holmes and A. Evens, "A Review of Frame Technology." Nov. 28 2003;». Archivado desde el original el 19 de julio de 2004. Consultado el 10 de octubre de 2008. 
  7. ↑ F.Sauer, "Metadata Driven Multi-Artifact Code Generation Using Frame Oriented Programming," Workshop on Generative Techniques in the context of Model Driven Architecture (Oopsla 02), 2002
  8. ↑ H. Basit, D.C. Rajapakse, and S. Jarzabek, "Beyond Templates: A Study of Clones in the STL and some General Implications," Proc.
  9. ↑ a b P.G. Bassett, Framing Software Reuse: Lessons from the Real World, Prentice Hall, 1997.
  10. ↑ S. Jarzabek, Effective Software Maintenance and Evolution: A Reuse-based Approach, Auerbach, 2007.
  11. ↑ P.G.Bassett, "The Case for Frame-Based Software Engineering," IEEE Software, July 2007, pp. 90–99
  12. ↑ a b P.G.Bassett, "Adaptive Components: Software Engineering's Ace in the Hole," Cutter Consortium's Agile Project Management, Vol.5 #5
  13. ↑ I. Grossman and M. Mah, "Independent Research Study of Software Reuse", tech. report, QSM Associates, 1994
  14. ↑ The semilattice is generic because its nodes and graph structure can vary, depending on parameter values.
  15. ↑ The ambiguity reflects the mental habit of thinking of a subassembly as one component.
  16. ↑ Non-nested subassemblies can reassign the same parameter.
  17. ↑ Hand editing the same customizations into regenerated code again and again spurred the invention of FT.
Obtenido de «https://es.wikipedia.org/w/index.php?title=Tecnología_de_frame&oldid=159825377»