Skip to content
Hamilton Archive
0 / 17
Pre-launch Review

Preventative Software Systems

Preventative Software Systems

Section titled “Preventative Software Systems”

Margaret H. Hamilton, Hamilton Technologies, Inc., 1994

The Problem Diagnosis

Section titled “The Problem Diagnosis”

Hamilton’s opening is her most thorough published indictment of traditional software development. She catalogs the failures systematically:

Requirements definition: Incompatible methods capture partial definitions — data flow in one notation, timing in another. No integration mechanism exists. “Methods available to them force designers to think this way” — the tools shape the thinking, not the reverse.

Object integration: Integration of objects, modules, phases, and application types is “a challenge left to the devices of a myriad of developers well into the development.”

Error propagation: Systems are “actually encouraged by these methods to be defined as ambiguous.” Interfaces are incompatible. Errors propagate. “The system and its development are out of control.”

Late distributed targeting: Systems are defined first for single-processor environments, then redeveloped for distributed environments — at least one unnecessary full development cycle.

Late reuse: “Little incentive exists for reuse in today’s changing market if a module is not able to be integrated, not portable or adaptable and it is error prone.”

Automation gaps: Tools concentrate on automating manual processes instead of doing the real work. When automation attempts the real work, it is “often incomplete across application domains” producing “shell code.”

The diagnosis concludes: “There is a promising solution to these problems: development before the fact. Whereas the traditional approach is curative, this approach is preventative.”

Development Before the Fact

Section titled “Development Before the Fact”

The Apollo origin is stated explicitly: research on man-rated software led to the finding that interface errors (data flow, priority, timing) accounted for most errors found during final testing. A theory was derived for defining systems such that this entire class of interface errors would be eliminated — “just by the way a system is defined.”

DBTF includes a language, an approach, and a process, all grounded in formal theory. The language is semantics-dependent but syntax-independent, capable of defining any aspect of any system and integrating it with any other. It covers hardware, software, and peopleware; real-time and database environments; requirements through detailed design. At its core: generic mechanisms that produce application-specific user “languages.”

The MakeATable Example

Section titled “The MakeATable Example”

Hamilton introduces a concrete example to demonstrate the three primitive control structures:

  • Join: MakeATable decomposes into MakeParts then Assemble. Assemble depends on output from MakeParts — a sequential dependency.
  • Include: MakeParts decomposes into MakeLegs and MakeTop, independent of each other — potential parallelism.
  • Or: MakeTop decides between FinishSoftWood and FinishHardWood based on the type of wood — a decision point.

The TMap (Type Map) for Table decomposes into Top and Legs with explicit structural relations. Top depends on Legs to stand on. Front legs and back legs have an independent relationship. The table “may have” various configurations via Or.

This example — mundane by design — makes the abstract structures concrete. Every system, from a table to a spacecraft, decomposes through the same three primitives.

Reusable Defined Structures

Section titled “Reusable Defined Structures”

Two important defined structures demonstrate reuse:

CoInclude: A frequently occurring pattern defined with Include and Join. Within the pattern, only the leaf functions change — the rest is a “hidden repeat.” A syntax definition allows users to employ the pattern without writing out its full structure each time.

Async: A real-time, distributed, communicating structure with both asynchronous and synchronous behavior. Applied as the Coordinate structure, it defines a planning robot (MasterO) coordinating with a task-execution robot (SlaveO) to build a table. This is not a toy example; it is a formal specification of distributed coordination.

Parameterized types provide reusable TMap patterns: TupleOf (fixed number of possibly different types), OSetOf (variable number of the same type, linearly ordered), OneOf (classification where one is selected), and TreeOf (tree-indexed collection).

The Complete 001 Tool Suite

Section titled “The Complete 001 Tool Suite”

The paper provides the most detailed published account of the 001 tool suite as of 1994:

  • 001 AXES: The systems language. Every system defined with it inherits DBTF properties.
  • VSphere (Virtual Sphere): A layered system of distributed hierarchical abstract managers providing traceable object relations.
  • Manager(x): Users tailor their own development environment by defining process needs with FMaps/TMaps and installing them. The tool suite itself is a Manager(x) configuration, meaning users can extend the tool suite using the same formalism.
  • RT(x) (Requirements Traceability): Forward/backward and upward/downward traceability from requirements through specification, design, implementation, and documentation.
  • Analyzer: Ensures language rules are followed. After successful analysis, the model goes to RAT.
  • RAT (Resource Allocation Tool): Configurable code generators for any target language, database, graphics, client-server, legacy code, OS, and machine environment. Maintains traceability: generated source code has the same names as the FMaps/TMaps from which it was generated.
  • Datafacer: Automatically generates user interfaces from TMap data descriptions.
  • Xecutor: Both a simulator (recording behavior for analysis) and a real-time executive (scheduling resources and managing distributed execution).
  • Baseliner: Version control for all maps and defined reusables.
  • Build Manager: Manages all entities used in constructing an executable.

The Preventative Hierarchy

Section titled “The Preventative Hierarchy”

Hamilton states the preventative philosophy in its most compressed form:

“In contrast to the just-in-time philosophy, the preventative philosophy is to solve a given problem such as finding or preventing errors as soon as possible (ASAP). Finding an error statically is an earlier process than finding it dynamically. Preventing it by the very way a system is defined is even earlier. Not having to define (and build) it at all is earlier yet.”

This four-level hierarchy — (1) do not build it, (2) prevent by definition, (3) find statically, (4) find dynamically — is the conceptual spine of all Hamilton’s subsequent work on error taxonomy.

Results

Section titled “Results”

The 001 tool suite had generated approximately 800,000 lines of C code per platform across 4 platforms, totaling over 7 million lines of code across 3 major versions. The tools themselves span database management, communications, client-server, graphics, and scientific systems — “inherently integrated as part of the same system.”

Productivity claims: 10:1 to 100:1 versus traditional C development. The critical observation: “Unlike with traditional systems, the larger a system, the higher the productivity.” This is the inverse of Brooks’s Law, and it holds only because 001’s reuse is structural — FMaps and TMaps compose formally rather than being copy-pasted.

The paper closes: “It is within our mistakes that the answers for success often exist. The first step is to recognize the root problems.”

References

Section titled “References”
  1. M. Hamilton, “Zero-Defect Software: The Elusive Goal,” IEEE Spectrum, Mar. 1986
  2. M. Hamilton and R. Hackler, “001: A Rapid Development Approach for Rapid Prototyping,” RSP 1990
  3. M. Hamilton, “Inside Development Before the Fact,” Electronic Design, Apr. 1994
  4. B. Krut Jr., “Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology,” CMU/SEI-93-TR-11, 1993
  5. M. Ouyang and M.W. Golay, “An Integrated Formal Approach for Prototyping High-Quality Software of Safety-Critical Systems,” MIT-ANP-TR-035, 1995
  6. Software Productivity Consortium, “Object-Oriented Methods and Tools Survey,” SPC-98022-MC, 1998
  7. “Software Engineering Tools Experiment — Final Report,” DoD/SDIO, 1992
Section titled “Related Documents”