| |
|
Summary for 3-CBD-facts & 3-CBD-rules
|
|
|
Can we even imagine designing and building complex one-of-a-kind products such as Jet-fighters or spacecrafts without componentization (i.e. partitioning into a component-hierarchy or CBD-structure)? No component in the hierarchy magically works perfectly at first attempt. Each component is refined or redesigned little-by-little to make it as best as it can be (in step-1 of CBD-process). This process of refining and redesigning each component would continue throughout the evolutionary life of the product-family, for example, as summarized in step-3 of CBD-process.
|
|
|
There is no valid reason why design and development of large software systems must be different from designing and building newly invented or one-of-a-kind physical products. For example, consider design and development of a newly invented product at: http://real-software-components.com/CBD/CBD_of_new_product.html
|
|
|
It is impossible to find a valid reason why each of the complex software products can’t be design as component-hierarchy (i.e. as a CBD-structure), where each component can be evolved individually outside of the product, especially in light of the following two important irrefutable facts about CBD of the complex physical-products (henceforth referred to as 3-CBD-facts):
|
|
| 1 |
It is an obvious fact that, it is not necessary that even a single component in the component-hierarchy of a one-of-a-kind or unique product (e.g. a spacecraft or experimental Jet-fighter) conform to so called component models or have any property (e.g. reuse or standardized) erroneously attributed to the any kind of software components known today.
|
| 2 |
We also know that either uniqueness or complexity of one-of-a-kind products (e.g. a spacecraft, experimental Jet-fighter or super-computer) can’t prevent designers from achieving component-hierarchy (i.e. CBD-structure, for example by using step-1/step-3 of CBD-process).
|
| 3 |
In the context of physical products, except very special kinds of physical functional parts (having very unique essential properties) no other kinds of physical functional parts can enable the CBD for physical-products, where the special kinds of physical parts are known as components.
|
|
|
|
It is an irrefutable fact that: the cost of disassembling or reassembling any complex CBD-product is under 5% of the cost of designing and building all the components of the complex CBD-product (in step-1 or step-3 of CBD-process). In light of this fact, why isn’t it possible to design each of the complex software products, so that the product try to satisfy the following three rules (hence forth referred to as 3-CBD-rules) by inventing real-software-components that are logically equivalent to large physical functional-components:
|
|
| 1 |
Any application (e.g. City_GIS) can be built by taking a bare application template having generic code, code for using reusable classes (or modules) and assembling all the components, where no component needs more than 2 to 5 lines of code to assemble.
|
| 2 |
Removing the 2 to 5 lines of code must effectively removes each component and removing all the components (one component at a time) result in the original bare application template.
|
| 3 |
Either in step-1 or step-3 of the CBD-process, the product can be disassembled or reassembled for about 5% of the cost of designing & building all the components in the component-hierarchy.
|
|
|
|
Note: Any application comprises
2 kinds of custom application code (i) code for construction, operation and coupling interfaces of
its components (i.e. SCCs), where custom code for each SCC could be encapsulated in a RCC, (so
needs 2 to 5 lines to plug-in each component); & (ii) coupling code for allowing
collaboration between the components (where couplings of the components can be automated by
using an intelligent
CASE-tool that uses the coupling interfaces implemented in RCCs).
|
|
|
After building hundreds of software GUI-applications each GUI-application (e.g. City_GIS) as a CBD-structure, I can’t find a valid reason why software applications can’t be built to satisfy the 3-CBD-rules. Let me confess that,
in case of some applications I implemented some custom code in each application template, but the custom code is
under 10% of the total application code implemented for all the real-software-components. Hence, this 10% custom code would be left in the template in case of rule-2 and costs up to
12% in case of rule-3 for including the custom code.
Of course, most of the custom code is implemented to fill gaps for doing certain routine house keeping work and communication code. Based on the earlier experience, I learned
that most of the custom code can be eliminated by inventing and using generic reusable
modules & intelligent CASE-tools,
where such reusable modules & tools are invented later for minimizing the
custom code.
|
|
|
The 3-CBD-facts not only proves that no known kind of software components is equivalent to the physical functional-components but also proves that it is possible to identify multiple software components equivalent to large physical functional-components. The 3-CBD-rules summarize the goals for ideal CBD-design for software products. It is important to understand the difference between proposed CBD and existing components. For example, consider sample CBD-application City_GIS. Today programmers use many kinds of known components (e.g. GUI-API, Tools and libraries) for building each of the SCCs (self-contained components) such as City_ATC or City_LandMarks.
|
|
|
In addition to using everything available to build each SCC, our CBD also requires identifying multiple SCCs in an application and encapsulating each SCC in a RCC (Replaceable-component class). It is not essential but extremely useful, hence recommends using intelligent CASE-tools to create and manage communication code between the real-software-components. Therefore number of optimal sized RCCs along with the CBD-rule-2 and CBD-rule-3 determines the total degree of componentization.
|
|
|
The componentization is the most effective and efficient process known to mankind for addressing complex problems by a team of experts. The real-CBSD and real-software-components can offer unprecedented degree of componentization. Let me illustrate the difference: If a SCC (e.g. City_ATC) is not encapsulated in a RCC, it is impossible to redesign and test the SCC outside of the application. That is, the whole application must be tested for testing any SCC even after small redesign or addition of a feature to the SCC. The components offer highest degree of autonomy for evolved individually throughout the life of the container product (i.e. in step-1 & step-3 of CBD-process). No other kind of parts can offer such high degree agility (i.e. for individually improving little-by-little throughout the life of container product), while allowing componentization of 90% of the application as per rule-2).
|
|
|
It is a huge error to assume that it is possible to build perfect component at first time. Each component in the component-hierarchy needs to be redesigned little-by-little and tested individually to make each component as best as it can be (during step-1 or step-3 of CBD-process). The real-components address area that can’t be addressed by other kinds of parts such as reusable components. For example, although other kinds of parts such as reusable ingredient parts (e.g. cement, steel, alloys or silicon) are designed and developed independently, they can’t be disassembled and tested outside once they are used in building container component or product.
|
|
|
My humble request is to discover innate nature and essential properties uniquely and universally shared by each and every physical functional-components, since the essential properties are useful for positively identifying equivalent software components (or SCCs) in large software applications. Although goal must be and can be 100% componentization of each complex application, please keep in mind that, even if 50% of the application code is created as component-hierarchies, each component can be redesigned and tested outside of the application individually at a fraction of the cost and time.
|
|
|
After reading sections on CBD-structure, CBD-process, sample City_GIS application and intelligent CASE-Tools in my brief paper on CBD a reviewer said: "A lot has been written about modular design of software. For example, encapsulation, independent testability of modules, etc, are all standard practices. It is not clear what exactly the paper says that hasn't been said before". Please let me respond to this: All the above sections only talked about real-CBD methods for increasing encapsulation, modular design and independent testability (for increasing productivity) by using new kind of real software components that can modularize the software to unprecedented degree. Every engineering activity for many centuries has been employing the
3 important
industrial engineering factors (i) division-of-labor, (ii) specialization and (iii) automation to a certain degree. The purpose for modular design, encapsulation and independent testability are to increase the degree of these factors for increasing productivity: Any invention directly or indirectly help increasing the degree of one or more of these industrial engineering factors for increasing productivity.
Objective of engineering inventions is to increase the productivity, quality
& reducing complexity, which can be achieved only by increasing the degree
of one or more factors (i) division-of-labor, (ii) specialization and (iii) automation. Is it hard to understand the various degrees of
wealth? Making 90 million is great, but making billion is greater to much higher degree
(so it is foolish to say "a lot has been written about making money/wealth" by not realizing the
novel ways for increasing wealth).
A great invention increases productivity by many folds by substantially increasing the 3 factors directly or indirectly. For example,
2 of the greatest inventions (i.e. introduction of interchangeable-components & Ford’s moving assembly line) for increasing productivity invented none of these factors (e.g. encapsulation, modularity & independent testability), but invented methods to increase the degree of the factors. The 3-CBD-rules define goals of an ideal-CBD design, where size of each component in the CBD-structure should be optimal (e.g. so that an average engineer can learn
& safely redesign in few days). CBD-fact-2 proves that it is possible to achieve the goals set by 3-CBD-rules.
The real-components are superior modules and offers superior encapsulation and independent testability than any other known kinds of
physical parts. We never claimed to invent modularity, encapsulation or independent testability. For example, no existing GUI-API allows modularizing large GUI-components such as City_ATC
or City_LandMarks for achieving such hierarchy of replaceable modules. We invented a GUI-API that allows encapsulation of such real components in a RCC for independent testability (at any time not only during step-1 but also during step-3 of CBD-process).
If reviewers read a paper submitted for the scientific conferences, how is it possible to find such lame
excuses (without any chance for rebutting).
|
|
