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).
ReplyDeleteThere is an interesting paragraph about the manufacturing of automobiles on PBS.org website: http://www.pbs.org/wgbh/peoplescentury/episodes/ontheline/description.html
“In the early 1900s, automobiles were built in small workshops, where craftsmen painstakingly assembled cars by hand. Charles Hill started work at fourteen as an apprentice in Britain's Vulcan Motor Company, where it took ten days to make a single car: "Everybody seemed to be busy doing something. You were amazed that every man is in one sense a specialist in his own particular job. There were men, skilled men, when I went there. They were there all their life to their dying day." Craftsmen controlled the pace and the quality of their own work -- and took a great deal of pride in what they turned out.”
Another interesting (but looks like bit more exaggeration compared to the above more balanced statement) at web page: http://rationalrevolution.net/articles/division_of_labor.htm
“Prior to Ford's advancement of the assembly line for automobile production, cars were primarily produced by craftsmen, as was the case with most things. Each car was individually produced by a team of craftsmen, and each of these craftsmen had to be highly skilled and very knowledgeable about the mechanics of cars in order to build them. Every person on the team had a very good working knowledge of virtually all aspects of car manufacture. Many of these craftsmen were capable of building an entire car by themselves. Not only did they have the skills, but they designed the cars, understood the mechanics, understood physics, engineering, metallurgy, etc. They had a wide range of knowledge and skills, often a complete set of skills and knowledge about the cars they were building.”
Today a team of software engineers building large application. The above statements apply to software engineers (by replacing the term car by software-application and craftsmen by software-engineers), for example: Each car/application was individually produced by a team of craftsmen/engineers, and each of these craftsmen/engineers had to be highly skilled and very knowledgeable about the mechanics/intricacies of cars/application in order to build them. Every person on the team had a very good working knowledge of virtually all aspects of car/application.
If I am a designer of a component (e.g. City_ATC) and when I am designing (or redesigning for a new model) the component (e.g. City_ATC), why do I need to expose to the intricacies and code of other components? When I am designing (re-designing) the component, I don’t like to be distracted by the intricacies of any other component (e.g. City_Hotels), even if I am also the designer of the other component (i.e. City_Hotels).
If I need to redesign a component in a CBD-structure, I should be able to unplug for redesigning and testing the component individually outside of the product.
Please kindly refer to FIG-2 in: http://real-software-components.com/CBD/CBD-structure.html
Please kindly refer to FIG-1 (in light of Listing-1 & Listing-2) in: http://real-software-components.com/CBD/City_GIS.html
Once I feel the component is ready for testing, I should be able to plug-in and test the components features, functionality and operations. I certainly could use help from an intelligent CASE-tools to make sure I didn’t inadvertently break any coupling interfaces. If I need to change the coupling interfaces of the component, I want the intelligent CASE-tools to inform me the effected coupling-interfaces of other components, so that I can inform the management for getting necessary approvals, for example, for coordinating with the designers of respective effected components.
ReplyDeleteWhat is the vision of the researchers of CBSE (Component-Based Software Engineering or Design)? Is it based on Reality or Science Fiction? Is it Practical or Fantasy?
If the researchers analyze all the obvious facts (please see few obvious facts), I am sure the researchers would realize what they envisioned is not much different from Science Fiction and Fantasy? http://real-software-components.com/CBD/main-differences.html and http://real-software-components.com/RSCC/ecosystem-evolution.html. Any vision, if it is not based on facts but based on erroneous axiomatic assumption (i.e. a myth), is just an elusion or fantasy.
After creating hundreds of real-software-components and creating dozens of hierarchies of replaceable components, I can’t find any valid reason why software designers can’t achieve CBD-structure for any complex software product. Even if it is hard to partition 100% of a complex software product as a balanced CBD-structure having components of optimal complexity, why is it not possible to identify many SCC (Self-Contained Components) for designing them as RCC (Replaceable-Component Classes)?
There are many clear indications that real-CBSE not yet discovered, such as: Today not even a single large GUI-SCC can be created as a RCC, since no other GUI-API is capable of creating such RCCs. Even in case of non-GUI applications, almost no conscious effort is made to identify SCCs to design them as RCCs, while it is possible to easily identify many SCCs in each of the large applications. When real-software-components and real-CBSD are discovered it would be obvious that the intelligent-CASE-tools are extremely useful. Today no one is using intelligent-CASE-tools for managing coupling interfaces of components and for facilitating communication between components with in an application (i.e. a single executable). http://real-software-components.com/CBD/Sample_SoA_CASE_tool.html