banner banner  
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.
  Leading the Software Engineering Revolution
Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries