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.