banner banner  

Brief Summary & Conclusions for Real-CBSD (CBD for Software)

It is very important to notice that, none of the facts and observations about the physical components or CBD of physical products presented in this website are new (or unknown) in the context of physical CBD-products, for example, to find accurate answers for the two basic questions in the preamble of our website. I am sure, any product design expert or engineer must already know most of the facts and observations, and rest (if any) can be easily confirmed by conducting simple enquiry or investigation in the context of the physical CBD-products.
Although many of the experts not accepted or agreed with our proposed accurate description for the active-components, almost no one disagreed with our descriptions for CBD-structure and CBD-process. That is, no one disagreed that each and every physical CBD-product in the world must comprise a structure logically similar to the CBD-structure and most likely built by employing a process logically similar to CBD-process. Hence, they must agree that the CBD-structure and CBD-process are essential aspects uniquely and universally shared by each and every physical CBD-product (exist today or even in the future).
In light of above descriptions, our definition for the real CBD for software is: Each of the CBD applications must comprise one or more structures logically equivalent to the CBD-structure, where each CBD-structure must be created by assembling real software components that are equivalent to the physical active-components. This requires invention of real software components that are equivalent to the physical active-components, for example, by discovering accurate description that can be used for uniquely and positively identifying each of the parts or modules that can implemented as real software components in each software application.
Our proposed accurate description comprises of two essential properties (i.e. Replaceable and Self-Contained) that are uniquely and universally shared by each and every ideal physical active-component in the world. The objective for discovering the unique properties (or hidden-nature) are (a) one must be able to positively and unambiguously identify each component and (b) one must be able to positively and unambiguously differentiate any other being (e.g. a thing or part) form the components (i.e. if and only if the being is not a component).
It is not necessary but certainly useful to employ processes logically similar to, step-1 of the CBD-process for designing each new large software application (and/or step-3 for maintaining designing newer product models/versions), which requires knowledge and experience for identifying multiple large SCCs (or Self-Contained Components/Modules) in the software application for implementing a RCC (Replaceable Component Class) for each of the SCCs.
Therefore, there is only one remaining problem, which we must address: The software community not yet accepted (e.g. many refuse to even verify) our invention of real software components, by using many baseless excuses, such as (i) it is impossible to invent software components that are equivalent to the physical components or (ii) it is impossible to discover unique nature and accurate description of the physical components, for example, were the accurate description is essential to uniquely identify real software components in each application. These and other such excuses are baseless, since the experts refuse to substantiate the excuses, while our frequent searches during past decade not yet found any evidence that any one else ever even tried to discover unique and distinctive properties of real-CBD/components.
Other invalid excuses include: each of the experts refer to one or more widely accepted or acclaimed research paper on software components or CBSE, which are based on existing deeply entrenched paradigm. It is invalid circular logic to defend a seed postulation of any paradigm by using any research papers or concepts to defend the seed postulation, if the papers or concepts are derived from the seed postulation (i.e. by assuming that the seed postulations are accurate).
We all know that, at any time tens of thousands of brilliant minds has been passionately working and researching for many decades on computer science and software engineering. So, the most popular excuse (this question even perplexed me many times in the past few years) is: Why no one else discovered or though of it? (If really there are errors in the seed postulations). Although many experts might not give this excuse, but this is most likely the real unconscious reason for their huge irrational skepticism and other baseless excuses used to discredit our discoveries (and/or to defend the erroneous seed postulations). If it were a valid excuse, it can be used to discredit any new discovery, so this excuse can stall scientific advancement in any field.
The state as of today is: None of the experts so far disputed our description of essential aspects of ideal CBD of physical products, while most experts not agreed with (and refuse to accept) our description for the real software components. I can prove that it is not possible to come to any other conclusion (i.e. for accurate description of real components), because I am proposing a widely practiced and accepted scientific process for discovering the unique properties that are universally shared by a very broad class comprising a highly diverse species (e.g. mammals or active-components). For example, a very simple expression/equation having just one unknown (i.e. a property which is named or referred by us as 'Self-contained') is employed for discovering the intended meaning of the one unknown term ‘Self-contained’.
Can any one find a valid flaw in the process for discovering the accurate description of real components or in the simple expression/equation employed? If there is no flaw, is it possible to come to any other conclusion for the unique set of essential properties universally shared by the active-components? If the unique set of essential properties are discovered, why is not possible to identify SCCs in large software applications? If multiple SCCs can be identified in a large software application, why is not possible to implement a RCC for each of the SCCs?
Although I feel, in case of many of the large application, it is possible to build about 90% of custom code-base of each application as RCCs, but initially it is OK to have a simple and modest goal of 30% to 50% of the custom code-base must be designed as RCCs/RSCCs, for example, by just picking/identifying low hanging fruits/SCCs. But we strongly recommend using intelligent CASE-tools for creating and managing communication interfaces of the RSCCs in each application. Please review a sample City-GIS application and try to grasp the 'objective of ideal-CBSD for each large software application' summarized in a table nearer to the end.
When designers gain expertise in identifying more kinds of hard to find SCCs, such CASE-tools can help designers to replace code-base of old SCCs by RSCCs (when the old SCC are redesigned to satisfy new needs). Of course, there could be small percent (e.g. 5% to 9%) of software parts of an application might fall on the boundary line, so very hard to positively identify each such part as a SCC. It is safe to assume each such part is not a SCC, except in a special case, where the custom code-base of the part is large enough and can be designed to have few (e.g. about 3) loosely coupled service-oriented interfaces, which can be managed by intelligent CASE-tools. The motive is make it simple to evolve each large part individually to satisfy unique and changing needs by refining the large part little-by-little (e.g. see evolution of useful things).
Ability to identify multiple SCCs (for designing each SCC as a RCC/RSCC) in each of the large applications is an important skill and essential activity of real CBD for software. Of course, certain kinds of SCCs are easy to identify, while it might require more and more experience and knowledge to identify certain kinds of SCCs. In early 1990s, I took a series of 2 courses on OOA (Object Oriented Analysis) & OOD (Object-Oriented Design) offered as night classes by University of California ( fee paid by employer). I feel, similar training can be used for training software designers on a process logically similar to the CBD-process for identifying multiple large SCCs in each application to achieve a structure logically similar to the CBD-structure (if basic errors in seed postulations of exiting paradigm are exposed and our discoveries are accepted).

Copy Right © 2013 SPPS Systems Pvt.Ltd. All Rights Reserved.
This Website presents patented and patent-pending Inventions and Discoveries