Thursday, February 27, 2014

Most software experts lost their ability to grasp even simple facts, because they are brainwashed and deeply indoctrinated into existing paradoxical paradigm for over 40 years.


            Please kindly allow me to briefly explain basic facts about an ideal Component-Based Design (CBD): If a physical product has 100 functional components, each functional component can be designed and build individually by an engineer as best as it can be. Then each component can be plugged-into container component (or product) to build the product. For example, in case of a computing device, the components can be designed to plug-into a bare PCB (Printed Circuit Board).  For example, please refer to CBD-structure for logical structure of physical functional components.

            If any component doesn’t fit or function as expected, the component can be unplugged and refined individually little-by-little (can be tested by plugging-in) to make sure it fits properly and functions as required within the product. This process is repeated for each of the components (by the designers of the component individually) until all the components and the resultant product functions as required. The essential nature of any functional component is: The component is fully constructed by the engineers building each of the functional components and the engineers using the physical functional component (e.g. as a component or as a sub-component of another component) can just plug-in the component without any construction and with little or no configuration.

Of course, most of the useful products must be evolved for many decades by releasing better or improved models. The above product is evolved by evolving each of the components individually (e.g. by adding more and more functionally and/or features to each component). Also the product can be evolved by adding more new components for providing more functionality and/or features. Please refer to CBD-process.

            The above are the simple and obvious facts of CBD for physical products. That is, engineers of each component must be able to design, built and test their component individually. It is not necessary for the engineers of any component to see internal design any other components. In case of ideal-CBD, when all the components are unplugged (one component at a time), the product left with an empty PCB. Therefore, the ideal CBD achieves highest degree of modularization theoretically possible. It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

            Of course, many software experts have no problem understanding the above ideal-CBD in the context of designing and building physical product such as an experimental super-computer. They have no problem accepting the facts that: It is not necessary that even a single component in the component-hierarchy to possess any properties (e.g. reuse, standardized or conform to any so called component models) erroneously attributed to so called software components known today.

They have no problem accepting the above simple facts of an ideal-CBD. But they would never accept these facts and nature in the context of software components and CBD for software. Many experts so deeply indoctrinated and brainwashed into existing paradoxical paradigm, they loose their ability to even see the above simple truths in the context of CBD of software products and software-components.

My research goal is to define an ideal-CBD for software products and achieve such ideal-CBD for software products, which must be equivalent to the ideal CBD for physical products. My research effort found a way for achieving this goal. This goal can be accomplished by using real-software-components equivalent to the physical functional components (where the real-software-components share essential properties uniquely and universally shared by each and every physical functional component).

That is, building software applications by taking a generic application template and plugging-in all the real-software-components. In case of ideal-CBD for software, each of the real-software-components must require no more than 3 to 5 lines of code to plug-in the real-software-component (even if the component has dozens of large sub-components). Furthermore, removing these 3 to 5 lines of code must effectively remove the real-software-component (without leaving any traces). The application must be left with generic application template, when all the software-components are unplugged (by unplugging one component at a time).

Unfortunately, software experts fail to grasp the simple fact about the real-components: The builders of each of the physical functional-component can only focus on the internal design of just one physical functional-component without any distractions, since it is not necessary for them to see internal design of any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product.

In case of software, it is not necessary for any engineer responsible for either implementing a component for first release or evolving by improving a component (i.e. RCC) for successive models to see even a single line of code implemented for any other component in the software application. Another essential requirement of a real-software-component is that the component must be unplugged effectively by removing 3 to 5 lines (even if has hundred sub-components). Only real-software-components can satisfy the second requirement, because reusable GUI-classes for GUI-components satisfy the first condition but can’t satisfy the second condition, because one must implement many lines of application code not only for accessing and processing the application data but also for using the data to construct and configure the instantiated GUI-object to assemble a GUI-component in an application.

Let me define 2 essential conditions for real-software-components (or ideal physical functional components) are: (i) The designers or engineers of any component must be able to focus on code-base of just one component without being distracted, for example they should never see even a single line of code implemented for any other component (not only during initial model for first release but also for each of the successive models throughout the evolutionary life) of the product. (ii) One must be able to plug-in each of the real-software-components by implementing just about 3 lines of code and one must be able to effectively unplug the component by removing the 3 lines. That is, no real-software-component requires implementing any more associated code, for example, either to construct or configure the component.  It is desirable to eliminate necessity of implementing even communication code by using intelligent CASE-tools.

The so called software component known today breaks the second condition. For example, reusable components (e.g. GUI-classes for presenting GUI-components such as Pie, Line or Bar charts) satisfy the first condition, but can’t satisfy the second condition. In general, the real-software-components are custom designed to satisfy unique needs of target application (so can encapsulate or packaged all the application logic in a replaceable container/package that can be plugged-in and unplugged) and self-contained, so requires little or no application code (e.g. for construction and configuration etc.) after plugging into its target product. This second condition is extremely important distinction between real-software-components and other kinds of so called software-components known today.

