Principle 25

"A program is a human artifact, a real-life program is a complex human artifact; and any human artifact of sufficient size and complexity is imperfect" (De Millo, Lipton, Perlis. 1979.

Principle 24

“It is the last lesson of modern science, that the highest simplicity of structure is produced, not by few elements, but the highest complexity” (Ralph Waldo Emerson).

Principle 23

"An important distinction to be made between programs properties that cause the program to be complex and program characteristics that are associated with complexity" (Kearney, 1986).

Principle 22

"Complexity usually arises from a small number of disproportionally complex procedures" (Henry, Kafura, 1984).

Principle 21

"Solving a problem involves mapping into knowledge available" (Nancy Leveson, ESD 355 lecture).

Principle 20

... "an architecture of a specific system [is] a collection of computational components—or simply components-—together with a description of the interactions between these components—the connectors... An architectural style, then, defines a family of such systems in terms of a pattern of structural organization.  More specifically, an architectural style determines the vocabulary of components and connectors that can be used in instances of that style, together with a set of constraints  on how they can be combined... Given this framework, we can understand what a style is by answering the following questions:

(1) What is the structural pattern—the components, connectors, and constraints?

(2) What is the underlying computational model?

(3) What are the essential invariants of the style?

(4) What are some common examples of its use?

(5) What are the advantages and disadvantages of using that style?

(6) What are some of the common specializations?"

(David Garlan, Mary Shaw. An Introduction to Software Architecture, 1994)

Principle 19

"The conversion from an intuition to a theory involved understanding:

(1) the software structure (which included a representation packaged with its primitive operators),

(2) specifications (mathematically expressed as abstract models or algebraic axioms),

(3)  language issues (modules, scope, user-defined types),

(4) integrity of the result (invariants of data structures and protection from other manipulation),

(5) rules for combining types (declarations),

(6) information hiding (protection of properties not explicitly included in specifications)."

(David Garlan, Mary Shaw. An Introduction to Software Architecture, 1994)

Principle 18

"Simplification results in fundamentally wrong answers, and focus on individual sectors separately will be counterproductive"

(Metropolitan Development as a Complex System:  A New Approach to Sustainability, Judith E. Innes and
David E. Booher, Working Paper #699, University of California at Berkeley, December 1997).

Principles 15-17

"Dijkstra, Hoare, Wirth:

Construction of correct programs requires that programs be intellectually manageable (15).

Key to intellectual manageability is the structure of the program itself (16).

Disciplined use of a few program building blocks facilitates correctness arguments (17)."

Form Nancy Leveson, ESD 355

Principle 14

"To achieve an efficient implementation we must abandon the assumption that a module is one or more subroutines, and instead allow subroutines and programs to be assembled collections of code from various modules" (Parnas, 1971).

Principle 13

"Accidents result from interactions among components that violate the safety constrains - in other words,  from a lack of appropriate control actions to enforce the constrains of the  interactions"  (Nancy Leveson, A New Accident Model for Engineering Safer Systems).