First Principles of CBD of physical products: Falsifiable Facts for the CBD (Component Based Design)

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 comprises hierarchies of replaceable components. Over 90% of features and functionality is implemented as 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.

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: containing one or more “hierarchies of replaceable components” and “no spaghetti code” (either within each of the components or within the ‘component hierarchy’).

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) and test it individually and plug-in. This is true for each of the components in the component hierarchy. The design of each component (i.e. blueprint or code) is 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 is free from spaghetti code).

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.

It is possible to identify many SCCs in any exiting non-GUI-application, where each SCC can be implemented as a replaceable components (to make it spaghetti code free) but are not implemented as replaceable components (so started its life as spaghetti code 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 fact. 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 replaceable component class).

In case of non-GUI-applications, any SCC can be implemented as replaceable component class, 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. On the other hand, it is not a trivial task to identify each of the SCCs in non-GUI-applications, but any such SCC can be implanted as RCC (but no conscious effort is made to identify SCCs, so almost no SCC is implemented as a RCC to free it from spaghetti code).

One must implant this picture (i.e. FIG-2 of CBD-structure) in his mind and one must never forget this structure and the essence represented in the image. 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 no RCC requires more than 3 to 5 lines of code to assemble (and disassemble) each of the respective RSCCs. These 2 pictures are burned into my memory (or hard wired into my mind).

My single minded objective and obsession is to achieve the hierarchy of replaceable components for software applications. 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 can achieve such 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).

If an application has 100 such SCCs (Self-Contained Components), our CBSD requires implementing each SCC as a replaceable component. Then it requires no more that 300 to 500 lines to assemble 100 replaceable components. That is, it needs 3 to 5 lines to assemble each replaceable component and removing the 3 to 5 lines must effective remove the replaceable component without leaving any traces. The collaboration between the components is handled using intelligent CASE-tools such as this CASE-Tool. There is no need for implementing any more communication code for each of the replaceable components, so there is no need for removing any communication code (when removed the component or replaced by an equivalent 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 even 10% of the functionality and features is implemented as replaceable components 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 of the application as replaceable components (or RSCC).

Even for argument sake, if it is not possible to achieve 90% modularity, there is no valid reason why it is not possible to achieve 30% to 50% modularity. 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 other 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 of 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).

Requesting software scientists and researchers to discover the light of truth for overcoming the darkness of ignorance and resultant software crisis

Known Facts about the Physical Functional Components: The physical products are built using many kinds of parts such as ingredient parts (e.g. steel, cement, metals, glass, silicon or plastic), mixtures (e.g. led and acid in led-aced batteries), alloys, tightly coupled parts (e.g. copper strings and plastic insulator in electric wires or threads in a cloth) and of course components. It is foolish to define that any kind of part having one of more useful properties (reusable or standardized) is a component.

Don’t we know that the components are a very special kind of parts having unique characteristics for achieving CBD (Component Based Design – hierarchy of replaceable components)? Except components, no other kind of parts can achieve equivalent hierarchy of replaceable parts. What is the hidden nature that is enabling them to achieve the hierarchy of replaceable parts?

            If we show to an expert a part and ask him, weather it is a component or it is not a component, I am sure he must have no problem positively identifying it. That is, if it is a component, he would say that it is a component. If it is not a component, he would say that it is not a component. He may make a mistake in case of very small non-functional parts such as bolts, screws or panels. He might fail in very rare fringe cases (e.g. false positively or false negatives). But he would not fail in case of functional components such as CPU, Engine, CD-player, car-battery or hard drive, where a functional component is a component that is built by using more than one part to perform a function of a container product.

            What are the unique striking characteristics that are allowing the experts positively identify the functional components? What are the features or characteristics unique to the functional components that are allowing the experts to positively distinguish functional components from other kinds of parts? Today software engineers are clueless about the nature of the physical functional components and CBD. The sad part is, scientists of computer science and researchers of software engineering refuse to discover the light of truth, that could expose huge error that side tracked the software engineering for nearly 50 years.

            Please kindly remember, the purpose of components is achieving hierarchy of replaceable components, which results in eliminating the spaghetti code. It is not necessary that even a single components in the hierarchy to have any properties (e.g. reusable or standardized) erroneously attributed to software components nor conform to any existing so called component models.

The computer science and software engineering research community committed a huge error. The sad part is scientists and researchers refuse to learn the truth and use the light of the truth to overcome the darkness of ignorance (e.g. to solve software crisis, which is due to the darkness of ignorance). It is beyond my grasp, why research community refuses to discover the truth (e.g. by acknowledging the obvious facts and analyze the facts and simple observations). I believe, discovering the truth (e.g. by starting with essential characteristics of functional components and CBD) shall put the computer science on the right path that leads to an unprecedented revolution in software engineering.

Research is nothing but pursuit of absolute truth and pursuit of absolute truth is sacred duty of any real scientist. Refusing to discover the truth (e.g. nature such as essential characteristics of physical functional components or essential aspects of CBD of physical products) is nothing but abdicating the sacred duty. Once the essential characteristics of physical functional components are discovered, it is impossible to find a valid reason, why is not possible to invent equivalent software components for achieving component hierarchy of replaceable software components (e.g. that eliminates spaghetti code), where the hierarchy of replaceable software components is equivalent to the hierarchy of replaceable physical components that is an essential aspect of the CBD of physical products.

For example, how can any software expert conclude that it is impossible to invent equivalent software components without even trying to know the essential characteristics uniquely and universally shared by each and every physical functional component known to mankind? The experts of various physical products have been using the tacit knowledge about the essential characteristics unconsciously either to positively identify each of the physical components or to positively differentiate each of the physical components from other kinds of physical parts. It may take few weeks of handwork to convert this kind of tacit knowledge into explicit knowledge to positively identify equivalent software components, but acquiring such explicit knowledge is not impossible.

There exists a truth and the truth can be discovered. It is not hard to discover the truth. My humble request to scientists of computer science and researchers of software engineering is kindly discover the light of truth for overcoming the darkness of ignorance and resultant software crisis. It is a fact that the computer science is in darkness, because no effort is made to discover various kinds of physical parts for categorize various kinds of parts by discovering essential characteristics (and purpose) of each kind of parts.