Frame technology (software engineering)

Frame technology (FT) is a language-neutral (i.e., processes various languages) system that manufactures custom software<ref>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.</ref> from reusable, machine-adaptable building blocks, called frames. FT is used to reduce the time, effort, and errors involved in the design, construction, and evolution of large, complex software systems. Fundamental to FT is its ability to stop the proliferation<ref name="jar0">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</ref> of similar but subtly different components, an issue plaguing software engineering, for which programming language constructs (subroutines, classes, or templates/generics) or add-in techniques such as macros and generators failed to provide a practical, scalable solution.

A number of implementations of FT exist. Netron Fusion specializes in constructing business software and is proprietary. ART (Adaptive Reuse Technology) is a general-purpose, open-source implementation of FT. Paul G. Bassett invented the first FT in order to automate the repetitive, error-prone editing involved in adapting (generated and hand-written) programs to changing requirements and contexts.

A substantial literature now exists<ref>P.G.Bassett "Frame-Based Software Engineering", IEEE Software, July 1987, pp. 9 -16</ref><ref>"C.Holmes and A. Evens, "A Review of Frame Technology." Nov. 28 2003;" (PDF). Archived from the original (PDF) on 2004-07-19. Retrieved 2008-10-10.</ref><ref>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 [1]</ref><ref name="basit">H. Basit, D.C. Rajapakse, and S. Jarzabek, "Beyond Templates: A Study of Clones in the STL and some General Implications," Proc. Int'l Conf. Software Eng. (ICSE 05), ACM Press, 2005, pp. 451–459</ref><ref name="bas">P.G. Bassett, Framing Software Reuse: Lessons from the Real World, Prentice Hall, 1997.</ref><ref name="jar">S. Jarzabek, Effective Software Maintenance and Evolution: A Reuse-based Approach, Auerbach, 2007.</ref><ref>P.G.Bassett, "The Case for Frame-Based Software Engineering," IEEE Software, July 2007, pp. 90–99</ref><ref name ="bas1">P.G.Bassett, "Adaptive Components: Software Engineering's Ace in the Hole," Cutter Consortium's Agile Project Management, Vol.5 #5</ref> that explains how FT can facilitate most aspects of software's life-cycle, including domain modeling, requirements gathering, architecture and design, construction, testing, documentation, fine tuning and evolution. Independent comparisons of FT to alternative approaches<ref>I. Grossman and M. Mah, "Independent Research Study of Software Reuse", tech. report, QSM Associates, 1994</ref> confirm that the time and resources needed to build and maintain complex systems can be substantially reduced. One reason: FT shields programmers from software's inherent redundancies: FT has reproduced COTS object-libraries from equivalent XVCL frame libraries that are two-thirds smaller and simpler;<ref name="jar0"/><ref name="basit"/> custom business applications are routinely specified and maintained by Netron FusionSPC frames that are 5% – 15% of the size of their assembled source files.<ref name="bas"/>

Frames

Below are two informal descriptions, followed by a more precise definition and explanation.

1. A frame is an adaptable component on an automated software assembly line. Imagine an auto factory where, instead of having specific bumpers, fenders, and other parts to suit the specifics of each car model, we have just one generic bumper, one generic fender, and so on. Now imagine that these generic parts could be cloned and shaped to fit each car model as it came down the line. Such a fantasy would revolutionize manufacturing; and while impossible for physical parts, this is what frames do for software (and information in general).
2. A frame is a recipe for "cooking up" a (program) text. Its instructions say how to blend its ingredients – chunks of frame-text within itself – with the ingredients from other frames. The “chef” is a frame processor that carries out the instructions, i.e. the frame commands, which alter (add, modify, delete) ingredients as necessary, to suit the main recipe.

