It is a huge
error to assume CBSD (Component-Based Design for Software) is using so called
software components. A simple method for discovering the real essence of CBD of
physical products is to compare the differences of (a) how each of the large
physical functional-components for prototype of a one-of-a-kind products (or a
product newly being invented) is custom designed and build for the target
physical product; with (b) how each of the large self-contained components (or
software modules logically equivalent to the physical functional-components) is
custom designed and build for it’s target software product.
Step-1: If I am responsible for a component Cx for a target product, I can design, build and test the component Cx independently outside of the product. Then when I feel it is ready, I can plug-in (or assemble) the component in the target product to make sure it functions as expected.
Step-2: If
doesn’t fit or function as expected, I can unplug (or disassemble) the
component Cx to refine little-by-little until it
fits properly and functions as expected in the container physical product (or in the
container-component, if Cx is a subcomponent of a container-component).
The Cx is custom designed to satisfy current
unique needs of the target product. The step-1 and step-2 can be repeated for
each Cx in the component hierarchy (e.g. CBD-structure)
of any CBD-product.
Once, the product model is released to the market, the
maker of the product need to design, build and release new models or versions
of the product. I can continue to refine the blueprint (e.g. design) of
component Cx little-by-little (in step-1 and also
in step-2) independently throughout the evolutionary life of the target product
(i.e. for each creation of successive new models and versions). Again the Cx is custom designed to satisfy current
unique needs of each of the new product model.
If I am a designer of City_ATC for a target City_GIS application, why do I need to touch or even see even a
single line of internal code any other components (e.g. City_LandMarks,
City_Hotels or City_Map)? If I am a designer of City_Theaters for a target
City_GIS application, why do I need to touch or even see even a single line of
internal code any other components (e.g. City_ATC or City_Hotels)?
Please remember, if I were designer of HardDrive for a
computer product, I don’t need to touch or even see tape-out Verilog code of
CPU, DRAM or any other IC-Chip. Likewise, if I were designer of auto-engine, I
don’t need to touch or even see a single line of code (i.e. internal design) of
CD-player, gearbox or auto-battery. If I were designer of motor that spins the
magnetic disks in HardDrive, I don’t need to touch or even see even a single
line of code (i.e. internal design) of magnetic disks or any other component in
the container component HardDrive or in the target computer product.
Therefore, in case of CBD for physical products, there is
no spaghetti code. The designer of each component-Ci (for each component-Ci,
where component-Ci can be any component between component-C1 to component -Cn),
don’t need to touch or even see single line of code (i.e. internal deign) of
any other component in the hierarchy of replaceable components (or
CBD-structure).
Toady it is impossible to avoid spaghetti code
in software products, since the source code of each Cx (e.g. City_ATC or
City_LandMarks) is forced to spread across multiple non-exclusive files, where
each of the file contain source code for more than one component. For
example, today no other GUI-API is capable of encapsulating complex
GUI-components such as City_LandMarks or City_ATC in a replaceable component
classes (RCC), so that the component can be plugged-in by implementing just 3
to 5 lines of code and can be unplugged by deleting the 3 to 5 lines of code.
It would take just few minutes to find the code base of any component, if
encapsulated in a RCC (otherwise would take forever to find all code-sections
spread across multiple non-exclusive files).
If I am a designer of City_ATC component (encapsulated in
a RCC), I don’t need to see a single line of code of any other component, even
if I work on the City_GIS application for seven years creating a new version of
City_ATC component every six months for each new release or upgrade. This is
not that much different from, I don’t need to see a single line of code of any
other component, if I were a designer of motor that spins the magnetic-disks in
the HardDrive and I need to constantly improve the motor for each of the new
models for ten years.
Why the software developers today are forced to design and
develop components such as City_ATC, City_LandMarks or City_TouristSpots as
spaghetti code? More and more spaghetti code would be accumulated as each of
the components is redesigned for satisfying unique needs of each of the newer
models of the target product. Why a designer and developers of any component
(e.g. City_TouristSpots or City_Hotels) need to see even single line of code of
any other component in City_GIS application? The real-CBD not only eliminates
spaghetti code but also eliminated reasons for accumulation of spaghetti code
during the evolutionary life of products.
Many physical products (e.g. automobiles, Airplanes or
super-computers) have been evolving for many decades and many successive new
models have been designed with nearly zero accumulation of spaghetti code. I
hope this example (using analogy of physical components) illustrate the essence
of the CBD (Component Based Design). We invented all the missing pieces (e.g.
GUI-API and intelligent-CASE-tools,
etc) for creating real-software-components and assembling the
real-software-components for achieving CBD-structure (i.e. hierarchy of
replaceable components).
Let me summarize the essence of CBD is simple terms: If
City_GIS application is built by assembling 6 components and 6 RCCs for 6
components are designed and built by 6 engineers (i.e. each engineer created a
RCC), it is not necessary for any engineer to see a single line of code implemented
in any other RCC. Likewise, if a product is built by assembling 1000 components
and each of the 1000 components is designed and built by an engineer, it is not
necessary for any engineer to see internal design (e.g. a single line of code
or blueprint) of any other component. Any component should be disassembled or
reassembled in minutes (e.g. either to replace or to redesign for successive
models).
It is impossible to find a valid reason why it is not possible to achieve real-CBSD (i.e.
hierarchy of replaceable components for complex software products), once
essential aspects of CBD for physical products and essential properties of
physical functional-component are discovered (where the essential aspects of
CBD for physical products are the aspects uniquely and universally shared by
the design of each and every complex product built by assembling physical
components; and essential properties of physical functional-component are
properties shared by each and every physical functional-component).
Analyzing the differences between ‘a’ and ‘b’ of the first paragraph at
the top not only expose the huge insane error but also help discover the true essence of real-CBD (e.g.
especially in the light of 3-CBD-facts).
