| |
|
What is real CBD for the physical products?
|
|
|
Any physical product is said to be a CBD product, if the product is built by assembling multiple physical components or comprising component hierarchies. In other words, no physical product can be a CBD-product if it contains neither
physical components nor hierarchies of physical components. Therefore one looks for components and component hierarchies to identify or ascertain if a product is a CBD product.
|
|
|
We don’t believe, complex semiconductor chips (e.g. DRAM, CPU etc.) are CBD-products,
even though few simple components (e.g. pieces of plastic moldings for packaging and pins to plug-in) are used.
The components in a true CBD-product must provide substantial complexity and functionality/features
of the CBD-product. This website refers such functional components as active-components (which are
defined in later web pages for real software
components).
|
|
|
An ideal physical CBD-product (e.g. a car, computer or cell-phone) is built by hierarchically assembling components, where no node-component in the component hierarchy must be very complex. A node-component is a component that has no subcomponents (i.e. is not built by assembling sub-components). Let’s define two essential aspects of the CBD-products that are universally shared by all the CBD-products (either exists today or invented in the future, which are (1):
CBD-structure and (2): CBD-process.
|
|
|
A real CBD for software products (or CBSD) must be equivalent to the CBD of physical products. That is,
the real CBSD must use real software components (equivalent to the physical components) for achieving a structure (or component hierarchy) logically similar to the CBD-structure by employing a process logically similar to the CBD-process. Please visit the web-page for
City_GIS to see such CBSD software application.
This sample software application achieved a structure equivalent to the CBD
structure by using software components that are equivalent to the real
components. That is, the real-software-components must have essential properties
that are uniquely and universally shared by each and every real physical
component in the world.
|
|
|
Please kindly note that, it is not necessary that even a single component
in the CBD-structure must be reusable, standardized or must have any properties erroneously
attributed to the existing software components. Only mature or crowded product
families can have
ecosystem for third party vendors for real components. Even after
objectively analyzing all the
facts and valid observations, it is impossible to find any valid reason why
it is not possible to achieve a structure equivalent to the CBD-structure for
any complex software product (it is useful & logical or natural choice, but not necessary
to employ a process
logically similar to the CBD-process).
|
|
|
What are the goals for achieving real-CBD for each software application?
|
|
|
The 5-Rules a Software Application must satisfy for Achieving the Ideal real-CBD
|
|
The CBD-process requires identifying each of the SCC (Self-Contained Components) in a software application and implementing an RCC for each SCC, so that it requires no more than 2 to 5 lines to assemble
each RSCC.
An Ideal CBD-application must strive to satisfy following rules:
|
|
1
|
The developers of each SCC start designing and developing each custom RCC individually.
|
|
2
|
Once very simple versions (e.g. initial bare-place-holders) of RCCs are ready, engineers build an ideal CBD application by taking a bare generic application template and start assembling each of the components, where no component requires more than 2 to 5 lines to
assemble.
|
|
3
|
Any component (i.e. replaceable-SCC or RSCC) can be disassembled by removing the 3 to 5 lines; and Removing all of the components
one RSCC at a time must end up with the above original generic or reusable application template.
|
|
4
|
Developer of each RCC can continue to refine or redesign his SCC (i.e. component) little-by-little individually and test it independently to make it
as best as it can be.
(i.e. Each RCC is individually evolved from initial/dummy-place-holder state to the state where it
is released).
|
|
5
|
The above rule-3 and rule-4 must be true (a) during and even after release of the first version
(i.e. step-1 of CBD-process) and
(b) during and after release
of each of the future version (i.e. step-3 of CBD-process) of the software
product (as illustrated by FIG-3 in City_GIS).
|
|
|
It is possible to invent sophisticated CASE-tools to eliminate the need for implementing any communication code for coupling each of the components in the application, so that each RSCC can be included in the application by properly including just an object instance of its RCC. The Real-CBD can and must use
sophisticated CASE-tools for not only (a) creating couplings between the components in the application automatically (without any need for implementing communications code in the application), but also (b) manage the coupling interfaces, for example to detect any broken or mismatched couplings between any two components.
|
|
|
|
Henceforth achieving ideal real-CBSD (i.e. real-CBD for software products) implies satisfying the above 5-rules of the ideal
real-CBD by using RSCCs, where the RSCCs are logically equivalent to the large physical
functional-components.
|
|
