| |
|
First Principles of CBD of physical products & Falsifiable Facts for the CBD
|
|
|
What do we know about the CBD (Component Based Design) of physical products? What are the irrefutable facts (e.g. essential aspects) of the CBD of physical products? Answer: Each physical product contains one or more hierarchies of replaceable components
(e.g. FIG-1 below). Over 90% of features and functionality is implemented as replaceable components. Total cost (or complexity) of disassembling (or reassembling) of any physical product is between 1% to 20% of the cost (or complexity) of designing and building all of the components used for building the product.
|
|
| FIG-1:
This figure is FIG-2 from
web page for CBD-Stricture |
 |
In this hierarchical construct, each component/part can be disassembled unplugged (e.g. disassembled to redesign individually) as a unit and plugged-back-in (e.g. reassembled after testing individually) as a unit. Removing (e.g. by unplugging) any container component (e.g. part-2) effectively removes all its sub-components (e.g. part-3) and sub-subcomponents (e.g. part-4), and so on. This website refers to this kind of component hierarchy as "CBD-structure" or "Hierarchy of Replaceable Components". Such replaceability of components a silent innate nature and an undocumented essential aspect of the CBD of the physical products, where any component (e.g. part-2 or part-1) can be removed (e.g. by unplugging) as a unit, since unplugging a component effectively remove all its subcomponents without leaving any traces of its sub-parts.
|
|
|
|
What is the true essence of the CBD of physical products and the physical components? It is not reuse, not standardization, nor any such other stuff (e.g. erroneously attributed to so called software components). The Irrefutable Answer is: No spaghetti code. What are the striking characteristics of elephant? Simple answer is, its big size, trunk and tusks. What are the striking characteristics of CBD of physical products? Simple answer is: contains one or more “hierarchies of replaceable components” and “no spaghetti code” (either within each of the components or within the ‘component hierarchy’). How could any design be a CBD (Component-Based Design), if the design doesn’t use real components (e.g. only uses fake components) and have no hierarchies of real components?
|
|
|
The physical product and each of the components contain no spaghetti code. There is no spaghetti code within each component in the hierarchy. If I am responsible for a component ‘component-X’ (e.g. to refine the component little-by-little), I can unplug component-X to redesign it (e.g. blueprint or source code) individually (to make it as best as it can be by refining little-by-little iteratively) and test it individually and plug-in. This is true for each of the replaceable components in the component hierarchy. Each component (i.e. blueprint or code) can be iteratively redesigned, tested and refactored individually to make it spaghetti code free. There is no spaghetti code at the level of the product. The spaghetti code is eliminated or minimized at the product level, since over 90% of the features and functionality (i.e. source code) of the product is implemented as such components (where each component can be made free from spaghetti code due to occasional refactoring individually).
|
|
|
It is not necessary that, even a single component in the hierarchy possess any of the properties (e.g. reuse, standardized) erroneously attributed to so called software components or conform to any so called software component models exist today. The single most important aspect and true hidden essence of real components for true CBD is: “No Spaghetti Code”. Implementing even a portion of the functionality or features of a software application as components proportionally reduces the spaghetti code. Today no conscious effort is made to identify SCCs to build even small portion of each of the applications by using replaceable components (or RCC) to proportionally reduce spaghetti code.
|
|
|
Today no large software product is created as hierarchy of components. But it is possible to build many GUI applications as hierarchy of replaceable components. For example, this City-GIS application is created as hierarchy of components. In fact, today it is impossible to find code base for even a single large SCC (‘Self-Contained Component’) of size City_ATC that is implemented as a RCC (Replaceable Component Class) to make it free from spaghetti code. Each RCC can’t be individually refactored to make it free from spaghetti code, if the code base for the SCC spread across many non-exclusive files containing code sections for other SCCs. Today code base for each SCC is spread across multiple non-exclusive files.
|
|
|
It is possible to identify many SCCs in any exiting non-GUI-application, where each SCC can be implemented as a RCC (to make it spaghetti code free) but are not implemented as RCC (so each SCC started its life as spaghetti code spread across many non-exclusive files and its developer is forced to refine this spaghetti code many times even before first release). Alternatively, it is easy to prove that, a large portion of functionality and features of most of the non-GUI-applications are implemented as SCCs, where each of the SCCs can be designed as a replaceable component but today no conscious effort is made to identify each SCCs to design the SCC as a replaceable component.
|
|
|
Today it is impossible to find even a single theory or hypothesis, (that is based on hunch, guess or wishful thinking), accepted as a fact (without testing it against whole world of known/recorded observations to falsify the theory or hypothesis), for example, to advance any scientific or engineering field for decades by blindly relying on such untested axioms. One of the previous well known examples is geocentric paradigm, and exposing the error in the seed axiom resulted in greatest scientific revolution known to mankind.
|
|
|
It is not hard to prove that there exists a truth and the truth can be discovered, where the truth is “there exists a set of essential properties that are uniquely and universally shared by each & every physical functional component known to mankind” and the set of essential properties (i.e. truth) can be discovered. This discovery is akin to discovering that the Sun is at the center, which exposed flaw in then widely accepted fact “the Earth is static at the center”. Likewise, it exposes errors in seed axioms of CBSD by proving that no other kind of software part can be a component without sharing the essential properties.
|
|
|
Once the set of essential properties (or characteristics) of physical functional components is discovered, it is kind of trivial task to identify SCCs in case of GUI applications. But today no attempt is made to identify even the simpler SCCs in the GUI applications. Although it is not hard capability to implement, no other GUI library (e.g. Java/Swing, Windows/VB) is implemented to encapsulate each of the larger SCCs in a class definition (to make it free from spaghetti code by implementing the SCC as RCC-Replaceable Component Class). So the code base of each SCC ends up as spaghetti code spread across many non-exclusive files.
|
|
|
In case of non-GUI-applications, any SCC can be implemented as RCC, but it is not a simple task to identify SCCs in each of the non-GUI-applications (even after discovering the set of essential characteristics of physical functional components). To identify SCCs in non-GUI-applications, one requires in-depth knowledge about the innate nature and essential characteristics of physical functional components backed by more experience (e.g. in identifying SCCs in GUI applications) and/or hands on training form a person who is expert in identifying SCCs.
|
|
|
Current state in summary: It is easy to identify SCCs in GUI-applications, but no conscious attempt is made to identify them. Even if large SCCs are identified, it is not possible to make each of the SCCs free from spaghetti code (by designing each of the SCCs as a RCC) due to the limitations of the exiting GUI libraries such as Java/Swing or Windows/VB. For example, except our GUI-Library no other GUI library allow developers to implement components such as City_ATC as RCC, so the developers are forced to implement the code base of City_ATC as spaghetti code (across many non-exclusive files, where many files contain code for other SCCs). On the other hand, it is not a trivial task to identify each of the SCCs in non-GUI-applications, but today nothing prevents implementing each of such non-GUI SCC as a RCC (but no conscious effort is made to identify SCCs, so almost no SCC is implemented in a set of exclusive files implemented for a RCC to free it from spaghetti code).
|
|
|
Isn’t it an obvious fact that, real-CBD for any product must use real components to build the products? One must implant this picture (i.e. FIG-2 of CBD-Structure) in his mind and must never forget this image of CBD-structure and the essence represented in the image of CBD-structure. The essence represented by logical CBD-structure is referred to as: Hierarchy of replaceable components. Hierarchy of replaceable components is the logical structure of any CBD of physical product. The objective of my research spanning nearly a decade is to achieve equivalent structure (hierarchy of replaceable components) for any complex software applications. The equivalent structure for software applications is represented by the picture (i.e. FIG-1 of City_GIS), where each RCC requires no more than 3 to 5 lines of code to assemble (and disassemble) each of the respective RSCCs. These 2 pictures
(i.e. FIG-1&2) are burned into my memory (hard wired into my thinking).
|
|
| FIG-2:
This figure is FIG-1 from City_GIS application |
 |
