| |
The Objective Reality of CBD/CBE & Facts about the Components | |
|
Which one of these two statements is closer to the objective reality or absolute Truth in the context of countless product models such as cars, computers, airplanes, cell-phones, machines or factory machinery (that are designed, engineered and built by using a specific kind of parts that are widely known or referred to as components)? |
|
1. The specific kind of parts that are designed and/or conducive to be reusable (e.g. for reuse across many products) are known as components, even if the parts can’t be assemble by any stretch of imagination?
2.The specific kind of parts that are designed and/or conducive to be assembled (or plugged-in) are known as components, even if the component is custom designed to fit perfectly and perform optimally in just one product model, so it can’t be reused in any other product model?
. |
|
|
Each of the above 2 statements provide two contradictory descriptions for the components. For example, geocentric paradigm was rooted in the belief that the Earth is at the center, while heliocentric paradigm is rooted in the belief that the Sun is at the center. Since both the earth and Sun can’t be at the center, each of the paradigms rooted in (i.e. evolved by relying on) 2 contradictory beliefs. In reality, large percent of reusable parts are not components. Also, large percent of components are not reused across product models (or product families). |
|
|
Isn’t common sense that we must use real Oranges for making real Orange juice? Likewise, one must use real components for achieving the real CBD/CBE (Component Based Design, Development or Engineering). Working very hard to acquire knowledge for the CBD/CBE for software, by relying on wrong answer (or belief) for components, leads to the geocentric paradigm of software engineering.
|
|
|
For example, relying on 2300 years old wrong belief for 1800 years resulted in creating a huge BoK (Body of Knowledge) for geocentric paradigm. Likewise, relying on 50 to 60 years old wrong beliefs (i.e. description for the components) for past 50 years resulted in creating a huge BoK for existing dominant software paradigm, which is flawed like the dominant geocentric paradigm in 16th century.. | |
|
|
Let me briefly summarize the objective reality and facts: Primarily 2 kinds of parts are used for building countless products we know such as cars, computers, airplanes, ships, cell-pones, TVs, Bikes, machines or machinery for factory. They can be broadly grouped as (1) reusable ingredient parts such as metals, steel, cement, alloys, plastic, wood, leather or silicon-wafers (e.g. to make computer chips), and (2) parts that are designed and/or conducive to be assembled (or plugged-in such as CPU, DRAM, CD-Player, Gear Box or Engine), where such parts are widely referred to (named or known) as components. Hence, any part that is not designed and/or not conducive to be assembled is not a component. |
|
|
To be clear, we can divide the components into 2 kinds (i) basic components having no sub-components and (ii) container components built by using sub-components. The components and other kind of parts are not mutually exclusive. In fact, each of the basic components is built by using reusable and/or ingredient parts such as metals, steel, cement, alloys, plastic, wood, leather or silicon. Hence, reusable or ingredient parts are essential for building the components. Many large components are created by assembling multiple sub-components, where each of the sub-components is built by using reusable and/or ingredient parts and/or other subcomponents. Hence, each of the products is built by assembling many components, where each of the components is created by using reusable, ingredient parts and/or other basic components (as sub-components). |
|
|
Kindly keep in mind that any part that is not conducive to be assembled (or plugged-in) is not a component. Software researchers not yet invented such very useful parts that are designed or conducive to be literally assembled for software products. Software researchers have been misleading or fooling themselves and the world that they have been already using components by referring to reusable or other kind of useful parts as components, where the reusable or other kind of parts are not conducive to be assembled by any stretch of imagination. |
|
|
It is not hard to invent software parts that can be assembled (or plugged-in), but no effort is made (i.e. no evidence can be found that anyone ever even tried) to invent such real components for software. Hence, today each and every large or complex software is built by using only reusable parts and/or ingredient parts. On the other hand, each of the large physical products is built by partitioning into components, sub-components and so on, where each of the components is designed, built and tested individually. Once each of the components is built and tested individually, the product is built by assembling all the components. |
|
|
The components are the best-known invention for modularization, which can increase productivity by at least 5 to 10 folds by substantially increasing each of the following factors, where each is proven to increase productivity (i) degree of specialization, (ii) degree of division-of-labor and (iii) degree of automation. The components are backbone of the modern industrial age. It is impossible to even imagine how many of the large products such as cars, TVs, computers, cell-phones or airplanes can be designed and built without using the components (i.e. special kind of parts that are designed and must be conducive to be assembled).
|
|
|
In this perspective, componentization is an intermediate process step for substantially increasing productivity and quality by substantially reducing the complexity. In other words, each of the components is a kind of an abstract package for other kind of parts, where the abstract package (i.e. organizer as an abstract container) is designed and conducive to be assembled (or plugged-in). The CBD/CBD (Component Based Design, Development or Engineering) increases productivity by partitioning a complex problem (e.g. features and functionality of the product or large components of the product) into small self-contained problems (e.g. small subset of features and functionality), where each of the problems (i.e. is a component) can be addressed and tested individually.
|
|
|
Let me provide clear and unambiguous contrast between the self-contained components for software and physical products (no comparison can be as black and white as this contradiction): In the context of the physical products (A1) every large physical product can be partitioned into many large disjoint sets of self-contained features and functionality, (A2) Almost each and every disjoint set of self-contained feature and functionality can be implemented as a replaceable component (i.e. part that can be assembled), (A3) Almost each and every disjoint set of self-contained feature and functionality is implemented as a replaceable component, which can be disassembled and reassembled at any time in the future (e.g. to redesign and test individually free from spaghetti design/code throughout the evolutionary lifecycle such as upgrade releases of the product).
|
|
|
In the context of the software products (B1) every large product comprises many large disjoint sets of self-contained features and functionality, (B2) Each and every large disjoint set of self-contained features and functionality can be implemented as RCC (Replaceable Component Class), so that it can be easily plugged-in and unplugged – This is the Heliocentric model of software engineering. |
|
|
This is the geocentric paradox of software engineering: (B3) Almost no large disjoint set of self-contained features, functionality is implemented as replaceable component (e.g. a module such as a class-definition for an object-instance that can be assembled or plugged-in). In other words, no effort is made to identify each set of self-contained features, functionality (that constitutes a component), where each can be implemented as a RCC (Replaceable Component Class).
|
|
|
Notice the black and white contrast between A3 & B3, while A1 and B1 is same; and A2 and B2 being the same. The root cause for the geocentric paradox of the software engineering: The wise men (i.e. researchers and scientists) 50 to 60 years ago came to tacit “consensuses” that it was inconceivable to create such replaceable parts (i.e. components that can be assembled or plugged-in), in light of then leading programming technologies Fortran or assembly languages.
|
|
|
Based on best information, knowledge and evidence available 50 to 60 years ago, the respected or influential thought leaders (i.e. wise men) tacitly came to consensus or conclusion (without any debate or discussion) that it is inconceivable to invent real-software-components (that are equivalent to the physical components) for achieving real-CBD for software, which is equivalent to the CBD of physical products. Such consensus or conclusions resulted in many untested and unproven beliefs, where the beliefs became received beliefs and foundation for all the research efforts for past 50 years.
|
|
|
The software researchers have been acquiring and accumulated huge BoK (Body of Knowledge) so far by relying on 50 to 60 years old untested flawed received beliefs about components. Since every expert proudly feels that he is an expert on components for the CBD/CBE (e.g. that has been gained by decades of experience, hard work), why he/she even contemplate inventing components? In fact, many experts feel offended by the facts about components that profoundly contradict their altered perception of reality and common sense evolved and/or shaped by the BoK rooted in the untested flawed received beliefs. |
|
|
Abstract: The objective of scientific or theoretical research is acquiring valid knowledge and wisdom about the objective reality backed by verifiable evidence, facts and valid reasoning. The objective of engineering research is creating new useful things or improving the existing useful things by applying the proven or valid scientific knowledge and wisdom. Software researchers must acquire and rely (or apply) valid scientific knowledge and wisdom for making useful inventions or innovations. Any research efforts would be diverted into a wrong path and end up in a crisis/wasted, if the efforts rely/apply flawed knowledge or facts. This paper proves that the existing software paradigm is created by relying on flawed facts.
|
| |
|
| |
Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries |
|
|
| |
