| |
Each Components is merely a higher-level abstraction for Modularization |
|
|
It is a mistake to see components are replacement or mutually exclusive from other kinds of parts such as ingredient and/or reusable parts. Keep in mind that 100% of each component is made by using other kinds of parts such as ingredient and/or reusable parts such as steel, metals, alloys, plastic, rubber specialized material such as silicon to make chips, Lead-acid or Nickle-Cadmium to make batteries. There is no savings in the quantity of any material (i.e. other kind of parts), weather we employ abstraction of components or not (for making each product). |
|
|
Each of the components of a product is merely a higher-level abstraction for modularization. The primary difference between CBD/CBE (Component Based Design, Engineering and Development or building) and non-CBD can be illustrated by using this example: Assume a component for ATC (Air Traffic Control System) for GIS (Geographical Information Systems) application having a dozen other components of size ATC requires implementing 2,500 lines of custom code, even after using every other kind of parts available for designing and building the ATC.
|
|
|
In case of non-CBD mode, the 2,500 lines of code is added to the code base of the GIS application. That is, many code-chunks (or code-sections) are added to many non-exclusive files, where the non-exclusive files contain code-sections (or segments) for other components. To make a small change to the component, it requires substantial effort to find the code segments spread across many non-exclusive files of the application, where non-exclusive files imply files contain code sections for multiple components. The whole application must be tested to test the component, whenever a small change is made to this component. To remove the component requires painstaking error prone effort of finding and removing several hundreds of lines of code form the non-exclusive files by finding code sections spread across many non-exclusive files.. |
|
|
In case of CBD (only difference is), the 2.500 lines of code is implemented in a pluggable module and the module is plugged into the GIS application (i.e. by adding 3 to 5 lines of code). The component can be removed by unplugging (i.e. by deleting 3 to 5 lines of code). The component can be redesigned and tested individually by unplugging for redesigning and testing the pluggable module individually outside of the product. For example, the whole 2,500 lines of code can be implemented in a set of exclusive files for class-definition and the component can be plugged-in by including an object instance. |
|
|
|
The CBD/CBE (Component Based Design, Development or Engineering) is merely an abstraction for modularization. Both cases (i.e. using or without using component abstraction) needs implementing same 2,500 lines of code and same reusable and/or other kinds of parts can be used in same manner. Only difference is implementing the 2,500 lines of code in pluggable module. There is no difference in the code/material used for designing and building each component for the product.
| |
|
|
Today no other GUI-technology can implement components of size such as the ATC in a class-definition, so unfortunately developers are forced waste lot of effort to add many code-sections for such components in many non-exclusive files. In effect, developers are forced to waste lot of effort to meagre the code sections for each such component into the huge code base of the application, and waste 10 times more time for finding the code sections in many non-exclusive files and to change, whenever the component needs to be redesigned for future releases. |
|
|
Let me illustrate this using FM-DVD player in a car: If the DVD player has 100 parts (e.g. devices), today all these parts are assembled in a pluggable-box and the box is plugged into the dashboard. If it is included as a software component, about 30 parts spread across in the hood along with parts for other components, 30 parts spread across in trunk and remaining parts spread along with parts for other components in places such as dashboard. All these parts are somehow connected to work by collaborating with each other. Imagine the complexity of removing (or replacing) the DVD player by finding and removing each of the 100 devices. This is true for each of the components, if the product has 100 such components. |
|
|
Please keep in mind, the invention of interchangeable components increased manual productivity by 100 to 200 folds without reducing the quantity of material needs for making each of the components for a product, where the product built by using the components. Therefore, it is not-necessary to reduce the code/material for substantially increasing the productivity, for example, by substantially reducing the complexity, substantially increasing automation, division-of-labour and specialization. Likewise, Ford’s moving assembly line increased manual productivity by 7 folds without any reduction in the quantity of material necessary for making the cars. But, implementation and redesigning each component individually for each of the future releases outside of the product makes it simple to optimize and minimize the code for each component. So, the total code for each component likely end up minimized. |
|
|
Most components contain parts as well as sub-components, so henceforth a component having no subcomponents is referred to as basic component. Each basic Component is merely a higher level of abstraction for other kinds of parts: Each of the container parts built by using one or more parts, and furthermore designed to be conducive for assembling (and disassembling) is a basic component. In other words, for example, an ingredient part (e.g. steel, metal, plastic or allow) designed and built such that the part can be assembled is a component. That is, an ingredient part into a particular form is a component. |
|
| A component may be perceived as an abstract form: For example, data structure or record is higher level abstraction for many pieces of data such as basic data types, arrays and other data structures or records. In other words, each data structure contains declarations of variables for basic data types, arrays and other data structures (as sub-data-records). Each instance of data structure (or record) allows adding (or removing) all the pieces of data, arrays and sub-records declared within the data structure as a unit. Likewise, each component is higher level abstraction for other kind of parts and sub-components.. |
|
|
Each component allows adding (or removing) all the parts and sub-component as a unit by assembling (or disassembling) the component. The data structures (or records) provide a way for organizing various data pieces in higher level modular abstractions. Likewise, the Components provide a way for using and organizing various parts in higher level modular abstractions
. |
| |
|
| |
Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries |
|
|
| |
