CDF - Canonical Design Form: What Is?

From: Universe (no email)
Date: 09/12/04 

Date: Sun, 12 Sep 2004 13:25:17 -0400

Canonical Design Form (CDF), or Standard Design Form (SDF), is system
design architectural pattern which should typically be applied to and
overlay the modularity structure of software systems to realize
optimal system abstraction, abstraction collaboration and dependency
management. Generally it as depicted:

                Canonical Design Form (CDF)
                          - or -
                 Standard Design Form (SDF)

         User Interface Subsystem Use Case Model Subsystem
                                  \ /
                                      +
                                  / \
          Domain Model Subsystem Data Model Subsystem

Decades of software engineering have demonstrated that CDF
partitioning and grouping more often than not makes possible the
creation of the best software systems in both the Structured and OO
paradigms of development. CDF contributes to the greatest Structured
and OO systems, and has frequently done so for software created in
other paradigms as well.

CDF has been found to maximize the largest number of advantageous
software system characteristics, while minimizing the undesired. Not
surprisingly advantageous characteristics work to minimize least
desired characteristics, just as reducing the undesired enhances the
advantageous characteristics.

CDF characteristics of benefit are fairly the same and congruent with
characteristics arising from project relevant simulation of
significant domain abstractions and abstraction collaborations. In
other words advantageous CDF properties match those that flow from
mirroring project scope significant domain entities and entity
networks as the core of both high level logical and high level
physical design of the software system and additionally within system
subsystems.

Listed specifically are some of the major advantages of overlaying CDF
on system design structure:

a) Fault line advantages
     i) for maintenance
     ii) for enhancement
     iii) complexity reduction
     iv) interface optimality
     v) most likely abstraction reuse
     vi) best dependency mgmt potential
b) Loose module coupling
    i) inter-subsystem
    ii) intra-subsystem
c) High module cohesion
    i) inter-subsystem
    ii) intra-subsystem
d) Complexity reduction
     i) facilitates developers' understanding
     ii) facilitates developers<==>client comms
e) Reuse
     i) most likely abstraction reuse

Canonical Design Form benefits may rearranged and aggregated in
multiple permutations. One, or more of them may contribute to one, or
more useful arrangements, or aggregations. Together they strengthen
one another in a synergistic fashion. Just as the aspects, flows,
lines and patterns in a well designed dress assist each other to
create a whole with new characteristics greater than the simple sum of
the parts.*

Systems exhibiting the listed features result in large part from
applying well tailored development process, and proven architectural
design principles and patterns. Of which most assuredly optimal
domain and use case simulation, as well as CDF, comprise 2 critical
software architectural success factors.

Before closing, it's important to note that usually CDF overlays (is
laid over) a number of other kinds modular system structuring. CDF
overlays in the manner that a chart of a frog's various biological
subsystems may be illustrated using multiple transparencies. Each
major frog subsystem is drawn on its respective sheet. The sheets may
be inserted, or withdrawn providing various perspectives of the frog's
biology.

Each set, or system of modularity constituting a software system along
with the CDF has its own specific goals, or aims. Notable among the
various types of modular structures: transaction, security,
distributed computing, and communication modularity systems, or
structures. In Toto we must believe. Just seeing if you're still
there. Hope you enjoyed reading about CDF with the same pleasure I
had in "penning" the explanation. See you later. Ciao!

* [A system calculus both in the derivative and integral must be
employed to analyze, synthesize and thereby extend our ability to
manage and leverage these valuable, fun, exciting and highly dynamic
systems.]

Elliott
-
"Creating proper abstractions and abstraction models, with loosely
coupled and highly cohesive modules are sine qua non of great
modelling and software programming." @Elliott, 2002
             Celebrate Modelling! *^* 3w.radix.net/~universe 

--
     We Don't Need the US Fat Cat's Geopolitical Hegemony War!
              People of the World Say US Out Now!
- 
"Object-oriented [OO] programming. A program execution is regarded as
a physical model, simulating the behavior of either a real or
imaginary part of the world...The notion of a physical model should be
taken literally."                     ~ Computerized physical models
     Madsen, Moeller-Pederson, Nygaard (co-founder of OO)
-
               * http:\\www.radix.net/~universe *
          @Elliott 2003 my comments ~ newsgroups+bitnet OK
-- 
Theory Leads, Practice Verifies
 Profiteer US Out of Iraq Now!
Quantcast