Defensive Modelling Principles

Defensive Modelling Principle #0 - Defensive Modelling generates questions.

System Integrators employ Defensive Modelling to generate questions about a modeled system by exposing gaps in the design.

Getting the questions raised and then answered provides many benefits concurrently:

1. Improving design

2. Learning about the system

3. Preparing for Integration

Defensive Modelling Principle #1 - There Should Be No Missing Gears.

When Systems Integrators apply Defensive Modelling against insufficient Systems Design, they check that there are no physical gaps between subsystems.

If two subsystems interface but are not in physical contact, something is missing, usually, some obvious subsystem like a wire harness, hosting hardware, or the Internet.

Defensive Modelling Principle #2 - It's turtles all the way down (and up). Each system is both a whole and a part of a more extensive system (each #system is a #holon).

There is certainly a system of interest, but from the #integration perspective, this system has parts that have their own parts. On the other hand, the system of interest is a part of a super-system with other parts, and the super-system is a part of yet another supersystem.

Identifying subsystems all the way down and supersystems all the way up ensures that we don't miss anything.

Still, no gaps are allowed between the systems (Defensive Modelling Principle #1).

Defensive Modelling Principle #3 - What happens in Vegas stays in Vegas.

Principles #1 and #2 partition the entire Universe into a hierarchy of systems in physical contact with each other, so everything that happens happens inside some system.

There are no free-floating objects or uncontained processes. Every object is a subsystem in some system (Object@System), and every process happens inside a system (Process@System).

Flows of matter, energy, and information from one system to adjacent systems happen on the boundary between the systems (Flow@Boundary).

efensive Modelling Principle #4 - Look for Missing Chain Reactions.

Principle #3 states that everything happens inside some system (Process@System) or on some boundary (Flow@Boundary), and Principles #1 and #2 physically partition all systems into subsystems, ad infinitum.

Integration happens when the processes in different subsystems (Process@Subsystem) link by boundary flows to form end-to-end chains. Each chain starts and ends with flows through the external boundary of a system of interest.

Each chain is a system-wide process (Process@System) partitioned into subsystem processes (Subprocess@Subsystem) and boundary flows. A process hierarchy forms, with multiple subsystem processes contributing to multiple system processes.

The Defensive Modelling Method looks for orphan subsystem processes and flows not mapped to higher-level processes and flags them as knowledge gaps to be investigated. The Method also looks for system-level processes not partitioned into subprocesses and flows and flags them as gaps in the design.

Missed chain reactions are never a good thing. Unexplained chain reactions are trouble as well.

D