banner banner  
 
One of My Goals and Vision for Software Engineering
Today software engineers could leverage huge infrastructure comprising tools, compilers, RDBMS and reusable libraries for building software applications. Even after using all kinds of available libraries and tools from the mature infrastructure, today many large applications still require implementing millions of lines of custom application code. It is impossible to avoid implementing custom application code, so it is designable to modularize the custom application code into replaceable components (which can be unplugged by deleting 3 to 5 lines of code and plugged-in by implementing 3 to 5 lines of code), which must achieve highest possible modularization by eliminating all the reasons that cause spaghetti code (e.g. to effectively disassemble, re-assemble after redesigning or to replace).
My Research Goal is to invent a new kind of software components that can achieve a new kind of CBSD (Component-Based Design for Software Products). The characteristics of the replaceable components are (i) no component must require more than 3 to 5 lines of code to plug-in the component as a unit, (ii) must encapsulate few hundred lines to few thousand lines of application code and (iii) removing the said 3 to 5 lines of code must effectively remove the component as a unit (leaving no traces of any associated application code). These new kind of components are referred to ‘replaceable components”, since any component can be removed by removing 3 to 5 lines and replaced by another equivalent component by implementing 3 to 5 lines of code.
Let me illustrate the new kind of CBSD by using an example for an ideal CBSD application: If an application has 1000 components and on average each component requires 4 lines of code to plug in the component, it must requires no more than 4000 lines of application code to assemble all the components for building the application, once all the components are properly designed & built. These components must be assembled into a generic reusable application template.
If the average custom application implemented for each component is 1000 lines for the above sample application of 1000 components, then total size of custom application code must be developed by software engineers would be about a million lines. In this case, over 99.5% of the application code is implemented as replaceable components. The components must communicate and/or collaborate with each other by using generic reusable intelligent CASE-tools (which should be able to automatically manage coupling-interfaces of each of the components and compatibility of coupling-interfaces between any two collaborating components).
For an example, please review City_GIS application, where it requires no more than 3 to 5 lines to assemble each of the replaceable components. The above City_GIS application has just 6 very large replaceable components (comprising code for using dozens to hundreds of reusable GUI-classes) and each replaceable component requires no more than 4 lines of application code for assembling each of the components. The silent features of the replaceable components are: (I) each component can be redesigned and tested individually (e.g. as an independent application). That is, each component can and must have excusive code base, so it is not necessary for the designers of each component to see or touch even a single line of code implemented for any other replaceable component. That is, code base for each replaceable component is sandboxed (from code-base of all the other components and code-base for the application) and each component can be versioned individually (e.g. for experimentation or to create multiple models to choose from).
The software researchers must had achieved about 90% of such goal of real-CBSD decades ago, if their goal were to build applications by plugging-in replaceable components, where each replaceable component is custom designed to satisfy current unique needs of the target application and must not require more than 5 lines of code (to disassemble or re-assemble the component). The application can be evolved (for releasing newer versions) by redesigning and testing each of the replaceable components individually. There is no reason for creating spaghetti code, since developers of each component can work on exclusive code base of the component and intelligent-CASE-tools help developers resolve any possible mismatches of coupling-interfaces (as illustrated by FIG-3, 4 & 5).
I can demonstrate hundreds of component hierarchies to prove this vision and goal is realistic. If researchers discover real-CBSD, real-software-components and set this realistic goal today, software researchers could achieve about 80% of this goal within one year. Here 80% of the goal means 80% of the application code and features must be implemented in replaceable components (rest of the 20% application code is in old fashioned spaghetti code). One must keep in mind certain important facts of CBD of physical products and ruled for real-CBSD.
Theoretically, it is impossible to find a valid reason, why it is not possible to achieve 99% goal. For example, the City_GIS application achieved 99% goal. Above sample application having 1000 replaceable components, in theory, achieved 99.5%, since total application code implemented for all the replaceable components is a million lines and application code required to assembly all the components to build the application is under 5000 lines of code.
What is the use of componentization of 99%, 90% or even 70%? If you are responsible for implementing and maintaining a component (e.g. City_ATC or City_Theaters), to implement the component you can create the application code in a set of exclusive files and test the component individually. You can make it as best as it can be and plug-into the application to make sure it fits properly and functions as expected in the application. Once satisfied, the code base (i.e. the exclusive files) of the component can be checked into a source code control system (or SCCS). If this version is 1.0 of the components and if one wishes to save source code for intermediate versions, it is possible to save source code for intermediate versions (e.g. 0.2, 0.4, 07 and 0.9 etc.) in the SCCS.
If the product containing this component become successful or people start using it, of course your employer need to make improvements for many of the components to build a better version. If you need to add more and more features and functionality, you can check out the code base from the SCCS to redesign the component to add required features and functionality. You can redesign and test the component individually. That is, no one else needs to change even single line of code implemented for your component. You don’t need to see even a single line of code implemented for any other component or application. You can re-factor the code-base as you wish to optimize and/or to make it as best as it can be (without any interference or noise from any other).
Today the life of any large GUI-component begins as a spaghetti code, since no other GUI-API is capable of encapsulating large GUI-components like City_ATC or City_LandMarks in a class definition, so code sections for each large component spread across multiple non-exclusive files (where each fine contains code sections for more than one component). The structure of the code progressively degrades into big-ball-of-mud as more and more features are added to each of the GUI-components by multiple software developers (having varying degree of skills, experience and talent) .
For example, if I created 20,000 lines of code (as 10 replaceable components) for the application, I don’t need to see code implemented for any other component (while redesigning one of my components) and no one else need to see my code (while redesigning one of his components). That is, I can’t screw up any one else’s code inadvertently (while I am redesigning one of my components) and no one can screw up my code inadvertently (while he is redesigning one of his components). In case of ideal CBSD, this is true for 99% of the custom application code implemented for the application. On the other hand, if only 70% of an application’s code is modularized, this is true for only 70% of the code.
The application or product can be evolved for many decades by redesigning multiple components individually for realizing periodically (e.g. every few months) each of the successive application or product models. For example, one day I had of stroke of genius and created a new version of my component. If I proudly showed my ingenious component to my customer and if he hated it (I can restore older version in minutes). For example, if you are promoted to manager and a junior engineer is recruited to maintain some of the components. If he screws up design of a replaceable component, you can always restore previous good version and ask him to start over again. He can’t screws up code of any other component or application, since he can’t see or touch code of any other component or application. It is not so easy, if the code sections for the component is spread across multiple non-exclusive files and other engineers need to asynchronously modify the code-sections implemented for other components in the files.
All these benefits are nothing new to the designers of physical functional components of complex physical products such as one-of-a-kind spaceship, prototype of new kind of supercomputer or experimental jet-fighter. For example, designer of a component (e.g. HardDrive) never need to see or inadvertently change internal design of any other component (e.g. DRAM, CPU or CP-player). The design and development of complex software applications are not much different from designing and building newly invented one-of-a-kind physical products.
What fascinated me most and induced irresistible curiosity to leave a profitable business is, I created multiple GUI-applications, where multiple components are implemented for each of the application. It is possible to create a container replaceable-component by plugging-in all these components implemented for all the applications, where the container replaceable-component can be plugged-in as a sub-component in yet another container component. It is hard to explain my experience, pleasant surprise and exhilarating feelings, which induced irresistible curiosity and drove me to focus on this research more than a decade ago. I guess, one must experience this on his own to know how I felt.
Please imagine: If a company creates 100,000 replaceable components for 200 different GUI-applications (e.g. See City_GIS) over a decade, I can’t see a valid reason why all the 10,000 replaceable components can’t be assembled into a single reusable application template by implementing on average 3 to 5 lines to assemble each of the 100,000 replaceable components. Why this is important or interesting? This allow diverse groups of software developers to work independently (e.g. at various locations around the world) to build and maintain more complex applications than practical today, since complexity grows more linearly (since intelligent CASE-tools can create and manage coupling-interfaces of each of the components and couplings between any two components).
Isn’t revolutionary to create 100 million lines of application code without any spaghetti code? When redesigning any of the components, no engineers need to see internal code for any other component throughout the life-cycle of this application having 100 million lines of custom code. Every component can be individually fine-tuned and optimized (e.g. refactored) to make it as best as it can be at any time throughout the life-cycle of this application. Although it is revolutionary for software products, this is taken for granted by designers of one-of-a-kind complex physical products such as spacecrafts or a new generation Aircrafts (e.g. such as Airbus 380 or Boeing 787).
 
   
 

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