Saturday, January 25, 2014

What is the essence of CBD (Component Based Design)? Simple Answer: Elimination of Spaghetti Code!


It is a huge error to assume CBSD (Component-Based Design for Software) is using so called software components. A simple method for discovering the real essence of CBD of physical products is to compare the differences of (a) how each of the large physical functional-components for prototype of a one-of-a-kind products (or a product newly being invented) is custom designed and build for the target physical product; with (b) how each of the large self-contained components (or software modules logically equivalent to the physical functional-components) is custom designed and build for it’s target software product.

Step-1: If I am responsible for a component Cx for a target product, I can design, build and test the component Cx independently outside of the product. Then when I feel it is ready, I can plug-in (or assemble) the component in the target product to make sure it functions as expected.

Step-2: If doesn’t fit or function as expected, I can unplug (or disassemble) the component Cx to refine little-by-little until it fits properly and functions as expected in the container physical product (or in the container-component, if Cx is a subcomponent of a container-component).

The Cx is custom designed to satisfy current unique needs of the target product. The step-1 and step-2 can be repeated for each Cx in the component hierarchy (e.g. CBD-structure) of any CBD-product.

Once, the product model is released to the market, the maker of the product need to design, build and release new models or versions of the product. I can continue to refine the blueprint (e.g. design) of component Cx little-by-little (in step-1 and also in step-2) independently throughout the evolutionary life of the target product (i.e. for each creation of successive new models and versions). Again the Cx is custom designed to satisfy current unique needs of each of the new product model.

If I am a designer of City_ATC for a target City_GIS application, why do I need to touch or even see even a single line of internal code any other components (e.g. City_LandMarks, City_Hotels or City_Map)? If I am a designer of City_Theaters for a target City_GIS application, why do I need to touch or even see even a single line of internal code any other components (e.g. City_ATC or City_Hotels)?

Please remember, if I were designer of HardDrive for a computer product, I don’t need to touch or even see tape-out Verilog code of CPU, DRAM or any other IC-Chip. Likewise, if I were designer of auto-engine, I don’t need to touch or even see a single line of code (i.e. internal design) of CD-player, gearbox or auto-battery. If I were designer of motor that spins the magnetic disks in HardDrive, I don’t need to touch or even see even a single line of code (i.e. internal design) of magnetic disks or any other component in the container component HardDrive or in the target computer product.

Therefore, in case of CBD for physical products, there is no spaghetti code. The designer of each component-Ci (for each component-Ci, where component-Ci can be any component between component-C1 to component -Cn), don’t need to touch or even see single line of code (i.e. internal deign) of any other component in the hierarchy of replaceable components (or CBD-structure).

Toady it is impossible to avoid spaghetti code in software products, since the source code of each Cx (e.g. City_ATC or City_LandMarks) is forced to spread across multiple non-exclusive files, where each of the file contain source code for more than one component. For example, today no other GUI-API is capable of encapsulating complex GUI-components such as City_LandMarks or City_ATC in a replaceable component classes (RCC), so that the component can be plugged-in by implementing just 3 to 5 lines of code and can be unplugged by deleting the 3 to 5 lines of code. It would take just few minutes to find the code base of any component, if encapsulated in a RCC (otherwise would take forever to find all code-sections spread across multiple non-exclusive files).

If I am a designer of City_ATC component (encapsulated in a RCC), I don’t need to see a single line of code of any other component, even if I work on the City_GIS application for seven years creating a new version of City_ATC component every six months for each new release or upgrade. This is not that much different from, I don’t need to see a single line of code of any other component, if I were a designer of motor that spins the magnetic-disks in the HardDrive and I need to constantly improve the motor for each of the new models for ten years.

Why the software developers today are forced to design and develop components such as City_ATC, City_LandMarks or City_TouristSpots as spaghetti code? More and more spaghetti code would be accumulated as each of the components is redesigned for satisfying unique needs of each of the newer models of the target product. Why a designer and developers of any component (e.g. City_TouristSpots or City_Hotels) need to see even single line of code of any other component in City_GIS application? The real-CBD not only eliminates spaghetti code but also eliminated reasons for accumulation of spaghetti code during the evolutionary life of products.

Many physical products (e.g. automobiles, Airplanes or super-computers) have been evolving for many decades and many successive new models have been designed with nearly zero accumulation of spaghetti code. I hope this example (using analogy of physical components) illustrate the essence of the CBD (Component Based Design). We invented all the missing pieces (e.g. GUI-API and intelligent-CASE-tools, etc) for creating real-software-components and assembling the real-software-components for achieving CBD-structure (i.e. hierarchy of replaceable components).

Let me summarize the essence of CBD is simple terms: If City_GIS application is built by assembling 6 components and 6 RCCs for 6 components are designed and built by 6 engineers (i.e. each engineer created a RCC), it is not necessary for any engineer to see a single line of code implemented in any other RCC. Likewise, if a product is built by assembling 1000 components and each of the 1000 components is designed and built by an engineer, it is not necessary for any engineer to see internal design (e.g. a single line of code or blueprint) of any other component. Any component should be disassembled or reassembled in minutes (e.g. either to replace or to redesign for successive models).

It is impossible to find a valid reason why it is not possible to achieve real-CBSD (i.e. hierarchy of replaceable components for complex software products), once essential aspects of CBD for physical products and essential properties of physical functional-component are discovered (where the essential aspects of CBD for physical products are the aspects uniquely and universally shared by the design of each and every complex product built by assembling physical components; and essential properties of physical functional-component are properties shared by each and every physical functional-component).

Analyzing the differences between ‘a’ and ‘b’ of the first paragraph at the top not only expose the huge insane error but also help discover the true essence of real-CBD (e.g. especially in the light of 3-CBD-facts).