|
No RCC should require more than 3 to 5 lines of code to assemble each of the RSCC (an object instance of RCC) in an application, and removing the 3 to 5 lines must effectively remove the RSCC and all its sub components (as a unit). That is, it should require just 3 to 5 lines to remove RSCC-19 (in the following figure) and all it's subcomponents (e.g. RSCC-16, RSCC-15), sub-subcomponents (e.g. RSCC-11, RSCC-12, RSCC13) and sub-sub-subcomponents (e.g. RSCC-08, RSCC-09, RSCC-10). It should not require more than 3 to 5 lines to assemble RSCC-20 as subcomponent in a container component, and so on.
|
 |
|
|
|
If an application has 100 such SCCs (Self-Contained Components), our CBSD needs implementing each SCC as a RCC. Then it requires no more that 300 to 500 lines to assemble 100 replaceable components (or RSCCs). That is, it needs 3 to 5 lines to assemble each RSCC (by including an object instance of respective RCC) and removing the 3 to 5 lines effectively removes the RSCC without leaving any traces. The collaboration between RSCCs is handled using intelligent CASE-tools (e.g. this CASE-Tool), so there is no need for implementing any more communication code for each RSCC. Since there is no associated communication code implemented for each RSCC (in its container component), there is no need for removing any communication code (form its container component), when removed the RSCC, or replaced by an equivalent RSCC.
|
|
|
My single minded objective and obsession has been to achieve the hierarchy of replaceable components for software applications (or products). The way I accomplished this objective is by discovering the innate nature and the set of essential properties of physical functional components, since no other kind of physical part except a very special kind of physical part (known to mankind as components) having very unique properties necessary for achieving such CBD-structure. The physical functional components are very special kind of parts having very unique nature and essential characteristics, which are unknown to the mankind, hence must be discovered to positively identify equivalent parts in software applications (e.g. to implement each equivalent part as a replaceable component).
|
|
|
Another falsifiable fact (but it is impossible to find a flaw) is, neither complexity nor uniqueness of one of a kind physical product (e.g. prototype of a spacecraft or experimental jet-fighter) can prevent its designers from achieving hierarchy of replaceable components. In contrast, today not even 10% of the functionality and features is implemented as RCCs in each of the large applications. Let me define a term: achieving X% modularity for a software application implies, implementing X% of the functionality and features (or code base) of the application as RCCs.
|
|
|
Even for argument sake, if it is impossible to achieve 90% modularity, there is no valid reason why it is not possible to achieve 30% to 50% modularity (by implementing 30% to 50% of code base in RCCs). Whatever excuse or justification one can find, I am sure, I can find a flaw in the justification. Any excuse to rationalize exist paradigm is falsifiable and it is not hard to find flaws in each of the excuses (or justifications). For example, if one insists that there exists no such set of essential properties for physical functional components, I can prove that there exits a truth (i.e. a set of essential properties) and the truth can be discovered. For example, if one says it is impossible to invent equivalent software components, I can identify few SCCs in any existing application that can be implemented as RCCs (but each is implemented as spaghetti code for no apparent reason).
|
|
|
There is no valid reason why design of software products alone must be infected with spaghetti code. No other kind of physical parts can achieve the highest degree of modularization possible for the components, so it is essential to discover the unique hidden characteristics that are enabling the components to achieve such high degree of modularization. I am providing many falsifiable assertions and concepts in support of our new paradigm, and I am sure it is impossible to find a flaw for any of my falsifiable assertions and concepts. On the other hand, it is not very hard to find flaws in each of the excuses or justifications given to defend or rationalize the existing paradoxical paradigm.
|
|
|
How could mankind invent computer chips by being clueless about the essential properties of electrons, such as how they behave in semi-conductor material? How could mankind invent fiber-optic networks by being clueless about essential properties of light, such as how it behaves in strands of optical-fibers? Likewise, mankind can’t invent real CBD for software by being clueless about essential properties of physical components and essential aspects of real CBD for the physical products, since the essential properties enable the components to achieve the real CBD having the essential aspects (e.g. 0% spaghetti code).
|
|
|
Few more interesting facts & observations about physical components & CBD:
|
|
|
Most of the features or functionality of a physical product is provided by the replaceable components, if the product is created by using CBD, where each replaceable component provides a subset of features and/or functionality of the product. Each component might depend on services (i.e. functionality) of one or more other replaceable components and/or provide one or more services (i.e. functionality) for the other components. The components in a CBD-product collaborate with each other by requesting services of each other.
|
|
|
What are the striking properties of physical functional components? Each of the components is designed to provide a subset of functionality or features of the container product (or component). Another striking difference between other kinds of parts and components is, the components are self-contained, so requires no more construction or configuration, so can be assembled readily. Likewise, each component can be easily disassembled as a unit at any time in the future, for example, either replace by an equivalent component or to refine and test it individually and reassemble. But other kinds of parts (e.g. ingredient parts) require substantial construction and configuration at manufacturing site for using as a sub-part for building container product (or component). Except components, no other kind of part can be disassembled (in the future) to test it individually outside of the container product (or component).
|
| |
