Wednesday, January 22, 2014

Urging software researchers to discover real-CBSD and set the goal to achieve real-CBSD for large and complex software products


Toady CBSD (Component-Based Software Design) or CBSE (Component-Based Software Engineering) is defined as using so called software components. It is not much different from defining flying is not much more than flapping wings, by alien species who have not yet discover ‘what is real flying’. Why is it not possible to discover the beauty and grace of real flying by observing aerobatic maneuvers of majestic birds (e.g. Peregrine Falcon, Golden Eagle etc.) chasing a prey or modern Jet-fighters in a dogfight (e.g. by watching videos)? Likewise, Why is it not possible to discover the beauty and grace of ideal-CBD and ideal-CBE (by investigating and analyzing all the facts to discover essential aspects uniquely and universally shared by the design of each and every complex physical product built by assembling physical components)?

Please let me describe an ideal CBD, since I believe it is possible to achieve the ideal CBD for designing and building complex software products. An ideal CBD of any complex product requires partitioning the product into hierarchy of replaceable components, where the term replaceable means that the component can be easily disassembled and reassembled as a unit. The FIG-2 in CBD-structure illustrates a logical structure of the components, where even a container component can be unplugged as a unit and disassembling the container component effective removes all it subcomponents from the product without leaving any traces. It is important to comprehend and always keep in mind the 3-CBD-facts and 3-CBD-rules.

In an ideal CBD, no component must take more than few minutes for disassembling by unplugging the component and must not take more than few minutes for reassembling by plugging-in the component. In ideal CBD, one must left with bare board (e.g. PCB board having holes to plug-in pins of each component), if all the components are unplugged (by unplugging one component at a time). In general, a team of engineers build each of the large and complex products, where each engineer is responsible for designing and building one or more components in the hierarchy of the replaceable components.

In case of ideal-CBD, no component should be too complex to require effort of more than one engineer. Each component should be of optimal complexity and allow each engineer to work in a manner consistent with his skills, expertise and talent. It is useful to define an optimal complexity, for example, an average newly recruited engineer should need no more than couple of weeks to grasp the design of a large component to safely make simple changes (e.g. to add simple features and functionality).

Each component can be designed developed and tested independently outside of the product. Once satisfied with its quality and functionality, the stable version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

This stable version of the component can be refined and tested independently outside of the product for adding more features or functionality for creating yet another stable version of the component. This version of the component can be assembled into the product to make sure it performs as expected in the product. Furthermore the component can be refined little-by-little until it performs optimally within the products (e.g. by perfectly collaborating with other components), which results in yet another stable version of the component.

For example, the sample City_GIS application achieved the ideal-CBD (Please also refer to important FIG-3). A source code control system SCCS or RCS/CVS can be and must be used for tracking the code base of each of the components, so that it is possible to restore any of the older versions of the components. For example, if an engineer wishes to experiment by adding few features he feel useful and creates a new version, but only 40% of the customers liked it, he could restore the older version. For example, a junior engineer joined and need to add few more features and in the process the code base of the component is ended up sub-optimally by the time he gained enough experience in the domain, he could restore older version and restart again.

In case of real-CBD, each component have exclusive blueprint (e.g.code-base) than can be versioned and sandboxed. Hence no engineer can damage design (e.g. code base or blueprint) of any other component. But in case of software, even a simple application having just three large components begin its life as spaghetti code. That is, each file contains code-sections for more than one component, so finding and redesigning code sections of any component is a complex task. Then to test the component, one must test whole system. If one wishes to restore older version, he must restore the all the files (which result in loosing changes made to other components during this period in those files).

Some of the benefits of real-CBD include: Each component can be optimized (e.g. re-factored) and tested independently. More than one version can be maintained for each component, to address different segments of customers. The real-components are often by nature neither reusable nor standardized, since each of the components are custom designed to optimally satisfy unique needs of its target application (and also must be adoptable to unpredictable evolving unique needs of its target application).

However, if another new product-model requires similar component, the blueprint (e.g. code base) of an existing component can be redesigned to create a customer version for the new product-model. Hence real-software-components offer excellent knowledge and code-base reuse. Today, it is not practical to reuse the knowledge and code-base, since the code-sections of large software components are spread across many non-exclusive files, where the files comprise code-sections for multiple components.  We invented a GUI-API, which allow encapsulation of any complex GUI-component is a class definition, which makes the component not only replaceable but also code-base for the GUI-component can be encapsulated in an exclusive set of files for versioning and sandboxing.

The above kind of GUI-API is one of the essential missing pieces for inventing real-CBSD. Other inventions essential for real-CBSD/CBSE include: An ideal CBSD/CBSE requires employing intelligent CASE-tools that must automate creation and management of communication code by managing coupling interfaces of each component for automatically detecting any incompatibilities between coupling interfaces of any two components.

After creating hundreds of component-hierarchies (many of them I am more than eager to demonstrate to fellow researchers), I can’t find any valid reason why designers of complex software products can’t achieve CBD-structure for most of the large and complex products. I strongly request software researchers to discover essential aspects uniquely and universally shared by design of each and every large CBD-product for discovering inherent nature of real-CBD; and discover essential properties uniquely and universally shared by each and every large functional-component for discovering inherent nature the functional-component.


Unfortunately substantial research effort has been wasted in past three decades for chasing goals that are not much less than science fiction by relying on baseless axiomatic postulations (which are not much less than myths). For example, a goal chosen in formative years during mid 1960s of software engineering was: building software as we build computers by assembling reusable components from third party vendors. Even a quick analysis of obvious facts and simple observations conclusively prove that it is impossible to achieve such a fantasy.