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.

1 comment:


  1. What is orange Juice? Any kind of juice extracted form Orange fruits. No other kind of juice extracted form any other kind of vegetable (e.g. carat, potato or brinjal) or forest fruit (tomato, dewberry or palm) can be Orange Juice. It is foolish to blindly define juice extracted from potato is a kind of Orange Juice, define juice extracted from tomato is another kind of Orange Juice and juice extracted from dewberry is yet another kind of Orange juice (without ever trying to discover what is an Orange fruit).

    What is CBD? Any kind of design that uses components for designing a product is CBD. The components are very special kind of parts having very unique and essential characteristics. That is each and every real component uniquely and universally shares certain characteristics. No other kind of part can be a component and using any other kind of part can’t be CBD. It is error to define any other kind of parts (either having useful properties or conform to a so called component model) is a kind of software components and it is error to define CBSD is using any kind of such so called components.

    Important conditions for real-CBD: (1) Cost of disassembling or reassembling must be less than 3% of the total cost of designing the product as hierarchy of replaceable components (i.e. CBD-structure), and designing and building all the components. (2) Each of the components in the CBD-structure can be redesigned and tested individually either in step-1 or step-3 of CBD-process. In case of software, any component can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component.

    For example, reusable modules such as each class for a GUI-component (e.g. line-chart, pie-chart or bar-chart) can be redesigned and tested individually without touching or even seeing a single line of code implemented for any other component. But such classes can neither achieve the 1st condition nor can be replaceable-components. Such reusable class is not self-contained, since it requires implementing substantial application logic to access/process application data for using the data to present a simple self-contained component. Such component is also not replaceable (i.e. can’t be disassembled as a unit), since it requires removing all this spaghetti application logic to effectively remove even a simple self-contained component.

    But each of the RSCC (replaceable self-contained component) in the CBD-structure could be more complex as illustrated in City_GIS application. For example, components such as City_GIS or City_Theaters comprise dozens of GUI-components, where each GUI-component is presented by implementing necessary application logic to access/process application data for using the data for initializing and configuring an object instance of respective GUI-class. The application logic for all the GUI-components implemented in a RCC (Replaceable Component-Class) for presenting in RSCC is generally implemented as a spaghetti code, so no single GUI-component is replaceable (i.e. can be disassembled as a unit to redesign and test individually).

    Since real-software-components are not yet known, today no other GUI-API is designed to encapsulate such large SCC (comprising multiple GUI-components) in a RCC, which is essential for achieving CBD-structure by building component hierarchies.

    Is it possible to extract Orange juice from any other kind of fruit or vegetable? Likewise, real-CBD requires using real-software-components. In case of physical products, we have only few kinds of parts, such as components and ingredient-parts (e.g. steel, silicon, alloys or plastic), since the physical parts are constrained by laws of nature and physical attributes (e.g. size, shape or weight). The software-parts have no such constraints, so it is possible to invent many kinds of parts, including very unique kind of parts that are logically equivalent to the physical functional-component (by having essential properties uniquely and universally shared by each and every physical component).

    ReplyDelete