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.
