banner banner  
 

The Creation & Evolution of CBD-Structure of a CBD-product

The first design of CBD-structure of each product family is created when early product models are invented and prototypes are built (i.e. in step-1 of CBD-process). For example, first version of CBD-structure of the cars was designed more than 120 years ago, when early models of automobiles were invented. The CBD-structure also evolves over time little-by-little (e.g. in step-3 of CBD-process) for example, to overcome shortcomings in the initial design and to accommodate increasing complexity of the future newer product models. After all a CBD-structure is nothing but a block diagram (e.g. FIG-1, FIG-2) of a tree of component hierarchy, which may be refined even for each of the sub-components (e.g. sub-tree of RCC-03, RCC-07 or RCC-15).
Today software applications comprising even 3 SCCs begin its life as spaghetti code, since real software components are not yet invented (e.g. No other existing GUI-API is designed to encapsulate any SCC in a RCC). The internal code structure of complex software applications degrade into spaghetti code or ‘big-ball-of-mud’. But engineering history of past century proves that, the CBD-structure of each product family only becomes better and better over time and always able to accommodate rapidly increasing complexity of even one-of-a-kind complex product-models such as spacecrafts, experimental jet-fighters or supercomputers. No competent engineering expert in the world can deny the obvious or easily observable facts.

FIG-1: A Simple application comprising 3-SCCs, where a shape is used to visually show parts of each of the SCCs (e.g. the parts of a SCC is shown by using qubes and parts of another SCC is shown by using pyramids.

FIG-2: The same application can be created by using 3-RCC, where each RCC is designed to encapsulate construction code of a SCC and assemble the SCC in the application.

          When a new developer is asked to add a feature to one of the SCCs, his motive is to learn as little as possible to implement the changes. In case of FIG-1, the structure of the application degrades. In case of FIG-2, the structure only becomes stronger (since he would prefer making the interfaces solid to avoid learning about the other SCCS).

As a system becomes more and more complex it would be cheaper, quicker and simpler to strengthen the CBD structure rather than weakening the CBD-structure. Any quick fixes that weaken the CBD-structure increasingly become costlier and complex as the system becoming more and more complex. For Example, it is much harder to comprehend, test or debug any spaghetti code resulting of quick fixes to set of effected RCCs that weaken CBD-structure; compared to comprehending, testing and debugging each affected RCC autonomously by preserving and leveraging the well designed interfaces between components that are managed by sophisticated tools (e.g. SRO).
It is important to understand positive spiral and negative spirals. For example consider this analogy: If an unexpected discovery of gas is made in a closed stable economy of a small country, it creates more jobs more taxes, which creates more investments on infrastructure or lesser taxes leading to more jobs and more taxes. This is an example of positive spiral. An example for negative spiral: If stable income and jobs from mining suddenly disappears, many people loose jobs and look for unemployment checks from government. The government spending goes up while tax revenue goes down, resulting in cutbacks in other investments or raising taxes leading to more job losses, and so on.
The introduction of CBD-structure creates positive spiral. The CBD-structure along with generic sophisticated CASE-tools such as SRO initiates a positive spiral. For example, generic sophisticated CASE-tools such as SRO offers huge incentive to strengthen the CBD-structure, since it is more painful, complex, and costlier to not use them by weakening the CBD-structure by making each effected RCC replaceable by a lesser degree. This instant infliction of pain is a huge disincentive for weakening the CBD-structure or making each of the effected RSCCs replaceable to a lesser degree. Hence as the system becomes more and more complex, the CBD-structure becomes more and more strong and each of the RCC is made replaceable to a higher degree (since it is less complex to comprehend or test each large RCC having higher degree of autonomy, where the degree of replaceability is a measure for degree of autonomy).
Today the software engineering is in negative spiral, leading to big-ball-of-mud. As a system becomes more and more complex, it is harder to preserve initial design structure. This negative spiral causes degradation of code structure as more and more features are added to the system by many engineers, where each engineer having inadequate understanding or grasp and different highly subjective perceptions over parts of the system developed by other engineers. For example, each engineer is forced to change code developed by other engineers, for example, to communicate with parts of other SCCs or inadvertently (since each file contains spaghetti code of various parts for each SCC of multiple SCCs by implemented multiple engineers).
 
   
 

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