Frame Technology (software engineering)

Frame Technology is a language-neutral, models-to-code system that manufactures custom software [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.] 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 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] of similar but subtly different components, a issue plaguing software engineering since the invention of macros and subroutines.

A number of implementations of FT exist. [http://www.netron.com Netron Fusion] specializes in constructing business software and is proprietary. [http://xvcl.comp.nus.edu.sg/ XVCL] 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 [ P.G.Basett "Frame-Based Software Engineering," IEEE Software, July 1987, pp. 9 -16 ] [ C.Holmes and A. Evens, "A Review of Frame Technology." Nov. 28 2003; [http://www.cs.york.ac.uk/ftpdir/reports/YCS-2003-369.pdf] ] [ 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 [http://www.volantec.biz/Metadata-driven.pdf] ] 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] P.G. Bassett, "Framing Software Reuse: Lessons from the Real World", Prentice Hall, 1997, and contains additional references. ] S. Jarzabek, "Effective Software Maintenance and Evolution: A Reuse-based Approach", Auerbach, 2007, and contains additional referencs. ] [ P.G.Bassett, "The Case for Frame-Based Software Engineering," IEEE Software, July 2007, pp. 90-99] P.G.Bassett, "Adaptive Components: Software Engineering's Ace in the Hole," Cutter Consortium's Agile Project Management, Vol.5 #5] 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 [ I. Grossman and M. Mah, "Independent Research Study of Software Reuse", tech. report, QSM Associates, 1994] 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 [Common Off The Shelf] object-libraries from equivalent XVCL frame libraries that are two-thirds smaller and simpler; custom business applications are routinely specified and maintained by [http://www.netron.com Netron Fusion] SPC frames that are 5% - 15% of the size of their assembled source files.

Frames

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

:#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 information. :#A frame is a recipe for "cooking up" a text. Its instructions say how to blend its ingredients, i.e. its subtexts, 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) subtexts 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 compileable source modules.

The main commands

:*"invoke" a frame non-recursively (a construction-time procedure call);

:*"Anchor|parameterassign" 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. If A invokes B and B invokes C, then B is A’s component and C is A’s subcomponent. Of course, many components may "invoke" the same subcomponent, each constructing a different text. The overall component structure forms a generic semilattice [The semilattice is generic because its nodes can vary (depending on parameter values) while its graph structure remains invariant.] , with each frame being the root of a subassembly. Thus C is its own subassembly; B and C are components of the B subassembly, and A, B, and C are components of the A subassembly [The ambiguity reflects the mental habit of thinking of a subassembly as one component.] .

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. When subassemblies are nested, 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 [Non-nested subassemblies can reassign the same parameter.] . In the above example, frames B and C would conflict if they assign different values to parameter P. So B overrides C – i.e., the frame processor ignores C’s assignment(s) to P, and uses B’s value(s) for P in B and C. Similarly, A can override both B and C.

Anchor|proliferationContext-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.

pecification Frames and Templates

Anchor|SPCA specification frame (SPC) is an entire assembly’s topmost, hence most context-sensitive frame. The processor starts at an SPC 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 files 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.

Anchor|templateA template is an archetypal SPC, with embedded comments explaining how to customize it. Typically, there are 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

A 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 unexpressable in the Domain Specific Language. Thus when users regenerate program code from altered DSL expressions, prior customizations are not lost. [Hand editing the same customizations into regenerated code again and again spurred the invention of FT.]

Frame Engineering

Anchor|engineeredFrame 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. 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.

Footnotes and References