| |
| “CBD-Structure” of the Physical Products |
| |
| This section briefly presents logical structure of the physical CBD-products, where the physical CBD-products are physical products built by assembling real physical components or physical products comprising component hierarchies (i.e. one or more components are built by assembling subcomponents, and so on). |
| |
| This section briefly presents logical structure of the physical CBD-products, where the physical CBD-products are physical products built by assembling real physical components or physical products comprising component hierarchies (i.e. one or more components are built by assembling subcomponents, and so on). |
| |
| Hierarchy of replaceable components: where the term ‘replaceable’ is used with a unique limited meaning: “The component is designed to be easy to disassemble and reassemble as a unit at any time in the future”. That’s it, and nothing more must be inferred in the context of this paper. The internal component structure (e.g. organization) of each of the physical CBD-products results in a logical hierarchy of components. Large physical CBD-products are designed and built by hierarchically assembling the components (i.e. each of the large components is in turn built by assembling its sub-components, and so on).
|
| |
|
|
| |
| For example, FIG-1 shows top-level large replaceable container components of a computer system. Each of the container-components in turn is built by assembling sub-components (see FIG-2). Each sub-components in-turn may be built by assembling its respective replaceable sub-subcomponents, and so on. For example, the Cars are built by assembling container-components such as engine, gearbox, alternator and stereo-system. Each large component is built by assembling other replaceable sub-components, and so on. FIG-2 represents ‘logical hierarchy of components and sub-components, and so on’ of any physical CBD-product (if it is designed by using physical components and CBD).
|
| |
|
|
| |
| In this hierarchical construct, each component or module can be disassembled and reassembled (as a unit). Removing a container-component (e.g. module-2) removes all its sub-component (e.g. module-3) and sub-sub- component (e.g. module-4) of each of the sub-component (i.e. module-3) of the container-component (i.e. module-2), and so on. This paper refers to this kind of structure/design as ‘component-hierarchy’ or ‘CBD-structure’. Such replaceability is an un-documented innate nature and an essential property of the CBD of physical products, where any component (e.g. module-2) that encapsulate all its sub-modules and can be disassembled as a unit (along with all of its sub-modules). |
| |
| In case of the physical-products, any component (e.g. 1, 2 or 4 in FIG-2) can be removed as a unit. When a container-component is removed, it effectively removes all its sub-components (without leaving any traces). This rule (i.e. hierarchy of replaceable-components) is not only true for any known physical CBE-product (e.g. car/cell-phone) but also true for complex new one-of-a-kind product such as experimental spacecraft, jet-fighter, fuel-cell ships or nuclear-submarine, (even if no single component/sub-component in CBD-structure is reusable or standardized). |
| |
| It can be safely assumed that any CBD-product invented in the future shell comprise components or component hierarchies (i.e. one or more components are built by assembling subcomponents, and so on). |
| |
| Preserving autonomy of each of the Components: Each component such as computer hard-drive or car-engine (having dozens or hundreds of sub-parts) can be easily separated (or detachable) as a unit from its product at any time in future for maintenance (e.g. replace or redesign). So each of the components can be evolved autonomously to incorporate new-innovations or satisfy evolving needs. |
| |
| Any component can be disassembled throughout the life of the CBD-product to (i) autonomously redesign and (ii) test it to assure quality (outside of its product), and then can be reassembled into its product. This ability to disassemble at any time in the future (i.e. throughout the evolutionary life of the CBD-product or to design newer models) is an extremely useful aspect of the physical-components.
|
| |
|
This section summarized an essential aspect and easily verifiable/irrefutable fact of the CBD for the physical CBD-products, which henceforth refer to either as CBD-structure (e.g. logical structure of components in each CBD-product), or hierarchy of replaceable components. The CBD-structure is absolutely essential property of CBD-products. That is, no physical product can be CBD-product, if it doesn’t have real components or hierarchies of components. In other words, looking for physical components or component-hierarchies is the only way to confirm that a physical product is a CBD-product or not a CBD-product. |
| |
|
Brief summary of few irrefutable facts: The true essence of CBD is achieving hierarchy of replaceable components. It is not necessary that even a single component in the hierarchy need to have any useful properties (e.g. reusable or standardized) or conform to any known component models erroneously attributed to so called software components. On the other hand, using reusable and/or standardized parts (e.g. steel, cement, plastic, metals, alloys or silicon wafers that are highly standardized and reused across many product families) is not CBD. The reality is most of the physical functional components are neither reusable not standardized.
|
| |
|
FIG-3: System Board designed without employing CBD (component-hierarchy)
|
|
|
|
If it were not possible to build as an hierarchy of replaceable modules, the devices must be flatly spread on the board. Then to replace each components (e.g. HardDrive), one must identify each of its devices (e.g. marked by red-arrows) and replace one device at a time. It is very complex to replace each device/object, since it is likely not designed as a replaceable part, so tightly coupled with other devices/objects. Except real-components, all other kinds of parts (even very small parts) by nature requires tight coupling (while even very large components can be designed as loosely coupled parts).
If the computer-board is designed an OOP applications, most devices are not designed to be replaceable. Each device (e.g. marked by '1') for a part (e.g. Hard drive) may end up tightly coupled with the devices for other parts (e.g. marked by blue-arrows). To replace a device, one must comprehend these couplings and must redesign interfaces of those devices/Objects.
Although Hard Drive may have 100 subcomponents/Objects, it can be removed in minutes, because it physically encapsulates all its subcomponents and also it is loosely coupled with other external components (with in the computer). When the whole product is build by assembling such loosely coupled swappable modules, the total cost of the product will be about 20% more than the total cost of all the swappable modules goes into it. This is true for Automobiles and Computers. How much it costs for Dell just to assemble each PC? Why the total cost of ownership of large software applications would be 1000% or 10 times more than the cost of all the Objects and parts goes into it?
|
|
| |
|
The goal for real CBSD (CBD for software) researchers must be inventing software components equivalent to the physical functional components that are capable of achieving equivalent hierarchy of replaceable components. Without even knowing the essence of real-CBSD is achieving hierarchy of replaceable components and without ever attempting to achieve such real CBSD, many software experts blindly insist that it is impossible to invent equivalent software components that are capable of achieving hierarchy of replaceable components. We can demonstrate hundreds of equivalent software components and hierarchies of replaceable components. Without
able to show even a single example, others foolishly argue that most of the software applications are already contain hierarchies of replaceable components.
|
| |
