AXIOMATIC DESIGN IN SOFTWARE DESIGN FOR SIX SIGMA (DFSS) - Software Design for Six-Sigma: A Roadmap for Excellence - page 350

DP and FR (see Figure 1.2). When R = S = 1, the design is completely uncoupled.

The design is decoupled when R = S (Suh, 1991).

⎡

⎤
⎦

2 p

p p

⎣ 1

A kj A kj R = − A kj A kj / (13.13)

j = 1 , p − 1
k = 1 + i , p

k = 1 k = 1 k = 1

⎛ ⎞

p p

⎝ | ⎠

A kj S = A jj | / (13.14)

j = 1 k = 1

Axiom 1 is best satisfied if A is a diagonal matrix depicting an uncoupled design.
For a decoupled design, axiom 1 can be satisfied if the DPs can be set (adjusted)
in a specific order conveyed by the matrix to maintain independence. A design that
violates axiom 1 as it distances itself from uncoupled and decoupled categories is, by
definition, a coupled design. The vulnerability of coupling is assured whenever the
number of DPs, p, is less than the number of FRs, m (El-Haik, 2005: See Theorem
1 and Theorem 2, Section 2.5). In other words, the desired bi-jection one-to-one
mapping property between two design domains cannot be achieved without an ax-
iomatic treatment. An axiomatic treatment can be produced by the application of
design theories and corollaries deduced from the axioms (El-Haik, 2005).
For a unifunctional design entity ( m 1), the independence axiom is always sat-

isfied. Optimization, regardless of whether being deterministic or probabilistic, of a
multifunctional module is complicated by the presence of coupling (lack of indepen-
dence). Uncoupled design matrices may be treated as independent modules for opti-
mization (where DPs are the variables) and extreme local or global DPs settings in the
direction of goodness can be found. In a decoupled design, the optimization of a modu-
lar element cannot be carried out in one routine. Many optimization algorithms, in fact
m routines, need to be invoked sequentially starting from the DP at the head of the tri-
angular matrix and proceeding to the base. The coupling that we need to guard against
in software design is the content type. The content coupling is bad as in hardware and
should be avoided. It occurs when one module (a DP) directly affects the workings
of another (another DP) or when a module (a DP) changes another module's data.
In addition to the content type, several types of software coupling are listed as
follows:

=

Common: Two modules have shared data (e.g., global variables).
External: Modules communicate through an external medium, like a file.
Control: One module directs the execution of another by passing control infor-
mation (e.g., via flags).
Stamp: Complete data structures or objects are passed from one module to
another.
Data: Only simple data is passed between modules.