In defining requirements, developers rely on many different types of mismatched methods to capture aspects of even a single definition. Among other things, data flow is defined using one method, state transitions another, dynamics another, data types another and structures using still another method.

Once these aspects of requirements are defined, there is no way to integrate them. Designers are forced to think and design this way because of the limitations of the methodologies that are available to them.

This leads to further problems. Integration of object to object, module to module, phase to phase, or type of application to type of application becomes even more of a challenge than solving the problem at hand.

This is compounded by a mismatch of products used for design and development. Integration of all forms is left to the devices of a myriad of developers well into the development process. The resulting system is hard to understand, objects cannot be traced, and there is at best little correspondence to the real world.

With these traditional methods, systems are actually encouraged to be defined as ambiguous and incorrect. Interfaces are incompatible and errors propagate throughout development. Once again the developers inherit the problem. The system and its development are out of control.

Requirements are defined to concentrate on the application needs of the user, but they do not consider that the user changes his mind or that his environment changes. Porting becomes a new development for each new architecture, operating system, data base, graphics environment, language or language configuration; critical functionality is avoided for fear of the unknown, and maintenance is both risky and the most expensive part of the life cycle. When a system is targeted for a distributed environment, it is often defined and developed for a single processor environment and then re-developed for a distributed environment--another unnecessary development.

Insufficient information about a system's run-time performance, including that concerning the decisions to be made between algorithms or architectures, is incorporated into a system definition. This results in design decisions that depend on analysis of outputs from exercising ad hoc implementations and associated testing scenarios. A system is defined without considering how to separate it from its target environment.

It is not known if a design is a good one until its implementation has failed or succeeded. The focus for reuse is late into development during the coding phase.

Requirements definitions lack properties to help find, create and make use of commonality. Modelers are forced to use informal and manual methods to find ways to divide a system into components natural for reuse.

Why reuse something in today's changing market if it is not able to be integrated, not portable or adaptable, and it is error-prone?

The result is that there is little incentive for reuse and redundancy is a way of life. Again, errors propagate accordingly.

Automation, itself, is an inherently reusable process. If a solution does not exist for reuse, it does not exist for automation.

Systems are defined with insufficient intelligence for automated tools to use them as input. Too often, automated tools concentrate on supporting the manual process instead of doing the real work.

Definitions supported by automation are given to developers to turn into code manually. A process that could have been mechanized once for reuse is performed manually over and over again.

When automation attempts to do the real work, it is often incomplete across application domains or even within a domain, resulting in incomplete code such as skeleton or shell code.

Manual processes are needed to complete unfinished automations. An automation for one part of a system (e.g., graphics) needs to be manually integrated with an automation for another part of the system (e.g., scientific algorithms) or with the results of a manual process.

The code generated is often inefficient and/or hardwired to a particular architecture, language, or even a particular version of a language. Most of the development process is needlessly manual. Again, all these manual processes are creating new errors each time.

From the very beginning, a system inherently integrates all of its own objects (and all aspects of and about these objects) and the combinations of functionality using these objects. It maximizes its own reliability and flexibility to change; capitalizes on its own parallelism; supports its own run-time performance analysis and the ability to understand the integrity of its own design; and maximizes the potential for its own reuse and automation. The system is developed with built-in quality and with built-in productivity.

Whereas a curative means to obtain quality is to continue testing the system until the errors are eliminated; a preventative means is to not allow errors to creep in, in the first place.

This same language can be used to define system requirements, specifications, design, and detailed design for functional, resource and resource allocation architectures throughout all levels and layers of "seamless" definition, including hardware, software and peopleware. It could be used define missile or banking systems as well as real-time or database environments. It is used to define and integrate implementation-independent, function- oriented decompositions with implementation-independent, object oriented decompositions. It defines and integrates these decompositions (control hierarchies) with networks of functions and objects. It can be used to define systems with diverse degrees of fidelity and completeness. Such a language can always be considered a design language, since design is relative; one person's design phase is another person's implementation phase.

This language has mechanisms to define mechanisms for defining systems. Although the core language is generic, the user "language", a by-product of a development, can be application specific, since the language is semantics-dependent but syntax-independent.

The first step in building a before the fact system is to define a model with the language. This process could be in any phase of development, including problem analysis, operational scenarios and design. The model is automatically analyzed to ensure that it was defined properly. This includes static analysis for preventative properties and dynamic analysis for user intent properties.

A fully production-ready and fully integrated software implementation for any kind of application, consistent with the model, is then automatically generated by the generic generator for a selected target environment in the language of choice (for example, in C or Ada) and the architecture of choice. If the selected environment has already been configured, it is selected directly; if not, the generator is configured for a new language (for example, for VHDL, EDIF, and C++) and new architecture before it is selected.