For example, kindly review a sample City_GIS application that is build by plugging-in just 6 large functional components. Of course, large applications might contain 100s to 1000s of such plug-in components. Since the real-software-components are custom designed to satisfy unique needs of target application, it is possible to design and build larger and larger real-software-components as plug-in components (that needs just 2 or 3 lines to disassemble or re-assemble) as illustrated by CityLandMarks (having 3 sub-components). It is not practical to design CityLandMarks to be reusable in multiple applications, because to make such components reusable, each component must be designed to be context-independent and must be configurable to context of each application (which requires implementing code for using application specific data).

Furthermore, nearly 100% of the application code for any application (e.g. City_GIS) can be implemented as real-software-components. The real-CBSD could eliminate 100% of the spaghetti code, since designers of each real-software-component can focus only code base of just one real-software-component (without being distracted by even single line of spaghetti code implemented for any other component in the application).

Each and every known physical functional-components satisfy two important conditions outlined for real-software-components above. Therefore, over 90% of the functionality and features of any complex physical product can be implemented in physical functional-components. Each engineering team can work on each of the functional components individually (without being distracted by noise or spaghetti code), even if the product has 1000s or tens of 1000s of functional components.

The manthra of real CBD for physical products is: Allow the designers of each functional-component to focus on internal design of the component, by eliminating 100% of noise or interference (by shielding them from exposing internal design of any other component). The manthra of real CBD for software products is: Elimination of 100% of the spaghetti code from the application, by partitioning all the functionality and features of any large application into hierarchy of real-software-components.

Partitioning any complex product into hierarchy of replaceable components eliminates huge accidental complexity and allows engineers to just focus on essential complexity. In case of complex software today, nearly 80% of the efforts of software engineers are wasted on accidental complexity. The real-software-components can be invented for achieving ideal CBD for software by discovering essential characteristics uniquely and universally shared by each and every physical functional component. The discovery of essential characteristics also helps experts realize that they were brainwashed and indoctrinated into existing paradoxical paradigm.

