NST FOUNDATION
LECTURE 1: THE DESIGN CYCLE AS A DYNAMIC SYSTEM
• Once upon a time…
o Some academics started wondering why software systems were so problematic to change, which
seemed to get even worse over time …
o Discussed this with many practitioners, most of whom agreed that this was probably the most important
problem in software systems …
o And asked themselves whether such progressive structure degradation could be scientifically described,
or even be controlled …
• Dynamic Instability due to Positive Feedback
o = something that gets worse overtime (progressive)
o Many examples of dynamic instability
▪ Tacoma Bridge collapse
▪ Swing / Hammock chair → force = swing gets larger and larger
▪ Childbirth contractions
▪ Thermal runaway
▪ Opamps
• Systems theory and stability
o In engineering, systems theory
▪ studies the dynamic behavior of system(s) (properties) under external inputs
▪ using differential (continuous) or difference (discrete) equations
▪ considering at least an input x(t) and output y(t) in the function of time
o A system is dynamically stable if and only if
▪ a bounded input results in a bounded output
o For a simple first order model
▪ dy(t)/dt = x(t) + ay(t)
▪ y[k+1]-y[k] = x[k] + ay[k]
o → Stability requires a < 0
• Aeroelastic flutter of Tacoma Narrows Bridge,
o Dynamic instability
o Caused by positive feedback
▪ between body deflection and force of fluid flow
→ dy(t) ~ x(t)
▪ with zero net damping
→a=0
• allowed the energy to cumulate in an unbounded way
o Positive Feedback in Childbith Contractions → dy(t)/dt ~ ay(t), a > 0
• Not used to study dynamics of system designs
o Used to study dynamics of system operations
• NS theory tries to use systems theory to study the evolution of a design
,• The Design Cycle as Dynamic System
o Consider the Function → Construction transformation
o Consider this design transformation as a system, with:
▪ the requirement specifications as inputs x
▪ the (versions of) artifact modules as outputs y
o Simplify the high dimensional vectors to scalars:
▪ x[k] the amount of specifications at k
▪ y[k] the amount of (versions of) modules at k
o Positive feedback is created by change ripples
▪ Example: The Saturn V
• Increase thrust power
o Add additional F1 engine
o ➔ Additional fuel line
o ➔ More powerful fuel pump
o ➔ Larger fuel tank stage 1
o ➔ Stronger fuel tank stage 1
o ➔ Adapt shape fuel tank stage 1
o ➔ Enlarge interstage & second stage
o ➔ Adapt interstage & second stage
o ➔…
→ Design complete new rocket
o Positive feedback mechanism that causes instability
▪ Example: A racing bike
• Gear handle worn out
o Replace gear handle
o ➔ Handle for 8 gears retired
o ➔ New handles only 7 or 9 gears
o ➔ Replace gear block in the rear
o ➔ Replace gear cabling
o ➔ Replace gear block in front
o ➔…
→ Replace racing bike
▪ A basic transformation
• You need to define what that transformation is (input → output)
• Basic form:
o Left side: requirements (speci fications) are data entities and action entities
▪ Conceptual
o Right side: software primitives (data structure, class)
▪ Transformation of the entities
▪ Software
o Change left side: output due to the positive feedback mechanism of ripples
, o In evolving information systems, changes:
▪ can be and are applied
▪ on a regular basis k=1,…
▪ do cause ripple effects
• Ripple Effects in a Growing Modular Structure
o Dynamic instability
o Caused by positive feedback
▪ between modular structure and change ripples
→ Dy[k] ~ ay[k], a > 0
• positive feedback factor a in the marginal addition number of versions you must make
for a certain set of requirements
▪ with growing structure
→ y[k+1] = y[k] + Dy[k] > y[k]
• grow = the marginal amount that becomes unbounded
• NST: we want to avoid these dynamic instabilities
• Desing Theorems for Stable Software
o In order to avoid dynamic instabilities in the software design cycle, the rippling of changes needs to be
depleted or damped: a = 0
o As these ripples create combinations of multiple changes for every functional change, we call these
instabilities combinatorial effects
o Demanding systems theoretic stability for the software transformation, leads to the derivation of
principles in line with existing heuristics
o Adhering to these principles avoids dynamic instabilities, meaning that these principles are necessary,
not sufficient for systems stability
LECTURE 2: DESIGN THEOREMS FOR SOFTWARE STABILITY
We can see software design cycle as a dynamic system
o Requirements x, software versions y, (positive) feedback cycle
Design theorems to make sure the effect of rippling of changes are minimized
• First principle: Separation of Concerns
o Two different things in two different software modules
o When you combine different things in one software module, and one thing needs to change you need to
duplicate the other things in different modules
▪ When one thing needs to change in the unchanged things in the different modules, you need to
change it at various point in the code, which causes ripple effects
▪ When these things are separated in different modules, the change only need to be done in one
place
o Manifestations
▪ An action entity can only contain a single task or change driver
▪ Heuristic manifestations:
• Multi-tier architectures
• External workflow systems
• Separating cross-cutting concerns
• Use of messaging, service, integration bus
➔ separation of concerns
LECTURE 1: THE DESIGN CYCLE AS A DYNAMIC SYSTEM
• Once upon a time…
o Some academics started wondering why software systems were so problematic to change, which
seemed to get even worse over time …
o Discussed this with many practitioners, most of whom agreed that this was probably the most important
problem in software systems …
o And asked themselves whether such progressive structure degradation could be scientifically described,
or even be controlled …
• Dynamic Instability due to Positive Feedback
o = something that gets worse overtime (progressive)
o Many examples of dynamic instability
▪ Tacoma Bridge collapse
▪ Swing / Hammock chair → force = swing gets larger and larger
▪ Childbirth contractions
▪ Thermal runaway
▪ Opamps
• Systems theory and stability
o In engineering, systems theory
▪ studies the dynamic behavior of system(s) (properties) under external inputs
▪ using differential (continuous) or difference (discrete) equations
▪ considering at least an input x(t) and output y(t) in the function of time
o A system is dynamically stable if and only if
▪ a bounded input results in a bounded output
o For a simple first order model
▪ dy(t)/dt = x(t) + ay(t)
▪ y[k+1]-y[k] = x[k] + ay[k]
o → Stability requires a < 0
• Aeroelastic flutter of Tacoma Narrows Bridge,
o Dynamic instability
o Caused by positive feedback
▪ between body deflection and force of fluid flow
→ dy(t) ~ x(t)
▪ with zero net damping
→a=0
• allowed the energy to cumulate in an unbounded way
o Positive Feedback in Childbith Contractions → dy(t)/dt ~ ay(t), a > 0
• Not used to study dynamics of system designs
o Used to study dynamics of system operations
• NS theory tries to use systems theory to study the evolution of a design
,• The Design Cycle as Dynamic System
o Consider the Function → Construction transformation
o Consider this design transformation as a system, with:
▪ the requirement specifications as inputs x
▪ the (versions of) artifact modules as outputs y
o Simplify the high dimensional vectors to scalars:
▪ x[k] the amount of specifications at k
▪ y[k] the amount of (versions of) modules at k
o Positive feedback is created by change ripples
▪ Example: The Saturn V
• Increase thrust power
o Add additional F1 engine
o ➔ Additional fuel line
o ➔ More powerful fuel pump
o ➔ Larger fuel tank stage 1
o ➔ Stronger fuel tank stage 1
o ➔ Adapt shape fuel tank stage 1
o ➔ Enlarge interstage & second stage
o ➔ Adapt interstage & second stage
o ➔…
→ Design complete new rocket
o Positive feedback mechanism that causes instability
▪ Example: A racing bike
• Gear handle worn out
o Replace gear handle
o ➔ Handle for 8 gears retired
o ➔ New handles only 7 or 9 gears
o ➔ Replace gear block in the rear
o ➔ Replace gear cabling
o ➔ Replace gear block in front
o ➔…
→ Replace racing bike
▪ A basic transformation
• You need to define what that transformation is (input → output)
• Basic form:
o Left side: requirements (speci fications) are data entities and action entities
▪ Conceptual
o Right side: software primitives (data structure, class)
▪ Transformation of the entities
▪ Software
o Change left side: output due to the positive feedback mechanism of ripples
, o In evolving information systems, changes:
▪ can be and are applied
▪ on a regular basis k=1,…
▪ do cause ripple effects
• Ripple Effects in a Growing Modular Structure
o Dynamic instability
o Caused by positive feedback
▪ between modular structure and change ripples
→ Dy[k] ~ ay[k], a > 0
• positive feedback factor a in the marginal addition number of versions you must make
for a certain set of requirements
▪ with growing structure
→ y[k+1] = y[k] + Dy[k] > y[k]
• grow = the marginal amount that becomes unbounded
• NST: we want to avoid these dynamic instabilities
• Desing Theorems for Stable Software
o In order to avoid dynamic instabilities in the software design cycle, the rippling of changes needs to be
depleted or damped: a = 0
o As these ripples create combinations of multiple changes for every functional change, we call these
instabilities combinatorial effects
o Demanding systems theoretic stability for the software transformation, leads to the derivation of
principles in line with existing heuristics
o Adhering to these principles avoids dynamic instabilities, meaning that these principles are necessary,
not sufficient for systems stability
LECTURE 2: DESIGN THEOREMS FOR SOFTWARE STABILITY
We can see software design cycle as a dynamic system
o Requirements x, software versions y, (positive) feedback cycle
Design theorems to make sure the effect of rippling of changes are minimized
• First principle: Separation of Concerns
o Two different things in two different software modules
o When you combine different things in one software module, and one thing needs to change you need to
duplicate the other things in different modules
▪ When one thing needs to change in the unchanged things in the different modules, you need to
change it at various point in the code, which causes ripple effects
▪ When these things are separated in different modules, the change only need to be done in one
place
o Manifestations
▪ An action entity can only contain a single task or change driver
▪ Heuristic manifestations:
• Multi-tier architectures
• External workflow systems
• Separating cross-cutting concerns
• Use of messaging, service, integration bus
➔ separation of concerns