The resulting system can then be executed. If the desired system is software, the system can now be tested for further user intent errors. It becomes operational after testing. Target changes are made to the requirements definition, not to the code. Target architecture changes are made to the configuration of the generator environment, not to the code. If the real system is hardware or peopleware, the software system serves as a simulation upon which the real system can be based.

Development before the fact is a function- and object-oriented approach based upon a unique concept of control. The foundations are based on a set of axioms and on the assumption of the existence of a universal set of objects. Each axiom defines a relation of immediate domination. The union of the relations defined by the axioms is control. Among other things, the axioms establish the relationships of an object for invocation, input and output, input and output access rights, error detection and recovery and ordering during its developmental and operational states. Table 1 summarizes some of the properties of objects within development before the fact systems.

This approach is used throughout a life cycle starting with requirements and continuing with functional analysis, simulation, specification, analysis, design, system architecture design, algorithm development, implementation, configuration management, testing, maintenance and reverse engineering. Its users include managers, system engineers, software engineers, test engineers as well as end users.

The first technology derived from this theory concentrated on defining and building reliable systems in terms of functional hierarchies. Since that time this technology has been further developed to design and build systems with development before the fact properties in terms of an integration of both functional and type maps where a map is both a control hierarchy and a network of interacting objects.

The philosophy behind this approach is inherently reusable where reliable systems are defined in terms of reliable systems. Only reliable systems are used as building blocks and only reliable systems are used as mechanisms to integrate these building blocks to form a new system. The new system becomes a reusable for building other systems.

Every model is defined in terms of functional hierarchies (FMaps) to capture time characteristics and type hierarchies (TMaps) to capture space characteristics (Figure 1). A map is both a control hierarchy and a network of interacting objects. FMaps and TMaps guide the designer in thinking through his concepts at all levels of system design. With these hierarchies, everything you need to know (no more, no less) is available. All model viewpoints can be obtained from FMaps and TMaps, including data flow, control flow, state transitions, data structure and dynamics. Maps of functions are integrated with maps of types.

On an FMap there is a function at each node, which is defined in terms of and controls its children functions. For example, the function--build the table-- could be decomposed into and control its children functions--make parts and assemble. On a TMap there is a type at each node that is defined in terms of and controls its children types. For example, type, table, could be decomposed into and control its children types, legs and top.

Every type on a TMap owns a set of inherited primitive operations. Each function on an FMap has one or more objects as its input and one or more objects as its output. Each object resides in an object hierarchy (OMap) and is a member of a type from a TMap. FMaps are inherently integrated with TMaps by using these objects and their primitive operations. FMaps are used to define, integrate, and control the transformations of objects from one state to another state (for example, a table with a broken leg to a table with a fixed leg). Primitive operations on types defined in the TMap reside at the bottom nodes of an FMap. Primitive types reside at the bottom nodes of a TMap.

When a system has all of its object values plugged in for a particular performance pass, it exists in the form of an execution hierarchy (EMap).

Typically, a team of designers will begin to design a system at any level (this system could be hardware, software, peopleware or some combination) by sketching a TMap of their application. This is where they decide on the types of objects (and the relationships between these objects) that they will have in their system. Often a Road Map (RMap), which organizes all system objects including FMaps and TMaps, will be sketched in parallel with the TMap.

All FMaps and TMaps are ultimately defined in terms of three primitive control structures: a parent controls its children to have a dependent relationship, an independent relationship, or a decision making relationship. A formal set of rules is associated with each primitive structure. If these rules are followed, interface errors are "removed" before the fact by preventing them in the first place. As a result, all interface errors (75% to 90% normally found during testing in a traditional development) are eliminated at the definition phase. Using the primitive structures supports a system to be defined from the very beginning to inherently maximize its own elimination of errors.

Use of the primitive structures is shown in the definition of the FMap for system, MakeATable (Figure 2). The top node function has FLATwood and ROUNDwood as its inputs and produces Table as its output. MakeATable, as a parent, is decomposed with a Join into its children functions, MakeParts and Assemble. MakeParts takes in as input FLATwood and ROUNDwood from its parent and produces Top and Legs as its output. Top and Legs are given to Assemble as input. Assemble is controlled by its parent to depend on MakeParts for its input. Assemble produces Table as output and sends it to its parent.

MakeParts, as a parent, is decomposed into children, MakeLegs and MakeTop who are controlled to be independent of each other with the Include primitive control structure. MakeLegs takes in part of its parent's input and MakeTop takes in the other part. MakeLegs provides part of its output (Legs ) to its parent and MakeTop provides the rest. MakeTop controls its children, FinishSoftWood and FinishHardWood with an Or. Here, both children take in the same input and provide the same output since only one of them will be performed for a given performance pass. FinishSoftWood will be performed if the decision function is: Soft, Wood returns true; otherwise, FinishHardWood will be performed. Notice that input (for example, FLATwood), is traceable down the system from parent to children and output (for example, Table), is traceable up the system from children to parent. All objects in a development before the fact system are traceable. MakeATable's TMap, Table, uses non primitive structures called parameterized types, a concept discussed in a later section.

