banner banner  

Brief History of existing Software Components and CBSD

Dr. Douglas McIlroy’s speech in ‘1968 NATO software engineering conference’ on “Mass produced software components” is widely credited for launching research on ‘software components’ and CBSE (Component-Based Software Engineering). Of course, it is understandable why there were errors in some of the seed postulations (or axioms/premises) and assumptions made in those early fledgling years of computer science. That is, it was impossible to even imagine to build software modules equivalent to the physical components using fledgling programming languages (e.g. FORTRAN or COBOL), technologies and tools prevailing in 1960s. Isn’t it understandable why mankind thousands of years ago assumed that the Earth is static at the center? It is scary even toady to imagine that the Earth is traveling around the Sun at nearly 18 times the speed of a speeding bullet fired from a rifle.
Initial target was to increase reuse of pre-built modules (for reducing custom code for building each application) by inventing reusable software modules, which were erroneously named (or referred to) as components. Also software researchers felt, it was possible to increase productivity, quality and/or reduce complexity by inventing new kinds of software modules having certain useful properties such as standardization etc. Also created frameworks for software modules, where modules for each conform to an innovative model (referred to as component models), for example, to make the modules simpler, more intuitive or increase reuse.
The above effort resulted in both inventions and innovations for many kinds of modules (erroneously referred to as either 'software components' or 'component models'). For example, many other kinds of useful models or useful modules were introduced since 1970s, where each model for given kind of modules (e.g. having given set of properties for conforming to a certain pre-defined model) erroneously referred to as a component model; or each kind of modules (e.g. having given set of useful properties) is erroneously referred to as a component.
Unfortunately today the term “software components” became synonym to any kind of useful software modules (or parts), or modules belong to any component model (without realizing that it is a huge error to assume each kind of useful parts is a kind of software components). Furthermore software researchers created more errors, such as defining CBD (Component-Based Design) was using such 'useful software modules' (i.e. fake components).
Today it is an obvious fact: If a new kind of useful coarse-grained software parts is invented, the new kind of parts most certainly will be referred to as yet another kind of software components, and using such fake components is considered yet another kind of CBSD (CBD for Software Products). Sad aspect of this is, each and every software expert knows this and no one sees any thing wrong with such obviously erroneous postulations (i.e. CBSD is using such kinds of software modules, which are certainly fake software components).
Unfortunately it is impossible to find any evidence that any software scientist ever even doubted and/or tried to re-evaluate the seed postulations (or premise/axioms) and erroneous assumptions that were made in the early fledgling years of computer science and software engineering. Today computer science, programming languages, tools and technologies for software engineering advanced substantially. Isn't it time to re-evaluate baseless misconceptions for discovering errors in the seed postulations for the software components and CBSD?
The longer such error in seed premise goes undetected the harder it is to expose, since more and more seminal concepts and acclaimed works are created based on seed premise. This makes nearly impossible to doubt the validity of such seed premise. Today few experts even feel that it offends their common sense, since they and many before them worked all their lives by using the term 'software components' as a synonym to 'kinds of useful software parts'. For example, astronomers created maps for paths of planetary motion on the premise that 'the Earth is static' for hundreds of years, so understandably many astronomers felt offended, when they were told that the Earth is moving. They and many generations before them lived all their lives on the Earth, and yet no one questioned or had reason to doubt the premise 'the Earth is static'.
Unfortunately most software scientists/experts refuse to evaluate the erroneous axioms (or postulations) by using baseless excuses, such as software is unique or different (without even trying to investigate or learn, why and in what manner software products are different from the physical CBD-products). For example, many scientists erroneously concluded that it is impossible to invent software components equivalent to the physical components for securing equivalent the huge benefits that are enjoyed by the designers of physical CBD-products built by assembling physical components, where the benefits include substantial increase in quality and productivity.
Absolutely there is no valid reason for why it is impossible to invent software components equivalent to the physical components. Of course, it is essential to discover accurate description for the physical components for inventing equivalent software components, where the accurate description is nothing but a list of few essential properties that are universally shared by all the large physical components in the world. It is absolutely essential to discover the few essential properties for identifying potential software components in each of the large software products and building each of the software components for the product.

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