|
| Differences between Physical Parts and Software Parts |
|
|
It is critical to recognize a fact (i.e. nature of components): Either complexity or uniqueness of a one-of-a-kind physical product can’t prevent designers from finding many active-components (i.e. SCC) and designing the product as a CBD-structure. It is not hard to realize that this fact also similarly applicable to the software products as well, once hidden true nature of the SCC is known. Without trying to grasp nature of true CBD and essential properties of active-components, many software experts erroneously concluded that software is unique or different. |
|
|
Yes! Software is unique/different for better, but not for worse as assumed. For example, software-components are not constrained by laws of physics such as weight, rigid physical shape or dimensions. Therefore, ity is possible to invent real software-components, which certainly can be better than the physical components for achieving an ideal CBD-structure by allowing a process logical similar to the CBD-process. |
|
|
Today’s false-impression about software components mislead the CBSD (i.e. CBD for Software) researchers to focus on inventing useful parts, instead of discovering real software components that can enable real CBSD (e.g. CBD-structure/CBD-process). However it is most certainly possible to invent many kinds of useful software parts/modules, but only real software components that are equivalent to the physical components can enable a structure that is logically similar to the CBE-structure. |
|
FIG-1: Difference Between Artificial and Physical Being |
|
|
|
|
For example, FIG-1 shows a cartoon-image comprising an artificial-being (e.g. standing-man) that is unconstrained by any rules/laws. A standing man 1 floating above land 3
and his center of gravity 4 is not-passing through his feet, so obviously the virtual-man is not obeying laws of physics. To imitate a physical-being (e.g. a physical man standing on his feet without any other support), the virtual man’s 2 feet must be firmly on the ground in the cartoon-image, and line from his center of gravity must passes through his feet (e.g. to appear or perceived to be obeying laws of nature). The physical-parts must obey laws of nature, hence there can be only very few kinds of physical-parts. |
|
|
This explains why it is possible to invent many kinds of useful software-parts (or models for software-parts, where the models are referred to as component models). For example, the front view of the figure is straight, since FIG-1 is just a 2D example. In a 3D example, the man might appear short in the front view, if he is also leaning forward in Z-axis. This explains why the software products has so many kinds of part than exist for the physical products. |
|
|
The physical-beings are constrained to certain physical form (e.g. each physical component is by default packaged as a replaceable unit and comprises necessary coupling interfaces). For example, the physical-components (e.g. Hard-Drive, Auto-engine or CD-player) are encapsulated in a physical-container (e.g. to replace as a unit) and often can’t function without being packaged in a single physical unit. But it requires conscious design and development effort to make each large SCC (e.g. CityLandmarks in the City_GIS application) a virtual replaceable unit, for example, by encapsulating in a RCC. The software-SCC can still function, if various parts of the SCC are spread across many non-exclusive files, where the files contain parts for other SCCs. |
|
|
FIG-2: An application built by using 3-RCCs, where each RCC encapsulated all the parts of a SCC.
|
|
|
|
|
Just because the artificial-beings (e.g. SCC) are unconstrained by rules or laws of nature and possible to have numerous forms and states (e.g. defy nature/rules) than practical for the physical-beings, it is an error to assume that artificial-beings can’t imitate (or emulate) physical-beings. Unfortunately many software engineering researchers came to such erroneous conclusion, without even trying to discover hidden laws, nature or forms that constrain physical-beings. |
|
FIG-3: The same application in FIG-2 comprising 3-SCCs built without using a the RCC for encapsulating all the parts of each of the SCCs. |
|
|
|
| Let’s look at another example of a simple software application containing just three large Self-contained components (SCCs), where each SCC comprises multiple parts: The FIG-2 shows 3 Replaceable Self-Contained Components (or RSCCs), where each RSCC encapsulated all the parts that are used for constructing the RSCC (so the RSCC can be disassembled and reassembled as a unit, any time in the future). A specific shape (e.g. cubes for a SCC or pyramids for another SCC) is used to visually distinguish parts belong to each RSCC form the parts belong to other RCCs in the application. The FIG-3 shows the same 3 Self-Contained Components (SCC) of same application built without using a RCC to encapsulate the parts of each SCC, where the parts of each SCC is spread randomly in multiple source code files. For example, the cubes in FIG-3 represent parts of a SCC and the pyramids in FIG-3 represent parts of another SCC. |
|
| |
It is often not practical or even impossible to spread parts of large physical components randomly. For example, is it possible for a car’s internal combustion engine to function, if various parts are placed at multiple locations such as the cylinders in the hood, the pistons in the back dickey/trunk and the spark plugs behind dashboard?
| |
|
|
|
But today almost every large software-SCC is designed and made to work that way. For example, is it possible to find a large RCC/RSCC, which is using reusable GUI-Classes for including dozens of GUI-components and associated application logic (e.g. RCC of CityLandmarks, RCC of City_ATC or RCC of City_GIS)? I believe, today no other existing GUI-API (e.g. Java/Swing or Windows/VC++) is capable of creating such RCCs for encapsulating such large GUI-components (although, I am sure, such capability can be quickly implemented, once real-software-components are discovered). |
|
|
On the other hand, I luckily stumbled onto a GUI-API that is capable of building hierarchies of RSCCs for RIA (Rich Internet Applications) more than a decade ago. And yet it has taken nearly a decade to realize that they are equivalent to the real physical components (and to discover the accurate description). An irresistible curiosity had been driven me to investigate and discover the hidden nature of physical components and CBD of physical products. This along with meticulous investigation of differences and similarities between various aspects of the physical CBD-products and the software products helped me to invent real software components that are equivalent to the active-components for achieving a structure logically similar to CBD-structure.
|
|
|
Therefore, it is extremely important to realize the fact that the software offers many more dimensions of freedom, to invent many more kinds of software-parts. It is an error to assume any other kind of useful software part is a kind of a software-component, and it is error to assume that using each kind of fake components is a kind of CBD for software. Using fake components (e.g. flapping fake wings) is not CBD (e.g. flying).
|
|
|
Of course, obviously it is a huge misconception that it is not possible to invent real-software-components that are equivalent to the active-components (although there are a million other possibilities to not get it right, as illustrated by using FIG-1, 2 & 3). The fact is, the physical products stuck with limited kinds of parts, but luckily one of them
is extremely useful kind of parts, which are referred to as components (which have very unique essential properties).
|
|
On the other hand, the software is cursed gifted with unlimited flexibility to invent many more kinds of useful parts, including a very special new kind of software parts that are equivalent to the physical components, only if software industry could discover accurate description. For example, the accurate description of a new kind of software-parts can be just a set comprising a list of essential properties, and each of the software parts belong to the new kind of software-parts must have all the essential properties in the set.
|
|
| |
Today no one else is even trying to find essential properties universally shared by the ideal physical active-components. So accidentally discovering the essential properties might be like accidentally finding a one-caret rough raw diamond stone in the sand of a dry 10 mile long river banks when not even looking for it. But once the essential properties of the physical components are discovered, it is not hard to invent real software components that are equivalent to the physical active-components.
| |
|
|
This gift curse of unlimited flexibility prevented software researchers from discovering SCCs and encapsulating each SCC in a RCC. The RCC is just one of countless possible forms/states for each SCC. For example, today CBSE researchers invented descriptions for many kinds of useful software parts (or erroneously defined each kind of useful pats as components, which concealed CPs), so yet to discover description for the real active-components. It is not hard to identify software-SCCs for building RSCCs (equivalent to the CPs) to satisfy physical constraints, once hidden essential properties and physical constraints of CPs are discovered.
|
|
| |
If laws of nature not imposing any constraints, why is it not possible to impose such constraints artificially (as illustrated in the above FIG-2 & right-side of FIG-1)? Of course, it is essential to impose constraints to organize numerous parts (beings or entities) of any complex system (or society). For example, the properties defined, for each of the existing kinds of software-components (e.g. reusability or standardization etc.) or for the component-models, are certainly constraints artificially imposed on each of them.
|
|
|
|
|
Today there exist many kinds of software components, where each kind of software component is defined by a set of useful properties or benefits (or satisfies a component-model). That is, today any software part is considered a kind of software component, if the part posses a set of given useful properties or benefits defined for said kind of component (or
model). For example, each definition for each kind of software component or component-model was accepted by a set of software experts, without giving any due consideration to the obvious aspects of the CBD of the physical-products (e.g. ‘CBD-structure’ and & ‘CBD-process’).
|
|
|
For example, it is an irrefutable fact with respect to the physical products that, except a very special kind of physical parts having certain unique set of properties no other kind of physical part can enable true CBD-structure, where the special kind of physical parts are referred to as components (or CP, short for Component-Part). Today no known kind of software components are equivalent to the physical ‘components’ and capable of enabling true CBD-structure.
|
|
|
In case of physical products (e.g. cars or computers), not all kinds of parts (having useful properties or benefits attributed to the software components) can be components. For example, ingredient parts (e.g. steel, plastic, wood, leather, glass, metals, silicon-wafers or alloys that are used in making components) can’t be components, even if they posses very useful properties such as highly standardized and widely reusable across many product families.
|
|
|
It is not necessary for the physical components (e.g. in a CBD-structure) to have any other useful set of properties that are erroneously attributed to the software components (e.g. by software experts today) such as standardized, reusable etc. That is, a physical component is still a component, even if it posses no other useful property, such as reusable or standardized. For example, it may be desirable but it is not necessary for the CBD of a new physical product that even a single component (e.g. in the CBD-structure) is reusable or standardized (or has other set of properties attributed to any known kind of software component). It is not necessary for the true physical components to satisfies any properties attributed to any known kind of software component (or conforms to any known kind of software component-model), as long as they can achieve a structure logically similar to the CBD-structure.
|
|
|
To enable CBD for the software products, it requires inventing new kind of software components. This website presents a new kind of software components (for enabling the CBD), referred to as Replaceable Self-contained Component (or RSCCs), where the components must possess two essential properties that are: (i) ‘self-contained’ and (ii) 'replaceable'. The term ‘self-contained’ has unique intended meaning, where the term ‘self-contained’ has hard to grasp and incommensurable meaning. This website defines many facts about CBD of physical products and physical active-components, which are valuable references to infer and interpolate the intended meaning for ‘self-contained’.
|
|
|
The popular CBSE misconception (or false-impression) today is: Any large useful software part is a software component, as long as it possesses certain given/defined useful properties (or belongs to a component-model), or offers certain given desirable benefits (e.g. standardized, reusable etc). The CBSE-experts overlooked few simple facts to grasp true nature of the right kind of physical components that can enable true-CBD (see CBD-structure and CBD-process).
|
|
|
For example, each physical product is created by using different kinds of parts, such as: (i) component-part such as CPU, DRAM-chip, car-engine, gearbox & CD-player etc., and (ii) ingredient-parts such as silicon, steel, wood, cement, plastic, metals, paint and alloys etc. Here parts belong to each kind (or type) has completely different set of unique useful properties/nature for serving different and unique, but very useful benefits or purposes/functions. For example, the ingredient-parts (e.g. silicon, alloys, steel, copper, lead/acid, cement, wood, plastic) are highly standardized and reusable across many product-families, but not self-contained nor replaceable. Where replaceable means that the part can be literally disassembled and reassembled at any time in future from its container). Most of the ingredient-parts like cement, TMT-steel or silicon used in building of bridges, ships or silicon-wafers to make IC-chips are highly standardized and reusable across many product families, but not practical to disassemble from its container for replacing it (only components can be replaced at any time in future). |
|
|
On the other hand, each component (or CP short for 'Component-Part') can be easily disassembled and reassembled (i.e. replaceable) as a unit throughout the life of its container. The replaceability is universal property of the CPs (i.e. one of the essential or necessary properties of the CPs). For example, a CP is no longer a CP, if the CP is welded into container CBD-product and it is not practical/easy to disassemble. For example, ideal components are designed to provide excellent service-access throughout the life of the container-product.
|
|
|
The ingredient-parts are tightly coupled with each other (or moulded) for manufacturing CPs (i.e. IC-chips or auto-battery), so not practical to disassemble/remove an ingredient-part from its container-CP to repair (e.g. to refine internal chemical-composition) or replace by assembling a better part after the container-CP is built. For example, ingredient parts like silicon, metal-oxide, silicon-dioxide insulator and silver inter connecting layer are used for manufacturing each IC-chip. Likewise, ingredients like lead and acid are used to make auto-batteries. It is not practical to replace any of the ingredient-parts of an IC-chip or auto-battery, while it is possible to replace Hard-drive or CD-player of a computer any time in the future.
|
|
|
Toady, if one goes to a largest trade show or exhibition for the software components, he can find many kinds of useful parts, except the real-software-components (i.e. for achieving the CBD-structure). To give an analogy: It was like going to trade show or exhibition for horses 700 years ago and finding many kinds of useful animals, except the horses (e.g. for creating a cavalry). Of course, each kind of animal may be useful in a specific manner (e.g. Chicken for eggs and meat), but it doesn’t change the fact that none of them are horses (essential for Cavalry). The fact is, no other kind of physical parts (except components) can achieve the CBD-structure. Likewise, only the real software components can offer very unique and huge benefits, which no other existing known kind of software parts can offer.
|
|
|
If achieving CBD-structure is flying (i.e. real CBD) for software, is it possible to invent right kind of wings (i.e. software components) to achieve flying (i.e. CBD-structure for software-products)? The ingredient-parts break CBD-structure, which needs that true CBD-structure must allow disassembling and refining each CP throughout life of the container-product/CP. Many such known aspects and irrefutable facts are ignored by the CBSE-researchers by using baseless excuses such as software is unique/different. This website proves that software is not unique/different in that context, so can’t prevent designers of software products from achieving the CBD-structure, if real-software-components are discovered.
|
|
| |
We are proud to contribute to our beloved computer science, this discovery that software can offer unconstrained flexibly and freedom that certainly encourages others in the future to invent few other kinds of useful software parts (one might be more useful than our real software components) and processes.
|
|
|
|
|