Each type on a TMap can be decomposed in terms of primitive structures into children types where the defined relationships between types are explicit. In figure 3, Table as a parent has been decomposed into its children, Top and Legs, where the relations between Top and Legs are on-1 and on-2, respectively, the relation between Table and legs is r-1 and the relation between Table and Top is r-0. Notice that Top depends on Legs to stand on to make a Table [Figure 3a]. On the other hand, an independency relationship exists between the front legs and the back legs of the Table [Figure 3b]. The Table may have FrontLegs or BackLegs, or both FrontLegs and BackLegs at once. In figure 3c, which illustrates a decision structure with objects, unlike with the dependent and independent structures, the pattern of the OMap is always different than the pattern of the TMap, since only one object is chosen to represent its parent for a given instance.

It can be shown that a system defined with these structures results in properties that support real-time distributed environments. Each system is event interrupt driven. Each object is traceable, reconfigurable, and has a unique priority. Independencies and dependencies can readily be detected and used to determine where parallel and distributed processing is most beneficial. With these properties, a system is defined from the very beginning to inherently maximize its own flexibility to change and the unpredictable and to capitalize on its own parallelism.

CoInclude is an example of a system pattern that happens often (Figure 4a). Its FMap was defined with primitive structures. Within the CoInclude pattern, everything stays the same for each use except for the functions at leaf nodes A and B. The CoInclude pattern can be defined as a non-primitive structure in terms of more primitive structures with the use of the concept of defined structures. This concept was created for defining reusable patterns.

Included with each structure definition is the definition of the syntax for its use (Figure 4b). Its use (Figure 4c) provides a "hidden repeat" of the entire system as defined, but explicitly shows only the elements that are subject to change (that is, functions A and B). The CoInclude structure is used in a similar way to the Include structure except with the CoInclude the user has more flexibility with respect to repeated use, ordering and selection of objects. Each defined structure has rules associated with it for its use just as with the primitive control structures. Rules for the non-primitives are inherited ultimately from the rules of the primitives.

Async, (Figure 5), is a real-time, distributed, communicating structure with both asynchronous and synchronous behavior. The Async system was defined with the primitive Or, Include and Join structures and the CoInclude user-defined structure. It cannot be further decomposed, since each of its lowest level functions is either a primitive function on a previously defined type (see Identify2:Any and Clone1:Any under End, each of which is a primitive operation on any type), recursive (see Async under DoMore), or a variable function for a defined structure (see A and B under process). If a leaf node function does not fall into any of these categories, it can be further decomposed or it can refer to an existing operation in a library or an external operation from an outside environment.

DependentRobots uses Async as a reusable where TurnAndPlan and Move are dependent, communicating, concurrent, synchronous and asynchronous functions. The two robots in this system are working together to perform a task such as building a table. Here one phase of the planning robot, RB, is coordinated with the next phase of the slave robot, RA.

Figure 6 shows a complete system definition for a manufacturing company, which has been defined in terms of an integrated set of FMap(s) and TMap(s). This company could be set up to build tables with the help of robots to perform tasks using structures such as those defined above. Since this system is completely defined, it is ready to be automatically developed to complete, integrated, and fully production ready to run code. This system's FMap, Is_FullTime_Employee, has been decomposed until it reaches primitive operations on types in TMap, MfgCompany. (See for example, Emps=Moveto:Employees (MfgC) where MfgC is of type MfgCompany and Emps is of type Employees.) MfgCompany has been decomposed until its leaf nodes are primitive types or defined as types that are decomposed in another TMap.

System, Is_FullTime_Employee, uses objects defined by TMap, MfgCompany, to check to see if an employee is full or part time. First a move is made from the MfgCompany type object, MfgC to an Employees type object, Emps. The defined structure, LocateUsing:Name finds an Employee based on a name. Once found, a move is made from Employee, Emp to PS of type, Payscale. The primitive operation YN=is:FullTime(PS) is then used to determine from PS if Emp is full time or part time.

Each parameterized type assumes its own set of possible relations for its parent and children types. In this example, TMap, MfgCompany is decomposed into Departments and Employees in terms of TupleOf. Departments is also decomposed in terms of TupleOf into Purchasing, Production and Marketing. Employees is decomposed in terms of OSetOf. One of the children of Employee , PayScale, is decomposed in terms of the parameterized type, OneOf.

