A real Kuhnian paradigm shift is somewhat like a religious conversion to a new religion having radically different belief system for an orthodox follower, who never even heard of possible existence of any other religion. For example, proposal of Heliocentric-model over 600 years ago was radical new religion for astronomers believed for many generations that the Earth is static at the center. The Geocentric-paradigm had evolved for 1000 years on the conviction that the Earth is static at the center, which had deeply entrenched in to the collective wisdom. It must never had even crossed their mind that there might be an error in the root axiomatic assumption “the Earth is static at the center” (since they or many generations before them found no reason to question this assumption).
They had overwhelming empirical evidence for the epicycles and retrograde-motions of the planets. Many generations of astronomers painstakingly documented epicycles and retrograde-motions by standing on the static Earth. Hence no one dared to question the retrograde-motions of the planets. The astronomers used the epicycles and retrograde-motions to discredit Heliocentric-model, without realizing that they were using invalid circular logic. A circular-logic can comprise of a short chain of concepts or long chain of concepts. It is hard to realize a circular-logic that comprising long chain of concepts, but it is still an invalid circular-logic, if one of the concepts in the long chain is used to prove to root postulation.
Unfortunately existing software engineering paradigm has been evolving by relying on a flawed root postulation(or axiomatic assumption) for decades and resulted in a complex ecosystem having many long chains of interdependent concepts and deeply entrenched collective wisdom. Today saying software parts equivalent to ingredient parts such as cement, paint, steel, silicon or alloys are not real components for achieving the real-CBD for software, is blasphemous or offends common sense of software researchers. It feels like asking one to convert to new religion, where he doesn’t even imagine possibility of another religion (i.e. possible existence of more than one religion or even atheism).
I am humbly requesting researchers to discover innate nature and essential properties that are uniquely and universally shared by the physical functional components, where the essential properties are very useful for achieving component-hierarchies (an essential requirement for the real-CBD). This exposes error in the root postulation (or axiomatic assumption) of deeply entrenched conventional wisdom of existing paradigm and accomplishes another important task: It is not hard to invent equivalent software components (having the essential properties, once the essential properties are discovered) for achieving real-CBSD (CBD for software), which is equivalent to the CBD of physical products such as one of a kind products such as experimental Jet-fighters or spacecrafts.
These new products are designed as component-hierarchies (or CBD-structure), where each component can be designed and tested individually outside of the product. Once all the components are ready, the total cost of disassembling or reassembling could never be more that 5% of the total cost of the product throughout the life of the complex product (i.e. in step-1 or step-3 of CBD-process). Please let me summarize two essential aspects CBD-Structure and CBD-process of real-CBD of physical products in separate web pages: http://real-software-components.com/CBD/Real-CBD.html
It is extremely important to recognize two important facts about the CBD-design (i) It is not necessary that even a single large functional component in the CBD-structure (or component-hierarchy) of a complex product to conform to any known so called component models or have any useful properties (e.g. reuse or standardized) erroneously attributed to software components today. (ii) Either complexity or uniqueness of one-of-a-kind product (e.g. experimental spacecraft) can’t prevent the designers from partitioning the product as component-hierarchy.
Please kindly look at design of a sample application that is designed as hierarchy of real-software-components that are equivalent to the physical functional-components for achieving CBD-structure (or component-hierarchy): http://real-software-components.com/CBD/City_GIS.html
The componentization is the most effective and efficient method known to mankind for addressing a complex problem (i.e. by a team of experts) by partitioning the complex problem in to hierarchies of smaller (or components) and smaller (or sub-components) self-contained problems, where each smaller self-contained problem can be addressed individually (by each member of the team in manner consistent with his domain expertise, knowledge and skills): http://real-software-components.com/technologies/componentization_purpose.html
The software engineering researchers committed a huge mistake not analyzing all the facts and valid observations for discovering the innate nature and essential properties of the physical functional components. It is not a small error: http://real-software-components.com/forum_blogs/year2013/IsItSmallError.html
No comments:
Post a Comment