Inside Development Before the Fact

About This Document

Citation: Hamilton, Margaret H. “Inside Development Before the Fact.” Electronic Design, Engineering Software supplement, April 4, 1994. Penton Publishing, Inc.

Source: Hamilton Technologies website (freely distributed)

This is the companion piece to the COMPSAC 1994 “Preventative Software Systems” conference paper. While that paper targets computer science academics, this Electronic Design article targets working engineers — hardware and embedded systems designers — using concrete manufacturing examples to make DBTF tangible. It contains some of the best visual introductions to FMap/TMap notation in Hamilton’s published work, including a complete hardware robot arm system specification.

View source document (PDF)

---

Inside Development Before the Fact

Margaret H. Hamilton, Hamilton Technologies Inc., 1994

The Diagnosis

Hamilton opens with a direct indictment aimed at her audience of design engineers:

“Today’s traditional system engineering and software development environments support their users in ‘fixing wrong things up’ rather than in ‘doing them right in the first place.’ Things happen too late, if at all. Systems are of diminished quality and an unthinkable amount of dollars is wasted.”

The problems are systematic: incompatible methods capture partial definitions; integration is left to “the devices of a myriad of developers”; systems are “actually encouraged by these methods to be defined as ambiguous”; and automation tools concentrate on supporting manual processes rather than doing the real work.

The solution: Development Before the Fact — where reliable systems are defined in terms of reliable systems.

FMaps and TMaps: The Two Fundamental Hierarchies

Every DBTF model is built from two complementary structures:

• FMaps (Function Maps) capture time characteristics — what happens, in what order, with what control flow. Each function takes input objects and produces output objects. Functions decompose into child functions.

• TMaps (Type Maps) capture space characteristics — the types of objects and relationships between them. Types decompose into child types.

Every viewpoint of a system — data flow, control flow, state transitions, data structure, dynamics — can be derived from these two map types. You don’t need separate diagrams for different views. FMaps and TMaps are sufficient.

The Three Primitive Structures

All FMaps and TMaps ultimately decompose through exactly three primitive control structures:

1. Dependent (Join) — Parent controls children in sequence. A then B. Assemble depends on MakeParts completing first.

2. Independent (Include) — Children are independent of each other. MakeLegs and MakeTop can proceed concurrently.

3. Decision (Or) — Parent selects which child executes based on a condition. Is the wood soft? Then FinishSoftWood. Otherwise, FinishHardWood.

Hamilton demonstrates all three through a MakeATable example — a deliberate choice of something mundane to prove the structures are universal. A table factory uses the same formal primitives as a spacecraft guidance computer.

The Central Claim

“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% typically found during testing in a traditional development) are eliminated at the definition phase.”

Reusable Defined Structures

Beyond the three primitives, Hamilton introduces defined structures — reusable patterns built from primitive ones:

CoInclude: A frequently occurring pattern where everything stays the same except leaf-node functions A and B. It acts as a template — a “hidden repeat” where users only specify the variable parts.

Async: A real-time, distributed, communicating structure with both asynchronous and synchronous behavior. Hamilton applies this as a Coordinate structure: 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

TMaps use parameterized type patterns for structural reuse:

• TupleOf — Fixed number of possibly different types (Table controls Top and Legs)
• OSetOf — Variable number of same type, linearly ordered (Legs controls Leg)
• OneOf — Classification, one selected (Wood controls Hard and Soft)
• TreeOf — Tree-indexed collection

Each parameterized type carries its own set of universal primitive operations — create, destroy, copy, reference, move, access value, detect/recover from errors. These operations are inherited by all types built from the parameterized forms.

Hardware System Specification

One of the most striking sections defines a complete robot arm control system (RotateRotateARM) entirely in FMaps and TMaps:

• TMap RobotA decomposes into Rotation, Time, and Ports
• FMap ComputeRotationTime navigates to ports, computes distances, looks up turn rates, calculates time
• ResetPorts manages the physical I/O state

Hamilton’s point is explicit: “Any kind of system can be defined with this language, including software, hardware, and peopleware.” The same formal structures that define a table-manufacturing process define a robot arm’s servo control.

Second-Order Control Systems

The article culminates with a distributed control hierarchy — a robot controller managing arm controllers, sensor controllers, and gripper units through an interruptible asynchronous architecture:

• Each distributed region cooperates with other distributed regions
• Each parent controller may interrupt the children under its control
• Rules parallel the primary primitive structures but operate at a higher level of abstraction

This directly parallels the priority-based executive architecture from Apollo — the same design pattern that saved Apollo 11 when the 1202/1201 alarms fired during lunar descent.

Apollo Lineage

Hamilton traces the methodology explicitly to Apollo: “This approach had its earlier beginnings with the Apollo space missions when research was performed for developing man-rated software. This led to the finding that interface errors accounted for most errors found in the flight software during final testing.”

The three categories — data flow errors, priority errors, timing errors — became the foundation for the formal theory that eliminates them by construction.

The Philosophy

Hamilton states the core philosophy that runs through all her work:

The 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.”

And from the DBTF perspective, systems engineering and software development are merged into one discipline. There is no handoff point where a “specification” becomes “code” — the formal definition is the system, and code generation is a mechanical transformation applied to it.

---

References

1. M.H. Hamilton, “Zero-Defect Software: The Elusive Goal,” IEEE Spectrum, March 1986
2. M.H. Hamilton and W.R. Hackler, “001: A Rapid Development Approach for Rapid Prototyping Based on a System That Supports Its Own Life Cycle,” RSP 1990
3. R.A. McCauley, “Software Development Tools in the 1990s,” AIS Security Technology Conference, 1993
4. B. Krut Jr., “Integrating 001 Tool Support in the Feature-Oriented Domain Analysis Methodology,” CMU/SEI-93-TR-11, 1993
5. Software Engineering Tools Experiment Final Report, DoD/SDIO

---

Related Documents

Preventative Software (1994) The companion conference paper (COMPSAC) — same methodology, academic audience, with 001 tool suite results and National Test Bed evidence

Higher Order Software (1976) The theoretical origin of the functional hierarchy approach and the three primitive structures

The 001 Tool Suite (1983-2012) The evolution of the automation environment described in this article

USL: Lessons from Apollo (2008) The mature formalization of USL with six axioms — the evolution of FMaps and TMaps into system-oriented objects

What the Errors Tell Us (2018) The mature error taxonomy — the preventative foundation articulated in this 1994 article reaches its full expression here