Formally, a frame is a procedural macro consisting of frame-text – zero or more lines of ordinary (program) text and frame commands (that are carried out by FT's frame processor as it manufactures custom programs). Each frame is both a generic component in a hierarchy of nested subassemblies, and a procedure for integrating itself with its subassembly frames (a recursive process that resolves integration conflicts in favor of higher level subassemblies). The outputs are custom documents, typically compilable source modules.

The main commands

• invoke a frame (a procedure call that occurs at construction time, while constructing program texts);
• assign a (list of) expression(s) to a frame parameter (a construction-time variable assignment);
• insert frame-text before, instead-of, or after blocks of frame-text, labeled by parameter expressions;
• instantiate a frame parameter (a construction-time expression evaluation);
• select frame-texts for processing (a construction-time case statement);
• iterate a frame-text while varying certain frame parameters (a construction-time while statement).

The processor transforms frame-text by replacing commands with ordinary text, and by emitting ordinary text as is. Examples: It replaces an invoke by the result of processing the invoked frame; it replaces an assign with nothing; and an instantiate becomes the ordinary text resulting from evaluating the frame parameter's assigned expression, which can be a concatenation of strings, arithmetic expressions, and nested frame parameters.

Component relationships

Invoke sets up component relationships among frames. For example, in figure 1: F is J’s component and C is J’s subcomponent. Of course, many components may invoke the same subcomponent, as in I and J invoking F, each constructing a different text. The overall component structure forms a generic semilattice,<ref>The semilattice is generic because its nodes and graph structure can vary, depending on parameter values.</ref> with each frame being the root of a subassembly. Thus C is its own subassembly; F and C are components of the F subassembly, and J, F, and C are components of the J subassembly.<ref>The ambiguity reflects the mental habit of thinking of a subassembly as one component.</ref>

Context scoping

Context scoping is what distinguishes FT from other modeling and construction systems: Each frame constitutes the context into which it integrates its subassembly. In nested subassemblies the lower levels are progressively more context-free because they integrate less information. Integration conflicts are resolved in favor of the most context-sensitive frame to assign or insert a parameter – it becomes read-only to all other frames in that frame's subassembly.<ref>Non-nested subassemblies can reassign the same parameter.</ref> In figure 1, frames F and C would conflict if they assign different values to parameter p. So F overrides C – i.e., the frame processor ignores C’s assignment(s) to p, and uses F’s value(s) for p in F and C. Similarly, J can override both F and C, and so on.

Context-scoping matters because all the adjustments needed to fit any number of (sub)components to a given context are explicit and local to that context. Without context-scoping such adjustments are mostly implicit, scattered and hidden within component variants. Not only do such variants tend to proliferate, causing unnecessary redundancy and complexity, but system evolution is also unnecessarily difficult and error-prone.

Specification frames and templates

A specification frame (SPC) is an entire assembly's topmost, hence most context-sensitive frame. The processor starts at an SPC, such as L or M in figure 1, in order to manufacture a complete program or subsystem. While in principle an SPC could customize every detail, in practice an SPC is a small fraction of its entire assembly because most of the exceptions (and exceptions to exceptions, etc.) have already been handled by various subassembly frames.

Given a frame library, SPCs logically entail the programs they construct; thus SPCs replace source files as primary control points. It's routine practice to use templates to create SPCs that create programs, then use SPCs to manage and evolve those programs indefinitely. This practice greatly reduces the number of details that application programmers must know and manage. It also avoids the redundancies, complexities, and errors inherent in copying and editing source texts by hand. Debugging time shrinks as well because most components are reused, hence pretested. Errors tend to localize in SPCs, as they are the least tested.

A template is an archetypal SPC, with embedded comments explaining how to customize it. Typically, there is a small number of types of programs, each type being characterized by a template. By copying and filling it in, programmers convert a template into an SPC without having to remember what frames they need, their component relationships, or what details typically need to be customized.

Frame-based domain-specific languages

An FT-based, domain-specific language (FT-DSL) is a domain-specific language whose semantics (expressed in program code) have been engineered into frames. A typical FT-DSL editor translates between DSL expressions and a frame that will adapt the framed semantics to express program-code equivalents of the DSL expressions. An SPC sitting atop this subassembly can then specify in program code any customizations inexpressible in the domain-specific language. Thus when users regenerate program code from altered DSL expressions, prior customizations are not lost.<ref>Hand editing the same customizations into regenerated code again and again spurred the invention of FT.</ref>

Frame engineering

Frame engineering applies software engineering to a frame technology environment. This includes domain analysis, designing, writing, testing, and co-evolving frames along with the systems they construct.<ref name="bas1"/> Framing occurs both bottom–up and top–down. Bottom–up, frame engineers typically create frames by unifying and parameterizing groups of similar program elements (of any granularity, from text snippets to subsystems) into generic equivalents. The top–down approach combines domain expertise with iterative prototype refinement, constrained by application and architectural requirements, corporate standards, and the desire to evolve a set of reusable assets whose return greatly exceeds the investment. (Reuse is measured by dividing the total size of the frame libraries into the total size of the resulting constructs, and/or by counting individual frame reuses.)

A mature frame library enhances cost-effectiveness because software project stakeholders can restrict their attention to a system's novelties, taking the bulk of its robust components and architecture for granted. A mature library is not static. Frame engineers can, using the select command, evolve reusable frames indefinitely, meeting new requirements without necessitating retrofits to programs manufactured from frames’ previous versions.<ref name="bas"/>

Footnotes

<References/>