3 comments:


  1. The software researchers must had achieved over 90% of the goal decades ago, if their goal were to building applications by using replaceable components, where each replaceable component is custom designed to satisfy current unique needs of the target application and must not require more than 5 lines of code (to disassemble or re-assemble the component). That is, if an application has 100 components and on average each component requires 4 lines of code to plug in the component, once all the components are ready, it must requires no more than 400 lines of application code for building the application.

    If researchers discover real-CBSD, real-software-components and set this realistic goal, software researchers could achieve about 80% of this goal within one year (where 80% of the goal means 80% of the application code and features must be implemented in replaceable components). Each of the replaceable components must have exclusive code-base (without any need to see or touch code implemented for any other component), so that the replaceable comment can be designed, developed and tested individually to make it as best as it can be. Each replaceable component can be plugged into its target application to make sure that it fits properly and functions as expected in the target application. The exclusive code base of each replaceable component can be refined little-by-little individually until the component fits properly and functions as expected in the target application.

    Once a new software or physical product is released and becomes successful or found to be useful, the software or physical product would be evolved by redesigning and realizing newer better or improved component models for many years or even decades. In case of physical products, the products are evolved by evolving each of the components individually. The engineers responsible for redesigning each component can easily find the internal design (e.g. blueprint) of the component and can exclusively focus on the internal design of the target component (without any need for exposing to internal design of any other functional component).

    In case of real-software-components (i.e. replaceable components), it would take no time to find the exclusive code base of each of the replaceable components, for example, to add more features or functionally for building improved custom component for each of the successive releases of the target application (throughout the future evolutionary life of the application). The developers of each of the replaceable components don’t need to see or touch any code implemented for any other component. That is, developers of each of the replaceable components can easily find all the exclusive code base of the component and focus on the exclusive code base of just one component to redesign the component for each of the successive models of the component for future product releases.

    The designers of cars (or cell-phones) deal with just one product family (e.g. cars or cell-phones). The software engineers’ deal with diverse product families (e.g. compilers, OS, Games or RDBMS) and many new product families are invented each year. The fact is, successfully inventing a new product family requires inventing or creating new custom components. Newer product models are created by innovating improvement for building better functional components.

    Unfortunately substantial research effort has been wasted in past 3 decades for chasing goals that are not much less than science fiction by relying on baseless axiomatic postulations (which are not much less than myths). For example, a goal chosen in formative years during mid 1960s of software engineering was: building software as we build computers by assembling reusable components from third party vendors. Even a quick analysis of obvious facts and simple observations conclusively prove that it is impossible to achieve such a fantasy: http://real-software-components.com/CBD/main-differences.html

    ReplyDelete

  2. A real-software-component must require no more that 3 to 5 lines of code to assemble the real-software-component, and must not requires any more construction, configuration or communication code. That is, in case of an ideal-CBSD for software, if an application has 1000 components and requires on average 4 lines of code to plug in each of the 1000 components into a bare reusable application template, it must requires no more than 4000 lines of application code for building the application, once all the components are created. Removing these 4000 lines must result in the bare reusable application template.

    Today software engineers could leverage huge infrastructure of tools and reusable libraries for building software applications. Even after using all kinds of available libraries and tools, today many large applications still require implementing millions of lines of custom application code. If the average custom application implemented for each component is 1000 lines for the above sample application of 1000 components, then total size of custom application code must be developed by software engineers would be about a million lines. In this case, over 99.5% of the application code is implemented as replaceable components.

    For example, the sample City_GIS application has just 6 replaceable components and requires no more than 5 lines of application code for assembling each of the components: http://real-software-components.com/CBD/City_GIS.html

    The software researchers must had achieved about 90% of such goal of real-CBSD decades ago, if their goal were to building applications by plugging-in replaceable components, where each replaceable component is custom designed to satisfy current unique needs of the target application and must not require more than 5 lines of code (to disassemble or re-assemble the component).

    I can demonstrate hundreds of component hierarchies to prove this vision and goal is realistic. If researchers discover real-CBSD, real-software-components and set this realistic goal today, software researchers could achieve about 80% of this goal within one year (where 80% of the goal means 80% of the application code and features must be implemented in replaceable components). Theoretically, it is impossible to find a valid reason, why it is not possible to achieve 99% goal. For example, the City_GIS application achieved 99% goal and above sample application having 1000 replaceable components achieved 99.5%, since total application code implemented for all the replaceable components is a million lines and application code required to assembly all the components to build the application is under 5000 lines of code.

    Each of the replaceable components must have exclusive code-base (without any need to see or touch code implemented for any other component), so that the replaceable comment can be designed, developed and tested individually to make it as best as it can be. Each replaceable component can be plugged into its target application to make sure that it fits properly and functions as expected in the target application. The exclusive code base of each replaceable component can be refined little-by-little individually until the component fits properly and functions as expected in the target application.

    The following condition must be true for each and every software developer working on the above software product: No engineer need to see or touch even a single line of code he hasn’t implemented. Fore example, if an engineer is responsible for implementing 10 components and 10,000 lines of code, it is not necessary for him to see or touch no other code in the million lines of code implemented for the application. I am hopping to create another intelligent CASE-tool to plug-in each of the components, which generates the 4000 lines of the code after assembling all the 1000 components (which should also do other things, such as allow searching for components, managing component relationships and adding/removing or replacing components etc).

    ReplyDelete
  3. What would you think of the state of zoology, if no zoologist in the world is able to name couple of essential characteristics of animals?

    What would you think of the state of botany, if no botanist in the world is able to name couple of essential characteristics of plans (or trees)?

    Such characteristics are essential not only to positively identify animals (or plants) but also to positively determine any other thing is not an animal (or plant), if the other thing is not an animal (or plant).

    Answers to these questions are so basic and fundamental that, schools are teaching these characteristics to kids in high school starting from 4th grade: http://www.slideshare.net/allsaintsscience/4th-grade-ch-2-lesson-1-what-are-plants-characteristics & http://animals.about.com/od/animal-facts/a/animal-characteristics.htm

    Countless software researchers and scientists have been doing research on software components and CBSD (Component-Based Design for Software) for over 4 decades. No software researcher or scientist in the world could accurately name couple of essential characteristics of physical components.

    It is impossible to invent real-software-components for achieving real-CBD for software, without discovering essential characteristics of ideal physical functional-components. Instead of discovering the essential characteristics, the researchers blindly defined characteristics of many kinds of software components (without any basis in reality or fact). In the context of physical products, no other kind of part except very special kind of part having certain unique essential characteristics can be a component.

    No software researcher or scientist in the world could accurately name essential aspects of CBD for software, except blindly defining that using each kind of so called software components is a kind of CBD for software.

    It is hard to believe that brilliant minds in software engineering could make such an obvious and fundamental mistake (and could not recognize or even suspect possible error after doing research on software components and CBD for software for 4 decades). But unfortunately that is the state of computer science and software engineering.

    The result of 4 decades research is a paradoxical paradigm complex web of countless interdependent concepts. Unfortunately experts are so much brainwashed and deeply indoctrinated in to the paradoxical paradigm, they lost their ability to even recognize simple scientific facts and processes.

    If any one raises this error with any software experts and asks for response or essential characteristics, he gets million excuses or evasive responses except accurate essential characteristics for components or essential aspects of CBD. Of course, the excuses could be persuasive and appear to be credible because experts could back the excuses by using dozens of references (selected form the paradoxical paradigm).

    Long time ago in 1960s, when computer science and software engineering was in formative years, early researchers defined useful software parts such as reusable and/or standardized software parts are components. No other researcher ever asked during past 4 decades, wait a minute, how could reusable and/or standardized software parts such as cement, steel, plastic, metal-alloys, paint or silicon wafers be components (and using such ingredient parts could be CBD)?

    Every successive generation of researchers since 1960s has been sheepishly accepted those baseless myths as if they are axiomatic facts (and relying on them as proven time tested facts for advancing software engineering). This research resulted in a paradoxical paradigm having countless concepts, which are now used to defend the baseless myths (without realizing illegal circular logic).

    The successive generations of researchers added more and more epicycles and retrograde motion without realizing initial error. Now any expert can find many references (from thousands references available to them) to prove the myth (e.g. Earth is static at the center) for snubbing the truth (e.g. Sun is at the center).

    ReplyDelete