 | This user page or section is in a state of significant expansion or restructuring. You are welcome to assist in its construction by editing it as well. If this user page has not been edited in several days, please remove this template. If you are the editor who added this template and you are actively editing, please be sure to replace this template with {{in use}} during the active editing session. Click on the link for template parameters to use.
This page was last edited by Frameengineer (talk | contribs) 15 years ago. (Update timer) |
Frame Technology edit
is a language-neutral, models-to-code system that manufactures custom programs from reusable, machine-adaptable building blocks, called frames.
The purpose is to reduce the time, effort, and errors involved in the design, construction, and evolution of large, complex software systems.
A number of implementations of FT exist. Netron Fusion specializes in constructing business software and is proprietary, (www.netron.com). XVCL is a general-purpose, open-source implementation of FT (http://xvcl.comp.nus.edu.sg/). Paul Bassett invented the first FT in the 1970s in order to automate the repetitive, error-prone editing involved in adapting Dibol programs to changing requirements and contexts.
A substantial literature now exists [cf. 1, 2, and their references] 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 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; custom business applications are routinely specified and maintained by Netron SPC frames that are 5% - 15% of the size of their assembled source files.
Frame: 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 specific parts to suit the requirements of each car model, we have just one generic bumper, one generic fender, and so on. And 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. While impossible for physical parts, this is what frames do for information.
2. A frame is a recipe containing a list of ingredients and instructions for combining them. Unlike food recipes, each ingredient can be either a line of text to be “cooked,” or contain the name of another frame that will replace itself with the text that its recipe produces. The “chef” is a frame processor that carries out the instructions, “cooking up” text files by following the recipe’s frame commands, which alter (add, modify, delete) ingredients and/or sub-ingredients, as necessary, to suit the recipes.
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). The main commands are:
•invoke a frame non-recursively (a construction-time procedure call);
•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.
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, 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 .
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 . 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.
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.
A 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.
A 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.
A FT-based domain specific language (FT-DSL) is a Domain-specific Language whose semantics have been engineered into frames. A typical DSL editor translates between DSL-user-input and a frame that will cause the DSL-semantics to express the source-code equivalent of DSL-user-input. An SPC sitting atop this subassembly can then specify any customizations that cannot be expressed in DSL-user-inputs. Thus when users alter their DSL inputs and regenerate the source code, prior customizations are not lost.
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. 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.
References:
[1] P.G. Bassett, Framing Software Reuse: Lessons from the Real World, Prentice Hall, 1997.
[2] S. Jarzabek, Effective Software Maintenance and Evolution: A Reuse-based Approach, Auerbach, 2007.