Abstract types decomposed with the same parameterized type on a TMap inherit (or reuse) the same primitive operations and therefore the same behavior. So, for example, MfgCompany, Departments, and Employee inherit the same primitive operations from parameterized type, TupleOf. An example of this can be seen in the FMap where both types, MfgCompany and Employee, use the primitive operation, MoveTo which was inherited from TupleOf.

The TMap provides universal primitive operations, which are used for controlling objects and object states which are inherited by all types. They create, destroy, copy, reference, move, access a value, detect and recover from errors and access the type of an object. They provide an easy way to manipulate and think about different types of objects.

With the universal primitive operations, building systems can be accomplished in a more uniform manner. TMap and OMap are also available as types to facilitate the ability of a system to understand itself better and manipulate all objects the same way when it is beneficial to do so.

TMap properties ensure the proper use of objects in an FMap. A TMap has a corresponding set of control properties for controlling spatial relationships between objects.

One cannot, for example, put a leg on a table where a leg already exists; conversely, one cannot remove a leg from the table where there is no leg; a reference to the state of an object cannot be modified if there are other references to that state in the future; reject values exist in all types, allowing the FMap user to recover from failures if they are encountered.

The same types of definition mechanisms are used to define RotateRotateArm, a hardware system (Figure 7), as the software system above. Note that this system also includes the use of primitives for numeric calculation. In this system the rotation of the robot arm is calculated to move from one position to another in a manufacturing cell to transfer a part. In this example the universal operation (an example of another form of reusable), Replace, is used twice. Each use of a universal operation has function qualifiers that select a unique TMap parent child combination to be used during the application of the function.

Figure 8 has a definition that takes further advantage of the expressive power of a TMap with the option of using explicitly defined relations. In this example, a stack of bearings is described. A bearing in the stack may be under (with relation on-0) or on (with relation on-1) another bearing object in the stack as defined by the DSetOf structured type. A bearing object is decomposed into a Cap, a RetainerWith Balls, and a Base. Object relationships at this level show that the Cap is above the RetainerWithBalls, which is in turn above the Base. Further detail reveals that a Retainer has (with the has-n relation) some number of RetainerHoleWithBall. The set of RetainerHoleWithBall objects are independent of each other, defined by the ISetOf structured type. This structure allows for physically independent relations on the objects in the set. Here, different portions of the Cap surface are independently related (with the on-Balls relation) to each individual Ball object (with the on-Ball relation).

As experience is gained with different types of applications, new reusables emerge for general or specific use. For example, a set of reusables has been derived to form a higher level set of mechanisms for defining hierarchies of interruptable, asynchronous, communicating, distributed controllers. This is essentially a second order control system (with rules that parallel the primary control system of the primitive structures) defined with the formal logic of user defined structures that can be represented using a graphical syntax (figure 9).

Objects, instantiations of TMaps, are realized in terms of OMaps. An execution, an instantiation of an FMap, is realized in terms of an EMap. Building block definitions which focus more on objects than on functions are independent of particular object oriented implementations. Properties of classical object oriented systems such as inheritance, encapsulation, polymorphism and persistence are supported with the use of generalized functions on OMaps and TMaps.

The development before the fact approach derives from the combination of steps taken to solve the problems of the traditional "after the fact approach." Collective experience strongly confirms that quality and productivity increase with the increased use of development before the fact properties. A major factor is the inherent reuse in these systems, culminating in ultimate reuse, which is automation itself.

From FMaps and TMaps any kind of system can be automatically developed resulting in complete, integrated, and production ready target system code and documentation. This is accomplished by the 001 Tool Suite, an automation of the technology that will be discussed in an article in the June 13 issue of this Software Engineering Supplement of ELECTRONIC DESIGN. The tool suite also has a means to observe the behavior of a system as it is being evolved and executed in terms of OMaps and EMaps.

M. Hamilton, "Zero-Defect Software: the Elusive Goal," IEEE Spectrum, vol. 23, no. 3, pp. 48-53, March, 1986.

M. Hamilton and R. Hackler, 001: "A Rapid Development Approach for Rapid Prototyping Based on a System that Supports its Own Life Cycle", IEEE Proceedings, First International Workshop on Rapid System Prototyping, Research Triangle Park, NC, June 4, 1990.

B. McCauley, "Software Development Tools in the 1990s", AIS Security Technology for Space Operations Conference, July 1993, Houston, Texas.

B. Krut, Jr., "Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology" (CMU/SEI-93-TR-11, ESC-TR-93-188), Pittsburgh, Software Engineering Institute, Carnegie Mellon University, 1993.

Software Engineering Tools Experiment-Final Report, Vols. 1, Experiment Summary, Table 1, Page 9, Department of Defense, Strategic Defense Initiative, Washington, D.C., 20301-7100.